Closed Bug 185547 Opened 19 years ago Closed 16 years ago

Status bar displays "transferring data from . . ." when tab or page done loading or reloading

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 209330
Milestone:
mozilla1.4final

People

(Reporter: mrmazda, Assigned: jag+mozilla)

References

(
URL
)

Details

(Keywords: regression, testcase, topembed+, Whiteboard: [adt1])

Attachments

(1 file)

mozilla image (from Slashdot)
2.53 KB, image/gif
Details 
2002121404 Linux trunk & 2002121409 OS/2 trunk.

To reproduce:
1-Open a bunch of bugzilla bugs in tabs
2-Mouse select a different tab
3-Click reload button
4-Wait for done on status bar and grayed out stop button
5-Mouse select a different tab
6-Click reload button
7-Wait for done on status bar and grayed out stop button
8-Goto 6 as required

Actual behavior:
1-Stop button grayed out when reload complete
2-"Transferring data from mozilla.org" remains on status bar

Expected behavior:
1-Stop button grayed out when reload complete
2-"Done" on status bar
*** Bug 185615 has been marked as a duplicate of this bug. ***
assign/qa change from duped bug 185615
Assignee: hyatt → antonio.xu
Component: XP Toolkit/Widgets: XUL → Networking: HTTP
QA Contact: shrir → tever
Actually, it doesn't matter how many tabs you have open - and some sites produce
the effect regardless of having done a reload or not.

Despite the fact that bug 185615 is a higher number, I'm reversing the duping
order since it's more accurate.

*** This bug has been marked as a duplicate of 185615 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Component: Networking: HTTP → XP Toolkit/Widgets: XUL
Resolution: --- → DUPLICATE
yeah, dupe war
*** Bug 185615 has been marked as a duplicate of this bug. ***
Poster of later bug who searched first would have found this, since the quote in
summary is exact match.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reference URL to reproduce:

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

Note that doing a Shift-Reload will load the page properly ("Done").

This bug is actually a regression from bug 133250, but that bug should not be
reopened due to its congestion.
Keywords: regression
Component: XP Toolkit/Widgets: XUL → Networking: HTTP
Bringing across dup instructions from Bug #185615, which are far easier to read
and gives a 100% reproducable testcase.

-->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 -
-->see reference URL.
Component: Networking: HTTP → XP Toolkit/Widgets: XUL
I wrote what I wrote because it is true. On some tabs when I click reload, done
appears. This is still true in 2002121512. It may be that only the tabs with
local files loaded are where done appears, since that is the case with my
current tab set. Done always fails to appear after I click reload on any Mozilla
bug in my current tab set.

So, is this really XUL, or is it networking?
The original bug (133250) was pointed at Networking:HTTP.
I saw that, and changed this bug to networking with my comments following duping
185615 the first time. But, somewhere along the way, it got changed back to XUL,
which, because the stop button gets grayed, would seem to be at least as likely,
as cosmetic problem only.

Trying again to condense the summary, removing mozilla.org. Don't know why it
didn't register last try.
Summary: Status bar displays "transferring data from mozilla.org" when tab done reloading → Status bar displays "transferring data from . . ." when tab done reloading
dgk@metrocast.net, did you mean to change back component to 'XP toolkit/XUL
widgets' or was there some sort of conflict while you hit 'reload'?
If it was by accident (see 'View bug activity'), please change back to
Networking:HTTP, because that was the home of the original bug 133250... 
I have no idea how the component got changed. I added myself to the cc list, got
a mid-air collision, hit reload, and then tryied again. Oh well, as the log says
I'm the one who changed it (not that I intended to, or tried to), I'll change it
back.
Component: XP Toolkit/Widgets: XUL → Networking: HTTP
David: Not to worry.  If you look at the log you'll see that I, too, "changed"
it.  Like you, it happened to me because of a mid-air collision, back, and
reload.  (I managed to catch it and change it back.)  I can understand textbox
content remaining on a reload, but I think that all other form elements should
switch back to the original...
This pair of bugs has convinced me to quit using reload after a mid-air. On the
second bug I saw comment 5 after reload, but also saw OS still WXP. So, I went
ahead with my comment 6 that caused a mid-air on first try, since it looked like
he made the comment without remembering to make the change described in the
comment. Now after a mid-air I hit back, then copy my new comments to clipboard,
click the bug number link to load it new, and manually change anything else I
had changed before the mid-air.

*** Bug 186102 has been marked as a duplicate of this bug. ***
*** Bug 188099 has been marked as a duplicate of this bug. ***
*** Bug 189331 has been marked as a duplicate of this bug. ***
I was able to reproduce this with a small testcase. I setup a simple Apache
1.3.27 install on my Linux box and created the following html file

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Test page</title>
</head>
<body>
<img src="topicmozilla.gif" alt="">
</body>
</html>

I then viewed this in Mozilla via http://<ip-address>/test.html

If I comment out the <img> tag, then I don't see any "Transferring data from .."
on the status bar. With the <img> tag in the HTML, If I press reload, I get a
"Transferring data from .." in the status bar. This doesn't happen every time
but more like 4 out of 5 times. I tested it with Linux nightly build 2003012022

The other observation is that whilst the status bar is displaying the
transferring data, the stop button isn't active. So clicking on the stop button
doesn't help, but if you click in the space between the reload and stop button
then this stops the display on the status bar

I took the topicmozilla.gif from Slashdot. I'll attach it here in case somebody
wants to try and reproduce it

Hope this helps
Since I originally reported this, I've changed the URL to one where it happens
to me nearly 100% of the time, "View Bugs Already Reported Today" on
http://bugzilla.mozilla.org/. I don't find very many pages where this bug isn't
exhibited.
URL: http://www.mozillazine.org/forums/vie... → oard=&status_whiteboard_type=substrin...
I'm on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030114

I get this "transferring" message too:
see http://www.aaa.net.au/campbell/transferring.jpg

It seems that all bug 166428, bug 185547, bug 190044 and bug 190442 are caused
by the same problem, which is neither Mail/News or browser component. Could
anybody with better insight confirm this suspection and file a new general bug?

(it might be that 190042 is the general one alredy)
Ooops. Of course I meant that 185547 (this bug) is a candidate for making all
the others dups (instead of creating a general one)
Testcase is in comment 19. I had to reload a couple of times to see the bug, but
it does work as a testcase.
Keywords: testcase
I can reproduce it with 2003012914/Linux with my test case in <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=185547#c19"> comment 19 </a>

This occurs with/without pipelining enabled
Flags: blocking1.3?
This has been happening to me too. In fact, I just reproduced it by reloading
this page several times. (I'm not even using tabs.)

I'm using the Mozilla 1.3b RH8 RPMS with GTK2 support.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211

*** Bug 178539 has been marked as a duplicate of this bug. ***
*** Bug 178704 has been marked as a duplicate of this bug. ***
Flags: blocking1.3? → blocking1.3-
If memory cache is turned on and you refresh any page containing pictures then
page is correctly displayed but status bar displays "transferring data from . .
.". Try with www.google.com.
Can be reproduced on
http://www.deftone.com/blogzilla/archives/you_make_my_slist.html
(reproduced with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
Gecko/20030308)

When the page is loaded, 'Done' appears in the status bar for about a second,
then it is replaced by 'Transferring data from www.deftone.com...'

Shift+Reload works correctly ('Done' is displayed).
Flags: blocking1.3- → blocking1.3?
Drivers (Asa) already set the blocking 1.3 flag to "-", deciding that it should
not block it.  Only drivers should be changing it to or from such a status. 
(Having said that, I will not, myself, correct the situation.)
Flags: blocking1.3? → blocking1.3-
*** Bug 197770 has been marked as a duplicate of this bug. ***
I get this with multiple web pages, with or w/o tabs. I'm using Moz 1.3 
(Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312)
*** Bug 196874 has been marked as a duplicate of this bug. ***
*** Bug 198411 has been marked as a duplicate of this bug. ***
*** Bug 200403 has been marked as a duplicate of this bug. ***
*** Bug 200840 has been marked as a duplicate of this bug. ***
*** Bug 201949 has been marked as a duplicate of this bug. ***
This is still broken as of 2003041508
While I realize there are more important bugs to fix (crashers, hangs, etc), I'd
just like to point out that I've had to, on numerous occasions performance-test
IE vs. Mozilla from a user's perspective (which of course is less accurate), and
this includes watching the status bar, the stop button, and the throbber. 
Granted this was in Netscape 7.x and several Mozilla milestones, but I'd like to
see this fixed so I can 'accurately' measure when the browser's finished loading
its content.
Just done some testing, and I've narrowed the problem down to the browser status
filter component.
*** Bug 203032 has been marked as a duplicate of this bug. ***
Is this really an issue only when tabs are used?
Go to http://www.oreka.com
and the "transferring..." will stay, with or without tabs
> Is this really an issue only when tabs are used?

No, "tabs" in the summary is a bit of a red herring.  (Just re-read the first
few comments.) The problem occurs even without any tabs at all.  It's simply
that it's more "exposed" when you have a lot of tabs (more chance of seeing it).
Changing summary so that (hopefully) it is more clear.
Summary: Status bar displays "transferring data from . . ." when tab done reloading → Status bar displays "transferring data from . . ." when page or tab done reloading
Summary: Status bar displays "transferring data from . . ." when page or tab done reloading → Status bar displays "transferring data from . . ." when tab or page done reloading
*** Bug 203653 has been marked as a duplicate of this bug. ***
Flags: blocking1.4?
datapoint: i can repro the problem with firebird trunk 20030428 under win2k
using http://www.oreka.com

anto, jag: either of you investigating this?
adt: nsbeta1+/adt1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]
Since the bug does appear even without reloading page on http://www.oreka.com,
summary should be changed :)
Summary: Status bar displays "transferring data from . . ." when tab or page done reloading → Status bar displays "transferring data from . . ." when tab or page done loading or reloading
would like this along with bug 166428. Anto, have you had a chance to look at
this yet?
Flags: blocking1.4? → blocking1.4+
Sounds like "Done" status should clear the timer-queue of status modifications
(assuming "Done" doesn't come by too often).
Flags: blocking1.4+ → blocking1.4?
Could the problem here be something like nsBrowserStatusHandler needing to flush
queued up requests on status changes or something like that?

-dbaron (typing as Asa)
Flags: blocking1.4? → blocking1.4+
ADT: Nominating topembed
Keywords: topembed
The underlying problem of this is dealt with in bug 93015. I just tested that
patch and it fixes this.
Depends on: 93015
-> me
Assignee: antonio.xu → jaggernaut
Status: REOPENED → NEW
Well, I just pulled and built with the patch for bug 93015, and this still
appears, at least on my Windows 2000 build.
Confirming with build 2003051008 that this problem still exists after the fix
for bug 93015.
Changing Target Milestone to match Blocking status.
Target Milestone: --- → mozilla1.4final
Discussed in topembed bug triage.  Plussing.  If it's assigned to jag is this an
embedding problem?  If not please remove topembed keyword.
Keywords: topembed → topembed+
michael: the problem is generally caused by some miscommunication between gecko
and the application layer.  fixing this bug for mozilla could mean fixing this
bug for all embedders (if indeed the problem isn't entirely app level).  we
won't know until the problem is understood...
We'll have to wait for bug 93015 to be fixed again (part of the patch was backed
out), but I'm pretty confident it'll fix this bug.

There might be one more case of images being loaded from the cache not getting
added to the right loadgroup, I'll have to investigate (see bug 166428 comment 21).
*** Bug 205439 has been marked as a duplicate of this bug. ***
I don't see this since the checkin for bug 166428, is this fixed?
I can no longer reproduce it using the steps in comment 8 - which have always
"worked" for me until now.
With build 2003051216, windows 2000:
I cannot reproduce the always working http://www.oreka.com

but, do this
1. open a new tab (apart from the one you are now)
2. enter a url and press go
3. before page is done loading switch to the original tab

message "transferring.. " is still there and does not go away.
Confirming remaining bug as described in comment 66 - I see that behaviour also.
 However, does it seem reasonable that this particular problem will be fixed by
bug 104532?  (If so, we should mark a dependency.)
Definitely a dependency.  (If not an outright dupe, enabling this bug to be
closed as fixed.)  See bug 104532 comment 2.
Depends on: TabSwitchStatusBar
I agree, Comment #66 is a dup of Bug #104532 (although I seem to recall another
bug about a similar kind of thing). Anyway, I'll resolve this bug as Fixed by
Bug #93015, and let someone Verify of Reopen it as needed.
Status: NEW → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
Removing dependency for consistency.  (Unrelated to this bug now that's it's
resolved fixed, just to comment 66.)

I'll also verify the resolution as I can't produce the unwanted result with any
method I know, and as per other comments.
Status: RESOLVED → VERIFIED
No longer depends on: TabSwitchStatusBar
Does it means that BUG 104532 is finally going to be fixed as well? I though it
would have been fixed before this one...
Nope, that bug has a different cause. The fix for it isn't that hard (I think),
let me comment in the bug.
Actually, what I was thinking of (as an intermediate fix) is to clear the
various status text variables (see nsBrowserStatusHander::updateStatusField)
when switching from one tab to another. This should get rid of lingering
"Transferring from..." etc. from other tabs, but it doesn't give you the current
status text value.
*** Bug 207653 has been marked as a duplicate of this bug. ***
*** Bug 209050 has been marked as a duplicate of this bug. ***
*** Bug 209232 has been marked as a duplicate of this bug. ***
*** Bug 209816 has been marked as a duplicate of this bug. ***
This is still happening. I posted details here
https://bugzilla.mozilla.org/show_bug.cgi?id=275784#c8

Seems to have regressed again. See Comment #78 (and the URL it points to).
Changing example URL.

Confirmed with Mozilla 1.8a5 and Firefox 1.0 on WinXP SP2.
URL: http://bugzilla.mozilla.org/buglist.c... → http://www.oreka.com/
Status: VERIFIED → REOPENED
Flags: blocking1.8a6?
Resolution: FIXED → ---
Flags: blocking1.8a6? → blocking1.8a6-
*** Bug 278488 has been marked as a duplicate of this bug. ***
i don't know if anybody already said it, but it is also caused by flash-movies
loading pages via the loadVariables()-function or the loadVars-object. here is a
short summary, a minimalized reproduction-code and swf/fla files to test. i used
the current nightly build of the mozilla suite 2005022805:
http://v2.philsworld.de/firefoxbug/
mfg Philipp Heckel

*** This bug has been marked as a duplicate of 209330 ***
Status: REOPENED → RESOLVED
Closed: 18 years ago → 16 years ago
Resolution: --- → DUPLICATE
Do we reopen this bug since its duplicate was fixed, but this one was not, or
should we open a new one?
Jerry, please file a new bug and mention the bug number here.
(In reply to comment #84)
> Jerry, please file a new bug and mention the bug number here.

what now? as i can see there are still no reactions on this bug. a new bug
number would be really nice. ;)
You need to log in before you can comment on or make changes to this bug.