Created attachment 8432710 [details] 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.
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.
Status: UNCONFIRMED → NEW
Component: General → General
Ever confirmed: true
Product: Firefox → Core
(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
Summary: Divs fail to render → Divs fail to render (invalidation issue)
Broken by something in this push http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=3637434788e5 Matt, maybe bug 976877?
tracking-firefox30: --- → ?
tracking-firefox31: --- → ?
tracking-firefox32: --- → ?
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?
tn, are you sure about that regression range? I can reproduce the issue with 1b4b7d198185 on OSX.
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.
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.
I'm using tbpl inbound builds I download from the inbound archive.
Even with that inbound build, and a completely new profile, I can still reproduce the bug with 1b4b7d198185. Super confused at this point.
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.
In the fresh profile the regression range I get is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=87928cd21b40&tochange=a761bfc192b5
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.
Assignee: nobody → matt.woodrow
tracking-firefox30: ? → -
tracking-firefox31: ? → -
tracking-firefox32: ? → -
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: email@example.com
Created attachment 8435551 [details] [diff] [review] 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.
Attachment #8435551 - Flags: review?(tnikkel)
(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: > firstname.lastname@example.org 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.
Attachment #8435551 - Flags: review?(tnikkel) → review+
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
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
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
(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.
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.
Reproduced in Nightly 2014-06-01. Verified fixed 33.0a1 (2014-06-12), Win 7 x64
Status: RESOLVED → VERIFIED
status-firefox33: --- → verified
You need to log in before you can comment on or make changes to this bug.