Closed Bug 421866 Opened 12 years ago Closed 10 years ago

invisible fixed elements with overflow:auto or overflow:scroll flicker when scrolling

Categories

(Core :: Layout, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: saugos, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(8 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4

A div element, which has CSS property "visibility" set to "hidden" and z-index set to "101", when "visibility" is changed to "visible" and then again changed to "hidden" causes major flickering of the page in place where div element was shown.

Reproducible: Always

Steps to Reproduce:
1. Open test case page at http://www.classicsunlocked.net/index.php/firefox_bug/index/
2. Find "Click here" at the top of the page; click it; a div (dropdown menu) will be shown
3. Find "Click here again" at the top of the page; click it; a div (dropdown menu) will be hidden; 
4. Now scroll the page; you will see major page flickering in place where div was shown
Actual Results:  
Major page flickering in place where div was shown

Expected Results:  
There should not be any flickering of the page
Attached file Testcase
Component: General → Layout
Keywords: testcase
OS: Windows Vista → All
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Seeing this as well: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b5pre) Gecko/2008030904 Minefield/3.0b5pre
Tested with Windows XP, I see the bug also in old builds so this is not a recent regression.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just noticed that the same effect of flickering of the page can be achieved by changing CSS display property of the div element from negative to positive and back again without introducing any value of visibility property.

The testcase is here:

http://www.classicsunlocked.net/index.php/firefox_bug/display_negative_to_positive_and_back/
Some new findings:

1) this bug has some relation with CSS overflow property. Two test case pages support this.

The first test case page is at

http://www.classicsunlocked.net/index.php/firefox_bug/visibility_hidden_to_visible_and_back_overflow

There are two divs, #menu1 and #menu2. #menu2 has overflow property value set to "scroll", #menu1 has no overflow property declared. By clicking buttons on  top of the page you can set visibility property of #menu1 and #menu2 from "hidden" to "visible" and back again. Only that div which has overflow property value set to "scroll" (#menu2) will cause page flickering.  

Tthe second test case page is at

http://www.classicsunlocked.net/index.php/firefox_bug/zindex_negative_to_positive_and_back_overflow

There are two divs, #menu1 and #menu2. #menu2 has overflow property value set to "scroll", #menu1 has no overflow property declared. By clicking buttons on  top of the page you can set z-index property of #menu1 and #menu2 from "-101" to "101" and back again. Only that div which has overflow property value set to "scroll" (#menu2) will cause page flickering.

2) Second test case page shows that there is recent regression.

If you will load second test case page in Firefox 2.00.12 you will see that changing z-index value of #menu1 and #menu2 neither of those divs causes flickering of the page. But flickering of the page can be achieved by changing z-index value of #menu2 in Firefox 3 b4.  
I'm seeing this as far back as Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050326 Firefox/1.0+
@stevee If you call by "this" flickering of the page, then yes, it can be found in quite old builds of Firefox. But the point of comment #5 and its second testcase was that flickering of the page caused by changing z-index value can be observed in Firefox 3 b4 but not in Firefox 2.0.0.12.
Attached file reduced testcase
This bug is triggered just by "overflow:auto" and "overflow:scroll"
Is there a bug for this filed?

Reporter, please check and change summary if you agree (perhaps something like "unvisible fixed elements with overflow:auto or overflow:scroll flicker when scrolling")
Related with/ duplicate of bug 302377?
Depends on: 302377
@j.j. I agree with your explanation of the reduced testcase and formulation of the summary. Only I think that it should be somewhere explicitly stated what is meant in the new summary by "invisible elements" -- they are 
1) fixed divs with visibility: hidden
2) fixed divs which have smaller z-index number than some other elements.
Summary: div, which has visibility:hidden when made visible and hidden again causes flickering of the page → unvisible fixed elements with overflow:auto or overflow:scroll flicker when scrolling
I can reproduce the bug with the reduced testcase ( https://bugzilla.mozilla.org/attachment.cgi?id=312665 ) also with visibility:hidden
Mh nothing, ignore my previous comment.
Duplicate of this bug: 461292
I'm bringing over the test case from bug 421866 because I've discovered a workaround for at least some situations.  This attachment shows the bug when you click on the left-hand orange bar.
This attachment should render identically to the one I just added, but will not show flickering.  The difference is just the addition of the #forcewidget div, which wraps the #main div and has overflow:auto.

What's going on in all these test cases is that anything styled with overflow:auto or overflow:scroll has a "widget" in our internal data structures, and therefore it gets a nested windowing-system-level window.  When the content of the widget-ful box is invisible, the window is still on screen -- it's just filled with whatever is visible instead of that box.  But then when we move that window, the windowing system helpfully moves all its contents too, whether or not they ought to have moved.

The workaround puts another box with a widget around the overflow:hidden box that is supposed to be clipping the moving boxes (one of which has a widget).  That makes the windowing system do the clipping for us.  I'm not sure this workaround is adaptable to all cases, but it oughta be useful in at least some cases.

(NOTE: The animation code in these testcases only works in Firefox, and should probably be ignored in favor of jQuery or some other animation library written by someone who knows what the hell they're doing.)
(In reply to comment #18)
> which wraps the #main div and has overflow:auto.

Bug 349375 seems related.
(In reply to comment #19)
> 
> Bug 349375 seems related.

Yep, that's another case where there are windowing-system-level nested windows inside the content area.  Long-term plan is to get rid of them, but it may not be possible to do so for all cases -- in particular, for <object>/<embed> third-party plugins expect a window (except on Mac, IIRC).
This is the simplest possible test case I can construct that shows _horrible_ display errors when an element with `overflow: scroll` is clipped by an element with `overflow: hidden`.  Drag your mouse around and you will see that the clipped div is (incorrectly) intersecting with the underlying text.

Seems like a mask is missing somewhere in implementing the drawing.

Note: This display error is _not_ seen on the Mac.

Note: Setting the overflow of the inner div to hidden makes the display errors go away.  Even though the inner div is still larger than the outer (clipping) div.  So, it is something about adding scroll to the inner div that triggers the display error.
Summary: unvisible fixed elements with overflow:auto or overflow:scroll flicker when scrolling → invisible fixed elements with overflow:auto or overflow:scroll flicker when scrolling
Attachment #370246 - Attachment mime type: text/plain → text/html
The "compositor phase 1" patches (https://build.mozilla.org/tryserver-builds/rocallahan@mozilla.com-try-f9bf8fa4178/) seem to have fixed the test cases in this bug.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090722 Minefield/3.6a1pre

Yes, it's fixed.
This was fixed by bug 352093.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.