Closed Bug 133250 Opened 18 years ago Closed 17 years ago

"Transferring data from..." remains on status bar.


(Core :: Networking: HTTP, defect)

Not set





(Reporter: jasonb, Assigned: antonio.xu)




(4 keywords, Whiteboard: DO NOT REOPEN. Further work in bug 185547)


(3 files, 16 obsolete files)

6.16 KB, text/plain
4.07 KB, patch
: review+
: superreview+
Details | Diff | Splinter Review
6.26 KB, patch
: review+
: superreview+
Details | Diff | Splinter Review
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
BuildID:    2002032203

The status bar keeps showing "Transferring data from..." even after the page has
been fully loaded.  I've seen this on several different sites, but list
Mozillazine as a link because I can always duplicate it there.  With other sites
it doesn't happen at all.  But, for those sites where it does, it's annoying.

Reproducible: Always
Steps to Reproduce:
1. Go to the URL listed.
2. Observe the status bar.

Actual Results:  "Transferring date from..." remains in status bar.

Expected Results:  Status bar text should change to "Document: Done".
Confirming on Linux 2002032421.
Ever confirmed: true
Confirming on Win Me 2002032408
Confirmed on W2K SP2 2002032408. Problem doesn't appear on
front page, but  does appear in the Build Talkback section
-> XP APPS (Browser genral doen't fix bugs..., please select a good component if
you confirm a bug.)
Assignee: asa → blaker
Component: Browser-General → XP Apps: GUI Features
QA Contact: doronr → paw
*** Bug 133196 has been marked as a duplicate of this bug. ***
Note: I see this on Mozillazine with build 2002031903 under Win 98SE.
->networking. high-visibility recent regression (sometime in the last few days I
Assignee: blaker → darin
Component: XP Apps: GUI Features → Networking: HTTP
QA Contact: paw → tever
Keywords: nsbeta1, regression
Doesn't show up in nightly from 3/7 or 0.9.9, but does in 3/17 nightly (under
Windows 2000). I don't have time at the moment to narrow it down further, but
perhaps this'll help.
It's doing it for me in Win98 with 2002032503 on several sites.
One URL it does it for is:
This also seems to affect tabbed-browsing.  Open this bug in one tab, then open
the build bar link that Joe has in another tab. Let the build-bar page pull
completely-up and then switch tabs a couple of times.  Now the status bar for
the first tab (THIS page!) says 'Transferring data from',
which of course does not belong in THIS tab..
is this problem only occuring when using multiple tabs?

i haven't seen this problem myself.

-> docshell
Assignee: darin → adamlock
Component: Networking: HTTP → Embedding: Docshell
QA Contact: tever → adamlock
Darin: You mean you don't see the problem when going to the reference URL: and looking at the status bar?

The multiple tabs issue is new to me - but I thought that everybody had a
problem with at least that one link.  What build / platform are you using?
I see this on the

moz 2002032603, XP
The problem still exists even without multiple tabs... it just seems to get
worse if you do have multiple tabs (the status bar seems to reflect the
corrupted state on all tabs unless it is updated via another event such as a

It almost seems that the status bar is just not being updated when the document
is finished.  It also seems that when this happens, it also doesn't update on a
tab-switch.  Could be related?
-> Tabbed browser
Component: Embedding: Docshell → Tabbed Browser
Assignee: adamlock → jaggernaut
QA Contact: adamlock → sairuh
Adam, this bug occurs also without tabs (see given URL), tabs just seem to
trigger it more often.
I can confirm that this is happenning with Mac OS X build 2002032608 without
involving any tab browsing
Nav triage team: What kinds/how many websites will this affect?  Does this
affect the top 100 trafficked sites?
Whiteboard: [need info]
I don't know if it's in the top 100 or not, but is affected.
Here's how I can make it happen with 2002040203 on Windows 2000:

1) Clear the browser caches and restart the browser.
2) Go to
3) Click items in the page's sidebar. Sooner or later, the "Transferring..."
status will stick. "Browser Central" and "Entertainment" are frequently affected
(today). The problem almost always manifests if I click "Browser Central" and
then "Entertainment."

I've only seen the problem manifest the first time a given item is clicked.
Given how frequently the site changes, these steps may not work another day. The
main point is that even Netscape's sites may be affected.

We know this regressed between 3/7 and 3/17. Would it be useful to further pin
it down?
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [need info] → [adt3]
Useful or not, I've pinned this regression down somewhat. As noted above, the
3/7/2002 build for Windows 2000 works correctly. The 3/10/2002 build (the oldest
I could find on the FTP site) manifests this bug. Perhaps a detective with CVS
expertise can use this to narrow the search for the guilty party.
-> 1.0
Target Milestone: --- → mozilla1.0
wfm 2002041306 - WinXP.
on linux, trunk cvs 2002-04-13 bugs
2002-03-02-23-trunk works
2002-03-06-08-0.9.9 works
2002-03-07-21-trunk bugs
2002-03-08-13-0.9.9 works

Test steps:
1) start browser
2) browse to this bug report
3) middle-click on URL link to open in new window
4) close second window, repeat step 3 to verify

Per comment 8 and comment 22, a build from 2002-03-07 works (w2k), so I guess
that narrows it down to that day, trunk only, 0:00-21:00.


There is still no proper 04-13 nightly build for Win32, so cannot confirm under

Frederic: What build are you using?  The only Win32 build I see that's dated
04-13 (none of the regular installer builds are) is "".
The problem with the status bar not updating on tab switching is bug 104532, and
is a lot older than this bug, so this is not a tabbrowser issue. Sending back to
Assignee: jaggernaut → adamlock
Component: Tabbed Browser → Embedding: Docshell
QA Contact: sairuh → adamlock
Agreed.  As has already been mentioned several times here, this bug has nothing
to do with tabs.  While you *can* see the problem while using tabs, if you
simply open a new window and go to the test case URL, without even thinking
about using tabs <grin>, you'll still see the problem.  Please don't bring up
tabbing as it only confuses things.
I disagree with comment #24

It doesn't work for me with builds 2002041303 or 2002041308 on Win98SE.
There are no "builds 2002041303 or 2002041308 for Win98SE" (in fact, other than
the SVG build, there is no Win32 build for April 13 at all), unless you're
talking about the 1.0.0 branch. But comment #24 referred to the trunk.
I got the builds from the following URL's

If these are branch (1.0.0) builds rather than trunk builds then it sure isn't
Normally, unless otherwise specified, the builds used in these bug discussions
(correct me if I'm wrong somebody) are the TRUNK builds, which can be found at:

This is what's linked to in the QA -> Latest Builds menu.
So, what about the builds found at :-

Are these Trunk or Branch builds?

I assume that anything in the "nightly" directory is Trunk, unless identified
otherwise (e.g. "latest-1.0.0" or "2002-04-13-09-1.0.0")
That's a good question.  I wish I knew what the "GMAKE" set of binaries were about.
The gmake binaries were probably built using Gnu's version of 
make, instead of nmake.  I don't know whether they are trunk 
or branch, and this is mostly a guess.  Could also have to do
with work to get builds working without MSVC.  
I just installed build 2002041408 from the "usual" source, in my case the
installer version - -
and it still exhibits the faulty behaviour as described here.  So if the GMAKE
version does not, maybe that could help figure out what's happening?  In any
case, this bug has still not been fixed.
The sample URL does not specify a length (try it with wget to see). It could be
a regression with dealing with CGI scripts and the like that do not specify a
length in advance.

I can reproduce this behaviour in Mozilla & mfcEmbed pointing to a lower level

I will CC a few of the Necko folks to see if its an issue they might recognize.
I assume you're referring to the content-length header. I see this problem
(using 2002041711 on Win2000 with my own scripts, which provide such a header.
If I remove the header, the problem remains. Looks to me like the absence of a
content-length at MozillaZine is coincidence.
it seems odd to make the status bar depend on the content-length header.  if
that is the case (i.e., someone is watching progress from 0 to content-length),
then that code is broken.  the load group is finishing as indicated by the
throbber stopping, but somehow that fact is not causing the status bar to say
"Document: done" ... anyone know how the status bar gets tickled normally?
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
CC Rick for ideas
There is something very odd about this URL in the page:

It appears to trigger multiple http requests yet each appears to return a 200
status code (i.e. not a redirect). Weirder yet, if I view the transaction log
via Privoxy it appears that the servers returning me this content are a
combination of kHTTPd/0.1.6-kb2, kHTTPd/0.1.6-kb3 and sometimes Tux/2.0. 

I will attach a log of one example.
Attached file Log file
Reassigning to netwerk.  I think the status updates are a side effect of
something odd happening lower down. See the odd URL I posted.
Assignee: adamlock → darin
Component: Embedding: Docshell → Networking: HTTP
QA Contact: adamlock → tever
Whiteboard: [adt3] → [adt3][RTM]
Target Milestone: mozilla1.0 → mozilla1.0.1
Keywords: mozilla1.0
the status bar sticks with 'connecting to...' aswell.
I had one window open, opened a 2nd tab in that window, loaded a page in that
tab, jumped back to the first tab. the status bar in that first tab had a stuck
'connecting to...' (even though the throbber had stopped throbbing). I jumped to
the 2nd tab and it had a stuck 'transferring data from...', I jumped back to the
1st tab (think I jumped about between the two a bit more here, seeing the
problem continue, but can't quite remember) and it too changed to 'transferring
data from...', I jumped back to the 2nd tab and back to the 1st and then the
status bar worked ok
Target Milestone: mozilla1.0.1 → ---
i will research this bug.
i can't reproduce this bug with build20020512 onwindows, if somebody can 
reproduce this bug,please add some comments,i onlu can reproduce #46's peoblem.
sounds like a problem with tabbed browsing then... jag?
Still reproducible ( under Windows XP,
build 2002051404.

Darin: Please do not start the tabbed browsing discussion yet again.  See
comment 17, comment 18, and comment 27.  You should know better since you
already sent it there once before (comment 11) only to have it brought back
since it's not related.

i only see the problem when i have more than one tab open.  i'm assuming that
either something has changed since you wrote comment #12 or else this is very
intermittent.  is the behavior easily reproducible for you without tabs?  either
way, the fact that tabs make this problem show up more often means that tabs
must have something to do with this bug, so who better to take a look then
someone familiar with the way tabbed browsing works?

BTW i'm testing RC2 under linux.
I can reproduce this bug on solaris with RC1 & RC2,but i can not reproduce this 
bug on win2000 with trunk 2002/05/12.
It seems to me that this has something to do with image swapping with
javascript. See testcases here:
I've never seen the bug in test1. I see it most of the time in tests 2 and 3.
I've seen it once in test4. Usually I can trigger the bug by doing shift+reload.

Right now using 2002051208 trunk win2K, but I've seen it for a while in
different builds, both branch and trunk.
Nice test cases, Lasse. You may be on to something. I see the same behavior you
describe with RC2 on Windows 2000. Furthermore, the steps outlined in comment #9
and comment #20 still cause the problem. I'm not using multiple tabs.
> is the behavior easily reproducible for you without tabs?

Every single time.  Start Mozilla, and go to the test case.  It never fails.  I
don't need to have any tabs open at all.  I can reproduce this 100% of the time.

> BTW i'm testing RC2 under linux.

I'm using the latest trunk builds.  Are we confusing ourselves because we're
using different builds?
I can reproduce this bug sometime on win2000 with RC2,i will research this 
bug,please give me some time.
*** Bug 144983 has been marked as a duplicate of this bug. ***
mass futuring of untargeted bugs
Target Milestone: --- → Future
*** Bug 136007 has been marked as a duplicate of this bug. ***
bug 136007 has a testcase for this bug
*** Bug 145464 has been marked as a duplicate of this bug. ***
it will have another transfer data status after document done,i will research 
why it was happen.
i found mozilla will get 
again ,when mozilla load completely then 
the load done,it did't fire 
document doen event.
the stack was happen after document done,i think mozilla shouldn't paint table  
again and load image from http after document done. 
nsIOService::NewChannelFromURI(nsIOService * const 0x016c2028, nsIURI * 
0x03dbefd0, nsIChannel * * 0x0012e710) line 749
imgLoader::LoadImage(imgLoader * const 0x0117ce00, nsIURI * 0x03dbefd0, nsIURI 
* 0x00000000, nsILoadGroup * 0x03c20840, imgIDecoderObserver * 0x03f15b20, 
nsISupports * 0x00000000, unsigned int 1, nsISupports * 0x00000000, imgIRequest 
* 0x00000000, imgIRequest * * 0x03f15b34) line 295 + 69 bytes
nsImageLoader::Load(nsIURI * 0x03dbefd0) line 123 + 77 bytes
nsPresContext::LoadImage(nsPresContext * const 0x03c7edb8, const nsString & 
{...}, nsIFrame * 0x03e5af3c, imgIRequest * * 0x0012eae8) line 1544
nsCSSRendering::PaintBackgroundWithSC(nsIPresContext * 0x03c7edb8, 
nsIRenderingContext & {...}, nsIFrame * 0x03e5af3c, const nsRect & {...}, const 
nsRect & {...}, const nsStyleBackground & {...}, const nsStyleBorder & {...}, 
int 0, int 0, int 1) line 2750 + 59 bytes
nsCSSRendering::PaintBackground(nsIPresContext * 0x03c7edb8, 
nsIRenderingContext & {...}, nsIFrame * 0x03e5af3c, const nsRect & {...}, const 
nsRect & {...}, const nsStyleBorder & {...}, int 0, int 0, int 1) line 2593 + 
45 bytes
nsTableFrame::Paint(nsTableFrame * const 0x03e5af3c, nsIPresContext * 
0x03c7edb8, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Underlay, unsigned int 0) line 1535 + 35 
nsContainerFrame::PaintChild(nsIPresContext * 0x03c7edb8, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x03e5af3c, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 256
nsTableOuterFrame::Paint(nsTableOuterFrame * const 0x03e5ad24, nsIPresContext * 
0x03c7edb8, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Underlay, unsigned int 0) line 376
nsContainerFrame::PaintChild(nsIPresContext * 0x03c7edb8, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x03e5ad24, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 256
nsBlockFrame::PaintChildren(nsIPresContext * 0x03c7edb8, nsIRenderingContext & 
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay, 
unsigned int 0) line 5508
nsBlockFrame::Paint(nsBlockFrame * const 0x03e5a7e0, nsIPresContext * 
0x03c7edb8, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Underlay, unsigned int 0) line 5380
nsContainerFrame::PaintChild(nsIPresContext * 0x03c7edb8, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x03e5a7e0, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 256
nsBlockFrame::PaintChildren(nsIPresContext * 0x03c7edb8, nsIRenderingContext & 
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay, 
unsigned int 0) line 5508
nsBlockFrame::Paint(nsBlockFrame * const 0x03ea3aa0, nsIPresContext * 
0x03c7edb8, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Underlay, unsigned int 0) line 5380
nsContainerFrame::PaintChild(nsIPresContext * 0x03c7edb8, nsIRenderingContext & 
{...}, const nsRect & {...}, nsIFrame * 0x03ea3aa0, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 256
nsContainerFrame::PaintChildren(nsIPresContext * 0x03c7edb8, 
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 197
nsHTMLContainerFrame::Paint(nsHTMLContainerFrame * const 0x03fa0bc0, 
nsIPresContext * 0x03c7edb8, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Underlay, unsigned int 0) line 135
CanvasFrame::Paint(CanvasFrame * const 0x03fa0bc0, nsIPresContext * 0x03c7edb8, 
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Underlay, unsigned int 0) line 388 + 27 bytes
PresShell::Paint(PresShell * const 0x03c78cdc, nsIView * 0x03bca470, 
nsIRenderingContext & {...}, const nsRect & {...}) line 5798 + 36 bytes
nsView::Paint(nsView * const 0x03bca470, nsIRenderingContext & {...}, const 
nsRect & {...}, unsigned int 0, int & 1242444) line 280
nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x0407d590, 
nsIRenderingContext & {...}) line 1192
nsViewManager::RenderViews(nsView * 0x03f66cf0, nsIRenderingContext & {...}, 
const nsRect & {...}, int & 0) line 1141
nsViewManager::Refresh(nsView * 0x03f66cf0, nsIRenderingContext * 0x03b6e5c0, 
nsIRegion * 0x03ffca58, unsigned int 1) line 732
nsViewManager::DispatchEvent(nsViewManager * const 0x040680a8, nsGUIEvent * 
0x0012f85c, nsEventStatus * 0x0012f770) line 1732
HandleEvent(nsGUIEvent * 0x0012f85c) line 83
i found a way to fix it
I found imgloader load background img after documnet done,so when mozilla will
load a background img from http,it should not fire status,so i add a  judgement
in nsHttpConnection.cpp for stopping SocketTransport fire status.
Keywords: patch
Comment on attachment 84586 [details] [diff] [review]
This a new patch of the bug for RC2, please rv

It looks like you're on the right track.

But the way the channel is obtained is *pure evil* :-)

I'd making the loadFlags part of the nsHttpConnectionInfo.

I know this will make the patch bigger, but i think it's a cleaner solution...

darin, what do you think?

-- rick
Attachment #84586 - Flags: needs-work+
Comment on attachment 84586 [details] [diff] [review]
This a new patch of the bug for RC2, please rv

>Index: nsHttpConnection.cpp

>+    nsCOMPtr<nsIHttpChannel>
>+        channel = do_QueryInterface((NS_STATIC_CAST(nsHttpTransaction *,
>+                                     mTransaction))->Callbacks());

as rick said.. yuck!  we should maybe add a flag to the transaction's
Capabilities() attribute that indicate if the transaction is to suppress

>+    if (channel) {
>+        nsLoadFlags loadFlags = 0;
>+        channel->GetLoadFlags(&loadFlags);
>+    }
>     rv = mSocketTransport->
>-            SetNotificationCallbacks(this, nsITransport::DONT_PROXY_PROGRESS);
>+            SetNotificationCallbacks(this,
>+                                    ((loadFlags & nsIRequest::LOAD_BACKGROUND)
>+                                     ? nsITransport::DONT_REPORT_PROGRESS
>+                                      : nsITransport::DONT_PROXY_PROGRESS));

BTW: this code doesn't work... loadFlags is in the wrong scope.  does
this actually compile?

>Index: imgLoader.cpp

>+    if (aLoadFlags & nsIRequest::LOAD_BACKGROUND) {
>+      newChannel->SetLoadFlags(aLoadFlags);
>+    } else {
>+      if (aLoadGroup) {
>+        PRUint32 flags;
>+        aLoadGroup->GetLoadFlags(&flags);
>+        newChannel->SetLoadFlags(flags);
>+      }

why is this necessary?	maybe rick's imgLoader cleanup is needed??
i changed so code for set the aLoadFlags as channel'LoadFlags in 
imgloader,because when we load background the aLoadFlags will be 
nsIRequest::LOAD_BACKGROUND,i added it in channel,but i can set it in another 
class,like httptransaction or something else,my patch can fix this bug,i 
replace channel'loadflags with aLoadFlags when mozilla load background img,so 
when httpconnection will run,it can get channel's loadflag and judge it whether 
we should let transport fire status event,i promiss my patch is work fine in my 
build,but i know i should change some code,i newd discuss with darin,find a 
good ideal.
i think i can add loadflag in httpconnectioninfo,then in httpconnection,i will 
ger it and judge it for whether transport should fire status.what do you think 
my ideal?
sorry for the spam, but I produced a reduced testcase for another bug, which
show the issue described here:
1. Load ,
2. Hit Shift-Reload,
3. Mouse over the image,
4. See the 'Tranferring from...' in status bar.

1. First load the image: ,
2. Load
3. Mouse over the image,
4. No 'Transferring from...' in status bar.

Is it because of a broken GIF ?

This is with build 2002052204 on Win2k.
can I have an onload on a background image?

Shouldn't this be hanlded higher up? Just because its in the background doens't
mean that the load is happening - surely docshell (or whoever) should be the one
suppressing this?
darin ,can i add a public function in nsHttpChannel.cpp for get mconnectioninfo?
This is second patch for this bug,i set background aloadflag in connectioninfo
and transfer the loadflag to nsHttpConnection by connectioninfo,so i must add
some code in nsHttpChannel,i had tested the patch,it work ok,please rv
&sr.Thank you
Comment on attachment 84763 [details] [diff] [review]
This is second of this bug,according to advices of rick and darin,please rv & sr 

loadFlags are an attribute of the channel, not the connection.	a connection
may be reused with multiple channels, so it is incorrect to associate loadFlags
with nsHttpConnectionInfo.  

i also don't understand why you need to add nsIHttpChannel::setBgImgLoadFlag...
we should be able to use nsIRequest::loadFlags for this.
Attachment #84763 - Flags: needs-work+
I just experienced this bug talking to on the page where I
posted another bug and it says "Bug ..... posted".  I have a bitmap of the
window.  It says "Transferring data from" even after the
page is complete.
i had merge the backgound into channel's loadflag,then judge it in
httptrannsaction for suppress fire status,so please rv & sr my patch
Comment on attachment 84887 [details] [diff] [review]
this is  third patch according to darin's advice.

>Index: nsHttpChannel.cpp

>     }
>+    if (mLoadFlags & nsIRequest::LOAD_BACKGROUND)
>     // create the transaction object

nit: how about an extra newline above and below this new code?

>Index: imgLoader.cpp

>+      if (aLoadFlags & nsIRequest::LOAD_BACKGROUND) {
>+        newChannel->SetLoadFlags(flags | nsIRequest::LOAD_BACKGROUND);
>+      } else {
>+        newChannel->SetLoadFlags(flags);
>+      }

nit: how about this instead:

>+      if (aLoadFlags & nsIRequest::LOAD_BACKGROUND)
>+        flags |= nsIRequest::LOAD_BACKGROUND;
>+      newChannel->SetLoadFlags(flags);

otherwise, the patch looks good to me.	how have you tested it?
Attachment #84887 - Flags: needs-work+
change some code according to darin's advice,i had tested my patch,it is work
fine.please rv and sr,thank you.
Comment on attachment 85134 [details] [diff] [review]
final patch according Darin's advice,thank you,please rv & sr

looks good, but there's another place in imgLoader.cpp where SetLoadFlags is
called.  does it need to have a similar LOAD_BACKGROUND check?
please give me rv & sr,Thank you
Attachment #84586 - Attachment is obsolete: true
Attachment #84763 - Attachment is obsolete: true
Attachment #84887 - Attachment is obsolete: true
Comment on attachment 85381 [details] [diff] [review]
add some code for this bug in final patch,make my patch firmly.please rv & sr

>Index: imgLoader.cpp


>     }
>     NS_NEWXPCOM(request, imgRequest);

nit: please don't add/remove whitespace like this.

otherwise, sr=darin
Attachment #85381 - Flags: superreview+
Attached patch final patch (obsolete) — Splinter Review
please rv my final patch
Comment on attachment 85394 [details] [diff] [review]
final patch

you are still adding whitespace where it does not belong!  please review your
patch carefully for such things ;)
Attachment #85394 - Flags: needs-work+
sorry,i didn't understant your means in comment #82,so i now i clear,so please
rv &sr my patch
Comment on attachment 85418 [details] [diff] [review]
final patch,please rv & sr

looks fine, r=bbaetz. I could never reproduce this, so I can't test it to see
if it works all the time
Attachment #85418 - Flags: review+
Comment on attachment 85418 [details] [diff] [review]
final patch,please rv & sr

Attachment #85418 - Flags: superreview+
Might this get into RC4 if there is one?
*** Bug 147946 has been marked as a duplicate of this bug. ***
I saw and tried this patch, but it did not fix the problem described in Bug 147946.
Comment on attachment 85418 [details] [diff] [review]
final patch,please rv & sr

the imgLoader changes are fine with me.
i found a way to fix dup bug147946,i will add patch tomorrow.
Becuase my first patch can not fix dup bug147946,so i had added second patch
for dup bug147946,i had tested my new patch,it could resolve bug147964's
problem,but i have to change some layout code,so i need other prople's
advice,but anyway,if it is correct fix,please rv &sr.thank you
Keywords: mozilla1.0.1
Comment on attachment 85873 [details] [diff] [review]
This is second patch for dup bug147946.please rv & sr

I don't think this is the right fix.  Normal images shouldn't be loaded in the
background, even if they are loaded after the document is finished.  

I feel quite sure that this is a bug in the docshell code and these changes
should not be required at all.
Attachment #85873 - Flags: needs-work+
Another test case:  Note that this actually happens to be
my own Web site, so if there's an issue with the code I can easily fix it if
somebody can point it out.

With the 2002060208 trunk build under XP I can confirm that problem with the
MozillaZine Website (original URL described) has been fixed - so headway is
definitely being made.
Happens on and on my corp. home page ( ONLY on first
load after clearing cache: reload handles status bar correctly. Both pages
contain a background image in a table cell. When I removed these on (which remains available), status bar error went away,
even after clearing cache.
It only happens on "" - the main page.  It never used
to happen there before.  This is a regression.  However, as I said in comment
#95, it's NOT happening (for me anyway) on
"" anymore.

So whatever patch was checked in seems to have fixed one instance and broken
i will see the new problem about my fix,and i way to fix them,give me some time.
i didn't see any regression,could you give me some detail.
Prior to the patch checkin, the page "" did NOT show
"Transferring data from..."  When going to that page it always showed "Document:
Done" as expected.  It was only the "/forums/" sub-page of MozillaZine that had
the problem.  Now the situation is reversed.  Where the main page did not have
any problem before the patch, now it does.  (Conversely, the sub-page has been

See comment #3 for confirmation of previous behaviour.  Now it's reversed.
I'm now also seeing this bug when logged into Hotmail, but the symptoms are a
bit different in that a Reload does no good.  The "Transferring data..."
remains.  I can't recall that this bug was present with Hotmail previously, but
I can't say for certain.
i had research the docshell,but i haven't result,so i add another patch for
bug147946,i didn't set aloadgroup into il->LoadImage(uri, baseURI,
loadGroup......when attribute change,so it will let img fire status,final it
will fire document done,this  behave like IE.please rv and sr,so i must sleep
now ,it is too late for me.
may this be a dup of bug 39310 ?
i had changed some code in nsDocLoaderImpl::StopURLLoad,we can get active count
from loadgroup,if the count =0,we should run another fireOnStateChange for fire
document done,so i add another fireonstatechange and edit some code for avoid
queryinterface failing in nsBrowserStatusHandler.js.hi Darin,please rv and sr
my patch.
Attachment #85873 - Attachment is obsolete: true
Attachment #86413 - Attachment is obsolete: true
Comment on attachment 87205 [details] [diff] [review]
This is new patch for dup bug147946.need rv & sr 

As a reminder to me, the problem here was that one should not send stop request
unless one sends start requests.  Antonio was going to attack the problem from
the JS side.
Why would that QI fail?
change some logic in my patch,add a new state for it,please rv & sr
I don't quite get it. Why do we need this |currentLoadTime|? What's preventing
us from using the existing mechanism to record start of document load and end of
document load and showing the time it took?
I use "currentLoadTime" for record one request's start time. When mozilla 
finish load a request,and the request is a only one request,i will force 
Browser fire document done status, so i need total time of this request to make 
default msg.
So why don't we send |STATE_START & STATE_IS_NETWORK| before the request, and
Jag: Antonio tells me that sending STATE_START | STATE_IS_NETWORK changes the
title (even though that ought to happen on STATE_IS_NETWORK).  I am inclined to
believe him and furthermore I am inclined to believe that we have such mixed
abstractions all over the browser.

Antonio: what happens with this when JS loads two images or resources at once? 
(Is this even possible?)  Really, I am not sure this is the best hack to do. 
Here are the two alternatives I think are best:

Small(er) Fix: find a way for WebProgress to send state that indicates whether
we are currently loading a document.  Better yet, set a flag in
nsBrowserStatusHandler that gets set to true when START|DOCUMENT occurs and
false when STOP|DOCUMENT occurs.  That way, if STOP|REQUEST happens, you can
check whether you're in a document and if you're not, check if load group count
is 0, and if it is, stop the progress bar.

Larger "correct" fix: make START|NETWORK and STOP|NETWORK work properly and send
those.  This means checking all places that look at STATE_IS_NETWORK (and maybe
some that do !STATE_IS_...) and make sure they do the right thing when just a
single image loads.

The fix you has does the job, at the expense of bloating the interface ... BTW,
if darin decides this fix is OK (he should decide on interface changes) then you
I found sending start|network will change some element like stopbutton and 
stopmenu....when request loading a img. It is didn't agree with Stuart.  If we 
sending start|network will allow somebody stop loaging img.  We shouldn't do 
it. if i can use start|network and stop|network, i can do it only change one 
line code in imgloader.cpp.  Because start&stop network change some element we 
didn't want to change.
My fix for two img is work fine. when stop the first img loading, i will not 
fire state_is _onlyone_request dut to the available request count!=0, so when 
stop the second img, it will happen.
I still can not give up my opinion. Because if i use a falg for judge whether 
the request is only one request, i must pass a flag into 
nsBrowserStatusHandler.js, but it will change more code in nsDocLoader.cpp, and 
change the frame of nsDocLoader.cpp. i think we shouldn't use start|network 
when fire request|start. Because we can't know it is a only one request or it 
is a last one request in a document loading. so i think the best way is, don't 
care request|start, we only care request|stop. If it is a only one request,and 
it isn't in a document loading, we should fire a stop state to force change 
some status and progress.  I hope you can agree with my fix.
Attached patch JS-only Patch (obsolete) — Splinter Review
This patch just changes the chrome to detect whether a document is being loaded
or not.  If it is, and we receive STOP, and the load group is at 0, we turn off
the progress meter and the status bar, reverting it to its previous value.

This assumes that we want the status bar to flicker while images are loading,
or do progress while *big* images are loading.
Attached patch JS-only Patch v1.0.1 (obsolete) — Splinter Review
Remove silly tabs.
Attachment #87478 - Attachment is obsolete: true
add some code for get img loadtime.
Hello, Jkeiser. I had added some code for this bug, and i add some code for
make throbber throb when open request, but i don't think we should change
button's state.  Couls you rv= ?bug133250.  Thank you
Attachment #87480 - Attachment is obsolete: true
Comment on attachment 87489 [details] [diff] [review]
Change some code due to Jkeiser's advice 

1. You need to put if (!aWebProgress.isLoadingDocument &
aRequest.loadGroup.activeCount == 1) around the throbber start and
currentLoadTime start, and you also need to initialize statusMeter,
finishedRequests and totalRequests in that case.

2. As noted before, you should find a way to share the status/throbber/progress
meter initialization and stopping code with the STOP|NETWORK case.  No
duplication of code is necessary, please.

3. Nit: aWebProgress.IsLoadingDocument -> aWebProgress.isLoadingDocument
Attachment #87489 - Flags: needs-work+
Comment on attachment 87489 [details] [diff] [review]
Change some code due to Jkeiser's advice 

>Index: nsIWebProgress.idl

>+  /**
>+   * The IsLoadingDocument associated with the WebProgress instance
>+   */
>+  readonly attribute PRBool IsLoadingDocument;

nsIWebProgress is an embedding API that is UNDER_REVIEW which means that
you will need to get approval from the module owner for this API before
you change anything.  i'm not sure who that would be, but i'd start by

>Index: nsBrowserStatusHandler.js
>+          this.throbberElement.setAttribute("busy", true);
>+        this.currentLoadTime = (new Date()).getTime();

	  this.currentLoadTime =;

same thing below...

>+            var elapsed = ((new Date()).getTime() - this.currentLoadTime) / 1000;
Darin: rpotts was the one who suggested it :)
jkeiser: ok, great!! no worries then :-)
Attached patch Consolidated Patch (obsolete) — Splinter Review
This patch:
- changes things to use
- does more of the start initialization
- consolidates initialization so that start|request and start|network use the
same code (except stop button)
- consolidates stop|request and stop|network so that they use the same code
(due to this the diff is bigger, since we had to move things into ifs protect
the QueryInterface of nsIRequest to nsIChannel and do some things slightly
differently if the request is not a channel, as in the case of img)
- adds comments
Attachment #85134 - Attachment is obsolete: true
Attachment #85381 - Attachment is obsolete: true
Attachment #85394 - Attachment is obsolete: true
Attachment #85418 - Attachment is obsolete: true
Attachment #87205 - Attachment is obsolete: true
Attachment #87341 - Attachment is obsolete: true
Attachment #87479 - Attachment is obsolete: true
Attachment #87489 - Attachment is obsolete: true
I'd like to point out for the sake of credit that I am just doing rearranging
here, doing some things that will help make the code more maintainable.  This
patch is Antonio's.

Additionally, I am tired and it is more than likely that the patch can be made a
tad bit simpler (though I bet it won't be *much* simpler).  Antonio is looking
at it now :)
Thinking about it, what's wrong with enabling the stop button when an image is
being downloaded? Why not provide the user with an opportunity to cancel it, if
it's a big download for example? So back to my question: why don't we send
|STATE_START & STATE_IS_NETWORK| before the request, and
|STATE_STOP & STATE_IS_NETWORK| after it? Especially if it's a one line change,
I would love to try that out for a while and see how that feels.
Attachment #85418 - Attachment is obsolete: false
Attached patch Consolidated Patch V1.1 (obsolete) — Splinter Review
only simple change,i think we don't need "- currentLoadTime : 0". :)
Another thing, my patch 85418 can fix bug133250,but it is can not fix
bug133250's dup bug147946,so i had to add another patch for bug147946, it is
this patch,but it only can fix please don't revoke my fist patch.

Thank you
Attachment #87660 - Attachment is obsolete: true
jag: The problem is that other people than just us assume that NETWORK has to do
with the document.  I just tried the START_NETWORK thing and had a browser crash.
I've been looking through the code and it appears that STATE_IS_NETWORK and
STATE_IS_DOCUMENT as they currently are, are nearly identical.  The only
difference is STATE_IS_DOCUMENT is sent on redirect while STATE_IS_NETWORK is not.

I believe we should fix the interface before it is frozen; and it turns out that
fixing the interface and sending NETWORK when load groups start will fix this
too.  It is up to rpotts and darin whether that is a separate bug.
Now,I will try to answer Jag's question.the STATE_START|STATE_IS_NETWORK is 
probably means mozilla start load a html file, it will change some browser 
window's status and do some preparative thing. But a html file maybe have some 
element like img, so when mozilla will load img in a html file, it will fire 
STATE_START|STATE_IS_REQUEST,but it didn't means we start loading a new file.  
If we ues STATE_START|STATE_IS_NETWORK for every document and element, it will  
make mozilla wrong, the progress and state and status maybe have a lot wrong. 
So when load a img after document with js, it will met a problem, mozilla 
didn't fire document done and leave over the progress and status.  So i and 
Jkeiser make a patch for fix this problem.
Ah, I thought we were able to distinguish between images loaded while the
document is loading, and images loaded after it's done loading (from js I
guess), and based on that send |STATE_START & STATE_IS_NETWORK| in the latter case.

I'm starting to like the last patch though. When images are loaded after the
document is done, can we make it so that the user can stop them (in other words,
keep the enabling/disabling of the stop button and items where it currently is)?
Also, I'm wondering how much testing the latest patch has had, since it's
|IsLoadingDocument| in the IDL but |isLoadingDocument| in the js.
Change some code for make stopbutton activated when start loading img afer
document done, and make it stopped when stop loading img afer document done.
Hi, Jkeiser could you rv=? bug133250
Attachment #87666 - Attachment is obsolete: true
Comment on attachment 87779 [details] [diff] [review]
Consolidated Patch V1.2

r=jkeiser :)
Attachment #87779 - Flags: review+
One qualification on that r=.  You need to test:

1. Run it against a page with a frames and make sure the throbber runs and stops
2. Run it against a page with many images and make sure the progress bar moves
through many steps
3. Try doing Stop on a normal page and make sure it stops loading
4. Try doing Stop when you are directly loading an image (for example and make sure it
stops loading the image
5. Try doing Stop when JS is loading an image and make sure it stops loading the

Anyone else have tests?
Test finish
1.Using a page with 4 frames, the throbber works fine.
2.Using a page with 5 images, the progress bar moves.
3.Using "",loading then stopping, mozilla works fine.
4.Using usl of images above, mozilla loading images works fine.
5.Trying stop JS loading a images, Stoping works fine.
Blocks: 114497
The changes to nsIWebProgress and nsDocLoader.cpp look good to me.

-- rick
Blocks: 1.1b
*** Bug 153914 has been marked as a duplicate of this bug. ***
Comment on attachment 87779 [details] [diff] [review]
Consolidated Patch V1.2
Attachment #87779 - Flags: superreview+
*** Bug 155214 has been marked as a duplicate of this bug. ***
two patchs have been checked in trunk,I think we resolve this bug.
Closed: 18 years ago
Resolution: --- → FIXED
It looks like this increased page load times on btek about 10ms (which isn't
surprising, given the number of times the code in nsBrowserStatusHandler.js is
called).  Hopefully what darin is working on in bug 144533 will help with this,
reassign to me
Assignee: darin → antonio.xu
I'm still seeing incorrect status bar text.  When a tab of a set of 4 was up (1
of which was loading from a site), the "Transfering data from" message would not go away.

This is in build 2002072608.

It'd be nice if each tab would have their own private access to the status bar,
and thde status bar would show "Document: done" if the *current* tab was loaded.
 That might also reduce the contention problem which is leaving my status bar in
incorrect states.

For example, I went to the bad tab and hit reload.  Now all four tabs are
loaded, and the status bar text is incorrectly set to "Sending request to".

To view a screenshot of this bug in action, see
Resolution: FIXED → ---
Open a new bug please, that's really a different problem.
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
*** Bug 151318 has been marked as a duplicate of this bug. ***
For the record.

We investigated this and I can tell you for future reference exactly what caused 
the regression.

It was pavlov's checkin for 62108

Our testcase was

I'm glad to see there was a general fix for this - we fixed it by backing out 
pavlov's imgLoader fix.
Whiteboard: [adt3][RTM] → [adt3][RTM]branchOEM
Whiteboard: [adt3][RTM]branchOEM → [adt3][RTM] branchOEM+
patch checked into NETSCAPE_7_0_OEM_BRANCH
Whiteboard: [adt3][RTM] branchOEM+ → [adt3][RTM] branchOEM+ fixedOEM
Whiteboard: [adt3][RTM] branchOEM+ fixedOEM → [adt3][RTM] fixedOEM
This is happening again on the trunk. 2002082109 trunk sees this problem quite a
bit on Windows XP.
Keywords: mozilla1.0, nsbeta1-
Whiteboard: [adt3][RTM] fixedOEM → fixedOEM
*** Bug 165287 has been marked as a duplicate of this bug. ***
I see it still...Jump to
and you will see the "Transfer data from..." on the status bar..

Also people are seeing on the trunk ...see couple comments before this comment.

can someone reopen this bug....

As I mentioned in bug 165287, the status bar shows "Done" for me right away. 
(I'm using 2002082804 trunk / XP).

However, I did notice something interesting when looking more closely - the
throbber keeps going forever, despite the status bar text indicating (for me
anyway) that the load is complete.  (If this in an indication that *something*
is going on then perhaps the status text you're getting is correct, and mine is
not.  In which case, I may have been too hasty in duping bug 165287 to this one.)

Is anybody else still seeing this in recent builds on any site?  Jerry, can you
confirm your statement in comment 146?
I see the problem with on MacOS 9.1 Build 2002082808

It is running for 10 minutes now

Works with NS4

I have tried to use the stop button (It is enabled, Mozilla icon is spinning).
No effect.
I will take a look at it.
it is really a regression,but I don't why is it happen? I must research it.
Is this really fixed?!
using trunk build 2002090108 on win-xp pro still has it remaining on the 
status bar!

Resolution: FIXED → ---
I don't know why did the regression happen, so I must research it,I'm sure my 
fix is good for tis bug,but now I can see the problem with the trunk. it is 
must be caused by another check in. 
Keywords: embed, top100
Keywords: fixedOEM
Whiteboard: fixedOEM
It's much more apparent now in the latest builds (9/18+). is a good test site.  If it doesn't stay after
loading a page try reloading it...
Is bug 166428 a duplicate or just similar?
That would depend on whether or not this bug and that one have the same root
cause.  I went to bug 166428 and tried the test URL.  On the 2nd reload I got
"Transferring data from..." remaining in the status bar, not "Sending
request..." as per that bug.
I have no more problems with (MAC OS 9.1 Build 2002102508). Comment 

Works also with

it is not very clear for me.
In a first step all works fine. But after a few seconds Mozilla load an another 
thing. The status test is reset to "Done", that is correct, But the progress bar 
stays filled at 100% and is never reset
Since I cannot reproduce this bug with the latest build, I'm wondering, has this
been fixed somehow?
Keywords: mozilla1.0.1mozilla1.3
Re: previous comment. I can still reproduce the problem with Mozilla 1.2 beta on
Windows 98 following the steps in comment 20.
Keywords: nsbeta1
Mozilla 1.2beta is not the latest build.  If you can reproduce this with the
latest build, please reopen, but neither I nor others can.

The issue is now filed
as bug 184806.
Closed: 18 years ago17 years ago
Resolution: --- → FIXED
i really can reproduce it on a propritary webpage. i'm trying to make a testcase. 
Rick: cool.  Please open a different bug when you do, however.  This bug is
fixed and it will be hard and confusing to do work in.
I had this yesterday with trunk build 2002121004.
Will look for Rick's new bug and keep my eyes open for how to still reproduce it.
verified  - 12/11/02 builds - winNT4, linux rh6, mac osX
FWIW: There seems to be some kind of regression going on with the status bar and
tabs that's causing the original bug as I reported it ("Transferring data
from...") to still be happening.  In recent builds, I've seen a marked increase
in the problem.  I will look down at the status bar and see the text in
question, despite the page being loaded.  Also, I am currently looking at the
status bar as I type this and seeing "Sending request to"
- even though that's opened in another tab and it *has* finished loading.

I'm not sure if this is a regression of this specific bug, or something else. 
In any case, I am unable to find a reproducible test case so I will not yet
reopen anything.
Further investigation.  Even if "Transferring data from..." does not appear when
a site is initially loaded, it *always* will when doing a regular reload. 
(Shift Reload makes the text go away and produces "Done".)  So go to any Web
site, look for "Transferring data from..." and, if you don't see it, do a
regular reload.

As for intitial loads, MozillaZine seems to always produce the effect again. 
Here's a link:

I can reproduce this 100% of the time.  Reopening.
Resolution: FIXED → ---
Forgot to mention - this is build 2002121408 under Windows XP.
Due to private communication, it's been suggested that I keep this bug closed
and file an (identical) bug to deal with the regression.  (Due to the "unwieldy"
nature of the congested patches/comments/dependencies here.)

As such, I've file bug 185615 to address the regression.  My apologies for any
inconvenience to those still on this bug's CC list who don't actually care any more.

Closing as "Fixed" (for historical purposes anyway).
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Whiteboard: DO NOT REOPEN. Further work in bug 185615.
Verifiying as per comment #171 and Whiteboard coments.
Whiteboard: DO NOT REOPEN. Further work in bug 185615. → DO NOT REOPEN. Further work in bug 185547
You need to log in before you can comment on or make changes to this bug.