White flashes after 45.0.1 Update

ASSIGNED
Assigned to

Status

()

Core
ImageLib
P3
normal
ASSIGNED
2 years ago
3 months ago

People

(Reporter: Stefan, Assigned: aosmond)

Tracking

({regression})

44 Branch
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 wontfix, firefox47 wontfix, firefox48 wontfix, firefox49+ wontfix, firefox50+ wontfix, firefox51 wontfix, firefox52 fix-optional, firefox53 fix-optional, firefox54 fix-optional)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 obsolete attachment)

(Reporter)

Description

2 years ago
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.

Comment 1

2 years ago
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
Status: UNCONFIRMED → NEW
status-firefox45: --- → affected
status-firefox48: --- → affected
Component: Untriaged → Graphics
Ever confirmed: true
Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → All
I can reproduce this.  I'm guessing it's a regression from bug 1209612, but I will verify.
Assignee: nobody → milan

Comment 3

2 years ago
ok,seems similarity with similarity bug 1259926,the flashing starts at 45

Updated

2 years ago
Duplicate of this bug: 1259926

Comment 5

2 years ago
Is there a reduced testcase?

Comment 6

2 years ago
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.)
Assignee: milan → nobody
Blocks: 1217571
Component: Graphics → ImageLib
Flags: needinfo?(seth)
Flags: needinfo?(nfroyd)
See Also: → bug 1217623
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.
Flags: needinfo?(nfroyd)
Didn't know/see the blue flashes; perhaps a different regression range is required?
Whiteboard: [gfx-noted]
Seth, Nathan, Timothy, how do we get this one moving again?
Flags: needinfo?(tnikkel)
Flags: needinfo?(nfroyd)
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.
Blocks: 1207355
Flags: needinfo?(tnikkel)
Flags: needinfo?(nfroyd)
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.
Assignee: nobody → seth
Version: unspecified → 44 Branch
(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.
Thanks.  Filed bug 1276044.
See Also: → bug 1276044

Updated

a year ago
status-firefox47: --- → affected
This is clearly an old regression and something we will not fix in 47.
status-firefox47: affected → wontfix
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.
status-firefox48: affected → wontfix
status-firefox49: --- → fix-optional
status-firefox50: --- → affected
tracking-firefox49: --- → +
tracking-firefox50: --- → +

Comment 17

a year ago
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.
Assignee: seth.bugzilla → aosmond
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.
Flags: needinfo?(seth.bugzilla)
status-firefox51: --- → affected
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.
Flags: needinfo?(aosmond)
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.
Status: NEW → ASSIGNED
Flags: needinfo?(aosmond)
Attachment #8784830 - Attachment is obsolete: true
Andrew, any news about this bug?
It is not clear to me if/how this is fixed... Especially on aurora or beta. Thanks
status-firefox45: affected → wontfix
Flags: needinfo?(aosmond)
As we're a week from RC, it's getting too late to get a fix for this in 50.  Wontfix.
status-firefox50: affected → wontfix

Comment 24

a year ago
(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.
status-firefox49: fix-optional → wontfix
status-firefox51: affected → wontfix
status-firefox52: --- → fix-optional
status-firefox53: --- → fix-optional
status-firefox54: --- → fix-optional
Flags: needinfo?(aosmond)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.