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

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Wayne Woods]

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.

Comment 1

[Uri Bernstein]

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

[pile0nades]

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

Comment 3

[Uri Bernstein]

Changing summary to match description.

Comment 4

[Wayne Woods]

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

Comment 5

[Ria Klaassen (not reading all bugmail)]

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.

Comment 6

[Ria Klaassen (not reading all bugmail)]

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. 

Comment 7

[Ria Klaassen (not reading all bugmail)]

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

Comment 8

[Wayne Woods]

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?

Comment 9

[Ria Klaassen (not reading all bugmail)]

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

Comment 10

[Simon Bünzli]

Attachment: 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.

Comment 11

[Simon Bünzli]

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 12

[Mike Connor [:mconnor]]

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.

Comment 13

[Simon Bünzli]

Attachment: 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.

Comment 14

[Wayne Woods]

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.

Comment 15

[Simon Bünzli]

Attachment: 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.

Comment 16

[Wayne Woods]

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.

Comment 17

[Mike Connor [:mconnor]]

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.

Comment 18

[Simon Bünzli]

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

Comment 19

[:Gavin Sharp [email: [e-mail]]]

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

Comment 20

[Simon Bünzli]

Attachment: patch for checkin

Comment 21

[Ria Klaassen (not reading all bugmail)]

I think the extension helps for I haven't seen the problem the last two days.

Comment 22

[Bryan]

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

Comment 23

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Sorry, didn't mean to change the status of this bug.

Comment 24

[:Gavin Sharp [email: [e-mail]]]

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

Comment 25

[Bryan]

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

[Worcester12345]

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

What about 1.5.0.2 branch?

Comment 27

[Mike Connor [:mconnor]]

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

[Darin Fisher]

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?

Comment 29

[Jesse Ruderman]

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

Comment 30

[Simon Bünzli]

Attachment: "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).

Comment 31

[Mike Connor [: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 :)

Comment 32

[François Gagné]

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

[Brian Polidoro]

(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

[François Gagné]

(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

[Bryan]

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

~B

Comment 36

[Tracy Walker [:tracy]]

Verified with Windows, Mac and Linux 2.0b1rc3 builds 

Comment 37

[Ria Klaassen (not reading all bugmail)]

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