162123 - stop paint suppression when html finishes loading (don't wait 250ms for images)

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Jesse Ruderman]

Mozilla doesn't paint anything until 1.2 seconds after a page finishes loading,
or until the entire page (including images) finishes loading.  It should paint
immediately if the html finishes loading but the images are still loading,
because the images are likely to load slowly and unlikely to alter the layout of
the page.

Mozilla's current behavior makes it look slow:
<Travis> and IE displays the HTML then adds the images
<Travis> on mozilla it waits for the images before displaying it
I explained to Travis that Mozilla only waits 1.2 seconds, and then realized
that waiting 1.2 seconds for images doesn't make sense.

Comment 1

[Jesse Ruderman]

Attachment: testcase 1: fast-loading image (text paints immediately)

Comment 2

[Jesse Ruderman]

Attachment: testcase 2: slow-loading image (text paints after 1.2s)

Comment 3

[Andrew Hagen]

Is this a duplicate of bug 125260?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

>images are likely to load slowly and unlikely to alter the layout of
>the page.

this is a wrong assumption - think <img src="...">, ie. without a width/height
attribute. in that case, the size of the image is not known until it is loaded

Comment 5

[Jo Hermans]

That's why we need a small delay to catch those cases. I think that bug 180241
really helped here : the delay is now 250 msec. If we went to 0, we would have
the same ugly behaviour as Internet Exploder ('dancing page'). I agree that it's
also the fault of those pages (they should have specified the image-size anyway,
which helps the performance in IE), but it's still very common.

BTW: if we're sure that the layout is finished (all image sizes are known, etc
...), do we paint immediately ?

Comment 6

[Jesse Ruderman]

Thanks to IE's behavior, most images in web pages have height and width
specified.  I think that most "dancing page" effects come from complex layouts,
not images.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So... do we still want to try and do this now that the timeout is only 250ms?

Comment 8

[Prognathous]

(In reply to Boris Zbarsky, comment #7)
> So... do we still want to try and do this now that the timeout is only 250ms?

Some claim that 250ms is too low and 500ms is the "sweet-spot". Perhaps with
this higher timout, fixing this bug may be worthwhile.,

Prog.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information