851755 - Make nsImageBoxFrame block onload when images are loading/decoding

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Joe Drew (not getting mail)]

nsImageBoxFrame currently doesn't block its document's onload when the image starts decoding, but it should. It should also do similarly to nsImageLoadingContent (bug 841579) and not fire its load events before decode happens, just in case images run into errors.

Try: https://tbpl.mozilla.org/?tree=Try&rev=3b1512e650b2

Comment 1

[Joe Drew (not getting mail)]

Attachment: wait for decode

Did I just dream about getting feedback about this patch? I swear I already got review on it. Or at least attached it to a bug.

Comment 2

[Timothy Nikkel (:tnikkel)]

Were there some tests failing because of this?

Comment 3

[Joe Drew (not getting mail)]

Yep - one or two.

Comment 4

[Timothy Nikkel (:tnikkel)]

Comment on attachment 726498 [details] [diff] [review]
wait for decode

Review of attachment 726498 [details] [diff] [review]:
-----------------------------------------------------------------

What happens if BlockOnload is called and then this frame gets destroyed? I think we should unblock onload in that case.

::: layout/xul/base/src/nsImageBoxFrame.cpp
@@ +725,5 @@
> +/* void blockOnload (in imgIRequest aRequest); */
> +NS_IMETHODIMP
> +nsImageBoxListener::BlockOnload(imgIRequest *aRequest)
> +{
> +  if (mFrame && mFrame->GetContent() && mFrame->GetContent()->GetDocument()) {

I think you want GetCurrentDoc here.

Comment 5

[Joe Drew (not getting mail)]

[8:41 PM] <joe> tn: well anyways I think we're actually OK here
[8:41 PM] <joe> that is, if destroying frames calls DestroyFrom
[8:42 PM] <joe> because CancelAndForgetObserver, from within DestroyFrom, will call unblockonload if necessary
[8:43 PM] <tn> joe, oh, okay, then that should be good

Comment 6

[Joe Drew (not getting mail)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/cd08011c06f7

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/cd08011c06f7