images keep loading in the background after status has changed to Done

RESOLVED DUPLICATE of bug 253851

Status

()

--
minor
RESOLVED DUPLICATE of bug 253851
14 years ago
12 years ago

People

(Reporter: bugs.caleb, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050420 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050420 Firefox/1.0+

I've spotted this bug a few nightlies away, this could be "the way it works",
but judging from the way it works in other browsers AND logics I think that it
may be a bug.

When you load certain pages, the HTML might complete loading, and Firefox would
say "Done.", but 1-2 seconds after that you will spot a few images suddenly
appearing on the page.

This could also be a different bug (such as, everything is downloaded but only
displayed later), so I'd like someone to check it out properly.

To reproduce:

1. Clean your cache
2. Visit the specified URL
3. Watch the page load

When it says "Done." on the statusbar and the progressbar disappears you should
notice the backgrounds of the tabs suddenly appearing, and the "Spot the fox"
image too (appearing a bit later).

In Opera 8 and IE6, the progress bar stays until everything is loaded and displayed.

Reproducible: Always

Steps to Reproduce:
(Reporter)

Comment 1

14 years ago
> When it says "Done." on the statusbar and the progressbar disappears you should
> notice the backgrounds of the tabs suddenly appearing, and the "Spot the fox"
> image too (appearing a bit later).

s/tabs/tables
I also see this with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2)
Gecko/20050429 Firefox/1.0+
I do not see this with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7)
Gecko/20050414 Firefox/1.0.3
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
So is this just about the fact that onload fires before all backgrounds are done
downloading?  Note that, in general, some background images will _never_ be
downloaded; should onload never fire then?
In any case, this isn't DOM, and it's almost certainly a dup.
Assignee: general → nobody
Component: DOM: Level 0 → Layout
QA Contact: ian → layout
Whiteboard: DUPEME
(Reporter)

Comment 5

14 years ago
(In reply to comment #3)
> So is this just about the fact that onload fires before all backgrounds are done
> downloading?  Note that, in general, some background images will _never_ be
> downloaded; should onload never fire then?


I'm not sure about onload, but I'm certain that this did not happen in previous
Firefox versions nor does it happen in any other browser.

It seems goofy (and quite annoying tbh) that the browser says "Done." at the
bottom and a few seconds later images are starting to appear. 

I tried it on http://www.mozilla.org today, and I had to wait for about 3-5
seconds until the preview image of Firefox appeared. This is not right. The
progress bar should not disappear, and it should not say that it finished
grabbing the page, if it did not do so!

IMO it is severe enough to be fixed by 1.1 final.
> but I'm certain that this did not happen in previous Firefox versions

Sure it did.  It was even worse, actually...  See bug 83774.  Or what versions
are you referring to, exactly?

> IMO it is severe enough to be fixed by 1.1 final.

IMO this is invalid, but I could perhaps be convinced that this behavior is
worth changing....
(Reporter)

Comment 7

14 years ago
(In reply to comment #6)
> > but I'm certain that this did not happen in previous Firefox versions
> 
> Sure it did.  It was even worse, actually...  See bug 83774.  Or what versions
> are you referring to, exactly?
> 

I'm referring to the aviary1.0.x branch. In 1.0.4, for example, the progress bar
is visible and it shows progress until _all_ images are loaded on the site
(mozilla.org), just like all other browsers do it.

On the trunk version the pages seems to report being "Done" prematurely, as the
progress bar disappears and some images have not been loaded yet.

> > IMO it is severe enough to be fixed by 1.1 final.
> 
> IMO this is invalid, but I could perhaps be convinced that this behavior is
> worth changing....

Why the heck is this invalid??? It is a visible regression from 1.0.x.
You will most likely see it on sites that have plenty of images like
gamespot.com, or some sites that load slowly.

I am not sure when it decides that it has finished downloading the page, but it
does seem to affect only _some_ images (as they are the ones that are downloaded
& rendered after the page was set to "Done")
Oh, so this is just about the status bar messages?  I thought (based on summary)
this was about backgrounds loading after onload (and you never actually said
otherwise)...

Staus bar messages aren't likely to have anything to do with layout or DOM. 
They're done by necko, docshell, and the UI itself; changes to any of those
could have caused this change.  I do see this in the suite, so chances are it's
in the shared UI code (the status filter) or something like that.  It would be
very helpful to have a regression range here (more of one than "sometime in the
last 13 months", at least).
Assignee: nobody → darin
Component: Layout → Networking
Keywords: qawanted
QA Contact: layout → benc
Summary: images keep loading in the background after the page has loaded → images keep loading in the background after status has changed to Done
Whiteboard: DUPEME
Except that happens in 1.0.4 builds.
(Reporter)

Comment 11

14 years ago
Optimistically requesting 1.8b4 blocking. IMO it's a noticeable regression
(heck, I've been noticing it in every build in the past few months) and it might
be worth to take one more look into this.

Basically it gives the illusion that the page has finished loading, while
there's still more stuff coming and appearing after FF reports it as "Done."
Flags: blocking1.8b4?
Caleb, if you want this fixed, could you help narrow down the regression range,
please?
(Reporter)

Comment 13

14 years ago
(In reply to comment #12)
> Caleb, if you want this fixed, could you help narrow down the regression range,
> please?

Will do now.
(Reporter)

Comment 14

14 years ago
Gah, after about 2 hours of testing and headaches (and thanks for Steve for
finding that it can also be easily reproducable via CTRL-F5) I think I found the
build this regressed on.

Works:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050124
Firefox/1.0+ (2005-01-24-08)

Broken:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050125
Firefox/1.0+ (2005-01-25-08)

I think that this is possibly the query:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-01-24&maxdate=2005-01-25&cvsroot=%2Fcvsroot

I'd like a confirmation on this info if possible!
(Reporter)

Comment 15

14 years ago
Steve said that he does not see any difference between the 2 builds.. and after
downloading them and testing again neither do I.

Can anyone else take over?

Comment 16

14 years ago
If I understand this bug correctly, it is a very old bug -- I see the same
behavior with Mozilla 1.0 as I see with FF 1.0.x and current trunk (FF and
suite).  bug 253851 seems to be identical and was reported in an older FF build
(was 0.9.1+ post-1.0?).  It was probably not reported until recently because
nobody specified background images on elements via CSS.
yes, this is very old. I can confirm this from my memory with a Mozilla1.0.X build.
(Reporter)

Comment 18

14 years ago
Yj(In reply to comment #16)
> If I understand this bug correctly, it is a very old bug -- I see the same
> behavior with Mozilla 1.0 as I see with FF 1.0.x and current trunk (FF and
> suite).  bug 253851 seems to be identical and was reported in an older FF build
> (was 0.9.1+ post-1.0?).  It was probably not reported until recently because
> nobody specified background images on elements via CSS.

Yeah, this could possibly be the same issue!

But I do not see it in FF 1.0.x at all, so that's strange.. maybe it has gotten
worse in trunk?
I see this quite clearly in Firefox 1.0.x on every single shift-reload of the
page in question.  So this is not a regression.  Further, this seems like the
right behavior from the point of view of networking; if the front end wants to
change when it outputs Done, then that should be handled in the front end.
Assignee: darin → nobody
Component: Networking → General
Keywords: qawanted, regression
Product: Core → Firefox
QA Contact: benc → general

Comment 20

14 years ago
*** Bug 298954 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking1.8b4? → blocking1.8b4-

Comment 21

13 years ago
Check http://csszengarden.com/?cssfile=/169/169.css&page=1 ...very noticeable
even w/ broadband. This is a very old bug.
(Reporter)

Comment 22

13 years ago
I'm leaning towards marking this as a dupe of bug 253851...

This bug wasn't very visible with Firefox 1.0, but I pretty much see it
(everywhere) with FF 1.5 and the current trunk.

*** This bug has been marked as a duplicate of 253851 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
No longer depends on: 296738
Resolution: --- → DUPLICATE

Comment 23

12 years ago
Did everyone give this up? One and a half years. Too bad.
You need to log in before you can comment on or make changes to this bug.