1019164 - Divs fail to render (invalidation issue)

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[Doug Banks]

Attachment: a zip file with html and supporting files demonstrating the problem.

Unpack the zip file.

Open the html file in Chrome for an example of what should happen:
- bring up the html file in the browser.
- skip the in-page error dialogs that appear.
- click the 'settings' gear widget in the upper right.
- the screen darkens and a white settings dialog appears.

Now try it in Firefox.
Instead of the whole screen darkening, only the divs containing text darken.
Instead of the settings box appearing, it is invisible.  It's there, according to Firebug, but completely invisible.
If you click & drag over the space where the box should be, some divs (the ones with text) in the settings box start to appear.

If I reload, the problem persists.

If I hit the 'Apple' key, the problem immediately goes away, and will not happen again even if I reload.

If I empty the cache and reload, the problem comes back.

Comment 1

[:Gijs (he/him)]

I can reproduce an issue here, but I can't tell what's causing it. I can get things to go back to normal when I switch between the tab and another tab with the mouse, too.

Comment 2

[Doug Banks]

(In reply to :Gijs Kruitbosch from comment #1)
> I can reproduce an issue here, but I can't tell what's causing it. I can get
> things to go back to normal when I switch between the tab and another tab
> with the mouse, too.

Thanks for the quick response. And it's good to know I'm not crazy ;).

Doug

Comment 3

[Timothy Nikkel (:tnikkel)]

Regression window
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4cb766685b73&tochange=529b86b92b1d

Comment 4

[Timothy Nikkel (:tnikkel)]

Broken by something in this push
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=3637434788e5

Matt, maybe bug 976877?

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Do we have any idea how frequently these STR are likely to be hit in the wild?  We've gone to build with our final candidate of FF30, if we have to take a backout here we should figure that out right away to avoid blowing our one chance with release builds on the beta channel pre-release.  Matt can you take a look?

Comment 6

[Matt Woodrow (:mattwoodrow)]

tn, are you sure about that regression range? I can reproduce the issue with 1b4b7d198185 on OSX.

Comment 7

[Timothy Nikkel (:tnikkel)]

I just tried again several times to verify, I couldn't reproduce the problem with 1b4b7d198185, I reproduced every time with 4895aa1f1ee5. So that gives the same range. This is also on OSX.

Comment 8

[Matt Woodrow (:mattwoodrow)]

Just did a complete rebuild with 1b4b7d198185 and I can still reproduce the problem :(

OpenGL OMTC, Quartz content. Not sure what else could be a factor here.

Comment 9

[Timothy Nikkel (:tnikkel)]

I'm using tbpl inbound builds I download from the inbound archive.

Comment 10

[Timothy Nikkel (:tnikkel)]

Specifically
http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1393616068/ for 1b4b7d198185
http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1393618889/ for 4895aa1f1ee5

Comment 11

[Matt Woodrow (:mattwoodrow)]

Even with that inbound build, and a completely new profile, I can still reproduce the bug with 1b4b7d198185. Super confused at this point.

Comment 12

[Timothy Nikkel (:tnikkel)]

If I create a brand new fresh profile then I get the same results as you Matt. But I still get the same results as comment 7 when I used my "testing" profile. It's a pretty vanilla profile, I try to change as little as possible in that profile, nothing important jumps out at me as modified in about:support.

Comment 13

[Timothy Nikkel (:tnikkel)]

In the fresh profile the regression range I get is
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=87928cd21b40&tochange=a761bfc192b5

Comment 14

[Matt Woodrow (:mattwoodrow)]

Confirmed in a local build to be:

05ba5f7fa647	Matt Woodrow — Bug 811831 - Don't create layers for nsDisplayOpacity items that have an opacity of 0. r=roc


(In reply to Lukas Blakk [:lsblakk] from comment #5)
> Do we have any idea how frequently these STR are likely to be hit in the
> wild?  We've gone to build with our final candidate of FF30, if we have to
> take a backout here we should figure that out right away to avoid blowing
> our one chance with release builds on the beta channel pre-release.  Matt
> can you take a look?

It appears this has been broken since 2012, at least for the default configuration. I don't think we need to block on it.

Comment 15

[Doug Banks]

If I am reading this thread correctly, it sounds like there will not be a fix in the near future.

In the meantime, is there some kind of hacky workaround I could use (e.g. add this or that css property, add and remove this or that, overdraw with some div on top then remove, etc.)

It seems that with some degree of poking (drag & drop, twiddling css properties realtime), it gets righted, but I don't know exactly the right steps, or how I could hard-wire them as a hack around this.

Feel free to email me directly:
[e-mail]

Comment 16

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't assume the visible region is unchanged

We take the 'invalidate the entire layer' patch because the ThebesLayer previously had a mask and now doesn't. The old code assumed that the visible region would be unchanged in this case, and only invalidates the old visible region (since the transform is unchanged). This assumption was horribly wrong, and led to us not invalidating all the new areas.

I assume the original regression range came up because it had a patch where we changed simplification of invalid areas. It's possible that this simplification managed to hide bugs.

Comment 17

[Matt Woodrow (:mattwoodrow)]

(In reply to Doug Banks from comment #15)
> If I am reading this thread correctly, it sounds like there will not be a
> fix in the near future.
> 
> In the meantime, is there some kind of hacky workaround I could use (e.g.
> add this or that css property, add and remove this or that, overdraw with
> some div on top then remove, etc.)
> 
> It seems that with some degree of poking (drag & drop, twiddling css
> properties realtime), it gets righted, but I don't know exactly the right
> steps, or how I could hard-wire them as a hack around this.
> 
> Feel free to email me directly:
> [e-mail]

It's a pretty crazy combinations of factors that come together to cause this issue, so it's hard to say exactly what you need to do to fix it. It's a combination of rounded corners within a transform and a whole lot of luck.

The regression range showed that not drawing content within an opacity:0 subtree made this show up, so you could fake that by using opacity:0.001 instead. Any sort of restructuring of the page content would probably avoid it too.

It's a fairly simple fix anyway, so hopefully we can fix this for 31.

Comment 18

[Doug Banks]

Thanks for the details.

I tried switching opacity as suggested and removing some rounded corners.  It fixed some cases and not others so I think I am just going to wait for the fix to go live.

Doug

Comment 19

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3c08e615c17a

Comment 20

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/3c08e615c17a

Comment 21

[Doug Banks]

I just updated to Firefox 30 and I can still repro the bug.

So I am not sure what 'Fixed' means in this latest update.  Fixed in some future release?  

At what point should I expect to see the fix reflected in my instance of Firefox?

Thanks
Doug

Comment 22

[:Gijs (he/him)]

(In reply to Doug Banks from comment #21)
> I just updated to Firefox 30 and I can still repro the bug.
> 
> So I am not sure what 'Fixed' means in this latest update.  Fixed in some
> future release?  
> 
> At what point should I expect to see the fix reflected in my instance of
> Firefox?
> 
> Thanks
> Doug

The fix will be in Firefox 33 for sure (you can try using the nightly channel at http://nightly.mozilla.org/ ). Depending on whether Matt and/or tn think it safe to do so, perhaps it will be applied to Firefox 32 (on aurora) or 31 (now in beta) as well.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Doug, see the "Target Milestone" field.  That indicates which development version the fix was checked into.  https://wiki.mozilla.org/RapidRelease/Calendar has the corresponding dates; in this case Firefox 33 would be released on 2014-10-14.

Sometimes fixes get backported to feature-frozen branches, but per comment 14 that's not planned for this one.

Comment 24

[Paul Silaghi, QA [:pauly]]

Reproduced in Nightly 2014-06-01.
Verified fixed 33.0a1 (2014-06-12), Win 7 x64