Last Comment Bug 104532 - (TabSwitchStatusBar) Status bar ticker fails to update when tabs switched.
(TabSwitchStatusBar)
: Status bar ticker fails to update when tabs switched.
Status: VERIFIED WORKSFORME
:
Product: SeaMonkey
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: P2 normal with 100 votes (vote)
: ---
Assigned To: neil@parkwaycc.co.uk
: sairuh (rarely reading bugmail)
Mentors:
: 107564 111597 112602 120091 122670 128108 129548 139770 140585 141770 144608 145423 147885 149168 151067 151713 152458 153119 159759 163609 sadsadsad 166779 178083 178730 181964 184551 184638 185002 185675 192426 193420 195658 198604 199885 199923 207278 208874 210877 211107 212268 213646 214243 215553 217961 219071 219226 219986 220250 220707 226834 226860 226909 227659 228312 228431 231074 233999 234784 237812 238191 238679 240032 243913 244430 245322 249676 249804 250971 251133 252030 252212 252986 256391 256819 257131 257135 260429 264421 267617 268294 268595 268745 272366 272950 274040 280666 281449 282015 287878 289109 289445 292816 296226 297757 300097 300361 300775 307443 308860 stbar.refresh 334391 343831 (view as bug list)
Depends on:
Blocks: advocacybugs 128632 327238
  Show dependency treegraph
 
Reported: 2001-10-12 20:54 PDT by Todd Cohn
Modified: 2010-05-26 12:24 PDT (History)
186 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Clear status when switching tabs (1018 bytes, patch)
2003-06-02 19:18 PDT, jag (Peter Annema)
neil: review+
Details | Diff | Review
I prefer this version :-) (680 bytes, patch)
2003-06-03 05:48 PDT, neil@parkwaycc.co.uk
jag-mozilla: review+
jag-mozilla: superreview+
asa: approval1.4+
Details | Diff | Review
Here's what I checked in on trunk (799 bytes, patch)
2003-06-03 15:03 PDT, jag (Peter Annema)
no flags Details | Diff | Review
Proposed patch (3.59 KB, patch)
2004-05-02 07:29 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Review
Moved ApplyChromeFlags into nsXULWindow.cpp (15.62 KB, patch)
2004-05-21 07:59 PDT, neil@parkwaycc.co.uk
danm.moz: review+
jst: superreview+
asa: approval1.8b+
Details | Diff | Review
some code (17.22 KB, patch)
2005-09-23 10:59 PDT, Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
no flags Details | Diff | Review

Description Todd Cohn 2001-10-12 20:54:09 PDT
If a page has a Status bar ticker it will be present even when another tab is
selected.  For example, go to http://www.cats-eye.com/ in one tab, then open a
new tab and go to http://bugzilla.mozilla.org/ and the cats-eye ticker will
remain on your status bar.  This in 0.9.5, Windows 98.
Comment 1 John Morrison 2001-10-12 21:03:46 PDT
yep. (i.e., a document is setting window.status on a timer; the same status
is shared by all windows).
Comment 2 Nick Pietraniec 2001-11-01 17:47:22 PST
Also, if you have 2 tabs and you start loading a page and then quickly switch
over to the other page, the status bar will say "connecting to" forever.

open 2 tabs:
Goto a website
before it's done loading, switch to the other tab
watch the status bar...
it will say "Connecting to www.xxxxx.com" forever.
Comment 3 Koike Kazuhiko 2001-11-15 20:06:51 PST
*** Bug 107564 has been marked as a duplicate of this bug. ***
Comment 4 Neil Pilgrim 2001-11-19 11:29:59 PST
I see this on linux 2001110815. IMO each tab should have its own status bar, or
more realistically its own status bar string, which is updated on switching tabs.
Comment 5 Niklas Mehner 2001-11-23 07:22:12 PST
*** Bug 111597 has been marked as a duplicate of this bug. ***
Comment 6 sairuh (rarely reading bugmail) 2001-11-26 17:54:04 PST
spam: set your filter for "SeverusSnape" to avoid the influx of bugmail

changing QA contact of open tabbed browser bugs from blake to me. if this bug
requires a reassignment, however, feel free to change it!
Comment 7 R.K.Aa. 2001-11-29 07:52:43 PST
*** Bug 112602 has been marked as a duplicate of this bug. ***
Comment 8 Ami Setton 2002-01-05 14:04:02 PST
It seems only the first tab can update the status line - this is annoying when
you want to see what a link is by hovering the mouse above it.

I would suggest that the status line be relevant only to the current tab.  Oops,
I mean: "I agree with comment #4".
Comment 9 sairuh (rarely reading bugmail) 2002-01-15 12:30:34 PST
*** Bug 120091 has been marked as a duplicate of this bug. ***
Comment 10 David Hyatt 2002-01-21 13:50:57 PST
Reassigning to new component owner.
Comment 11 Alfonso Martinez 2002-01-30 14:21:02 PST
*** Bug 122670 has been marked as a duplicate of this bug. ***
Comment 12 Peter Trudelle 2002-02-21 12:47:40 PST
nsbeta1+ per ADT triage team, ->1.0.
Comment 13 Alfonso Martinez 2002-02-27 14:20:01 PST
*** Bug 128108 has been marked as a duplicate of this bug. ***
Comment 14 Koike Kazuhiko 2002-03-07 13:25:37 PST
*** Bug 129548 has been marked as a duplicate of this bug. ***
Comment 15 Nick Kocharhook 2002-03-30 15:05:41 PST
Is this gonna get fixed for 1.0? It's mildly annoying, but it's certainly not
something people should be spending time on unless it's a really quick fix...
Comment 16 selmer (gone) 2002-04-03 14:01:09 PST
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!
Comment 17 Peter Trudelle 2002-04-10 00:30:22 PDT
removing plus for re-triage.
Comment 18 Samir Gehani 2002-04-10 11:16:48 PDT
Nav triage team: nsbeta1-
Comment 19 jag (Peter Annema) 2002-04-11 15:24:25 PDT
-> 1.1
Comment 20 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-04-24 09:19:05 PDT
*** Bug 139770 has been marked as a duplicate of this bug. ***
Comment 21 Kevin Cook 2002-04-24 21:35:39 PDT
This bug isn't a serious one, but.....  To the uninitiated, seeing this kind of
browser behaviour probably makes the whole browser look like it's messed up and
buggy, and really wouldn't inspire confidence in a user.

So, if Mozilla 1.0 is mainly destined for the developer community, I'd agree
that this bug is just "mildly annoying" as per comment #15.

On the other hand, if non-specialists will be using and evaluating this browser
too, this bug has the potential to be far more visible than some broken CSS
somewhere.

I'm just glad there aren't too too many pages these days with that scrolling
status bar effect!

Personal example:  I remember a version of Netscape (4.01 ?) several years back
that left an hourglass cursor on the screen after loading a page.  After seeing
that *just once* on a friend's computer, I vowed not to install that (presumably
buggy) browser on my system.  I stuck with an older version until the next release.
Comment 22 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-04-27 11:30:22 PDT
*** Bug 140585 has been marked as a duplicate of this bug. ***
Comment 23 Alfonso Martinez 2002-05-02 10:06:12 PDT
*** Bug 141770 has been marked as a duplicate of this bug. ***
Comment 24 Andrei Boros 2002-05-13 23:59:23 PDT
confirm behaviour on Mozilla post 1.0, nightly build 2002042806
Comment 25 R.K.Aa. 2002-05-14 16:49:36 PDT
*** Bug 144608 has been marked as a duplicate of this bug. ***
Comment 26 Alfonso Martinez 2002-05-18 01:53:20 PDT
*** Bug 145423 has been marked as a duplicate of this bug. ***
Comment 27 jerry asher 2002-05-18 10:37:22 PDT
I have little (to no) business commenting as I cannot contribute to Mozilla
apart from writing bug reports (however, it is evident this will not stop me
from commenting.)  

So just a comment that there have been 12 other bugs marked as a duplicate of
this bug.  Is that a high number of duplicates or a small number?  If a high
number than this does seem to indicate that while this is a minor bug from a
development point of view, it's indicative of a jarring user experience, and if
so, is more a normal or even major severity.
Comment 28 hugo van woerkom 2002-05-18 11:02:28 PDT
I wouldn't say that this minor bug is "jarring" as "disappointing and careless"
to an end-user. IE probably doesn't have this sort of thing. This should be
fixed first because it is very visible. As long as it exists the end-user will
think "they don't care".
Comment 29 Niklas Mehner 2002-05-29 10:19:45 PDT
*** Bug 147885 has been marked as a duplicate of this bug. ***
Comment 30 Alfonso Martinez 2002-06-05 00:31:38 PDT
*** Bug 149168 has been marked as a duplicate of this bug. ***
Comment 31 jag (Peter Annema) 2002-06-12 21:21:05 PDT
-> 1.2beta
Comment 32 Alfonso Martinez 2002-06-14 09:27:37 PDT
*** Bug 151713 has been marked as a duplicate of this bug. ***
Comment 33 Stefan Borggraefe 2002-06-16 08:36:56 PDT
*** Bug 151067 has been marked as a duplicate of this bug. ***
Comment 34 Maurício Collares Neto [:mauricioc] 2002-06-20 07:50:15 PDT
*** Bug 152458 has been marked as a duplicate of this bug. ***
Comment 35 Alfonso Martinez 2002-06-20 08:00:22 PDT
*** Bug 153119 has been marked as a duplicate of this bug. ***
Comment 36 Christian Eyrich 2002-07-06 08:14:22 PDT
In comment #21 Kevin wrote "I'm just glad there aren't too too many pages these
days with that scrolling status bar effect!" and so represents what I think much
people think of this bug: happens with tickers or other js things.

A major point is the muddle when loading pages in multi tab environment as Nick
stated in comment #2. This isn't a serious problem but one every user can see
and easy reproduce and very annoying.

That just to make clear what's affected and it's not this special.
Comment 37 Duke 2002-07-24 19:57:12 PDT
Confirm Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020714
This bug is terribly annoying when one of your tabs is displaying advertising
via the scroll bar (savannah.gnu.org, of all places.)  Off topic, I'd rather see
a banner ad than a scrolling ad in my status bar.

However, upon mousing over links, the scrolling ad goes away, and the link under
the mouse comes up.  So at least the bug doesn't allow the status bar to be
completely taken over.  I can also still see page loading progress, and other
status bar stuff.  Only when the status bar is available will it be taken over
by this scrolling ad.

Neat -- just now, I used one of the bug's effects, as detailed in Comment #2, to
get rid of the ad.  Now it permanently says "Sending request to.." unless I
mouse over something.
Comment 38 sairuh (rarely reading bugmail) 2002-08-02 17:37:43 PDT
nominating for buffy.
Comment 39 Daniel Yanez 2002-08-08 08:38:56 PDT
(Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530)
As a "non-specialists user" I found this bug very visible, in part by my
intensive use of tabs but, most important, due to my low-speed connection. I
could live with a status bar saying "sending request to bugzilla.mozzilla.org"
(from Tab 1) while reading news from Netscape website in Tab 2, but I agree with
comment #28, IE don't  have this kind of bugs and  must be fixed.


Comment 40 Alfonso Martinez 2002-08-20 02:56:39 PDT
*** Bug 163609 has been marked as a duplicate of this bug. ***
Comment 41 Phil Schwartau 2002-09-03 16:27:24 PDT
*** Bug 166312 has been marked as a duplicate of this bug. ***
Comment 42 Greg K. 2002-09-05 09:51:24 PDT
*** Bug 166779 has been marked as a duplicate of this bug. ***
Comment 43 Thomas Brown 2002-10-28 06:09:18 PST
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016

Would be nice if all status bar activity was unique to the active tab, for both
JavaScript code as well as internal browser usage of the bar.

Since it's currently shared, if two tabs have active status bar tickers then
they fight each other making the scrolling text mostly unreadable.
Comment 44 André Dahlqvist 2002-11-02 16:25:36 PST
*** Bug 178083 has been marked as a duplicate of this bug. ***
Comment 45 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-11-06 17:56:30 PST
*** Bug 178730 has been marked as a duplicate of this bug. ***
Comment 46 Paul Wyskoczka 2002-11-08 11:38:39 PST
nsbeta1+/adt3 per the nav triage team.

Comment 47 Seb Tomasini 2002-11-22 08:26:38 PST
Confirm that this bug still exists in the latest build Mozilla:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021120
Comment 48 Thomas Brown 2002-11-22 11:20:47 PST
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021122
Confirmed bug still exists.  In fact, sometimes status bar message is now
"stuck".  Even though the browser is idle ("stop" button gray, no Mozilla logo
animation), I have "Sending request to localhost..." on the status bar permanently.
Comment 49 Jay Davis 2002-11-22 14:48:40 PST
Thomas,

I confirm also I've been seeing the very same thing on both points.  This is a
bug that certainly clutters the mind and irritates more frequently than most
Mozilla bugs.
Comment 50 Chris Lyon 2002-12-01 18:31:10 PST
*** Bug 181964 has been marked as a duplicate of this bug. ***
Comment 51 R.K.Aa. 2002-12-09 18:47:46 PST
*** Bug 184551 has been marked as a duplicate of this bug. ***
Comment 52 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-12-10 10:16:47 PST
*** Bug 184638 has been marked as a duplicate of this bug. ***
Comment 53 Torben 2002-12-11 04:34:57 PST
*** Bug 159759 has been marked as a duplicate of this bug. ***
Comment 54 R.K.Aa. 2002-12-12 03:50:35 PST
*** Bug 185002 has been marked as a duplicate of this bug. ***
Comment 55 R.K.Aa. 2002-12-16 12:40:09 PST
*** Bug 185675 has been marked as a duplicate of this bug. ***
Comment 56 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-02-08 12:59:29 PST
*** Bug 192426 has been marked as a duplicate of this bug. ***
Comment 57 Chris Casciano 2003-02-14 16:54:45 PST
*** Bug 193420 has been marked as a duplicate of this bug. ***
Comment 58 Patrick Xia ("Octalc0de") 2003-02-15 11:20:38 PST
*** Bug 193475 has been marked as a duplicate of this bug. ***
Comment 59 Zvi Devir 2003-02-26 12:25:17 PST
It seems that there are several BUGs of almost the same issue:

A. "Transferring..." message stays forever, if tabs are switched before the
"Done" message - Bug 185547 and its 6 dups, comment 2.
B. The status bar ticker is common for all tabs - This bug (104532) and its 32 dups.
C. Ticker is not removed when originating tab is closed. (Outcome of B).
D. "Ticker fight" - Comment 43. (Outcome of B).
E. The "Transferring..." message of one tab mixed with other tabs' status bar. 
F. Disabling the "Allow scripts to: Change status bar text" doesn't clear out
the previous ticker. (Not an actual bug, but not what the user expects).

Note that E is an outcome of B. But when regarding to the additional behaviour
of C (Ticker from dead source), we get the result of A.

Since this bug is visible and quite annoying; connected with bug 185547; stayed
opened for almost 1.5 years; got 32 (!!!) dups (and still counting); and got 42
votes;
I believe it's about time to change the sevirity to Normal (as 185547), if not
Major, and get it finally fixed.
Comment 60 David A. Cobb 2003-03-02 16:05:28 PST
*** Bug 195658 has been marked as a duplicate of this bug. ***
Comment 61 Patrick 2003-03-20 03:23:01 PST
upgrading severity -> normal
Because this behavior also negatively affects performance [maybe it should even
be major then].

There might actually be two issues here 
1) status bar message is not updated to display message for active tab only
2) status bar message is uselessly generated for the non-active tabs.
I'm not sure if "one-patch-fits-all" or if a separate bug should be filed.

The second issue [which affects performance] is illustrated by the following:
Go to the testcase at http://kvip81.kvi.nl/~hendriks/test.html and watch the CPU
usage : about 2% on my machine. Then open the same page in about 10 or 20 new
tabs [link provided on test page for your convenience]. About 10 or 20 clicks
later CPU usage maxes out and the entire system slows down.

Now close all but one of the tabs and in EDIT - PREFERENCES - ADVANCED - SCRIPTS
&PLUGINS uncheck the option "change status bar text". Close all Moz [for the
pref change to take effect and clear the status bar]. Again open the URL in
about 20 or so tabs. CPU usage now levels off at about 40%.

So even though you can only see one status bar message [which should be that of
the active tab] lots of CPU is wasted on generating status bar messages for each
tab.

Or am i doing something wrong?
Comment 62 Chris Casciano 2003-03-21 09:08:20 PST
*** Bug 198604 has been marked as a duplicate of this bug. ***
Comment 63 snebeling 2003-03-22 04:18:13 PST
Now pardon my possible ignorance (because I'm not familiar with
the Mozilla source code), but from a programmer's point of view,
there is a very simple fix for this kind of problem:

1.) Internally, save one status message (= one string)
    per document (= HTML page or whatever the content is)
2.) When the status message string of a document is changed,
    only update the window's status bar if that document is
    the one that is currently visible (e.g., in the selected tab)
3.) When the selection of which tab is currently visible changes,
    update the window's status bar with the status message string
    of the document contained in the newly selected tab
Comment 64 Andreas Lange 2003-03-23 03:39:10 PST
This isn't one of those bugs that gets delayed because it is a hard one, it is
more the usual problem of having a limited amount of resources - programmers
with knowledge of the code and their time, and a very large amount of bugs
demanding their attention, many bugs more severe than this one.

One benefit of this not beeing that hard is that perhaps someone with a little
spare time could step in and make a tentative patch, that usually speeds up the
resolution of the bug a lot. Perhaps it might be helpful to look how the page
title is handled (a per tab variable that updates a per window resource).
Comment 65 Sébastien Delahaye 2003-03-30 13:14:52 PST
*** Bug 199885 has been marked as a duplicate of this bug. ***
Comment 66 Bill Mason 2003-03-31 01:48:02 PST
*** Bug 199923 has been marked as a duplicate of this bug. ***
Comment 67 Narayan 2003-03-31 03:47:08 PST
While this bug may not be "irritating" or "high-impact" on its own, when it
combines with another bug, it makes a deadly cocktail:

That other bug can be described as follows:

Some tabs just don't load. Their Tab shows "loading..." forever. The tabs have
to be selected by clicking: the CTRL+arrow combination does not cycle through
such tabs.

Now consider the *combined* effect of these two bugs in the following scenario:
1. The user has a URL open in a tab that contained a lot of links. He launches
several new tabs using "CTRL+click" method.
2. Some of these tabs have both problems described above. When the user opens
the tab, he does not find the URL anywhere (neither in Address Bar nor in Status
Bar). Now he does not know which URLs he launched, and which are not getting
loaded. Just refresh does not work, as the address bar is actually empty!
3. At best, he has to re-open the original URL and launch all the URLs again,
including the oones that were succesfully launched in the first attempt.

Considering the effect, the severity of this bug should be upgraded.
Comment 68 Vaclav Dvorak 2003-03-31 17:37:50 PST
Narayan: I'm often bitten by that problem, too, but I don't think that proper
updating of the status bar would be the solution (although it would certainly be
an improvement). What you really mean is bug 104778 and/or bug 103720, I think.
This bug is, for me, just an annoyance, not a component of a "deadly cocktail".
It does sound nice, though. :-)
Comment 69 Narayan 2003-04-01 00:16:21 PST
Yes, 'both bugs combined' would be it.

Why should we rank the combination higher?

Well, the USP of Mozilla (over Internet Explorer) is its ability to launch
multiple Tabs. And this combination of bugs cripples that USP. 

Now this is a bit like overselling a product by singing virtues of a single
"killer" feature that turns out to be a dud in actual use.

Apply the "house of quality" principle to this fact (Highly prized feature x Not
available in competition product x Not working well) and you immediately see why
these bugs should be given a much higher prominence.
Comment 70 Andrew Church 2003-04-01 01:17:22 PST
As comment #64 suggested, I thought I would take a look into making a
preliminary patch for this bug.  Unfortunately, I neglected the fact that
jumping into 350 megabytes of source with no prior knowledge is like jumping off
a ship in the middle of the Pacific without a lifejacket: you don't get very
far.  If someone could provide pointers to e.g. where data structures for
windows and tabs are defined, I'll take a closer look.
Comment 71 Agustín Fernández 2003-04-18 13:10:54 PDT
I'm looking into this. I think that there are actually two problems:

1. The statusbar text is not updated when you move between tabs.
2. The window's statusbar text should only be updated on window.status when we
that tab is selected.

In order to fix it I will (try to):

1. Edit <method name="updateCurrentBrowser"> in
/source/xpfe/global/resources/content/bindings/tabbrowser.xml to update the
statusbar from window.status.

2. Edit GlobalWindowImpl::SetStatus in /source/dom/src/base/nsGlobalWindow.cpp,
and add a check of if we are in the current window or not.

This would be the first time I try to fix a bug in mozilla, so anything I say
should be hyper- and mega-reviewed.
Comment 72 Felix Miata 2003-04-19 13:41:36 PDT
*** Bug 202637 has been marked as a duplicate of this bug. ***
Comment 73 jag (Peter Annema) 2003-05-14 15:51:12 PDT
Agustin: most of the status (e.g. transferring from, document done) cannot be
gotten from window.status. What we really should do is move some of the logic
from nsBrowserStatusHandler into the mTabProgressListener in tabbrowser.xml.
Then there is indeed this problem that things like window.status and
window.defaultStatus directly get sent to the XUL window instead of to the
content window, bypassing our inactive tab filters. This is going to be harder
to fix.
Comment 74 José Jeria 2003-05-19 04:27:44 PDT
I also noticed that you get this when you 
1. open a new tab and type in a location (big page)
2. before page is loaded close tab
3. Tranferring remains.

Fixing this bug will also fix that?
Comment 75 Erik 2003-05-27 14:35:19 PDT
*** Bug 207278 has been marked as a duplicate of this bug. ***
Comment 76 [:jesup] on pto until 2016/7/5 Randell Jesup 2003-06-02 15:09:07 PDT
Jag - any chance of time to hit this for 1.4?  I'm willing to help out.
Comment 77 jag (Peter Annema) 2003-06-02 15:30:50 PDT
This will be a big scary patch. The small not so scary patch would be to just
clear the status bar when we switch tabs.
Comment 78 jag (Peter Annema) 2003-06-02 19:18:03 PDT
Created attachment 124781 [details] [diff] [review]
Clear status when switching tabs

Not quite the fix I want but it'll do for now. See previous comments for the
right fix.
Comment 79 Jonathan Louie 2003-06-02 20:14:35 PDT
i'm sorry, i may not understand your intentions here, but the "less scary patch"
really doesn't seem to fix the problem at all.  (after this patch, if my
foreground tab is bugzilla and my background tab is cnn, and i switch to cnn, i
will still get status from bugzilla loading while reading cnn.)  i really hope
the plan isn't to check this patch in and call this bug fixed.
Comment 80 jag (Peter Annema) 2003-06-02 23:10:12 PDT
Hmm, could you give me a step by step of how to reproduce what you're seeing?

My testcase:

Load cnn.com in tab A
Load slashdot.org in tab B
While tab B is loading, switch to tab A

I haven't been able yet to get bugzilla status to show up for CNN
Comment 81 jag (Peter Annema) 2003-06-02 23:14:10 PDT
Whoops... The above would be kinda hard since I didn't load bugzilla anywhere ;-)

Make that "I haven't been able yet to get slashdot status to show up for CNN"
Comment 82 Byron Jones ‹:glob› 2003-06-02 23:20:15 PDT
happens for me everytime following your steps.

try it on a slower connection.
Comment 83 Jonathan Louie 2003-06-02 23:42:07 PDT
or try a loading an overseas site (eg, www.yahoo.co.jp) then switching tabs
immediately.  one of the previous examples with status bar tickers might also
work, although i have javascript disabled for that particular case.
Comment 84 jag (Peter Annema) 2003-06-02 23:51:32 PDT
byron: with my attached patch applied?

Jonathan: I just tried that url, still no longer seeing the problem. Could you
do view-source:chrome://navigator/content/nsBrowserStatusHandler.js and make
sure my patch ended up in your test build?
Comment 85 Jonathan Louie 2003-06-03 00:20:10 PDT
hrm, the patch seems not to be in the nightly i just downloaded:  Mozilla/5.0
(Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030602

is there something i'm doing wrong?
Comment 86 Byron Jones ‹:glob› 2003-06-03 00:55:49 PDT
> byron: with my attached patch applied?

oops.  *sheepish grin*

i'm unable to duplicate the issue with your patch applied :)
Comment 87 Bill Mason 2003-06-03 01:09:03 PDT
Re: comment 85:
The patch has not been checked in, so it's not going to be in a build you
download yet.
Comment 88 neil@parkwaycc.co.uk 2003-06-03 05:46:00 PDT
Comment on attachment 124781 [details] [diff] [review]
Clear status when switching tabs

I get the idea, but...
Comment 89 neil@parkwaycc.co.uk 2003-06-03 05:48:31 PDT
Created attachment 124813 [details] [diff] [review]
I prefer this version :-)
Comment 90 jag (Peter Annema) 2003-06-03 08:27:17 PDT
Comment on attachment 124813 [details] [diff] [review]
I prefer this version :-)

I totally agree.
Comment 91 (not reading, please use seth@sspitzer.org instead) 2003-06-03 09:28:22 PDT
Comment on attachment 124781 [details] [diff] [review]
Clear status when switching tabs

clearing request, looks like this patch is obsolete.
Comment 92 (not reading, please use seth@sspitzer.org instead) 2003-06-03 09:33:16 PDT
Comment on attachment 124813 [details] [diff] [review]
I prefer this version :-)

I think a=sspitzer for the 1.4 branch, but I we're at the point where we need a
second driver (so let's ask asa).

of course, please land on the trunk so we can get some eyeballs on it ASAP (to
look for regressions).
Comment 93 (not reading, please use seth@sspitzer.org instead) 2003-06-03 09:36:36 PDT
updating summary and TM.
Comment 94 Asa Dotzler [:asa] 2003-06-03 10:05:50 PDT
Comment on attachment 124813 [details] [diff] [review]
I prefer this version :-)

a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Comment 95 Agustín Fernández 2003-06-03 14:56:05 PDT
Hi, perhaps I got it wrong, but I think you should check what I wrote in in
comment 71. I think that this bug has nothing to do with _clearing_ the status
bar, that would only attenuate the problem a little.

The problem (as I understand it) was, and still is:

1. The statusbar text is not updated when you move between tabs.
2. The window's statusbar text should only be updated on window.status when that
tab is selected.

The only scenario this patch solves is when you have something in your status
bar and switch to another tab, and even then it doesn't take into account the
real value that the status bar should have. As a minimum it should set it to the
tab's document.status (not empty it). The bigger (although much less frecuent)
problem is the second one, but even that one doesn't seem hard to fix. I wanted
to write a patch but I had trouble setting up a developing enviroment (I had
problems with linux and drivers, my connection to the internet goes through a
proxy that doesn't like CVS very much, and the ever present Real Life(tm)
demands more and more time).
Comment 96 jag (Peter Annema) 2003-06-03 15:03:50 PDT
Created attachment 124853 [details] [diff] [review]
Here's what I checked in on trunk

Since setOverLink will clear this.defaultStatus for us, why not depend on that
too?
Comment 97 jag (Peter Annema) 2003-06-03 15:24:55 PDT
I want to keep this bug open for the better fix, removing nsbeta1+[adt3] and
blocking1.4 to remove this bug from the radar.
Comment 98 Bill Mason 2003-06-04 09:59:10 PDT
Verified the interim patch 2003060404 PC/WinXP
Comment 99 sairuh (rarely reading bugmail) 2003-06-04 16:09:22 PDT
i have two tests:

a. status bar ticker in one of the tabs, as mentioned in comment 0 and comment 1.

b. status bar containing "Connecting to..." or "Transferring..." in one of the tabs.

using 2003.06.04 commercial 1.4 branch builds, case (a) is still a problem. i'm
using http://www.cats-eye.com in the 1st tab, and something simply static like
http://mozilla.org. because of this, i'm "reopening" this for the branch by
removing fixed1.4 and adding nsbeta1.

case (b) with 2003.06.04 commercial 1.4 branch builds, in contrast, seems to be
mostly resolved; it seems more aggressive (quick to remove the status). not sure
if that's what's wanted at this point.

1. have two tabs open to pages whose status quickly becomes static ("Done"), eg,
http://mozilla.org and http://google.com.

2. in the 1st tab, load something that takes a while to load, like a bugzilla
query or http://cnn.com (in order to get "Connecting..." or "Transferring..." to
appear).

3. before the 1st tab finishes loading, switch to the 2nd tab.

as expected, the 2nd tab doesn't display the status in the 1st tab.

4. quickly, while the 1st tab is *still* loading, switch from the 2nd tab back
to the 1st tab.

results: the status bar is empty, even though the throbber is active (it's still
loading). shouldn't the previous "Connecting..." or "Transferring..." message
persist upon returning back to a loading tab?
Comment 100 jag (Peter Annema) 2003-06-06 04:38:49 PDT
Sairuh: for case b, yes, that is what we'd like, but that's much riskier than
the patch that was checked in. Usually the status bar should update within a
second to another "transferring from..." or similar message. Case a is really a
different bug (we should be able to filter out js status changes), though I
guess it could be perceived as part of this bug and should probably block this bug.

I wouldn't mark this bug fixed yet, but I think what we have on the branch (and
trunk) now, namely that there'll be no lingering "transferring from..." when
switching from a tab that's still loading to a tab that's done loading (or also
still loading but hasn't had a chance to update the status bar yet), is good
enough for now.
Comment 101 sairuh (rarely reading bugmail) 2003-06-06 12:27:18 PDT
jag, i agree with you about the status bar clearing behavior for
"transferring..." / "connecting to..." (case (b)). it might be a bit
"enthusiastic" to clear it, but it's certainly better than before.
Comment 102 Samir Gehani 2003-06-06 15:03:56 PDT
adt= nsbeta1+/adt2 Please land on 1.4branch and add fixed1.4 keyword
Comment 103 Asa Dotzler [:asa] 2003-06-09 13:09:20 PDT
Jag, can you verify that we have what we want for 1.4? If so, please add the
fixed1.4 keyword and resolve this bug. Thanks.
Comment 104 jag (Peter Annema) 2003-06-10 00:11:25 PDT
Adding fixed1.4, for now we have an adequate workaround.

Not marking this bug fixed yet, some work still needs to be done for a true fix.
Comment 105 Erik 2003-06-10 02:28:47 PDT
*** Bug 208874 has been marked as a duplicate of this bug. ***
Comment 106 sairuh (rarely reading bugmail) 2003-06-10 11:08:23 PDT
okay, carrying over my testing observations for the branch (still applied to
today's branch bits) regarding case (b). marking verified1.4, but leaving open
for a better fix for the trunk.
Comment 107 Simon Paquet [:sipaq] 2003-06-30 03:15:36 PDT
*** Bug 210877 has been marked as a duplicate of this bug. ***
Comment 108 Bill Mason 2003-06-30 10:44:02 PDT
*** Bug 211107 has been marked as a duplicate of this bug. ***
Comment 109 Matthias Versen [:Matti] 2003-07-10 01:35:09 PDT
*** Bug 212268 has been marked as a duplicate of this bug. ***
Comment 110 Martin van Dijken 2003-07-10 01:48:10 PDT
Please change the title on this bug or start a new one for the JS status ticker
problem. I just filed a new bug and I DID search through the bug list. I think a
lot of pollution from new bugs can be prevented if simply the title matches the
JS status problem as well.
Comment 111 Joaquin Menchaca 2003-07-16 18:45:51 PDT
I did a search for status bar and I found this one with ease.  The little bar at
the bottom has always been called "status bar" and that's what I searched for. 
I was going to write this bug up, but found this.

This still occurs talk-back build for Mozilla 1.5a (Build ID: 2003070908).
Comment 112 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-07-23 23:54:08 PDT
*** Bug 213646 has been marked as a duplicate of this bug. ***
Comment 113 jag (Peter Annema) 2003-07-25 15:04:45 PDT
Actually, the js status ticker bug is another bug... I wish I could find the
number. It's basically that the js status stuff (window.status = "....")
bypasses the normal listener code and sends stuff to the UI listener directly. I
need to fix that one of these days.
Comment 114 Alfonso Martinez 2003-08-08 10:03:09 PDT
*** Bug 215553 has been marked as a duplicate of this bug. ***
Comment 115 Hermann Schwab 2003-09-01 09:53:10 PDT
*** Bug 217961 has been marked as a duplicate of this bug. ***
Comment 116 Bill Mason 2003-09-12 14:56:38 PDT
*** Bug 219071 has been marked as a duplicate of this bug. ***
Comment 117 Bill Mason 2003-09-14 18:49:10 PDT
*** Bug 219226 has been marked as a duplicate of this bug. ***
Comment 118 Gulliver 2003-09-18 06:03:45 PDT
Still present in 1.5 RC1 (MacOS X)!!!

Nobody able to fix this??????
Comment 119 Luis Miguel Lagoa Baptista Ferro 2003-09-18 06:43:31 PDT
I find this bug very grave because it ruins the user experience of the browser
and ruins the content integrety (sp) of the content creators...

For instance... having a company page in a tab with corp info and in the status
having a "spammer" ticker offering an "enlargement" of you know what...

Not the kind of thing that i would place under the rug...

Comment 120 Bill Mason 2003-09-18 08:38:46 PDT
Anyone wanting to add more comments along the lines of:

* It's still broken
* I think this is grievous because...

Please go read section 1.1 of Bugzilla Etiquette first before spamming any more
mailboxes.
http://mecha.mozilla.org/page.cgi?id=etiquette.html

Thank you.
Comment 121 Bill Mason 2003-09-22 12:24:06 PDT
*** Bug 219986 has been marked as a duplicate of this bug. ***
Comment 122 Oleg Sidletskiy 2003-09-25 03:38:29 PDT
*** Bug 220250 has been marked as a duplicate of this bug. ***
Comment 123 Felix Miata 2003-09-29 14:48:57 PDT
*** Bug 220707 has been marked as a duplicate of this bug. ***
Comment 124 Thomas Brown 2003-10-15 11:13:43 PDT
Forgive me if this suggestion has already been considered, but how about this
for a solution:

I imagine that the current status bar text is stored in a variable somewhere, so
rather than a single status bar variable why not make it an array which is
indexed by the tab number?

By approaching it in this way, no matter what tab you switch to Mozilla would
simply paint the contents of the appropriate array variable onto the status bar.

Of course for JavaScript tab updates to work with this method, you would have to
make sure that the JS status bar update code doesn't just paint the text on the
tab directly, but rather into that indexed array variable instead.
Comment 125 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2003-10-15 11:19:25 PDT
I don't think the code knows which tab a script that is writing to the status
bar came from.  Last time I asked, Jag said he thought he'd have to rewrite a
lot of stuff to do this.
Comment 126 Agustín Fernández 2003-10-16 08:14:30 PDT
Actually you just need to know if we are currently in the selected tab or not
before writting to it, and update the text at the event of a tab switch to the
window.status content. Every document already has the status bar text in its own
dom, otherwise it would be a security problem.
Comment 127 timeless 2003-10-16 12:59:42 PDT
yo@agustinfernandez.com.ar: if it's so easy then may i assign the bug to you?
when can we expect your patch?
Comment 128 axolote 2003-11-09 07:09:58 PST
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Status bar isn't updated when a tab times out and you're watching another tab.
Comment 129 axolote 2003-11-09 07:43:29 PST
Both bugs <a href="/show_bug.cgi?id=214243">#214243</a> and <a
href="/show_bug.cgi?id=217535">#217535</a> should be marked as duplicates to this.

Bill Mason, your link to http://mecha.mozilla.org/page.cgi?id=etiquette.html is
broken, it returns forbidden (403) error message.
Comment 130 Bill Mason 2003-11-09 09:06:46 PST
*** Bug 214243 has been marked as a duplicate of this bug. ***
Comment 131 Gilles Durys 2003-11-26 06:56:40 PST
*** Bug 226834 has been marked as a duplicate of this bug. ***
Comment 132 Bill Mason 2003-11-26 12:03:45 PST
*** Bug 226860 has been marked as a duplicate of this bug. ***
Comment 133 Bill Mason 2003-11-27 01:05:52 PST
*** Bug 226909 has been marked as a duplicate of this bug. ***
Comment 134 Bill Mason 2003-12-06 11:30:35 PST
*** Bug 227659 has been marked as a duplicate of this bug. ***
Comment 135 Bill Mason 2003-12-12 12:52:04 PST
*** Bug 228312 has been marked as a duplicate of this bug. ***
Comment 136 José Jeria 2003-12-14 04:30:35 PST
*** Bug 228431 has been marked as a duplicate of this bug. ***
Comment 137 Arjen Anker 2003-12-15 01:16:39 PST
As I understand it, there are 2 kinds of statusbar texts.

1. The "Loading ..." and "Connecting ..." messages in Moz/FB
2. Statusbar texts from JavaScripts (window.status & window.defaultStatus)

Am I correct so far?

If I am, I can immagine getting this right for tabs would be difficult.
I can see 2 possibilities: the statusbar is unique for the window or, the
statusbar is unique for the tab.
If you see tabbed browsing as the same as multi-windowed browsing, but just in a
container, I'm tended to say the statusbar should be unique to a tab, the same
as it is to a page in a different window. Even though my logic says the
statusbar is part of the UI and not the website, but if that were true,
window.status shouldn't be possible, cause it would be affecting a part of the UI.

But, from a user point-of-view, I suggest about the same as proposed before. You
should only see that statusbar text for the active tab. The only other option I
see would be to split the two components I mention above, but I do not see how
that could be displayed logically. IMHO it is kind of weird that the statusbar
is used for those two purposes in such a way, but it's often used nevertheless.

Whouldn't it be easier if those two components get merged somehow? That
statusbar texts are handled by the same component? This would probably be a
pretty big overhaul, but it would make things easier in the future, I suppose.
Comment 138 MZM 2003-12-15 09:51:56 PST
IMHO it wuld not be dificult to fix - every tab has its own messages like 
"Loading..." and others. If you load page in background tab, then you dont see 
aditional loading message. It means, that tab is interperted as seperate 
window, as it should be. A window inside other window. Thous, who had used 
Opera, will understand - if Opera works in tabbed mode, then "open link in new 
window" opens in a new tab. 
 
PS. Now it seems, that this bug will be fixed in 2.x ;) 
Comment 139 Zvi Devir 2003-12-15 11:44:26 PST
This bug was not fixed yet because the implementation of the status bar is not
correct. There is one status bar for all tabs, instead of one status-bar per tab
as suggested above (comments 43, 63, 124, 126, 137 and others). I guess the fix
would involve changes to the class-structure of the browser, and hence why this
one is still an open bug...

BUT, and again, this bug is very annoying one; stayed opened for more than two
years; got 57 (!!!) dups (still counting); and 71 votes;
Therefore, I'd suggest changing the sevirity to Major, so it will be finally
fixed correctly (unlike the bugfix of bug 185547).
Comment 140 Bill Mason 2004-01-16 01:35:02 PST
*** Bug 231074 has been marked as a duplicate of this bug. ***
Comment 141 Asa Dotzler [:asa] 2004-02-09 15:05:40 PST
Please close this bug and open a new one which covers the javascript ticker
problem which is (I believe) distinct from the other status update problems.
Thanks. This is unlikely to be fixed for 1.7a, especially not from a bug that's
this much of a mess.
Comment 142 Zvi Devir 2004-02-10 02:53:36 PST
(In reply to comment #141)
> Please close this bug and open a new one which covers the javascript ticker
> problem which is (I believe) distinct from the other status update problems.

All the problems arise from the same point -- the one status-bar per all tabs.
Detailing the bugs into its various aspects is a recipe that it will never be
properly fixed.

FYC.
Comment 143 José Jeria 2004-02-12 04:25:00 PST
*** Bug 233999 has been marked as a duplicate of this bug. ***
Comment 144 Bill Mason 2004-02-18 09:07:01 PST
*** Bug 234784 has been marked as a duplicate of this bug. ***
Comment 145 Bill Mason 2004-03-17 11:34:32 PST
*** Bug 237812 has been marked as a duplicate of this bug. ***
Comment 146 Bill Mason 2004-03-21 12:42:44 PST
*** Bug 238191 has been marked as a duplicate of this bug. ***
Comment 147 Bill Mason 2004-03-25 12:00:02 PST
*** Bug 238679 has been marked as a duplicate of this bug. ***
Comment 148 R.K.Aa. 2004-04-08 12:09:43 PDT
*** Bug 240032 has been marked as a duplicate of this bug. ***
Comment 149 neil@parkwaycc.co.uk 2004-05-02 07:29:44 PDT
Created attachment 147496 [details] [diff] [review]
Proposed patch

This is what I had to do to hide status updates from background tabs:
1. Make the content tree owner return itself as the web browser chrome.
If you don't do this, it will ask the xul window for a default tree owner.
2. Only allow the status to be set from the primary tree owner.
Background tabs use the default non-primary tree owner.
3. Forcibly update the tree owner whenever the browser type changes.
Otherwise a tab switch would forget to set the new primary tree owner.
Comment 150 neil@parkwaycc.co.uk 2004-05-02 07:34:16 PDT
Comment on attachment 147496 [details] [diff] [review]
Proposed patch

I've no idea who, if anyone, understands this stuff any more ;-)
Comment 151 Christian :Biesinger (don't email me, ping me on IRC) 2004-05-02 08:38:26 PDT
In:
 NS_IMETHODIMP nsContentTreeOwner::SetStatus(PRUint32 aStatusType, const
PRUnichar* aStatus)
your indentation seems to be off by one...


shouldn't you also back out attachment 124853 [details] [diff] [review]? (the "temporary hack")
Comment 152 Dan M 2004-05-10 11:06:31 PDT
+++ nsContentTreeOwner.cpp	2 May 2004 14:23:50 -0000

-  if(aIID.Equals(NS_GET_IID(nsIWebBrowserChrome)))
-    return mXULWindow->GetInterface(aIID, aSink);

This admittedly hackish thing was added on purpose. See bug 58539 comment 8.
Yes, there's a conflict here, since the object itself also supports that
interface. I barely recall that it was important to get the top-level chrome,
and it was done this way because that's the way the embedding interfaces worked.
But I forget details.

After applying this patch the WebBrowserChrome referenced by a DOM window's *bar
objects does indeed change. And it doesn't seem to hurt anything. But I'm leery
of doing this arbitrarily. A better solution to the conflict may be to make this
object not support nsIWebBrowserChrome. I don't remember.

--

About the ContentShellAdded changes:

They pretty much make sense to me. But I'm afraid that some of the things you're
simplifying may break something subtle. For example the part that looks for and
destroys multiple copies appears to be important for bug 98109. cc:ing Hyatt.
Comment 153 neil@parkwaycc.co.uk 2004-05-10 15:50:54 PDT
(In reply to comment #152)
>-  if(aIID.Equals(NS_GET_IID(nsIWebBrowserChrome)))
>-    return mXULWindow->GetInterface(aIID, aSink);
>This admittedly hackish thing was added on purpose. See bug 58539 comment 8.
Hmmm, my patch breaks all the chrome bar properties :-(

>About the ContentShellAdded changes: They pretty much make sense to me.
>But I'm afraid that some of the things you're simplifying may break
>something subtle. For example the part that looks for and destroys
>multiple copies appears to be important for bug 98109.
Dynamic content-primary type shifting is what I'm trying to fix :-)
Comment 154 Dan M 2004-05-17 13:24:10 PDT
You don't need the extant code that nulls multiple copies of the same docshell?
I mean I don't get that; you'd think multiple copies would be harmful. But it
does seem to have been explicitly added for dynamically shiftable primary
content. In the absence of a comment from Hyatt I'm ready to r= that part
because it /looks/ OK.

But breaking the *bar properties is obviously a bad thing. Is that part of the
patch necessary, or just cleanup?
Comment 155 neil@parkwaycc.co.uk 2004-05-17 15:54:05 PDT
The problem is that all the content tree owners just used to hand the default
tree owner to the global window whenever you set the status or changed a bar
prop. Now not having noticed the bar prop stuff, I thought, surely, only primary
content tree owners should be able to set the status. But I've unfortunately
created multiple sets of bar props :-( I think the fix should be to make the xul
window own the window flags, I just haven't implemented that yet.
Comment 156 Stewart Gordon 2004-05-18 06:12:20 PDT
*** Bug 243913 has been marked as a duplicate of this bug. ***
Comment 157 neil@parkwaycc.co.uk 2004-05-21 07:59:13 PDT
Created attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

Dan, the nulling bit was sorta getting in my way, because it was attaching the
content shell to the new id, rather than attaching the new id to the shell...
Comment 158 neil@parkwaycc.co.uk 2004-05-21 08:15:34 PDT
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

Oh, and biesi, I think that other patch is still needed to clear the status
when tabs are switched.
Comment 159 Dan M 2004-05-26 17:55:32 PDT
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

Seems right, and a general logic improvement. Go for it.
Comment 160 jag (Peter Annema) 2004-05-28 16:24:03 PDT
If someone reads window.status from a "background" tab, what will they get?

And yeah, I guess we'll still need attachment 124853 [details] [diff] [review].

I was looking at fixing this bug by storing the user set ("ticker") status
strings per tab, probably by (somehow) delegating the SetStatus call to the
appropriate tab web progress listener so that when we switch we'll actually have
the correct ticker text.

Let me study your patch and understand what it's doing.
Comment 161 neil@parkwaycc.co.uk 2004-05-28 16:50:28 PDT
(In reply to comment #160)
>If someone reads window.status from a "background" tab, what will they get?
Each frame caches its own value of window.status (in GlobalWindowImpl).
Comment 162 Bogdan Stroe 2004-06-03 12:35:11 PDT
*** Bug 245322 has been marked as a duplicate of this bug. ***
Comment 163 Bogdan Stroe 2004-06-03 12:37:52 PDT
*** Bug 244430 has been marked as a duplicate of this bug. ***
Comment 164 Christian :Biesinger (don't email me, ping me on IRC) 2004-07-04 15:43:24 PDT
*** Bug 249804 has been marked as a duplicate of this bug. ***
Comment 165 Bogdan Stroe 2004-07-06 11:35:41 PDT
*** Bug 249676 has been marked as a duplicate of this bug. ***
Comment 166 Bill Mason 2004-07-12 00:48:21 PDT
*** Bug 250971 has been marked as a duplicate of this bug. ***
Comment 167 Kunal Shah 2004-07-12 21:40:13 PDT
*** Bug 251133 has been marked as a duplicate of this bug. ***
Comment 168 Bill Mason 2004-07-18 15:18:36 PDT
*** Bug 252030 has been marked as a duplicate of this bug. ***
Comment 169 Nian Liu(n/a in a long time) 2004-07-20 00:54:53 PDT
*** Bug 252212 has been marked as a duplicate of this bug. ***
Comment 170 Ben Goodger (use ben at mozilla dot org for email) 2004-07-22 12:16:06 PDT
If there is no checkin here in 7 days or so, missing the boat. 
Comment 171 Ben Goodger (use ben at mozilla dot org for email) 2004-07-22 12:17:16 PDT
Blake, why don't you sr this one, and take it on the branch if you want. But
please do asap. 
Comment 172 José Jeria 2004-07-25 08:54:23 PDT
*** Bug 252986 has been marked as a duplicate of this bug. ***
Comment 173 chris hofmann 2004-07-30 14:09:56 PDT
seth did some research on this to find out where we are...  here are is comments

For the 1.4 branch, we checked in a low risk, but partial fix.  That partial fix
is on the aviary 1.0 branch.

(see
http://lxr.mozilla.org/aviarybranch/source/xpfe/browser/resources/content/nsBrowserStatusHandler.js#259)

It look Neil has a better, more complete fix for the trunk.  I think we want to
see this one bake on the trunk before we take it on aviary 1.0.

Or has he already landed on the trunk and it baked fine?  Neil has r=danm, but
no sr=yet. 


--any recommendations of the patch that has landed on the trunk?

thanks

chris h.
Comment 174 Bill Mason 2004-07-30 14:22:40 PDT
(In reply to comment #173)
> 
> Or has he already landed on the trunk and it baked fine?  Neil has r=danm, but
> no sr=yet. 
> 
> 
> --any recommendations of the patch that has landed on the trunk?

Looking at, for example, the first file in the patch, the patch has never landed
on the trunk.
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/appshell/public/nsIXULWindow.idl

The version of this file that the patch is diff'ed from is still the current
version in CVS.
Comment 175 Dan M 2004-07-30 16:16:39 PDT
Comment 173: I second Seth's opinion. I trust Neil and everything, and he seems
to have an understanding of what needs to be done. I've r=ed his patch. But I'd
still want to see some bakeage before it found its way into something like the
1.4 branch. A lower risk, less complete solution sounds ideal for 1.4 at this point.
Comment 176 chris hofmann 2004-08-13 12:23:46 PDT
any ideas on if sufficient baking on the trunk has occurred?  asa is checking
for feedback but if anyone has seen anything please post.  I think we we are
going to take any more on this it will have to be early next week.
Comment 177 Bill Mason 2004-08-13 12:31:51 PDT
(In reply to comment #176)
> any ideas on if sufficient baking on the trunk has occurred?  asa is checking
> for feedback but if anyone has seen anything please post.  I think we we are
> going to take any more on this it will have to be early next week.

Unless what I said in comment 174 is completely wrong, this patch isn't even on
the trunk.
Comment 178 chris hofmann 2004-08-16 14:16:35 PDT
ok, seems we have run out of time for aviary PR and too many more higher risks
items.  if this gets landed and shakes out ok we could consider for final
Comment 179 José Jeria 2004-08-21 03:29:35 PDT
*** Bug 256391 has been marked as a duplicate of this bug. ***
Comment 180 Bill Mason 2004-08-25 01:07:34 PDT
*** Bug 256819 has been marked as a duplicate of this bug. ***
Comment 181 Bill Mason 2004-08-27 08:49:15 PDT
*** Bug 257131 has been marked as a duplicate of this bug. ***
Comment 182 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-08-27 15:08:05 PDT
*** Bug 257135 has been marked as a duplicate of this bug. ***
Comment 183 Bill Mason 2004-09-19 22:25:20 PDT
*** Bug 260429 has been marked as a duplicate of this bug. ***
Comment 184 Ben Goodger (use ben at mozilla dot org for email) 2004-09-25 23:02:59 PDT
Not a "blocker"
Comment 185 Christian :Biesinger (don't email me, ping me on IRC) 2004-10-14 14:20:08 PDT
*** Bug 264421 has been marked as a duplicate of this bug. ***
Comment 186 José Jeria 2004-11-04 01:20:27 PST
*** Bug 267617 has been marked as a duplicate of this bug. ***
Comment 187 Uri Bernstein (Google) 2004-11-08 09:58:46 PST
*** Bug 268294 has been marked as a duplicate of this bug. ***
Comment 188 Tracy Walker [:tracy] 2004-11-09 10:06:08 PST
*** Bug 268595 has been marked as a duplicate of this bug. ***
Comment 189 OstGote! 2004-12-03 06:41:15 PST
*** Bug 272950 has been marked as a duplicate of this bug. ***
Comment 190 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-03 21:51:07 PST
*** Bug 272366 has been marked as a duplicate of this bug. ***
Comment 191 José Jeria 2004-12-10 05:10:13 PST
*** Bug 274040 has been marked as a duplicate of this bug. ***
Comment 192 Worcester12345 2004-12-24 01:10:24 PST
(In reply to comment #178)
> ok, seems we have run out of time for aviary PR and too many more higher risks
> items.  if this gets landed and shakes out ok we could consider for final

aviary-landing keyword?
Comment 193 Ryan VanderMeulen [:RyanVM] 2005-01-15 16:43:40 PST
Can we get this checked into the trunk?
Comment 194 José Jeria 2005-02-01 08:51:33 PST
*** Bug 280666 has been marked as a duplicate of this bug. ***
Comment 195 Johnny Stenback (:jst, jst@mozilla.com) 2005-02-01 18:04:39 PST
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

sr=jst
Comment 196 neil@parkwaycc.co.uk 2005-02-02 05:31:03 PST
Attachment 149042 [details] [diff] checked in.

Note that this does not restore the status bar across tab swtiches,
it just blocks setting the status bar from background tabs.
Comment 197 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-02-07 16:55:44 PST
*** Bug 281449 has been marked as a duplicate of this bug. ***
Comment 198 Marek Schimara 2005-02-09 07:45:21 PST
88 duplicates & counting..
I almost logged one myself, replicated on 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050205 Firefox/1.0+
from the nightly build, no extensions, no prefs set except of allowing JS to
change the status bar text; visited a page with scrolling info
(www.cdiscount.com) opened a new tab and voila - it's there...
Comment 199 Gérard Talbot 2005-02-14 13:35:56 PST
*** Bug 282015 has been marked as a duplicate of this bug. ***
Comment 200 Asa Dotzler [:asa] 2005-02-15 22:25:21 PST
Neil, can we get this patch landed for 1.8b? 
Comment 201 neil@parkwaycc.co.uk 2005-02-16 02:17:27 PST
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

I'm sorry, I thought I had checked it in, but I obviously didn't fix up the
merge conflicts correctly :-[
Comment 202 Asa Dotzler [:asa] 2005-02-16 16:45:26 PST
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

a=asa for checkin to 1.8b.
Comment 203 Mike Shaver (:shaver -- probably not reading bugmail closely) 2005-02-17 09:01:12 PST
Deblockerizing after #drivers discussion.  Neil: please land if you find time
before 1.8b1 leaves the station, but a bug of this age and relatively minor
severity shouldn't be a reason to keep the trunk closed.
Comment 204 neil@parkwaycc.co.uk 2005-02-17 12:21:38 PST
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

OK, I checked in the missing link...
Comment 205 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-02-20 12:44:35 PST
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

I think the nsXULWindow changes caused a pretty major leak -- bug 282938 -- a
leak of webshells from inside tabbrowser *until* the window containing the
tabbrowser goes away.
Comment 206 José Jeria 2005-03-20 06:22:08 PST
*** Bug 217961 has been marked as a duplicate of this bug. ***
Comment 207 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-03-26 20:49:31 PST
*** Bug 287878 has been marked as a duplicate of this bug. ***
Comment 208 Matthias Versen [:Matti] 2005-04-05 06:10:53 PDT
*** Bug 289109 has been marked as a duplicate of this bug. ***
Comment 209 José Jeria 2005-04-07 10:15:12 PDT
*** Bug 289445 has been marked as a duplicate of this bug. ***
Comment 210 charlie 2005-04-07 14:11:28 PDT
I am not a programmer so may have this wrong, but it seems not to be just
tickers.  I see it with static text as well.  Or maybe looking for and loading
are a form of ticker that I don't recognize.

I started reading down through the comments and got to a spot where people were
talking about a working patch and thought there was a glimmer of hope until I
realized that that was back in 2003 and this bug has been around since 2001.
Comment 211 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-05-03 21:12:50 PDT
*** Bug 292816 has been marked as a duplicate of this bug. ***
Comment 212 Caleb 2005-05-04 09:21:56 PDT
*** Bug 292816 has been marked as a duplicate of this bug. ***
Comment 213 Jo Hermans 2005-06-01 09:12:55 PDT
*** Bug 296226 has been marked as a duplicate of this bug. ***
Comment 214 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-06-01 17:05:54 PDT
*** Bug 268745 has been marked as a duplicate of this bug. ***
Comment 215 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-06-15 10:11:26 PDT
*** Bug 297757 has been marked as a duplicate of this bug. ***
Comment 216 psellhorst 2005-06-23 23:49:32 PDT
> 2004-09-25 23:02 PDT
> bugs@bengoodger.com
> Removed Flag blocking-aviary1.0+ Added Flag blocking-aviary1.0-
>
> 2005-06-15 11:21 PDT
> asa@mozilla.org
> Removed Flag blocking-aviary1.1+ Added Flag blocking-aviary1.1-

You are not trying to turn the stuck status bar messages into some sort of
intentional Firefox trademark, are you?
Comment 217 Worcester12345 2005-06-24 13:58:56 PDT
This patch is over a year old. Is this a WONTFIX or is it going to get in for 1.1?
Comment 218 Zvi Devir 2005-06-24 16:11:52 PDT
As far as I see it, the patch does not really fix the bug. It just hide some of
its aspects. In order to properly fix the bug, the status bar should be
separated for each tab. Right now, there is one common logical status bar for
all tabs, and all the problems arise from that.
This is one of the most annoying bugs still open (unless the fix for bug 209330
solves some of the problems). I can recount the dups (98), or the votes (148),
or the CCs (174). All of those indicate that this bug MUST be fixed, and properely. 
I also have some suspicions that this bug is responsible for numerous bugs in
Thunderbird related to mishandling the status bar of the various "tabs" in TB
(bug 216276, bug 223730, bug 238764, bug 238986, bug 245823, bug 252667, bug
275199, bug 283438, bug 290596). If I am correct, those bugs will be much harder
to fix unless this bug is finally fixed.

(Can anyone change the severity to Major?)
Comment 219 Michal 'hramrach' Suchanek 2005-06-25 02:21:21 PDT
(In reply to comment #218)
> As far as I see it, the patch does not really fix the bug. It just hide some of

hmm, I thought I overlooked something when looking at the patch as people vere
talking here about properly fixing the bug.

So I vote for a real fix as well.
Comment 220 Ryan VanderMeulen [:RyanVM] 2005-06-25 07:33:09 PDT
@hramrach - ONLY developers set the + switch for blockers. Bugzilla users are
allowed to nominate (?) bugs for blocking status, but not to approve them. In
this case, it was nominated and minused already by developers. End of story.
Re-nominate for the next round, but do NOT go changing things you shouldn't be
changing.
Comment 221 Thomas Brown 2005-06-25 12:09:31 PDT
(In reply to comment #218)
> In order to properly fix the bug, the status bar should be
> separated for each tab. Right now, there is one common logical status bar for
> all tabs, and all the problems arise from that.

I made this suggestion on comment #43 and comment #124 over 2.5 years ago so
either the suggested fix is extremely difficult or the priority has been set
very low.  I know the developers are working very **** new features and bug
fixes for other issues, but I hope that this one will eventually make it on the
radar screen.
Comment 222 RDL 2005-06-25 15:46:21 PDT
(In reply to comment #220)
> @hramrach - ONLY developers set the + switch for blockers. Bugzilla users are
> allowed to nominate (?) bugs for blocking status, but not to approve them. In
> this case, it was nominated and minused already by developers. End of story.
> Re-nominate for the next round, but do NOT go changing things you shouldn't be
> changing.

Mr  Ryan VanderMeulen;

1) hramrach was permitted, by this Bugzilla setup to change the flag even though
his role does not authorise that action. For some reason, Bugzilla is not aware
of this restriction.
2) In view of (1) then, at worst, hramrach can be accused of being a poor
reader, not being able to cope with masses of "small print" or (probably
unintentionally) negligence of "back page" provisos.
3) Good practice is to not subject users to committing sins of commission where
this can and should be automatically precluded by software.
4) If there is no bug relating to points (1) and (3), which constitute a Moz
BugZilla deficiency, perhaps you should express your actual or longed-for
authority by submitting one and by referring us to that so we might vote for it.
If there is one, please inform here or on TEM, so we can all vote for that.
5) The difference between helpful people trying to progress life, and someone
with poor self esteem relieving their needs to be heard by issuing heavily
authoritarian, bullying replies to people who offend in ways the system should
prevent, involves some things called courtesy and respectful good tone of voice,
which, I believe, are considered prime directives in this forum. As a starting
point, I did not see the word "please" anywhere in your reply.
6) I shall take no note of any reply to this post until I see someone has bugged
the cause of the problem instead of berating clots who use the flags because
they are available. Perhaps you think I should raise the bug but I think you
have earned that honour. So please don't bother to tell me I'm 'spamming'. Just
get BugZilla fixed. Please. RDL
Comment 223 Michal 'hramrach' Suchanek 2005-06-26 03:51:59 PDT
(In reply to comment #220)
> @hramrach - ONLY developers set the + switch for blockers. Bugzilla users are
> allowed to nominate (?) bugs for blocking status, but not to approve them. In
> this case, it was nominated and minused already by developers. End of story.
> Re-nominate for the next round, but do NOT go changing things you shouldn't be
> changing.

Sorry, I did not notice asa already marked the bug as - two weeks ago.
I tried to frob anything that bugzilla would allow me and since I managed to
frob this I exected it is an unpriviledged operation.

As it turns out, I found a bug in bugzilla that allows me to change something I
should know to not change :)
Comment 224 Zvi Devir 2005-06-26 07:12:50 PDT
(In reply to comment #222)
> 4) If there is no bug relating to points (1) and (3), which constitute a Moz
> BugZilla deficiency, perhaps you should express your actual or longed-for
> authority by submitting one and by referring us to that so we might vote for it.
> If there is one, please inform here or on TEM, so we can all vote for that.
And not to forget to mark that bug as dependent of this one ;)
Comment 225 Jason Daly 2005-06-29 20:35:07 PDT
Extremely annoying bug for anyone who takes advantage of tabbed browsing, which
is more and more people, and this bug is minused yet again...

I mean, it can't be that hard to fix, after all, it is and has been assigned for
a while.
Comment 226 A G 2005-06-30 22:54:51 PDT
> its aspects. In order to properly fix the bug, the status bar should be
> separated for each tab. Right now, there is one common logical status bar for
> all tabs, and all the problems arise from that.

I dont think so. The forward, back, refresh etc buttons are common across the
tab. Still they work fine, right? So even the status bar should work fine.

All said and done... I am grateful to the developers of Firefox for providing
such a wonderful product.
Comment 227 Zvi Devir 2005-07-03 09:17:14 PDT
(In reply to comment #226)
> I dont think so. The forward, back, refresh etc buttons are common across the
> tab. Still they work fine, right? So even the status bar should work fine.
I don't think I follow you. Are you talking about the GUI or about the logic
behind the GUI?
Comment 228 Uri Bernstein (Google) 2005-07-08 10:25:47 PDT
*** Bug 300097 has been marked as a duplicate of this bug. ***
Comment 229 Asa Dotzler [:asa] 2005-07-12 14:02:31 PDT
neil, is there anything more that's you're going to be able to do for this bug
in time for the upcoming Aviary releases?
Comment 230 neil@parkwaycc.co.uk 2005-07-12 16:09:35 PDT
Saving the status bar across tab switches is not a priority for me.
Comment 231 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-07-13 18:47:21 PDT
(In reply to comment #196)
> Attachment 149042 [details] [diff] [edit] checked in.
> 
> Note that this does not restore the status bar across tab swtiches,
> it just blocks setting the status bar from background tabs.

Is there a way to get more info on the source of the SetStatus call than just
whether SetStatus was called by the current tab or not ("mPrimary" being true)?
Comment 232 José Jeria 2005-07-14 08:41:35 PDT
*** Bug 300775 has been marked as a duplicate of this bug. ***
Comment 233 Forrest Goodson 2005-07-26 10:52:48 PDT
*** Bug 300361 has been marked as a duplicate of this bug. ***
Comment 234 José Jeria 2005-08-20 02:28:16 PDT
*** Bug 305298 has been marked as a duplicate of this bug. ***
Comment 235 Phil Ringnalda (:philor) 2005-09-07 19:28:30 PDT
*** Bug 307443 has been marked as a duplicate of this bug. ***
Comment 236 Ryan Flint [:rflint] (ping via IRC for reviews) 2005-09-16 13:25:29 PDT
*** Bug 308860 has been marked as a duplicate of this bug. ***
Comment 237 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-09-23 10:59:51 PDT
Created attachment 197194 [details] [diff] [review]
some code

I think this patch gets the docshell for the <browser> whose JS did
window.status="foo" to nsBrowserStatusHandler.js.  It might be possible from
nsBrowserStatusHandler to iterate over each browser and check if the docshell
matches - then it would know which tab's status text should be set (it could
store that somewhere and restore the right text when you switch tabs).
Comment 238 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-09-23 11:01:04 PDT
The onprogresschange edit and countRemainingItems function should not have been
part of that.  If you plan to use that patch for anything, you'll want to ignore
those changes.
Comment 239 Frank Yan (:fryn) 2005-10-04 18:55:37 PDT
if a patch has been approved, why hasn't it been checked in?
Comment 240 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-10-04 18:57:56 PDT
(In reply to comment #239)
> if a patch has been approved, why hasn't it been checked in?

Did you read comment #196?
Comment 241 Frank Yan (:fryn) 2005-10-04 18:59:19 PDT
(In reply to comment #240)
> (In reply to comment #239)
> > if a patch has been approved, why hasn't it been checked in?
> 
> Did you read comment #196?

it still appears in my build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004
Firefox/1.4.1 ID:2005100415
Comment 242 Eric Portelance 2005-10-04 19:32:12 PDT
(In reply to comment #241)
I don't think you understood properly.  The patch that was approved and checked
in is NOT a fix for this bug.  Please read comment #196.
Comment 243 psellhorst 2005-10-11 20:59:32 PDT
Could you please *at least* revive that old patch that clears the status bar
on tab switches and check it in in time for Firefox 1.5-final?

Also, note that the workaround of opening a blank tab, reloading that tab and
closing it again does not work anymore now that bug 237776 has been fixed.
Previously, it could be used to replace the stuck status bar message with "Done".
Comment 244 pile0nades 2005-11-25 20:58:40 PST
I have an idea as to the nature of this bug:

I have 2 tabs open, tab A and tab B. When I switch to tab B, tab A's status bar text stays until something in tab B (js, reload page, visit link) changes it. It doesn't matter if it is loading or not. Both tabs may be finished loading and should have the "Done" message, but when I switch to tab B, the status bar keeps tab A's "Done" message even though it should say that anyway, so the bug isn't noticed in that case.

When loading a tab, it goes through the following messages in the status bar:
1. "Looking up www.google.com"
2. "Connecting to www.google.com"
3. "Waiting for www.google.com"
4. "Transferring data from www.google.com"
5. "Done"

The bug happens like this. I have 2 tabs open, google (may be too fast on broadband, I have a 5K/sec wifi card) and mozillazine.org, which is the selected tab. I right-click the google tab and click "Reload tab". I wait 1 second, select the google tab, status bar shows the following:
1. "Done" (from the mozillazine tab even though google tab is loading)
2. "Waiting for www.google.com"
3. "Transferring data from www.google.com"
4. "Done"

What should have happened is when I selected the google tab, the status bar says "Connecting to www.google.com" instead of retaining the "Done" message from the mozillazine tab. I think a better name for this bug would be "Status bar text from current tab persists when selecting another tab until it is changed."

Comment #64 suggests looking at the way the titlebar is handled. When switching tabs, the titlebar instantly changes to the title of the current tab, but the statusbar text is the same as the previous tab until something changes it. What does the titlebar code do on tab switch that the status bar code does not? The fix for this bug could be in the titlebar code.
Comment 245 charlie 2005-11-27 20:46:38 PST
It is now worse than just the status bar not updating.  I found today that when I have multiple Firefox windows open with multiple tabs, when I close a window and switch to another window and then close a tab there the title bar doesn't update, the taskbar doesn't update and worst, the URL still has the address of the closed page.
Comment 246 Bruce Wolfe 2006-01-16 22:13:16 PST
Okay, folks, I do not understand how this very important element got broken.  The code had to be the same for Firefox and Mozilla as for SeaMonkey.  It seems core to the build.

Here is what happens with Build 206011609.
1: Open Navigator
2: Default page opens (i.e., www.mozilla.org)
3: Ctrl-L and enter new URL (i.e., www.google.com)
4: Click on a link in Google
5: Now try to go back in history...There is none and the status bar didn't change with the subsequent locations www.google.com and the link within Google.

If you open a new tab, it will work perfectly.
So, the only way I can use SeaMonkey's Navigator effectively is to open it and then immediately open a new tab and work from there leaving the original window tab behind.

This is a major broken element.

Thank you for all your hard work and attention on this. If I didn't suffere from severe nerve damage from fingers to neck, I would join you in this work.  I will try to review the code and make suggestions with a helper.
Comment 247 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-01-17 05:15:20 PST
(In reply to comment #246)
> 5: Now try to go back in history...There is none and the status bar didn't
> change with the subsequent locations www.google.com and the link within Google.
> 
> If you open a new tab, it will work perfectly.
> So, the only way I can use SeaMonkey's Navigator effectively is to open it and
> then immediately open a new tab and work from there leaving the original window
> tab behind.

That doesn't sound like it's this bug.
Comment 248 Bruce Wolfe 2006-01-25 01:08:17 PST
Please explain your response.  I read the entire thread and it does seem to exactly fit especially with the post just prior to mine.


(In reply to comment #247)
> (In reply to comment #246)
> > 5: Now try to go back in history...There is none and the status bar didn't
> > change with the subsequent locations www.google.com and the link within Google.
> > 
> > If you open a new tab, it will work perfectly.
> > So, the only way I can use SeaMonkey's Navigator effectively is to open it and
> > then immediately open a new tab and work from there leaving the original window
> > tab behind.
> 
> That doesn't sound like it's this bug.
> 
Comment 249 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-01-25 05:07:00 PST
(In reply to comment #248)
> Please explain your response.  I read the entire thread and it does seem to
> exactly fit especially with the post just prior to mine.

The comment before yours is also not this bug.  This bug is *only* about things that happen when you switch tabs, not when you go back/forward/between windows.  It's not about any problems other than the text in the status bar being incorrect.
Comment 250 Ria Klaassen (not reading all bugmail) 2006-02-08 05:11:57 PST
*** Bug 326387 has been marked as a duplicate of this bug. ***
Comment 251 Zvi Devir 2006-02-15 15:36:36 PST
Can someone (Neil?) please state the status of this bug?
Thanks.

--------------------------------------------------------

A quick recount:
* Age: Four years and four months.
* Sevirity: Normal (shouldn't be a Major?)
* Dups: 105.
* Votes: 209.
* CC's: 189.
* Comments: 251.
Comment 252 Clark Pearson 2006-02-16 02:56:38 PST
I don't understand why - HOW - this bug can possibly be taking so long to fix.

I reported it over a year ago as a USER, not as a developer. How much time has been spent reading update emails regarding the bug and cross referencing new bug reports to it to mark them as duplicates of this one? Too much.

Moz/FFox should default to ALLOWING update of the status bar via JavaScript. Why doesn't it? Could it possibly be due to this bug...? Thereby hiding the problem from a lot of users. I'm sure it must all be the same general problem. That is, window.status & .defaultStatus don't work properly either, I'm assuming there are bugs for that as dups of this one: I have to have onmouseover/out statements to do it for me instead.

Please, for your users' sakes, get this problem sorted out. I imagine "IE" is pretty much a banned word on this site, but I have to say if IE can get it right, surely Moz can?!
Comment 253 Daniel Beardsmore 2006-02-16 03:43:22 PST
IE is not tabbed -- this issue relates to tabbed browsing (unless you're referring to IE 7?) But iCab for Macintosh never had this problem from the instant a beta was released with tabbed browsing implemented. (In general, using iCab is an eye opener to all the things that Firefox should get right, but under Windows you're not as fortunate! At least with Firefox 1.5, someone finally realised that it was utterly absurd to prevent you saving something to disc that's open in a tab but no longer accessible on the site, but I have yet to see whether it also fixes the bug where Firefox 1.0.x keeps not caching images in the first place).

Someone SERIOUSLY needs to hit the Mozilla developers over the head with a copy of iCab, to play with it and see how well everything works, and hope that some of the design sense rubs off on them. Why does upgrading 1.0.7 to 1.5 randomly delete incompatible extensions? Why does upgrading to 1.0.7 to 1.5.0.1 randomly delete incompatible extensions? Why does upgrading 1.5 to 1.5.0.1 cause some extensions to become obsolete?! (What on earth did a 0.0.0.1 change make to the extension mechanism?) Why does Firefox randomly lose whole swathes of settings?

And then you have stupid bugs like this (tabbed browsing vs the status bar) that last for years. Conceptually this bug is trivial, so I cannot imagine what sort of crawling horror Firefox is inside that would lead to something this simple being perpetually unable to be fixed. It's scary how bad IE must be to allow something as buggy as Firefox to gain so much popularity...
Comment 254 Clark Pearson 2006-02-16 03:54:47 PST
Just for the record, the status bar not updating isn't only related to tabbed browsing, it's just the title that this bug has. I think I originally raised the prob wrt window.status/defaultStatus but had my bugged marked as a dup of this one.
Comment 255 Ryan VanderMeulen [:RyanVM] 2006-02-16 04:02:07 PST
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Either put up a patch or stop with the whining in this bug. It serves no purpose whatsoever. Did it ever occur to you that maybe some bugs are harder to fix than they may appear?

Anyway, those of us who are CCed to this bug are CCed because we're interested in USEFUL discussion on the matter. I didn't CC myself to this so I could hear everyone and their mother interject their opinion. Have some respect for your peers and take your complaining to Mozillazine where it belongs and STOP SPAMMING THIS BUG.
Comment 256 ibrahim.awwal 2006-02-16 16:27:21 PST
Well the changing of the status bar via javascript can be a security bug, and is often used in phishing techniques to make users think that a link points to one site when it actually points to another. So, I don't think it's a good thing for that to be able to be changed via javascript. In that case, the fact that window.status doesn't work is a feature, not a bug. ;)
Comment 257 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-02-16 22:32:50 PST
ajschult did some testing which I confirmed, and this bug seems to be WFM.  The status bar never contains text from alternate tabs regardless of status bar tickers, changing tabs during pageload, etc.

Firefox is in worse shape than SeaMonkey (various issues remain), but a separate bug should be filed in the Firefox product for it.
Comment 258 Uri Bernstein (Google) 2006-02-17 00:09:00 PST
(In reply to comment #257)
> ajschult did some testing which I confirmed, and this bug seems to be WFM.  The
> status bar never contains text from alternate tabs regardless of status bar
> tickers, changing tabs during pageload, etc.

I can still reproduce this using the steps in comment #2.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060216 Firefox/1.6a1

Given the many comments on the difficulties in fixing it, I would be very surprised if it just started working one day.
Comment 259 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-02-17 00:20:28 PST
(In reply to comment #258)
> (In reply to comment #257)
> > ajschult did some testing which I confirmed, and this bug seems to be WFM.  The
> > status bar never contains text from alternate tabs regardless of status bar
> > tickers, changing tabs during pageload, etc.
> 
> I can still reproduce this using the steps in comment #2.
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060216
> Firefox/1.6a1
> 
> Given the many comments on the difficulties in fixing it, I would be very
> surprised if it just started working one day.
> 

Read the second paragraph in the comment you quoted.
Comment 260 Wayne Woods 2006-02-17 01:21:17 PST
New bug for Firefox component: bug 327604.

Given that the bug still exists in Mozilla's official browser, I'm surprised this bug was closed because of a partial fix in a community project. If anything, I believe the Product should have been changed.

Nevertheless, this bug could probably could do with a fresh start. Rather than resurrect one of the many dupes (most of which were changed to "Core" anyway), I opened the new bug.

I'm not sure who is still "active" on the Firefox side of this bug, so I haven't added anyone to the bug 327604. Anyone interested, please add yourselves. Please remember, however, that "expressions of displeasure" that the bug hadn't been fixed are not suitable for Bugzilla. If you feel you have to vent, please take it to the Mozillazine Forums.
Comment 261 Uri Bernstein (Google) 2006-02-17 01:29:31 PST
(In reply to comment #259)
> Read the second paragraph in the comment you quoted.

OK. For the record: the comment #2 issue was resolved (or worked around) in Mozilla somewhere between 1.3 and 1.4 (i.e., circa spring 2003).

Many (perhaps most) of the bugs duplicated to this one, starting from bug 234784 (comment 144) are reporting that same issue for Firefox, so I guess one of them should be re-opened and the others duplicated to it (except now I see that bug 327604 was created for this).
Comment 262 Gérard Talbot 2006-04-17 21:01:18 PDT
*** Bug 334391 has been marked as a duplicate of this bug. ***
Comment 263 Ryan Flint [:rflint] (ping via IRC for reviews) 2006-07-06 21:14:41 PDT
*** Bug 343831 has been marked as a duplicate of this bug. ***
Comment 264 Ryan Jones 2006-07-07 02:52:09 PDT
*** Bug 343847 has been marked as a duplicate of this bug. ***
Comment 265 :Hb 2009-10-12 04:58:32 PDT
SM2.0 on Win and Linux against http://freespace.virgin.net/rob.young/WebSight/JScript/StatusScroll.htm

Note You need to log in before you can comment on or make changes to this bug.