If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Status bar message text persists when switching tabs while page is loading

VERIFIED FIXED in Firefox 2 alpha2

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
12 years ago
7 years ago

People

(Reporter: Wayne Woods, Assigned: Simon Bünzli)

Tracking

({verified1.8.1})

2.0 Branch
Firefox 2 alpha2
verified1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox2 +
blocking1.8.0.4 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

12 years ago
This bug has been opened because bug 104532 was closed due to a fix in SeaMonkey. The problem persists in Firefox, however. There are many Firefox dupes to that bug, but it's ultimately easier to just open a fresh bug report...

Essentially, the text on the left hand side of the status bar, which is presented during page loading, persists when you switch to another tab.

The status bar in the second tab will not be updated by any further changes in the status of the original tab, however. The status bar text can only be changed by switching to a tab in which a page is loading (including the original) and waiting for the the status message to update. A side-effect of this is that if the original page finishes loading while you're in another tab, and you don't load any new pages, then the status message remains in all tabs indefinitely.

To reproduce, open at least two tabs. Start loading http://www.mozilla.org in one. Before the page can finish loading, switch to another tab. Check the status bar. It should say something akin to "Transferring data from www.mozilla.org...", even though it's not relevant to the current tab. Note that this text remains static unless you switch back to the first tab and receive a new status update, or you start loading a page in the new tab.

Repeat the above, and wait until the Mozilla page has fully loaded before switching back to it. Note that the status message now remains for all tabs, including new ones you open, unless you start to load a new page.
(Reporter)

Updated

12 years ago
Flags: blocking1.8.0.3?
Flags: blocking1.9a1?
The following bugs are direct duplicates of this one (i.e., reported for Firefox, and not involving setting the status bar text using JavaScript):
bug 208874, bug 210877, bug 220250, bug 234784, bug 244430, bug 245322, bug 250971, bug 251133, bug 252030, bug 257135, bug 267617, bug 268294, bug 268595, bug 268745, bug 272366, bug 274040, bug 289109, bug 289445, bug 292816, bug 296226, bug 297757, bug 300097, bug 300361, bug 300775, bug 307443, bug 308860, bug 326387.

This issue was resolved for Seamonkey (before Mozilla 1.4) by attachment 124853 [details] [diff] [review] (bug 104532 comment #96). The patch has a comment reading "XXX temporary hack for bug 104532".
A similar hack can probably be added to the corresponding Firefox code.

Comment 2

12 years ago
I tried some experimenting with this. I installed the Extension Developer Extension (http://ted.mielczarek.org/code/mozilla/extensiondev/). Using the JS Shell, I tried this code:

gBrowser.getBrowserAtIndex(gBrowser.mTabContainer.selectedIndex).status

which is an empty string for some reason. Or is this code wrong? I can get the title of the current tab, or any other tab using this:

gBrowser.getBrowserAtIndex(0).contentDocument.title

and this works. Is it another bug that the first code returns an empty string?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060215 Firefox/1.5 - Build ID: 2006021503
Changing summary to match description.
Summary: Status bar ticker text persists when switching tabs → Status bar message text persists when switching tabs while page is loading
(Reporter)

Comment 4

12 years ago
(In reply to comment #1)
> This issue was resolved for Seamonkey (before Mozilla 1.4) by attachment 124853 [details] [diff] [review] [edit]
> (bug 104532 comment #96). The patch has a comment reading "XXX temporary hack
> for bug 104532".
> A similar hack can probably be added to the corresponding Firefox code.

The SeaMonkey solution seems to do nothing more than wipe the status bar between tab switches. So even if the tab has a page loading, the status message is blank until the next time it receives an update. It's better than nothing, but really the current status for the tab (including "Done" if it finished loading) needs to be added instead.

Note that bug 327596 (including patch - attachment 212194 [details] [diff] [review]) has been created to improve the status update for SeaMonkey. If it applies the current status message for the tab, then perhaps it could be adapted for this bug. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060224 Firefox/1.6a1 ID:2006022408
I see a frozen green progress indicator on the first tab (with the statusbar text "Done") after closing the other tabs.
This is very annoying: when I have one tab open and I load Gmail in another tab and I close Gmail while it is loading (which is very frequently the case for it reloads very often) I see the frozen green progress indicator on the first tab. 
What I also see, is when the green progress indicator is frozen on the first tab the toolbar Reload button is disabled so you can't reload this page, because Firefox thinks the page is still in a loading state (which is not, for the indicator belonged to the closed Gmail tab). 
(Reporter)

Comment 8

12 years ago
What OS are you using? I don't see any bugs with the Win XP and Mac OS X builds, but then I don't see a green progress indicator, either. Are you using some special theme?
(In reply to comment #8)
> 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060309 Firefox/1.6a1 ID:2006030922
No, default theme. It happens every day a few times. Gmail auto-reloads very frequently so the chance that it is reloading at the moment that I close the Gmail tab is very high. 
(Assignee)

Comment 10

12 years ago
Created attachment 214682 [details] [diff] [review]
Cache the status bar values in tabbrowser.xml and update them at tab switching

This patch should correctly fix the problem by storing the status bar values for all tabs and updating when tabs are switched.
Assignee: nobody → zeniko
Status: NEW → ASSIGNED
Attachment #214682 - Flags: review?(mconnor)

Updated

12 years ago
Flags: blocking-firefox2?
(Assignee)

Comment 11

12 years ago
If you want to test the attached patch without modifying Firefox' source, you can download it in form of an extension from the following thread (see the Bug 327604 section): http://forums.mozillazine.org/viewtopic.php?t=370248
Comment on attachment 214682 [details] [diff] [review]
Cache the status bar values in tabbrowser.xml and update them at tab switching

>+              this.mTotalProgress = (aMaxTotalProgress)?aCurTotalProgress / aMaxTotalProgress:0;

the brackets are bogus, spaces around operators please.

r=me otherwise.
Attachment #214682 - Flags: review?(mconnor)
Attachment #214682 - Flags: review+
Attachment #214682 - Flags: approval-branch-1.8.1+

Updated

12 years ago
Flags: blocking-firefox2? → blocking-firefox2+
(Assignee)

Comment 13

12 years ago
Created attachment 214948 [details] [diff] [review]
reset the cached values at STATE_START

I actually got the event order wrong in the first patch. This patch should give more correct results in some edge cases. Re-requesting review due to code path changes. Should I also need superreview, please suggest an appropriate reviewer.
Attachment #214682 - Attachment is obsolete: true
Attachment #214948 - Flags: review?(mconnor)
(Reporter)

Comment 14

12 years ago
Just out of curiosity, how does this compare to the proposed fix for SeaMonkey (bug 327596, attachment 212194 [details] [diff] [review])? Your patch seems to be far more extensive, and I'm curious to know if that means it's a better fix, or if Firefox just needs more code to fix it.

And will the fix apply stuff like "Done" if the tab has finished loading, or "Waiting for..."? :) I was going to try out your extension to see, but wasn't sure if the extension works correctly now that you've altered the patch, anyway.
(Assignee)

Comment 15

12 years ago
Created attachment 214996 [details] [diff] [review]
correctly set "busy" indication between STATE_START and STATE_STOP

Another minor update to the patch above: it could happen in some rare cases that the throbber wasn't set to busy although the page was still loading.

(In reply to comment #14)
> how does this compare to the proposed fix for SeaMonkey
> (bug 327596, attachment 212194 [details] [diff] [review])? Your patch seems to be far more extensive, and
> I'm curious to know if that means it's a better fix, or if Firefox just needs
> more code to fix it.

This patch should be pretty comprehensive; i.e. it should make sure that loading state (Done, Stopped, Timed out), transfer state (Waiting, Connecting, etc.) and progress state are correctly set when you switch tabs.

For testing, just (re)download the extension from the link mentioned above. I've updated it for each patch I posted.
Attachment #214948 - Attachment is obsolete: true
Attachment #214996 - Flags: review?(mconnor)
Attachment #214948 - Flags: review?(mconnor)
(Reporter)

Comment 16

12 years ago
Thanks. I downloaded the extension and tested it in the Mac nightly. Will try the Windows one at work tomorrow.

Only one bug so far... Even though the status bar is empty when you open a new window, in every new tab you open, it's set to "Done", even though the tab is fresh.

Apart from that, everything seemed to work as it should. :)

On a related issue, I notice that the page activity indicator on the mouse arrow seems to indicate activity when hovering over the tab bar when one of the pages is loading in the background, even though you're not actually hovering over that tab. But I expect that's a separate bug.
(Assignee)

Updated

12 years ago
Depends on: 330452
Comment on attachment 214996 [details] [diff] [review]
correctly set "busy" indication between STATE_START and STATE_STOP

>+
>+              if (aStateFlags & (nsIWebProgressListener.STATE_START
>+                                 | nsIWebProgressListener.STATE_STOP)) {

nit: operator before the linebreak please.

I think this looks good, I'm still pretty wiped though.
Attachment #214996 - Flags: review?(mconnor) → review+
(Assignee)

Comment 18

12 years ago
(In reply to comment #17)
> I think this looks good, I'm still pretty wiped though.

Wiped?

Do I need superreview for this (and if so who'd be a candidate)?
And: Gavin, can you take care of the nit when checking in - or do you want another patch?

(In reply to comment #16)
> Only one bug so far... Even though the status bar is empty when you open a new
> window, in every new tab you open, it's set to "Done", even though the tab is
> fresh.
This will be taken care of in bug 330452.
(In reply to comment #18)
> Do I need superreview for this (and if so who'd be a candidate)?

No. No super review is required for files in mozilla/browser or mozilla/toolkit. See http://www.mozilla.org/projects/firefox/review.html and http://www.mozilla.org/projects/toolkit/review.html.

> And: Gavin, can you take care of the nit when checking in - or do you want
> another patch?

Doesn't hurt to attach a final patch, but I can fix on check in.
Whiteboard: [checkin needed]
(Assignee)

Comment 20

12 years ago
Created attachment 215046 [details] [diff] [review]
patch for checkin
Attachment #214996 - Attachment is obsolete: true
I think the extension helps for I haven't seen the problem the last two days.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 22

12 years ago
Was this checked in?  I don't see it as being checked in on http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&date=hours&hours=24&mindate=1123874820&maxdate=1123881179&cvsroot=%2Fcvsroot

~B
Sorry, didn't mean to change the status of this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → NEW

Updated

12 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 2 alpha2
Trunk:
mozilla/browser/base/content/browser.js 	1.595
mozilla/toolkit/content/widgets/tabbrowser.xml 	1.137
1_8:
mozilla/browser/base/content/browser.js 	1.479.2.99
mozilla/toolkit/content/widgets/tabbrowser.xml 	1.103.2.29
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago12 years ago
Flags: blocking1.9a1?
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Version: Trunk → 2.0 Branch

Comment 25

12 years ago
Things are much improved with this patch but have seen two instances where the status bar is not updated correctly or set to "Done".  I'll try to reproduce the issue and document the steps here...

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060322 Firefox/2.0a1 ID:2006032221

Bryan

Comment 26

12 years ago
(In reply to comment #24)
...
> 1_8:
...

What about 1.5.0.2 branch?

This patch isn't really appropriate for 1.5.0.x, but you should know that by now.  Please try to learn a little bit more about what should go where instead of asking all of these questions in Bugzilla, since you're really bordering on spam these days.

Comment 28

12 years ago
mconnor: so, you recommend 1.8.0.3- for this bug?  or, do you just feel that the current patch is not appropriate for a 1.8.0.x release and that we should try for a different patch?
Flags: blocking1.8.0.3? → blocking1.8.0.3-
(Assignee)

Updated

12 years ago
Depends on: 331938

Comment 29

12 years ago
This still doesn't work correctly when JavaScript in one tab sets window.status.  Uri's comment 1 makes it sound like that's considered a separate bug.  Has a bug like that been filed (and not marked as a dup of bug 104532)?
(Assignee)

Comment 30

12 years ago
Created attachment 217400 [details] [diff] [review]
"temporary hack for bug 104532" for Firefox

That is a separate bug. While connection status is available on a per-tab base, status messages set from JavaScript are per window and simply not available for background tabs (this seems to be a limitation of nsIXULBrowserWindow). To fix this issue, I suggest landing the patch mentioned in comment 1 also for Firefox (cf. attachment).
Attachment #217400 - Flags: review?(mconnor)
Comment on attachment 217400 [details] [diff] [review]
"temporary hack for bug 104532" for Firefox

Ok, that'll work for now, not that we enable content to set status anyway :)
Attachment #217400 - Flags: review?(mconnor)
Attachment #217400 - Flags: review+
Attachment #217400 - Flags: approval-branch-1.8.1+

Comment 32

12 years ago
The status text act strangely when:

1)Open http://www.mozilla.org
2)Open the link 'Firefox and Thunderbird Have a New Home' in a new tab (leads to http://www.mozilla.com/)
3)Click the new tab with http://www.mozilla.com/ loaded
4)Click back on the http://www.mozilla.org tab.

The status text written is 'http://www.mozilla.com/' instead of 'Done'. If you past hover another link it solve the problem (status text go back to 'Done'). If you change to another tab and go back to this tab the problem reappear (status text 'http://www.mozilla.com/')

Comment 33

12 years ago
(In reply to comment #32)
I don't think that's a bug.  What happens is that the link to mozilla.com on the mozilla.org page has focus so the status shows mozilla.com.  If you hit the tab button a few times then other links will get focus and the status changes to show the URLs of those links.  

It seems to be an issue of keyboard focus vs cursor focus.  I guess when you change tabs keyboard focus is used to set the status because the mouse is probably on the tabbar.

Comment 34

12 years ago
(In reply to comment #33)
This is most probably a focus problem because even if I double-click on the page background on mozilla.org and thus unselect the selected/active link the status text don't go back to 'Done', it stays at 'http://www.mozilla.com/'.

So I guess this is a bug that was not possible to see before the per-tab status text persistence was corrected?

Comment 35

11 years ago
Starting to see this more often now.  Has anything been checked in that would make this more pronounced?

~B

Updated

11 years ago
Depends on: 343847
Verified with Windows, Mac and Linux 2.0b1rc3 builds 
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1
*** Bug 353084 has been marked as a duplicate of this bug. ***
Depends on: 371243
(Assignee)

Updated

9 years ago
Blocks: 483895

Updated

7 years ago
Blocks: 583317
Depends on: 597421
No longer blocks: 483895
You need to log in before you can comment on or make changes to this bug.