stickyToolbar & overflowed scrollableContainer not working as intended

[Mboulianne]

Expected behavior.

The toolbar should always stick if a scrollableContainer is specified.

Actual behavior.

When there the page and the scrollableContainer have a scrollbar, the toolbar won't stick as it should if the page scrollbar is at its top-most or bottom-most position.

Steps to reproduce the problem.

1- Make sure page scrollbar is at its topmost position. 2- Scroll the scrollbar in the scrollcontainer 3- Toolbar didn't stick :( 4- Do the same with scrollbar at its bottom-most position. 5- Toolbar didn't stick. 6- Put the page scrollbar somwhere between its top-most position and its bottom-most position. 7- Scroll the scrollbar in the scroll container. 8 - Toolbar did stick!!!

See jsfiddle https://jsfiddle.net/ppyLhnqt/65/

To make sure everything is clear I'll put some screenshot 1- Page scrollbar is at its top-most position. The toolbar isn't visible anymore. It didn't stick.

2- Page scrollbar is at its bottom-most position The toolbar isn't visible anymore. It didn't stick.

3- Page scrollbar is somwhere in the middle The toolbar is visible. It did stick.

OS.

Windows 10

Browser.

Firefox 61.0.1 (64-bit) Chrome 67.0.3396.99 (Official Build) (64-bit) Edge Microsoft Edge 42.17134.1.0 / Microsoft EdgeHTML 17.17134

[Mboulianne]

@gabra20

[stefanneculai]

That is because the height of the view is smaller than 500px and the editor is designed to keep the toolbar at the top when it exceeds the scrollable container. If you would set it to a value smaller than the height of the view all is good: https://jsfiddle.net/froala/ppyLhnqt/70/.

[Mboulianne]

new jsfiddle: https://jsfiddle.net/ppyLhnqt/103/

how do you explain that I'm getting that now?

The toolbar appears below my scrollContainer. I've hadded content before and after my container to represent my real use case

Also If I only scroll the page (not the scroll container) the toolbar don't stick at all.

It looks pretty buggy to me.

@stefanneculai

[stefanneculai]

Thanks for the further details. Indeed, it appears to be a problem. I updated it accordingly.

[Mboulianne]

I think I found a similar bug: My editors are contained in a fixed container that lies at the end / bottom of the body tag with top: 0; bottom: 0; left: 0; right: 0; (it take the whole viewport). If the body has enough content to make a scrollbar appear and if that scrollbar is scrolled, editor toolbar won't stick correctly

jsFiddle: https://jsfiddle.net/184f7zpd/63/

Body has no scrollbar => (everything is ok)

Body has a scrollbar but the user haven't scrolled yet => (everything is ok)

Body has a scrollbar and the user have scrolled => Buggy!

@stefanneculai

I think toolbarSticky should work correctly even if the editors are in a fixed container no?

[stefanneculai]

Related to https://github.com/froala/wysiwyg-editor/issues/2981.

[Mboulianne]

@stefanneculai are you sure these are related? My bug is about the toolbar that isn't positionned correctly. However, I opened a similar bug https://github.com/froala/wysiwyg-editor/issues/3038 ?

[stefanneculai]

Yes, they are related because they use the same logic for positioning inside a scrollableContainer.

[Mboulianne]

@stefanneculai ok we'll see once this get resolved then. It's not a big deal for us since we found a workaround.

[loocaworld]

Is this bug fixed?

[JessieCowie23]

Is a fix for this still in the works? I'm having the same issue in 3.0.6

[spankyed]

Such a simple issue faced by many, yet 3 years later still no accepted solution.

[brucetp]

This is really a frustrating bug, so I decided to work around it myself. I'm using Vue but the concept still works in plain JS. "ActivityPage" is my scrollable DIV.

1. Attach to the scroll event listener on the DIV Tag when the page loads
2. Wait for scrolling, then disable the listener (better performance than constantly checking)
3. Check to see how far we've scrolled down the page (my editor is approx 30% down the page, yours will very)
4. If scrolling is less than 30%, remove the 'sticky' class from the froala toolbar, otherwise add the class because we have scrolled past it
5. remove the listener when navigating away from the page

[The code block isn't formatting this correctly so that why part of it is in plan text]

` mounted () { document.getElementById('ActivityPage').addEventListener('scroll', this.handleScroll, { passive: true }) }

destroyed () { document.getElementById('ActivityPage').removeEventListener('scroll', this.handleScroll) }

handleScroll (event) {
  document.getElementById('ActivityPage').removeEventListener('scroll', this.handleScroll)
  console.log('stop listening for performance reasons')
  setTimeout(() => {
    document.getElementById('ActivityPage').addEventListener('scroll', this.handleScroll, { passive: true })
    console.log('start listening')
    this.handleStickyToolbar()
  }, 300)
}

handleStickyToolbar () {
  var element = document.getElementById('ActivityPage')
  var b = element.scrollHeight - window.innerHeight
  var c = element.scrollTop / b
  var x = document.getElementsByClassName('fr-toolbar')
  if (c < 0.3) {
    x[0].classList.remove('fr-sticky-on')
  } else {
    x[0].classList.add('fr-sticky-on')
  }
}`

[loocaworld]

on every updates, I do this modification.

1. find t.css("top", S.helpers.getPX(t.data("top")) + i) # S could be L or something. That "i" is problem.
2. modify this to t.css("top", S.helpers.getPX(t.data("top")) + (S.$sc.css("position") === "fixed" ? S.$sc.position().top : i))

[nateleavitt]

Also, having a similar problem.

@loocaworld - can you reference where in the code you make that change?

[loocaworld]

@nateleavitt Variables are always changed on every big updates. So if you are using froala editor version 4.0.10,

1. open file "js/froala_editor.min.js"
2. find this L.helpers.getPX(t.data("top")) + i
3. change like this L.helpers.getPX(t.data("top")) + (L.$sc.css("position") === "fixed" ? L.$sc.position().top : i)

[OdaNeo]

I have same problem, I add this css in global and fix this problem version: "react-froala-wysiwyg": "3.0.6",

.fr-toolbar.fr-top { position: sticky !important; z-index: 2 !important; }

[loocaworld]

This problem is caused because the editor is in a scroll-downed fixed container. If the background parent has a little offset from the top, inner elements in the fixed container's offset().top contains parent's offset too. So, if $sc(=scrollable container) is in a fixed container or is a fixed container, you have to consider that.

in "js/froala_editor.min.js", find below code t.css("top", L.helpers.getPX(t.data("top")) + i) change that code line to t.css("top", L.helpers.getPX(t.data("top")) + (L.$sc.parents().filter(function(){return $(this).css('position') == 'fixed';}).length ? L.$sc.position().top : i))

[dplarina]

I have a similar problem. The scrollable container is not fixed but it sounds like the same issue.

If the scrollable container is offset from the top of the viewport at all, it will offset the toolbar down by that amount. I created a minimal repro here with the latest version (4.0.19) https://jsfiddle.net/2spd3tha/2/

The body adds 8px. The wrapper element adds 16px, and the header adds 64px, so the scrollable container is pushed down for a total of 8px + 16px + 64px = 88px. Since the offsetTop of the scrollable container is 88px, it sets the top of the toolbar to 88px, despite me setting the toolbarStickyOffset to 0.