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

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Jason Bassford]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020322
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.
3.

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

Expected Results:  Status bar text should change to "Document: Done".

Comment 1

[Arthur]

Confirming on Linux 2002032421.

Comment 2

[Tony Wilson]

Confirming on Win Me 2002032408

Comment 3

[Joe O'Connor]

Confirmed on W2K SP2 2002032408. Problem doesn't appear on www.mozillazine.org
front page, but  does appear in the Build Talkback section
http://www.mozillazine.org/talkback/list.php?f=4

Comment 4

[Matthias Versen [:Matti]]

-> XP APPS (Browser genral doen't fix bugs..., please select a good component if
you confirm a bug.)

Comment 5

[Alfonso Martinez]

*** Bug 133196 has been marked as a duplicate of this bug. ***

Comment 6

[David G King]

Note: I see this on Mozillazine with build 2002031903 under Win 98SE.

Comment 7

[Asa Dotzler [:asa]]

->networking. high-visibility recent regression (sometime in the last few days I
think)

Comment 8

[jsp]

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.

Comment 9

[Dan Tobias]

It's doing it for me in Win98 with 2002032503 on several sites.
One URL it does it for is:  http://www.21stcenturyalert.com/

Comment 10

[Dustin Marquess]

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 www.mozillazine.org...',
which of course does not belong in THIS tab..

Comment 11

[Darin Fisher]

is this problem only occuring when using multiple tabs?

i haven't seen this problem myself.

-> docshell

Comment 12

[Jason Bassford]

Darin: You mean you don't see the problem when going to the reference URL:
http://www.mozillazine.org/talkback/ 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?

Comment 13

[Eugene Savitsky]

I see this on the http://www.mozillazine.org/talkback/.

moz 2002032603, XP

Comment 14

[Dustin Marquess]

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
mouse-over).

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?

Comment 15

[Adam Lock]

-> Tabbed browser

Comment 16

[Adam Lock]

.

Comment 17

[Arthur]

Adam, this bug occurs also without tabs (see given URL), tabs just seem to
trigger it more often.

Comment 18

[Mark Bitterling]

I can confirm that this is happenning with Mac OS X build 2002032608 without
involving any tab browsing

Comment 19

[Samir Gehani]

Nav triage team: What kinds/how many websites will this affect?  Does this
affect the top 100 trafficked sites?

Comment 20

[jsp]

I don't know if it's in the top 100 or not, but home.netscape.com 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 http://home.netscape.com.
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?

Comment 21

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 22

[jsp]

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.

Comment 23

[jag (Peter Annema)]

-> 1.0

Comment 24

[Frederic Bezies]

wfm 2002041306 - WinXP.

Comment 25

[Tuukka Tolvanen (sp3000)]

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.

HEAD:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2002-03-07+00%3A00%3A00&maxdate=2002-03-07+21%3A00%3A00&cvsroot=%2Fcvsroot

MOZILLA_0_9_9_BRANCH:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_0_9_9_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2002-03-07+00%3A00%3A00&maxdate=2002-03-07+21%3A00%3A00&cvsroot=%2Fcvsroot

Comment 26

[Jason Bassford]

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

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 "mozilla-win32-svg-mathml.zip".

Comment 27

[Jonas Jørgensen]

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
Docshell.

Comment 28

[Jason Bassford]

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.

Comment 29

[David G King]

I disagree with comment #24

It doesn't work for me with builds 2002041303 or 2002041308 on Win98SE.

Comment 30

[Sören 'Chucker' Kuklau (gone)]

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.

Comment 31

[David G King]

I got the builds from the following URL's

http://download.mozilla.org/pub/mozilla/nightly/2002-04-13-03-WIN_GMAKE/
http://download.mozilla.org/pub/mozilla/nightly/2002-04-13-08-WIN_GMAKE/

If these are branch (1.0.0) builds rather than trunk builds then it sure isn't
obvious.

Comment 32

[Jason Bassford]

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:

ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/

This is what's linked to in the QA -> Latest Builds menu.

Comment 33

[David G King]

So, what about the builds found at :-

http://download.mozilla.org/pub/mozilla/nightly/latest-WIN_GMAKE/

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")

Comment 34

[Jason Bassford]

That's a good question.  I wish I knew what the "GMAKE" set of binaries were about.

Comment 35

[Jonadab the Unsightly One (Nathan Eady)]

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.  

Comment 36

[Jason Bassford]

I just installed build 2002041408 from the "usual" source, in my case the
installer version -
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer.exe -
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.

Comment 37

[Adam Lock]

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
problem.

I will CC a few of the Necko folks to see if its an issue they might recognize.

Comment 38

[jsp]

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.

Comment 39

[Darin Fisher]

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?

Comment 40

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 41

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 42

[Adam Lock]

CC Rick for ideas

Comment 43

[Adam Lock]

There is something very odd about this URL in the page:

http://images.paypal.com/images/x-click-but04.gif

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.

Comment 44

[Adam Lock]

Attachment: Log file

Comment 45

[Adam Lock]

Reassigning to netwerk.  I think the status updates are a side effect of
something odd happening lower down. See the odd URL I posted.

Comment 46

[Pete Boyd]

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

Comment 47

[Antonio.Xu]

i will research this bug.

Comment 48

[Antonio.Xu]

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.

Comment 49

[Darin Fisher]

sounds like a problem with tabbed browsing then... jag?

Comment 50

[Jason Bassford]

Still reproducible (http://www.mozillazine.org/talkback/) 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.

Comment 51

[Darin Fisher]

jason:

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.

Comment 52

[Antonio.Xu]

I can reproduce this bug on solaris with RC1 & RC2,but i can not reproduce this 
bug on win2000 with trunk 2002/05/12.

Comment 53

[Lasse Marøen]

It seems to me that this has something to do with image swapping with
javascript. See testcases here:
http://lama.no/mozilla/bug133250/
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.

Comment 54

[jsp]

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.

Comment 55

[Jason Bassford]

> 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?

Comment 56

[Antonio.Xu]

I can reproduce this bug sometime on win2000 with RC2,i will research this 
bug,please give me some time.

Comment 57

[Boris Zbarsky [:bzbarsky]]

*** Bug 144983 has been marked as a duplicate of this bug. ***

Comment 58

[Darin Fisher]

mass futuring of untargeted bugs

Comment 59

[Pete Boyd]

*** Bug 136007 has been marked as a duplicate of this bug. ***

Comment 60

[Pete Boyd]

bug 136007 has a testcase for this bug

Comment 61

[Pete Boyd]

*** Bug 145464 has been marked as a duplicate of this bug. ***

Comment 62

[Antonio.Xu]

it will have another transfer data status after document done,i will research 
why it was happen.

Comment 63

[Antonio.Xu]

i found mozilla will get http://www.mozillazine.org/image/new/tile_new.png 
again ,when mozilla load http://www.mozillazine.org/talkback/ completely then 
the http://www.mozillazine.org/image/new/tile_new.png load done,it did't fire 
document doen event.

Comment 64

[Antonio.Xu]

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 
bytes
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

Comment 65

[Antonio.Xu]

i found a way to fix it

Comment 66

[Antonio.Xu]

Attachment: This a new patch of the bug for RC2, please rv

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.

Comment 67

[rpotts (gone)]

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

Comment 68

[Darin Fisher]

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
notifications.

>+    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??

Comment 69

[Antonio.Xu]

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.

Comment 70

[Antonio.Xu]

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?

Comment 71

[Olivier Cahagne]

sorry for the spam, but I produced a reduced testcase for another bug, which
show the issue described here:
1. Load http://wolruf.free.fr/mozbug/103530.html ,
2. Hit Shift-Reload,
3. Mouse over the image,
4. See the 'Tranferring from...' in status bar.

Workaround:
1. First load the image: http://wolruf.free.fr/mozbug/off.gif ,
2. Load http://wolruf.free.fr/mozbug/103530.html
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.

Comment 72

[Bradley Baetz (:bbaetz)]

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?

Comment 73

[Antonio.Xu]

darin ,can i add a public function in nsHttpChannel.cpp for get mconnectioninfo?

Comment 74

[Antonio.Xu]

Attachment: This is second of this bug,according to advices of rick and darin,please rv & sr

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 75

[Darin Fisher]

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.

Comment 76

[David Campbell]

I just experienced this bug talking to bugzilla.mozilla.org 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 bugzill.mozilla.org..." even after the
page is complete.

Comment 77

[Antonio.Xu]

Attachment: this is third patch according to darin's advice.

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 78

[Darin Fisher]

Comment on attachment 84887 [details] [diff] [review]
this is  third patch according to darin's advice.

>Index: nsHttpChannel.cpp

>     }
>-
>+    if (mLoadFlags & nsIRequest::LOAD_BACKGROUND)
>+        caps |= NS_HTTP_DONT_REPORT_PROGRESS;
>     // 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?

Comment 79

[Antonio.Xu]

Attachment: final patch according Darin's advice,thank you,please rv & sr

change some code according to darin's advice,i had tested my patch,it is work
fine.please rv and sr,thank you.

Comment 80

[Darin Fisher]

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?

Comment 81

[Antonio.Xu]

Attachment: add some code for this bug in final patch,make my patch firmly.please rv & sr

please give me rv & sr,Thank you

Comment 82

[Darin Fisher]

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

Comment 83

[Antonio.Xu]

Attachment: final patch

please rv my final patch

Comment 84

[Darin Fisher]

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 ;)

Comment 85

[Antonio.Xu]

Attachment: final patch,please rv & sr

sorry,i didn't understant your means in comment #82,so i now i clear,so please
rv &sr my patch

Comment 86

[Bradley Baetz (:bbaetz)]

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

Comment 87

[Darin Fisher]

Comment on attachment 85418 [details] [diff] [review]
final patch,please rv & sr

sr=darin

Comment 88

[jsp]

Might this get into RC4 if there is one?

Comment 89

[Pete Boyd]

*** Bug 147946 has been marked as a duplicate of this bug. ***

Comment 90

[Thomas Schoepf]

I saw and tried this patch, but it did not fix the problem described in Bug 147946.

Comment 91

[Stuart Parmenter]

Comment on attachment 85418 [details] [diff] [review]
final patch,please rv & sr

the imgLoader changes are fine with me.

Comment 92

[Antonio.Xu]

i found a way to fix dup bug147946,i will add patch tomorrow.

Comment 93

[Antonio.Xu]

Attachment: This is second patch for dup bug147946.please rv & sr

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

Comment 94

[Stuart Parmenter]

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.

Comment 95

[Jason Bassford]

Another test case: http://www.dante.com/  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.

Comment 96

[David Merrill]

Happens on mozillazine.org and on my corp. home page (orenews.com) 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
orenews.com/indexB.html (which remains available), status bar error went away,
even after clearing cache.

Comment 97

[Jason Bassford]

It only happens on "http://www.mozillazine.org/" - 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
"http://www.mozillazine.com/talkback/" anymore.

So whatever patch was checked in seems to have fixed one instance and broken
another...

Comment 98

[Antonio.Xu]

i will see the new problem about my fix,and i way to fix them,give me some time.

Comment 99

[Antonio.Xu]

i didn't see any regression,could you give me some detail.

Comment 100

[Jason Bassford]

Prior to the patch checkin, the page "http://www.mozillazine.org/" 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
fixed.)

See comment #3 for confirmation of previous behaviour.  Now it's reversed.

Comment 101

[Jason Bassford]

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.

Comment 102

[Antonio.Xu]

Attachment: This is third patch for dup bug147946.please rv & sr

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.

Comment 103

[Christoph]

may this be a dup of bug 39310 ?

Comment 104

[Antonio.Xu]

Attachment: This is new patch for dup bug147946.need rv & sr

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.

Comment 105

[John Keiser (jkeiser)]

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.

Comment 106

[jag (Peter Annema)]

Why would that QI fail?

Comment 107

[Antonio.Xu]

Attachment: This is fouth patch for dup bug147946.need rv & sr

change some logic in my patch,add a new state for it,please rv & sr

Comment 108

[jag (Peter Annema)]

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?

Comment 109

[Antonio.Xu]

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.

Comment 110

[jag (Peter Annema)]

So why don't we send |STATE_START & STATE_IS_NETWORK| before the request, and
|STATE_STOP & STATE_IS_NETWORK| after it?

Comment 111

[John Keiser (jkeiser)]

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
need to send STATE_START|STATE_IS_ONLYONE_REQUEST as well.

Comment 112

[Antonio.Xu]

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.

Comment 113

[John Keiser (jkeiser)]

Attachment: JS-only Patch

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.

Comment 114

[John Keiser (jkeiser)]

Attachment: JS-only Patch v1.0.1

Remove silly tabs.

Comment 115

[Antonio.Xu]

Attachment: final patch for bug133250's dup bug

add some code for get img loadtime.

Comment 116

[Antonio.Xu]

Attachment: Change some code due to Jkeiser's advice

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

Comment 117

[John Keiser (jkeiser)]

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

Comment 118

[Darin Fisher]

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
asking [e-mail].


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

nit:
	  this.currentLoadTime = Date.now();

same thing below...

>+            var elapsed = ((new Date()).getTime() - this.currentLoadTime) / 1000;

Comment 119

[John Keiser (jkeiser)]

Darin: rpotts was the one who suggested it :)

Comment 120

[Darin Fisher]

jkeiser: ok, great!! no worries then :-)

Comment 121

[John Keiser (jkeiser)]

Attachment: Consolidated Patch

This patch:
- changes things to use Date.now()
- 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

Comment 122

[John Keiser (jkeiser)]

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 :)

Comment 123

[jag (Peter Annema)]

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.

Comment 124

[Antonio.Xu]

Attachment: Consolidated Patch V1.1

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 bug147946.so please don't revoke my fist patch.

Thank you

Comment 125

[John Keiser (jkeiser)]

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.

Comment 126

[John Keiser (jkeiser)]

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.

Comment 127

[Antonio.Xu]

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.

Comment 128

[jag (Peter Annema)]

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.

Comment 129

[Antonio.Xu]

Attachment: Consolidated Patch V1.2

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

Comment 130

[John Keiser (jkeiser)]

Comment on attachment 87779 [details] [diff] [review]
Consolidated Patch V1.2

r=jkeiser :)

Comment 131

[John Keiser (jkeiser)]

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
http://www.digitalblasphemy.com/graphics/freeg/smidgeons.jpg) 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
image

Anyone else have tests?

Comment 132

[Antonio.Xu]

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 "www.cnn.com",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.

Comment 133

[rpotts (gone)]

The changes to nsIWebProgress and nsDocLoader.cpp look good to me.

-- rick

Comment 134

[Pete Boyd]

*** Bug 153914 has been marked as a duplicate of this bug. ***

Comment 135

[rpotts (gone)]

Comment on attachment 87779 [details] [diff] [review]
Consolidated Patch V1.2

sr=[e-mail]

Comment 136

[Sven Krohlas]

*** Bug 155214 has been marked as a duplicate of this bug. ***

Comment 137

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 87779 [details] [diff] [review]
Consolidated Patch V1.2

checked in

Comment 138

[Antonio.Xu]

two patchs have been checked in trunk,I think we resolve this bug.

Comment 139

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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,
though.

Comment 140

[Antonio.Xu]

reassign to me

Comment 141

[dylang]

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 mozdev.org site), the "Transfering data from
mozillazine.org" 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
browserg.mozdev.org".

To view a screenshot of this bug in action, see
http://web.thock.com/mozilla/bug133250.png

Comment 142

[John Keiser (jkeiser)]

Open a new bug please, that's really a different problem.

Comment 143

[Michael Lefevre]

*** Bug 151318 has been marked as a duplicate of this bug. ***

Comment 144

[Mike Kaply [:mkaply]]

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 http://www.kaply.com/work/fluff.html

I'm glad to see there was a general fix for this - we fixed it by backing out 
pavlov's imgLoader fix.

Comment 145

[Antonio.Xu]

patch checked into NETSCAPE_7_0_OEM_BRANCH

Comment 146

[Jerry Baker]

This is happening again on the trunk. 2002082109 trunk sees this problem quite a
bit on Windows XP.

Comment 147

[Jason Bassford]

*** Bug 165287 has been marked as a duplicate of this bug. ***

Comment 148

[sujay]

I see it still...Jump to http://www.kzgolf.com
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....

Comment 149

[Jason Bassford]

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?

Comment 150

[Jean-Pierre Melkonian]

I see the problem with http://www.kzgolf.com on MacOS 9.1 Build 2002082808

Comment 151

[Jean-Pierre Melkonian]

Look http://www.darty.fr/

It is running for 10 minutes now

Works with NS4

Comment 152

[Jean-Pierre Melkonian]

I have tried to use the stop button (It is enabled, Mozilla icon is spinning).
No effect.

Comment 153

[Antonio.Xu]

I will take a look at it.

Comment 154

[Antonio.Xu]

it is really a regression,but I don't why is it happen? I must research it.

Comment 155

[Markus Hübner]

Is this really fixed?!
http://webreference.com/dhtml/column66/HM4-3/LoadMe.html
using trunk build 2002090108 on win-xp pro still has it remaining on the 
status bar!

Comment 156

[Antonio.Xu]

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. 

Comment 157

[Jason Bassford]

It's much more apparent now in the latest builds (9/18+). 
http://www.mozillazine.com/ is a good test site.  If it doesn't stay after
loading a page try reloading it...

Comment 158

[Ere Maijala (slow)]

Is bug 166428 a duplicate or just similar?

Comment 159

[Jason Bassford]

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.

Comment 160

[Jean-Pierre Melkonian]

I have no more problems with www.darty.fr (MAC OS 9.1 Build 2002102508). Comment 
151

Works also with http://www.21stcenturyalert.com/

With http://webreference.com/dhtml/column66/HM4-3/LoadMe.html
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

Comment 161

[Jay Davis]

Since I cannot reproduce this bug with the latest build, I'm wondering, has this
been fixed somehow?

Comment 162

[Andrew Hagen]

Re: previous comment. I can still reproduce the problem with Mozilla 1.2 beta on
Windows 98 following the steps in comment 20.

Comment 163

[John Keiser (jkeiser)]

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 http://webreference.com/dhtml/column66/HM4-3/LoadMe.html issue is now filed
as bug 184806.

Comment 164

[Rick Ju]

i really can reproduce it on a propritary webpage. i'm trying to make a testcase. 

Comment 165

[John Keiser (jkeiser)]

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.

Comment 166

[Andreas Kunz]

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.

Comment 167

[Tom Everingham]

verified  - 12/11/02 builds - winNT4, linux rh6, mac osX

Comment 168

[Jason Bassford]

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 www.mozillazine.org..."
- 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.

Comment 169

[Jason Bassford]

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:

http://www.mozillazine.org/forums/viewforum.php?f=4&sid=d8cf58cacf1b8fa71c80c8c9692a6354

I can reproduce this 100% of the time.  Reopening.

Comment 170

[Jason Bassford]

Forgot to mention - this is build 2002121408 under Windows XP.

Comment 171

[Jason Bassford]

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).

Comment 172

[David G King]

Verifiying as per comment #171 and Whiteboard coments.