User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: I had a page with one outer div which has height specified and overflow: auto/scroll. There were two child divs both with overflow: hidden/auto and border radius each with content to cause the outer div to scroll. Actual results: When scrolling outer div and reaching the top of the lower child div the top div disappears. If nothing is done for a few seconds the top div will re-draw as normal. Expected results: The top element should not disappear when scrolling to the lower element.

Threre are 2 regression #1 regression: The top element disappear (exposed in Firefox15) #2 regression: The top element vertical border is drawn like a gradient (in Firefox16 and later) *after about 2 sec, the element repainted properly. #1 Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/2db9df42823d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120503142649 Bad as #1: http://hg.mozilla.org/mozilla-central/rev/e1a40027dc7e Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120504014349 #1Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2db9df42823d&tochange=e1a40027dc7e #1 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/c608de1b6a53 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120502221102 Bad as #1: http://hg.mozilla.org/integration/mozilla-inbound/rev/77bf50b33a05 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120502223302 #1Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c608de1b6a53&tochange=77bf50b33a05 #2 Regression window(m-c) Bad as #1: http://hg.mozilla.org/mozilla-central/rev/5c07a681371d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120625121718 Bad as #2: http://hg.mozilla.org/mozilla-central/rev/74e503bfa575 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120626015518 #2Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c07a681371d&tochange=74e503bfa575 #2 Regression window(m-i) Bad as #1: http://hg.mozilla.org/integration/mozilla-inbound/rev/1d8cb944f7a9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120625193218 Bad as #2: http://hg.mozilla.org/integration/mozilla-inbound/rev/9a1934aec83c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120625194619 #2Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1d8cb944f7a9&tochange=9a1934aec83c

Confirmed on nightly with basic layers and D3D10 layers (slightly different manifestation of the bug on the latter). This is almost certainly a mask layers problem, I don't have any more insight than that atm.

Given that the two divs have the same size and border radius, they should share a mask layer, which will affect this, thus referencing bug 757347.

(In reply to Alice0775 White from comment #1) > Threre are 2 regression > #1 regression: The top element disappear (exposed in Firefox15) > #2 regression: The top element vertical border is drawn like a gradient (in > Firefox16 and later) > > *after about 2 sec, the element repainted properly. The gradient effect is probably due to the shader doing interpolation where it shouldn't be doing it, which suggests the mask texture is somehow messed up. I see this only with accelerated layers (no shaders = no interpolation on basic layers). The proper repaint after ~2 sec, is the rendering switching to use inactive layers where mask layers are not used, i.e., the bug only manifests with active layers, which further suggests the problem is with mask layers.

Should we consider splitting this out into 2 separate bugs?

(In reply to Alex Keybl [:akeybl] from comment #5) > Should we consider splitting this out into 2 separate bugs? No, I think there is only one bug - doubling up mask layers causes rendering problems.

This appears to be a regression, so tracking it.

Comment on attachment 657149 [details] [diff] [review] fix Review of attachment 657149 [details] [diff] [review]: ----------------------------------------------------------------- We shouldn't be storing the clip count in Layer. The clip count is private to FrameLayerBuilder.

Comment on attachment 657176 [details] [diff] [review] fix with clip count in user data Review of attachment 657176 [details] [diff] [review]: ----------------------------------------------------------------- r+ with InvalidateAll removed ::: gfx/layers/Layers.h @@ +1057,5 @@ > + > + virtual void InvalidateAll() > + { > + mValidRegion.SetEmpty(); > + } If you're going to add this, you should change the current callers of InvalidateRegion who are invalidating-all to call this. But personally I think you should probably just call InvalidateRegion with GetValidRegion() or even GetValidRegion().GetBounds(). ::: layout/base/FrameLayerBuilder.cpp @@ +501,5 @@ > + * Record the number of clips in the Thebes layer's mask layer. > + * Should not be reset when the layer is recycled since it is used to track > + * changes in the use of mask layers. > + */ > + size_t mMaskClipCount; uint32_t

Is my bug similar or different? https://bugzilla.mozilla.org/show_bug.cgi?id=786745

Try push: https://tbpl.mozilla.org/?tree=Try&rev=11825cd2645a

addressed roc's comments, carrying r+

Please get this patch onto whatever branches are affected.

Push backed out for burning the tree: https://hg.mozilla.org/integration/mozilla-inbound/rev/a4fb15293efc

Try again: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=f88af5665cf2

and out again: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=f88af5665cf2

Tryserver please...

Does this need branch nominations

(In reply to Boris Zbarsky (:bz) from comment #24) > Does this need branch nominations Yes please, when comfortable with the testing on Nightly.

I missed this the first time round.

Reopening for the one line fix patch, I don't want to open another bug because we want to push this to Aurora etc. soon and I don't want things to get lost.

If low risk, please nominate for Aurora and Beta at the same time some time this week.

[Approval Request Comment] Bug caused by (feature/regressing bug #): GPU-clipping-rounded User impact if declined: bug in rendering as described above Testing completed (on m-c, etc.): been on m-c for 10 days, one bug fixed (in second patch) Risk to taking this patch (and alternatives if risky): low String or UUID changes made by this patch: none

Comment on attachment 657784 [details] [diff] [review] fix [Triage Comment] Low risk fix for a FF15 regression, and we'll still have the opportunity to back out if we find new regressions in FF16 beta. Approving for branches.

(please land today or early tomorrow to make it into beta 4)

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 beta 4 Verified the fix on the above build.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 beta 1 Verified the fix on the above build. Scroll is working smoothly to lower element while upper element is not disappearing.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Verified on 18b1 as well. Scrolling is smooth from one element to another.

I think I have the same issue on Firefox 29 on Linux. Regression?

File a new bug please.