User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160315153207 Steps to reproduce: Clicking thorough the NAV menu on my website (http://www.oxfordstrat.com/about/) several times in succession. Actual results: When clicking thorough the NAV menu on my website (http://www.oxfordstrat.com/about/), after several clicks, the blue picture on the top makes a short white flash during transition from one page to another. Expected results: The above flashes are not observed in IE or Chrome. I did also tests on my old XP where was Firefox 43 (all was ok), updated to 44.0.2 (still all was fine), once updated to Firefox 45.0.1 the white flash is there.
Hi Stefan, I can reproduce this in Mac OS X 10.10 with FF 45 and FF Nightly 48.0a1 but I can't reproduce it with FF 43, based on that this is a regression. I used mozregression and here are the results: Last good revision: 0eaf345983b3afc2b426e25a3be93ebf0d93e6c1 First bad revision: faf815a0fa9b052a38bce00c0c2aa1e2c9610936 Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0eaf345983b3afc2b426e25a3be93ebf0d93e6c1&tochange=faf815a0fa9b052a38bce00c0c2aa1e2c9610936 Last good revision: a4ce197dfecef223c0e9f84ab3bc1fc27c5cf0cb First bad revision: bf864106469cefbea0cb1f9931d35a9b23350c73 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a4ce197dfecef223c0e9f84ab3bc1fc27c5cf0cb&tochange=bf864106469cefbea0cb1f9931d35a9b23350c73
I can reproduce this. I'm guessing it's a regression from bug 1209612, but I will verify.
ok，seems similarity with similarity bug 1259926，the flashing starts at 45
Is there a reduced testcase?
think this based on same bug 1 ctr+shift+b，make sure there some boomarks in the right side（the more bookmarks，the stronger flashing） 2 resize the bookmarkmanager by mouse through draging its bottom ，up and down 。 3 can put the manager front a white color background so that can make it observability
This is a fallout from bug 1217571 (image caching change.)
Running the reported URL in a debug build and clicking around spams a number of: [Parent 3866] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0xC1F30001: file /home/froydnj/src/gecko-dev.git/netwerk/cache2/CacheFileMetadata.cpp, line 308 warnings on the console. This is NS_ERROR_NOT_INITIALIZED, coming from: http://dxr.mozilla.org/mozilla-central/source/netwerk/cache2/CacheFileIOManager.cpp#1933 but none of the things we're failing to write look anything like images; they're all Google Analytics things. I'm not really sure what's going wrong, though I can confirm that if I revert the patch from bug 1217571, there's no white flashes (there are blue ones, though). I kinda feel like bug 1217571 is just the canary in the coal mine, and the real regressing bug happened someplace else, as we didn't have proper cache interfaces in imglib until bug 1217571 was fixed.
Didn't know/see the blue flashes; perhaps a different regression range is required?
Seth, Nathan, Timothy, how do we get this one moving again?
I noticed that this also regressed on non-e10s which was interesting since bug 1217571 should have only affected e10s. I got https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=99a4fb4ba5c1ee96ac745c6ad11894bf0537f73a&tochange=2e19045ba652ca2a5a5fc0e20d6f95293acfa32d So bug 1207355, which has caused a heap of other regressions. Bug 1207355 removed some requestDecode calls for CSS background images that we still need. This means that we draw the images when they aren't decoded on this page. The website has a background color behind the images that has the same general color as the images, so we should see this as the images coming into view. But instead we see it as a jarring flash of white due to bug 1225750. Now with e10s, and before bug 1217571 we always fetched a new image. When a new image says it is decoded, it actually have a decoded copy of the image around (because there hasn't yet been time to discard it). When e10s was fixed to re-use images from the image cache then we start using images that have been discarded but claim to be decoded, hence making e10s susceptible to bug 1225750. There are 3 actions we should take: 1) fix the regression from bug 1207355 where we don't requestDecode css background images 2) finish bug 1225750 3) why are these images getting discarded so quickly? My testing consisted of opening on the test page only and clicking with an interval of about 1 second. Firefox was not using much memory, there was no reason to throw away an image we had just used a second ago.
Bug 1207355 also makes more sense from the timing point of view, as bug 1217571 actually got uplifted to 44, and comment 0 clears 44 of any wrong doing. Do we have a bug opened for #3 in the previous comment? I agree this sounds like something that we should find out.
(In reply to Milan Sreckovic [:milan] from comment #12) > Do we have a bug opened for #3 in the previous comment? I agree this sounds > like something that we should find out. Not that I'm aware of.
This is clearly an old regression and something we will not fix in 47.
Seth, tnikkel, any progress here? Going by comment 11 I'm going to mark this as wontfix for 48. I would still take a fix in 49 aurora or early beta.
seems nightly has fixed it？ at least，duplicates:1259926 https://bugzilla.mozilla.org/show_bug.cgi?id=1259926#c9 is fixed
I can still reproduce the original workflow in nightly 2016/08/08.
Created attachment 8784830 [details] [diff] [review] Start fully decoding CSS images after we get the size if in a visible frame, v1 try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3aaa20d53a8d This patch will cause us to decode an image loaded from CSS as soon as we get the size and one of its frames are visible. This does tend to trigger the full decode sooner than at present, but that isn't enough to eliminate the flickering. But since imagelib always does a metadata decode first, this may be the best we can do at present, aside from fixing bug 1225750.
Hi Andrew, we reviewed this in the platform meeting today. There is a patch here, does this need to be r+'d and landed to m-c? I'd be happy to uplift a patch to Beta50, the sooner the better.
I don't see the white flash on nightly anymore. While the image gets redecoded, it appears the CSS background is coming in to hide it now. The image cache only gets cleared because the page itself is purged from the back history (requires cycling between 3 or more pages), thus the document requests a discard of all images.
Andrew, any news about this bug? It is not clear to me if/how this is fixed... Especially on aurora or beta. Thanks
As we're a week from RC, it's getting too late to get a fix for this in 50. Wontfix.
(In reply to Julien Cristau [:jcristau] from comment #23) > As we're a week from RC, it's getting too late to get a fix for this in 50. > Wontfix. actually,it can not be reproduced on 50beta10 already.
The annoying white flashes are gone thanks to bug 1260324. They are now just flashes of the background color behind the image, which is approximately the same color as the images so it's much much less annoying.