Closed Bug 291172 Opened 19 years ago Closed 19 years ago

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

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED DUPLICATE of bug 253851

People

(Reporter: bugs.caleb, Unassigned)

References

(
URL
)

Details

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:
> 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
(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....
(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.
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?
(In reply to comment #12)
> Caleb, if you want this fixed, could you help narrow down the regression range,
> please?

Will do now.
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!
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?
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.

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
*** Bug 298954 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b4? → blocking1.8b4-
Check http://csszengarden.com/?cssfile=/169/169.css&page=1 ...very noticeable
even w/ broadband. This is a very old bug.
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
Closed: 19 years ago
No longer depends on: 296738
Resolution: --- → DUPLICATE
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.