Closed
Bug 1091229
Opened 10 years ago
Closed 10 years ago
When nsBulletFrame loads images, it should block onload
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: seth, Assigned: seth)
References
Details
Attachments
(1 file, 3 obsolete files)
12.70 KB,
patch
|
Details | Diff | Splinter Review |
nsBulletFrame needs to block onload when it loads images. Not doing so makes any test that uses list items a potential intermittent orange (see bug 850197 for an example that has plagued us for years). Bug 1089046 makes changes to the timing of ImageLib notifications that make such intermittent oranges much more likely, as well, so now is the time to take this on.
Assignee | ||
Comment 1•10 years ago
|
||
In the long term what we really want to do is make nsBulletFrame use ImageLoader for loading; I've filed bug 1091236 as a followup.
Assignee | ||
Comment 2•10 years ago
|
||
I suspect with this fixed, we can enable the |list-simple-1.html| test on B2G. Making this block bug 773482 speculatively. (I'll remove the block if that turns out not to be true. I haven't tested this theory on try yet.)
Blocks: b2g-reftest
Assignee | ||
Comment 3•10 years ago
|
||
Here's the patch. It's pretty simple, though it got a bit more verbose just because I wanted to make this a zero-overhead patch but I also wanted to assert for double blocks/unblocks, which meant I needed to pack the new boolean flag I added, which meant I needed some additional code to avoid taking the address of a bitfield. I think things came out pretty clean, though.
I verified that the use of GetComposedDoc() in GetOurCurrentDoc() is correct in person with wchen.
Try job here:
https://tbpl.mozilla.org/?tree=Try&rev=43e898114422
Attachment #8513838 -
Flags: review?(tnikkel)
Comment 4•10 years ago
|
||
Comment on attachment 8513838 [details] [diff] [review]
Make nsBulletFrame block onload when it loads images
>@@ -686,24 +666,76 @@ nsBulletFrame::Notify(imgIRequest *aRequ
>+ if (aType == imgINotificationObserver::LOAD_COMPLETE) {
>+ // Unconditionally start decoding for now.
>+ // XXX(seth): We eventually want to decide whether to do this based on
>+ // visibility. We should get that for free from bug 1091236.
>+ if (aRequest == mImageRequest) {
>+ mImageRequest->StartDecoding();
> }
> }
I think RequestDecode would be better here, do you agree?
Attachment #8513838 -
Flags: review?(tnikkel) → review+
Assignee | ||
Comment 5•10 years ago
|
||
(In reply to Timothy Nikkel (:tn) from comment #4)
> I think RequestDecode would be better here, do you agree?
Thanks for the quick review! I think you're right that RequestDecode would be better. I had just imitated what nsImageLoadingContent did, but actually I wonder if it might be better off with RequestDecode too.
I'm a bit puzzled at these try results, though. How could this patch have caused these failures?! I've pushed a couple of variants to investigate.
Comment 6•10 years ago
|
||
(In reply to Seth Fowler [:seth] from comment #5)
> (In reply to Timothy Nikkel (:tn) from comment #4)
> > I think RequestDecode would be better here, do you agree?
>
> Thanks for the quick review! I think you're right that RequestDecode would
> be better. I had just imitated what nsImageLoadingContent did, but actually
> I wonder if it might be better off with RequestDecode too.
I've wanted to change that too, but haven't gotten to it.
> I'm a bit puzzled at these try results, though. How could this patch have
> caused these failures?! I've pushed a couple of variants to investigate.
Odd, I'm curious what the answer is too.
Assignee | ||
Comment 7•10 years ago
|
||
This tweaked version of the patch invalidates the frame on LOAD_COMPLETE, just like nsImageFrame does.
Assignee | ||
Updated•10 years ago
|
Attachment #8513838 -
Attachment is obsolete: true
Assignee | ||
Comment 8•10 years ago
|
||
Also, B2G needs a little bit of fuzz.
Assignee | ||
Updated•10 years ago
|
Attachment #8514484 -
Attachment is obsolete: true
Assignee | ||
Comment 9•10 years ago
|
||
Here's a new try job:
https://tbpl.mozilla.org/?tree=Try&rev=d41ae163ae79
Assignee | ||
Comment 10•10 years ago
|
||
Hmm. Here's an additional try push that tries some more aggressive techniques:
https://tbpl.mozilla.org/?tree=Try&rev=6e39bb271d25
Assignee | ||
Comment 11•10 years ago
|
||
Doh. Needed to repush that one:
https://tbpl.mozilla.org/?tree=Try&rev=6383f8d0ba37
Assignee | ||
Comment 12•10 years ago
|
||
Sigh. Forgot a null-check.
https://tbpl.mozilla.org/?tree=Try&rev=1b9e32321838
Assignee | ||
Comment 13•10 years ago
|
||
Alright, the remaining failures look real. It looks like we're failing to unblock onload in those cases. I've added code to unblock onload in DeregisterAndCancelImageRequest, which should hopefully take care of it. I've also added an NS_ASSERTION about it in the destructor.
Here's a new try job:
https://tbpl.mozilla.org/?tree=Try&rev=c00dedcc3bde
Assignee | ||
Updated•10 years ago
|
Attachment #8514486 -
Attachment is obsolete: true
Assignee | ||
Comment 14•10 years ago
|
||
Looks like that took care of the problem. Nice! So this patch is ready to go.
Assignee | ||
Comment 15•10 years ago
|
||
Comment 16•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in
before you can comment on or make changes to this bug.
Description
•