Problem:
We’ve recently come across an interesting issue with implementing floating pop-up windows (such as notes, etc) on Mac OSX/Firefox/Mozilla/Gecko browsers.
The issue is with displaying floating content that “floats” above areas with scrollbars.
Firefox and Mozilla/Gecko browsers on Macintosh OSX operating systems suffer from a scrollbar rendering bug that causes scrollbars on DIV elements (DIV CSS ‘overflow:scroll;‘ or ‘overflow:auto;‘ with overflowing content) to be rendered outside the layer ordering in the DOM hierarchy. This is a known and documented Mozilla bug having to do with their use of the OS UI chrome on the Mac and the inability to control when the scrollbars are rendered (see [https://bugzilla.mozilla.org/show_bug.cgi?id=187435] for details).
The upshot of this is that if you try to display content ABOVE such a scrollbar, or hide an element containing such scrollbars, these scrollbars remain visible - creating a very noticeable display bug. The Mozilla bug report doesn’t offer a good solution for how the problem presents in the Krugle application (although comments put together get you almost entirely there), so we recently decided to see if we could tackle the issue. The following documents our solution to this issue.
In “Example 1″ we can see what happens when the floating window is placed above a scrollbar, the underlying scrollbar is visible and appears to be above the floating window content.
Example 1 / Problem 1: Underlying Scrollbars Bleedthrough:

The issue doesn’t stop at just displaying the content. When content is hidden (see “Example 2″) the remnants of the floating window still linger, such as masked underlying contents and left-over scrollbars from the floating content.
Example 2 / Problem 2: Hidden Scrollbars Visible (after the “Close” button was clicked):

As mentioned in Mozilla’s bug report (https://bugzilla.mozilla.org/show_bug.cgi?id=187435), this issue only occurs on the Mac and has to do with draw/re-draw order of operations (see comments 38 and 39 for more info).
So what now? How do we get around this (at least until this issue is resolved)?
Well, there are several approaches to solving this, almost all involve setting the overflow attribute of the <div> tag to auto (and in some cases setting it back). But first, let’s start by reproducing this.
Reproducing the problem:
I have created two test pages that demonstrate both the problem and the solution (page 1, page 2). Naturally, you’ll need to be on Mac OSX with Firefox/Mozilla/Gecko browser to see the problem.
Test case (both pages):
Click on “Example 1″ button to see the problem
Click “Close” button inside the floating pop-up window to close it
Click on “Example 2″ button to see the problem partially solved (notice the borders)
Click “Close” button inside the floating pop-up window to close it, this closes/hides the pop-up window, however now we see problem demonstrated in the “Problem 2 Hidden Scrollbars Visible” (above). Click “Reload” button to reset the page
Click on “Example 2″ button (again) to see the problem partially solved (notice the borders)
Click “Close (Fixed)” button inside the floating pop-up window to close it, now we have a clean close with no artifacts remaining
Click on “Example 3″ button to see the problem fully solved
Click “Close” button inside the floating pop-up window to close it, this closes/hides the pop-up window, however now we see problem demonstrated in the “Problem 2 Hidden Scrollbars Visible” (above). Click “Reload” button to reset the page
Click on “Example 3″ button (again) to see the problem partially solved (notice the borders)
Click “Close (Fixed)” button inside the floating pop-up window to close it, now we have a clean close with no artifacts remaining
Solution:
Both pages rely on setting the overflow attribute of the <div> tag to auto. Both work in all the major browsers.
Overlap test 1:
In this example we employ a technique that is a bit more costly than some of the others, both in terms of resources used and operations performed, but it causes less problems if you have multi-tier popups/divs (for example a pop-up that opens up on top of another).
Technique for solving “Problem 1″ (Underlying Scrollbars Bleedthrough)::
Create a child <div> and with overflow set to auto and populate it’s innerHTML with what previously was windows innerHTML
function showWindowFixed(id){ var win = document.getElementById(id); if (!document.getElementById(id + "_child")) { win.innerHTML = "<div style='overflow:auto;' id='" + id + "_child'>" + win.innerHTML + "</div>"; } win.style.visibility = "visible"; win.style.display = "inline";}Technique for solving “Problem 2″ (Hidden Scrollbars Visible):
Change display of the parent div to none (don’t forget to set it back to inline or block when showing the window again).
function hideWindowFixed(id){ var win = document.getElementById(id); win.style.visibility = "hidden"; win.style.display = "none";}Overlap test 2:
The technique used here seems a bit more efficient, both in terms of amount of code and operations used. However this technique, sometimes, causes some residual problems with re-drawing of the scrollbars of the underlying page if multiple tiers/layers are in use.
Technique for solving “Problem 1″ (Underlying Scrollbars Bleedthrough)::
Before displaying the window set the style.overflow to auto
function showWindowFixed(id){ var win = document.getElementById(id); win.style.overflow = "auto"; win.style.visibility = "visible";}Technique for solving “Problem 2″ (Hidden Scrollbars Visible):
Before hiding the window set the style.overflow to hidden. This removes the scrollbars from the element/window.
function hideWindowFixed(id){ var win = document.getElementById(id); win.style.overflow = "hidden"; win.style.visibility = "hidden";}Conclusion:
This solution is not perfect, there are still some side-effects, for example if a pop-up is open and is on top of an underlying scroollbar, the underlying scrollbars will re-appear/bleed through on the next redraw (for example if one switches tabs/windows back and forth). One thought was to play with window.onfocus event and flip the style.overlow attribute from hidden to auto (with 1 millisecond delay). The problem with this approach is that onfocus event propagates to window’s child elements and causes the function to fire more often than desired, the visual side-effect of this is that underlying scrollbars flicker through every time focus changes within the window (for example clicking on links, buttons or within the document).