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

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Laisvunas]

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

Comment 1

[José Jeria]

Attachment: Testcase

Comment 2

[José Jeria]

Seeing this as well: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b5pre) Gecko/2008030904 Minefield/3.0b5pre

Comment 3

[Ria Klaassen (not reading all bugmail)]

Tested with Windows XP, I see the bug also in old builds so this is not a recent regression.

Comment 4

[Laisvunas]

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/

Comment 5

[Laisvunas]

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.  

Comment 6

[Steve England [:stevee]]

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+

Comment 7

[Laisvunas]

Attachment: Attachtent for comment #4

Comment 8

[Laisvunas]

Attachment: First test case for comment #5

Comment 9

[Laisvunas]

Attachment: Second test case for comment #5

Comment 10

[Laisvunas]

@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.

Comment 11

[j.j.]

Attachment: 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")

Comment 12

[j.j.]

Related with/ duplicate of bug 302377?

Comment 13

[Laisvunas]

@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.

Comment 14

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

I can reproduce the bug with the reduced testcase ( https://bugzilla.mozilla.org/attachment.cgi?id=312665 ) also with visibility:hidden

Comment 15

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Mh nothing, ignore my previous comment.

Comment 17

[Zack Weinberg (:zwol)]

Attachment: alternate test case from 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.

Comment 18

[Zack Weinberg (:zwol)]

Attachment: modified alternate test case, working around bug

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.)

Comment 19

[j.j.]

(In reply to comment #18)
> which wraps the #main div and has overflow:auto.

Bug 349375 seems related.

Comment 20

[Zack Weinberg (:zwol)]

(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).

Comment 21

[P T Withington]

Attachment: Simplest test case I can create

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.

Comment 22

[Zack Weinberg (:zwol)]

The "compositor phase 1" patches (https://build.mozilla.org/tryserver-builds/[e-mail]-try-f9bf8fa4178/) seem to have fixed the test cases in this bug.

Comment 23

[j.j.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090722 Minefield/3.6a1pre

Yes, it's fixed.

Comment 24

[Sander]

This was fixed by bug 352093.