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)
Tracking
()
RESOLVED
DUPLICATE
of bug 209330
mozilla1.4final
People
(Reporter: mrmazda, Assigned: jag+mozilla)
References
()
Details
(Keywords: regression, testcase, topembed+, Whiteboard: [adt1])
Attachments
(1 file)
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
Reporter | ||
Comment 1•19 years ago
|
||
*** Bug 185615 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 2•19 years ago
|
||
assign/qa change from duped bug 185615
Assignee: hyatt → antonio.xu
Component: XP Toolkit/Widgets: XUL → Networking: HTTP
QA Contact: shrir → tever
Comment 3•19 years ago
|
||
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
Comment 4•19 years ago
|
||
yeah, dupe war
Reporter | ||
Comment 5•19 years ago
|
||
*** Bug 185615 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 6•19 years ago
|
||
Poster of later bug who searched first would have found this, since the quote in summary is exact match.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 7•19 years ago
|
||
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
Updated•19 years ago
|
Component: XP Toolkit/Widgets: XUL → Networking: HTTP
Comment 8•19 years ago
|
||
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
Updated•19 years ago
|
Reporter | ||
Comment 9•19 years ago
|
||
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?
Comment 10•19 years ago
|
||
The original bug (133250) was pointed at Networking:HTTP.
Reporter | ||
Comment 11•19 years ago
|
||
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
Comment 12•19 years ago
|
||
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...
Comment 13•19 years ago
|
||
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
Comment 14•19 years ago
|
||
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...
Reporter | ||
Comment 15•19 years ago
|
||
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.
Comment 16•19 years ago
|
||
*** Bug 186102 has been marked as a duplicate of this bug. ***
Comment 17•18 years ago
|
||
*** Bug 188099 has been marked as a duplicate of this bug. ***
Comment 18•18 years ago
|
||
*** Bug 189331 has been marked as a duplicate of this bug. ***
Comment 19•18 years ago
|
||
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
Comment 20•18 years ago
|
||
GIF attachment for comment http://bugzilla.mozilla.org/show_bug.cgi?id=185547#c19
Reporter | ||
Comment 21•18 years ago
|
||
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.
Comment 22•18 years ago
|
||
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
Comment 23•18 years ago
|
||
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)
Comment 24•18 years ago
|
||
Ooops. Of course I meant that 185547 (this bug) is a candidate for making all the others dups (instead of creating a general one)
Comment 25•18 years ago
|
||
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
Comment 26•18 years ago
|
||
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
Updated•18 years ago
|
Flags: blocking1.3?
Comment 27•18 years ago
|
||
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
Comment 28•18 years ago
|
||
*** Bug 178539 has been marked as a duplicate of this bug. ***
*** Bug 178704 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Flags: blocking1.3? → blocking1.3-
Comment 30•18 years ago
|
||
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.
Comment 31•18 years ago
|
||
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?
Comment 32•18 years ago
|
||
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.)
Updated•18 years ago
|
Flags: blocking1.3? → blocking1.3-
Comment 33•18 years ago
|
||
*** Bug 197770 has been marked as a duplicate of this bug. ***
Comment 34•18 years ago
|
||
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)
Comment 35•18 years ago
|
||
*** Bug 196874 has been marked as a duplicate of this bug. ***
Comment 36•18 years ago
|
||
*** Bug 198411 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Comment 37•18 years ago
|
||
*** Bug 200403 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 38•18 years ago
|
||
*** Bug 200840 has been marked as a duplicate of this bug. ***
Comment 39•18 years ago
|
||
*** Bug 201949 has been marked as a duplicate of this bug. ***
Comment 40•18 years ago
|
||
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.
Comment 42•18 years ago
|
||
Just done some testing, and I've narrowed the problem down to the browser status filter component.
Comment 43•18 years ago
|
||
*** Bug 203032 has been marked as a duplicate of this bug. ***
Comment 44•18 years ago
|
||
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
Comment 45•18 years ago
|
||
> 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).
Comment 46•18 years ago
|
||
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
Reporter | ||
Updated•18 years ago
|
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
Reporter | ||
Comment 47•18 years ago
|
||
*** Bug 203653 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Flags: blocking1.4?
Comment 48•18 years ago
|
||
datapoint: i can repro the problem with firebird trunk 20030428 under win2k using http://www.oreka.com anto, jag: either of you investigating this?
Comment 49•18 years ago
|
||
adt: nsbeta1+/adt1
Comment 50•18 years ago
|
||
Since the bug does appear even without reloading page on http://www.oreka.com, summary should be changed :)
Updated•18 years ago
|
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
Comment 51•18 years ago
|
||
would like this along with bug 166428. Anto, have you had a chance to look at this yet?
Flags: blocking1.4? → blocking1.4+
Comment 52•18 years ago
|
||
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?
Comment 53•18 years ago
|
||
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+
Assignee | ||
Comment 55•18 years ago
|
||
The underlying problem of this is dealt with in bug 93015. I just tested that patch and it fixes this.
Depends on: 93015
Well, I just pulled and built with the patch for bug 93015, and this still appears, at least on my Windows 2000 build.
Comment 58•18 years ago
|
||
Confirming with build 2003051008 that this problem still exists after the fix for bug 93015.
Comment 59•18 years ago
|
||
Changing Target Milestone to match Blocking status.
Target Milestone: --- → mozilla1.4final
Comment 60•18 years ago
|
||
Discussed in topembed bug triage. Plussing. If it's assigned to jag is this an embedding problem? If not please remove topembed keyword.
Comment 61•18 years ago
|
||
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...
Assignee | ||
Comment 62•18 years ago
|
||
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).
Comment 63•18 years ago
|
||
*** Bug 205439 has been marked as a duplicate of this bug. ***
Comment 64•18 years ago
|
||
I don't see this since the checkin for bug 166428, is this fixed?
Comment 65•18 years ago
|
||
I can no longer reproduce it using the steps in comment 8 - which have always "worked" for me until now.
Comment 66•18 years ago
|
||
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.
Comment 67•18 years ago
|
||
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.)
Comment 68•18 years ago
|
||
Definitely a dependency. (If not an outright dupe, enabling this bug to be closed as fixed.) See bug 104532 comment 2.
Depends on: TabSwitchStatusBar
Comment 69•18 years ago
|
||
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
Comment 70•18 years ago
|
||
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
Comment 71•18 years ago
|
||
Does it means that BUG 104532 is finally going to be fixed as well? I though it would have been fixed before this one...
Assignee | ||
Comment 72•18 years ago
|
||
Nope, that bug has a different cause. The fix for it isn't that hard (I think), let me comment in the bug.
Assignee | ||
Comment 73•18 years ago
|
||
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.
Comment 74•18 years ago
|
||
*** Bug 207653 has been marked as a duplicate of this bug. ***
Comment 75•18 years ago
|
||
*** Bug 209050 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 76•18 years ago
|
||
*** Bug 209232 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 77•18 years ago
|
||
*** Bug 209816 has been marked as a duplicate of this bug. ***
Comment 78•16 years ago
|
||
This is still happening. I posted details here https://bugzilla.mozilla.org/show_bug.cgi?id=275784#c8
Comment 79•16 years ago
|
||
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.
Status: VERIFIED → REOPENED
Flags: blocking1.8a6?
Resolution: FIXED → ---
Updated•16 years ago
|
Flags: blocking1.8a6? → blocking1.8a6-
Comment 80•16 years ago
|
||
*** Bug 278488 has been marked as a duplicate of this bug. ***
Comment 81•16 years ago
|
||
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
Comment 82•16 years ago
|
||
*** This bug has been marked as a duplicate of 209330 ***
Status: REOPENED → RESOLVED
Closed: 18 years ago → 16 years ago
Resolution: --- → DUPLICATE
Comment 83•16 years ago
|
||
Do we reopen this bug since its duplicate was fixed, but this one was not, or should we open a new one?
Comment 84•16 years ago
|
||
Jerry, please file a new bug and mention the bug number here.
Comment 85•16 years ago
|
||
(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.
Description
•