Closed Bug 209330 Opened 21 years ago Closed 19 years ago

status bar changes when JavaScript prefetches images after a page's onLoad

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8beta2

People

(Reporter: mozilla, Assigned: Biesinger)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(4 files)

Testcase which creates image in document's onload handler
466 bytes, text/html
Details
setTimeout-based testcase
499 bytes, text/html
Details
possible patch
2.73 KB, patch
darin.moz
: review+
jst
: superreview+
brendan
: approval1.8b2+
Details | Diff | Splinter Review
patch v2
3.25 KB, patch
jag+mozilla
: review+
darin.moz
: superreview+
shaver
: approval1.8b3+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030507

The page at http://www.killerinstinct.com/bugsample.html demonstrates a user
interface problem that seems to have started with Mozilla 1.3b. When JavaScript
is used to prefetch images *after* the page has finished loading, the following
text flashes in the status bar: "Waiting for somehost..." and "Transferring data
from somehost...". This is inconsistent with MSIE 6.x and is inconsistent with
Mozilla 1.2.1 and 1.3a. Most importantly, it is potentially very disruptive to a
user's experience: cyclical changes that occur to the browser's "chrome" give
the impression that the page is still loading and distract the user from any
page contents that are already displayed. This is fine if the page truly is
still loading, but once it has finished such changes should be suppressed to
avoid distracting the user from the page content.

Clicking the button below causes the browser to prefetch 100 images. In Mozilla
1.2.1, Mozilla 1.3a and MSIE 6.0, no visible change to the status bar occurs. In
Mozilla 1.3b->1.4b, messages are flashed repeatedly.

JavaScript image preloading is commonly used to pre-cache sets of images that
may be needed on subsequent pages.  Web site publishers who want to support
Mozilla will likely be unwilling to use this feature if it makes their pages
appear to continue loading.  This feature is also sometimes used to precache
images that must be displayed inline on mouseover.  A message in the status bar
is not desirable in this case, either.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.killerinstinct.com/bugsample.html
2. Make sure that the page has finished loading.
3. Click the button.

Actual Results:  
The status bar very quickly flashes the message "Waiting for
www.killerinstinct.com...", then changes to "Transferring data from
www.killerinstinct.com...", and repeats this 100 times.  When it finishes, it
leaves the message "Transferring data from www.killerinstinct.com..." in the
status bar even though nothing is being transferred.

Expected Results:  
Mozilla should have left the status bar empty and given no indication in the
browser chrome that anything was happenning.

This bug occurs with both the classic and modern theme.
*** Bug 209331 has been marked as a duplicate of this bug. ***
This bug has been in the queue "unconfirmed" for over six months.  When will it
be confirmed?  It is still valid for Mozilla & FireFox rev: 1.4, 1.5, 1.6, and
1.7a on Windows and probably other platforms.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've made another testcase, with as body tag:
<body onload="var testimage=new
Image();testimage.src='http://bugzilla.mozilla.org/ant.jpg';">

This causes an enless "Waiting for bugzilla.mozilla.org..." in my statusbar.
I'm using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520
Firefox/0.8.0+

This can also be seen at: http://www.pcworld.com/
The status bar problem (endless showing "loading..") there is caused by this
bug, I think.
*** Bug 244401 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
This interface bug also shows up in google maps.

http://maps.google.com

Press the '+' button to zoom in and the status bar will never revert back to
"Done" it will always say "Transferring data from mt.google.com"

To restate what has been said above, it is common for webpages to load images
after the entire dom tree has been loaded.  With this bug unresolved, all
prefetching of images with javascript will cause the browser to appear to
incompletely load the page.
Requesting blocking1.1
Flags: blocking-aviary1.1?
This also occurs with setTimeout(). Modifying the example from Comment #3:

setTimeout("var testimage=new
Image();testimage.src='http://bugzilla.mozilla.org/ant.jpg';", 5000);

In 5 seconds, "Waiting for bugzilla.mozilla.org..." appears in the
statusbar and lingers forever.

I'm starting to wonder if this is a general problem affecting image
fetches in all event handlers...
To clarify my Comment #7:

I tested this setTimeout() in two ways:
1) called setTimeout() from inside onload handler
2) called setTimeout() from <SCRIPT> section in document. No onload used
   anywhere in the document.

Both tests triggered the behavior I described.

Tested in: "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6)
Gecko/20050223 Firefox/1.0.1"

seems like this bug has the wrong component assignment.  it is also present in
firefox and maybe could be related to changes in networking or js code. 

also reports that this is a problem with maps.google.com and yahoo web apps.  we
need more investigation to isolate where the problem lies.
Component: XP Apps: GUI Features → General
Product: Mozilla Application Suite → Firefox
-> core: networking
Assignee: firefox → darin
Component: General → Networking
Product: Firefox → Core
QA Contact: pawyskoczka → benc
Just to confirm, this is still a bug in Firefox 1.0.2. The status bar remains as
'Transferring data from ...' after an image is updated with javascript after
page load.

Browser version:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317
Firefox/1.0.2
Flags: blocking-aviary1.1?
hm...
OSC: [ 00010001 00000000 https://bugzilla.mozilla.org/ant.jpg              ]
START | IS_REQ
OSC: [ 00020010 00000000 https://bugzilla.mozilla.org/attach...gi?id=149145]
STOP           | IS_DOC
OSC: [ 000c0010 00000000 https://bugzilla.mozilla.org/attach...gi?id=149145]
STOP                    | IS_NET | IS_WIN
OSC: [ 00010010 00000000 https://bugzilla.mozilla.org/ant.jpg              ]
STOP  | IS_REQ

(removed some dummy requests, and a chrome://.../lock-secure.gif item)
the bug is in nsBrowserStatusFilter.cpp. it does not send a STATE_STOP for the
image.

this bug is somewhat similar to Bug 166428 (at least in symptomps)...
might this be a regression caused by bug 192022? the checkin before that one to
the file supposedly fixed this. on the other hand, I don't currently see how
that can have caused this...
the issue seems to be that we suppress sending the statuschange here:
    else if (aStateFlags & STATE_STOP) {
        if (aStateFlags & STATE_IS_REQUEST) {
            ++mFinishedRequests;
            if (!mUseRealProgressFlag && mTotalRequests)
                return OnProgressChange(nsnull, nsnull, 0, 0,
                                        mFinishedRequests, mTotalRequests);
        }
    }
mUseRealProgressFlag is false, mTotalRequests is 5, so we return here. (it is 5
because the counter didn't get cleared at the end of the document load. but if I
do clear it there, it doesn't help - dummy requests increase it above 1 anyway,
thus making mUseRealProgressFlag false again)
taking for now
Assignee: darin → cbiesinger
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta2
Attached patch possible patch — — Splinter Review 
how about this? it makes sure to use the real progress flag while not loading a
document, which has the effect of also sending STATE_STOP appropriately.

What would, maybe, also work is to only count nsIChannels for
m{Total,Finished}Requests, but that is probably unreliable when more than one
image is preloaded.
Status: NEW → ASSIGNED
Comment on attachment 181164 [details] [diff] [review]
possible patch

yup, make sense to me.	r=darin
Attachment #181164 - Flags: review?(darin) → review+
Attachment #181164 - Flags: superreview?(jst)
Comment on attachment 181164 [details] [diff] [review]
possible patch

sr=jst
Attachment #181164 - Flags: superreview?(jst) → superreview+
Flags: blocking1.8b2+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Comment on attachment 181164 [details] [diff] [review]
possible patch

a=brendan for 1.8b2.

/be
Attachment #181164 - Flags: approval1.8b2+
Does firefox also use the xpfe status filter, then?
(In reply to comment #16)
>the issue seems to be that we suppress sending the statuschange here:
>    else if (aStateFlags & STATE_STOP) {
>        if (aStateFlags & STATE_IS_REQUEST) {
>            ++mFinishedRequests;
>            if (!mUseRealProgressFlag && mTotalRequests)
>                return OnProgressChange(nsnull, nsnull, 0, 0,
>                                        mFinishedRequests, mTotalRequests);
>        }
>    }
>mUseRealProgressFlag is false, mTotalRequests is 5, so we return here. (it is
>5 because the counter didn't get cleared at the end of the document load. but
>if I do clear it there, it doesn't help - dummy requests increase it above 1
>anyway, thus making mUseRealProgressFlag false again)
What if you return early only if mFinishedRequests < mTotalRequests ?
Is Suite bug 248749 related to (or even going to be fixed by) this bug?
*** Bug 248749 has been marked as a duplicate of this bug. ***
*** Bug 250542 has been marked as a duplicate of this bug. ***
*** Bug 246052 has been marked as a duplicate of this bug. ***
*** Bug 247002 has been marked as a duplicate of this bug. ***
*** Bug 281925 has been marked as a duplicate of this bug. ***
I checked this patch in as-is... it already had reviews etc. please file a new
bug for improvements :-)
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
ok, I changed my mind. reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch patch v2 — — Splinter Review 
this patch backs out the previous patch and fixes the bug via this change:
     else if (aStateFlags & STATE_STOP) {
	 if (aStateFlags & STATE_IS_REQUEST) {
	     ++mFinishedRequests;
+	     // Note: Do not return from here. This is necessary so that the
+	     // STATE_STOP can still be relayed to the listener if needed
+	     // (bug 209330)
	     if (!mUseRealProgressFlag && mTotalRequests)
-		 return OnProgressChange(nsnull, nsnull, 0, 0,
-					 mFinishedRequests, mTotalRequests);
+		 OnProgressChange(nsnull, nsnull, 0, 0,
+				  mFinishedRequests, mTotalRequests);
	 }
Attachment #181338 - Flags: superreview?(darin)
Attachment #181338 - Flags: review?(jag)
moving blocking flag out to 1.8b3
Flags: blocking1.8b3+
Comment on attachment 181338 [details] [diff] [review]
patch v2

ok, yeah.. that does seem better.
Attachment #181338 - Flags: superreview?(darin) → superreview+
*** Bug 291409 has been marked as a duplicate of this bug. ***
*** Bug 124032 has been marked as a duplicate of this bug. ***
*** Bug 185547 has been marked as a duplicate of this bug. ***
Christian, why wasn't this bug duped to core bug 185547 which Netscape marked
adt1 plus set target milestone mozilla1.4final plus at least 18 dupes before
this bug was ever filed? This bug started as Firefox long after both those events.
because originally, I weren't aware of that bug, and later, I thought that this
bug was a newer regression. sorry about that.
Keywords: testcase
Flags: blocking1.8b2+
I'm not sure whether patch v2 covers this or not, but there seems to be the same
problem when you close a currently loading tab.

You need a page that does some redirections/loads slowly (if you have a yahoo or
a gmail account that'll do).

I have reproduced it like this:
 - Open tab with mail.yahoo.com
 - Close tab

"Waiting for us.f524.mail.yahoo.com..." is stuck in the statusbar.
(In reply to comment #41)
>  - Open tab with mail.yahoo.com
>  - Close tab
> 
> "Waiting for us.f524.mail.yahoo.com..." is stuck in the statusbar.
Odd, I thought switching tabs was supposed to clear the statusbar.
Attachment #181338 - Flags: review?(jag) → review+
Comment on attachment 181338 [details] [diff] [review]
patch v2

fixes this bug in a better way, with less code
Attachment #181338 - Flags: approval1.8b3?
Comment on attachment 181338 [details] [diff] [review]
patch v2

a=shaver
Attachment #181338 - Flags: approval1.8b3? → approval1.8b3+
Checking in xpfe/browser/src/nsBrowserStatusFilter.cpp;
/cvsroot/mozilla/xpfe/browser/src/nsBrowserStatusFilter.cpp,v  <-- 
nsBrowserStatusFilter.cpp
new revision: 1.13; previous revision: 1.12
done
Checking in xpfe/browser/src/nsBrowserStatusFilter.h;
/cvsroot/mozilla/xpfe/browser/src/nsBrowserStatusFilter.h,v  <-- 
nsBrowserStatusFilter.h
new revision: 1.4; previous revision: 1.3
done
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
I tested this bug against the following URLs:

http://maps.google.com/

https://bugzilla.mozilla.org/attachment.cgi?id=149145

http://www.killerinstinct.com/bugsample.html

https://bugzilla.mozilla.org/attachment.cgi?id=181085

All of them clear status just fine using build 2005-06-05-05 on Windows XP
Seamonkey trunk.

There is a totally separate case that I found while testing this bug fix, but
it's unrelated -- bug 296738.

This bug is now Verified FIXED.
Status: RESOLVED → VERIFIED
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050607
Firefox/1.0+

I still see the extra status bar messages using the two testcases in this bug.
Mozilla still has the error in the setTimeout-based testcase:

Mozilla 1.7.8
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.8) Gecko/20050511
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I won't fix this for 1.7.x.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
*** Bug 264967 has been marked as a duplicate of this bug. ***
*** Bug 299256 has been marked as a duplicate of this bug. ***
biesi: is there a reason you don't want this in 1.7? This would be a nice fix
for some major app compatibility we have so we would love it in the 1.0.X branch.
I thought 1.7.x was for security bugs only? this seemed a bit high risk for the
branch for me, but I guess it's ok as I am not aware of any regressions caused
by this bug...
I ran into this issue and spent days testing various cases to draw the same conclusions - I should have checked Bugzilla first! :)

I have a couple quick questions related to this I would greatly appreciate feedback on:

1) Thanks so much for fixing in future versions. I really need a way though to work around this with versions of Netscape 7-8 and Mozilla 1.7.  Is there ANY type of way you guys can think of to using JS to trick the browser into doing something that forces the status bar to clear after the background image loads?

For instance, I was thinking maybe I could put some code into the *image's* onError and onLoad event, so that once the browser is finished loading the image I would force the browser to execute some statement that would result in the browser doing something else which would then cause it to recognize that it was finished.  Any possible work around/trick here?

2) I'm confused as to what official browser releases this specific bug will be (or is already) fixed in.  For instance:

  a) What release version of Firefox was the first to incorporate this fix? 1.0.7?

  b) What release version of Netscape will be the first to incorporate this fix? I see that as of NN 8.1 it still contains this bug.

  c) What release version of Mozilla will be the first to incorporate this fix? Or is 1.7.x the last version of Mozilla due to Seamonkey?  I have verified it is fixed in Seamonkey 1.0.

Thanks guys!!
Summary: status bar changes when Javascript prefetches images after a page's onLoad → status bar changes when JavaScript prefetches images after a page's onLoad
(In reply to comment #54)
> For instance, I was thinking maybe I could put some code into the *image's*
> onError and onLoad event, so that once the browser is finished loading the
> image I would force the browser to execute some statement that would result in
> the browser doing something else which would then cause it to recognize that it
> was finished.  Any possible work around/trick here?

Hm, maybe you can load about:blank in an iframe, or load javascript:void(0); or something...

>   a) What release version of Firefox was the first to incorporate this fix?
> 1.0.7?

1.5

>   b) What release version of Netscape will be the first to incorporate this
> fix? I see that as of NN 8.1 it still contains this bug.

No idea.

> Or is 1.7.x the last version of Mozilla due to Seamonkey?  I have verified it
> is fixed in Seamonkey 1.0.

Not fixed in any 1.7.x version.
> Hm, maybe you can load about:blank in an iframe, or load javascript:void(0); 
> or something...

Sounds promising. The challenge though is that I have to operate entirely within the Body's OnLoad tag.  In other words I don't have the flexibility to create an IFrame somewhere in the document body.

Is it possible to do this trick or any other trick from directly within the Body's onLoad tag?  Currently I'm doing <body onload=new Image().src = 'abc';> so I need to do something in that line.  Any ideas?

Incidentially I wanted to report that I found that if the .src for the image being loaded was a relative URL like .src='/whatever.gif' then this status bar bug did NOT occur.  It only happened when it was an absolute URL.  I even tried creating a new Image in the other images onload event and setting its .src to a relative url but it still doesn't clear the "Transfering..." status from the first image - dang!

> In other words I don't have the flexibility to
> create an IFrame somewhere in the document body.

couldn't you create an iframe element from there? :)

maybe you can also try the javascript:void(0) variant for the document itself, like:

  window.location.href = "javascript:void(0)";
*** Bug 192059 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: