Closed Bug 104532 (TabSwitchStatusBar) Opened 23 years ago Closed 19 years ago

Status bar ticker fails to update when tabs switched.

Categories

(SeaMonkey :: Tabbed Browser, defect, P2)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: cohntm, Assigned: neil)

References

Details

Attachments

(3 files, 3 obsolete files)

Here's what I checked in on trunk
799 bytes, patch
Details | Diff | Splinter Review
Moved ApplyChromeFlags into nsXULWindow.cpp
15.62 KB, patch
danm.moz
: review+
jst
: superreview+
asa
: approval1.8b+
Details | Diff | Splinter Review
some code
17.22 KB, patch
Details | Diff | Splinter Review 
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.
yep. (i.e., a document is setting window.status on a timer; the same status
is shared by all windows).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
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.
*** Bug 107564 has been marked as a duplicate of this bug. ***
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.
*** Bug 111597 has been marked as a duplicate of this bug. ***
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!
QA Contact: blakeross → sairuh
*** Bug 112602 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Hardware: PC → All
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".
*** Bug 120091 has been marked as a duplicate of this bug. ***
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
*** Bug 122670 has been marked as a duplicate of this bug. ***
nsbeta1+ per ADT triage team, ->1.0.
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla1.0.1 → mozilla1.0
*** Bug 128108 has been marked as a duplicate of this bug. ***
Blocks: 128632
*** Bug 129548 has been marked as a duplicate of this bug. ***
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...
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!
removing plus for re-triage.
Keywords: nsbeta1+ → nsbeta1
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
-> 1.1
Target Milestone: mozilla1.0 → mozilla1.1alpha
*** Bug 139770 has been marked as a duplicate of this bug. ***
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.
*** Bug 140585 has been marked as a duplicate of this bug. ***
*** Bug 141770 has been marked as a duplicate of this bug. ***
confirm behaviour on Mozilla post 1.0, nightly build 2002042806
*** Bug 144608 has been marked as a duplicate of this bug. ***
*** Bug 145423 has been marked as a duplicate of this bug. ***
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.

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".
*** Bug 147885 has been marked as a duplicate of this bug. ***
*** Bug 149168 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
-> 1.2beta
Target Milestone: mozilla1.1alpha → mozilla1.2beta
*** Bug 151713 has been marked as a duplicate of this bug. ***
*** Bug 151067 has been marked as a duplicate of this bug. ***
*** Bug 152458 has been marked as a duplicate of this bug. ***
*** Bug 153119 has been marked as a duplicate of this bug. ***
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.
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.
nominating for buffy.
Keywords: nsbeta1- → nsbeta1
(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.



*** Bug 163609 has been marked as a duplicate of this bug. ***
*** Bug 166312 has been marked as a duplicate of this bug. ***
*** Bug 166779 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → pmac
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.
*** Bug 178083 has been marked as a duplicate of this bug. ***
*** Bug 178730 has been marked as a duplicate of this bug. ***
nsbeta1+/adt3 per the nav triage team.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
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
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.
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.
*** Bug 181964 has been marked as a duplicate of this bug. ***
*** Bug 184551 has been marked as a duplicate of this bug. ***
*** Bug 184638 has been marked as a duplicate of this bug. ***
*** Bug 159759 has been marked as a duplicate of this bug. ***
*** Bug 185002 has been marked as a duplicate of this bug. ***
*** Bug 185675 has been marked as a duplicate of this bug. ***
*** Bug 192426 has been marked as a duplicate of this bug. ***
*** Bug 193420 has been marked as a duplicate of this bug. ***
*** Bug 193475 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2beta → mozilla1.4beta
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.
*** Bug 195658 has been marked as a duplicate of this bug. ***
QA Contact: pmac → sairuh
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?
Severity: minor → normal
*** Bug 198604 has been marked as a duplicate of this bug. ***
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
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).
Blocks: majorbugs
*** Bug 199885 has been marked as a duplicate of this bug. ***
*** Bug 199923 has been marked as a duplicate of this bug. ***
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.

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. :-)
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.
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.
Flags: blocking1.4b?
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.
*** Bug 202637 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b?
Flags: blocking1.4b-
Flags: blocking1.4?
Flags: blocking1.4? → blocking1.4+
Blocks: 185547
No longer blocks: 185547
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.
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?
*** Bug 207278 has been marked as a duplicate of this bug. ***
Jag - any chance of time to hit this for 1.4?  I'm willing to help out.
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.
Whiteboard: [adt3] → [adt3][2003-06-05]
Attached patch Clear status when switching tabs (obsolete) — — Splinter Review 
Not quite the fix I want but it'll do for now. See previous comments for the
right fix.
Attachment #124781 - Flags: superreview?(sspitzer)
Attachment #124781 - Flags: review?(neil.parkwaycc.co.uk)
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.
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
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"
happens for me everytime following your steps.

try it on a slower connection.
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.
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?
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?
> byron: with my attached patch applied?

oops.  *sheepish grin*

i'm unable to duplicate the issue with your patch applied :)
Re: comment 85:
The patch has not been checked in, so it's not going to be in a build you
download yet.
Comment on attachment 124781 [details] [diff] [review]
Clear status when switching tabs

I get the idea, but...
Attachment #124781 - Flags: review?(neil.parkwaycc.co.uk) → review+
Attached patch I prefer this version :-) (obsolete) — — Splinter Review 

    
    

    
  
Comment on attachment 124813 [details] [diff] [review]
I prefer this version :-)

I totally agree.

        Attachment #124813 -
        Flags: superreview+

        Attachment #124813 -
        Flags: review+

        Attachment #124813 -
        Flags: approval1.4?

    
    

    
  
Comment on attachment 124781 [details] [diff] [review]
Clear status when switching tabs

clearing request, looks like this patch is obsolete.

        Attachment #124781 -
        Attachment is obsolete: true

        Attachment #124781 -
        Flags: superreview?(sspitzer)

    
    

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

    
    

    
  
updating summary and TM.
Status: NEW → ASSIGNED
Whiteboard: [adt3][2003-06-05] → [adt3][2003-06-05][a=sspitzer for 1.4, but let's get a= from another driver]
Target Milestone: mozilla1.4beta → mozilla1.4final

    
    

    
  
Comment on attachment 124813 [details] [diff] [review]
I prefer this version :-)

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

        Attachment #124813 -
        Flags: approval1.4? → approval1.4+
Whiteboard: [adt3][2003-06-05][a=sspitzer for 1.4, but let's get a= from another driver] → [adt3][2003-06-05][a=sspitzer,asa for 1.4 branch]

    
    

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

    
    

    
  


  
Since setOverLink will clear this.defaultStatus for us, why not depend on that
too?

        Attachment #124813 -
        Attachment is obsolete: true

    
    

    
  
I want to keep this bug open for the better fix, removing nsbeta1+[adt3] and
blocking1.4 to remove this bug from the radar.
Flags: blocking1.4+
Keywords: nsbeta1+ → fixed1.4
Whiteboard: [adt3][2003-06-05][a=sspitzer,asa for 1.4 branch] → [2003-06-05][a=sspitzer,asa for 1.4 branch]
Target Milestone: mozilla1.4final → ---

    
    

    
  
Verified the interim patch 2003060404 PC/WinXP

    
    

    
  
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?
Keywords: fixed1.4 → nsbeta1

    
  
Flags: blocking1.4+
Keywords: fixed1.4

    
    

    
  
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.

    
  
Whiteboard: [2003-06-05][a=sspitzer,asa for 1.4 branch] → [2003-06-05][a=sspitzer,asa for 1.4 branch][landed on trunk, 1.4branch]

    
    

    
  
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.

    
    

    
  
adt= nsbeta1+/adt2 Please land on 1.4branch and add fixed1.4 keyword
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [2003-06-05][a=sspitzer,asa for 1.4 branch][landed on trunk, 1.4branch] → [adt2][2003-06-05][a=sspitzer,asa for 1.4 branch][landed on trunk, 1.4branch]

    
    

    
  
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.

    
    

    
  
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.
Keywords: fixed1.4

    
    

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

    
    

    
  
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.
Keywords: fixed1.4 → verified1.4

    
    

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

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

    
    

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

    
  
Summary: Status bar ticker fails to update when tabs switched. → Status bar ticker fails to update when tabs switched. (JS status ticker)

    
    

    
  
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.
Summary: Status bar ticker fails to update when tabs switched. (JS status ticker) → Status bar ticker fails to update when tabs switched.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Still present in 1.5 RC1 (MacOS X)!!!

Nobody able to fix this??????

    
    

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



    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

    
  
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.


    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
yo@agustinfernandez.com.ar: if it's so easy then may i assign the bug to you?
when can we expect your patch?

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
  
Flags: blocking1.7a?

    
    

    
  
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.
Flags: blocking1.7a? → blocking1.7a-

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Proposed patch (obsolete)
        — 
          — Splinter Review
      

    


  
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.
Assignee: jag → neil.parkwaycc.co.uk

    
    

    
  
Comment on attachment 147496 [details] [diff] [review]
Proposed patch

I've no idea who, if anyone, understands this stuff any more ;-)

        Attachment #147496 -
        Flags: superreview?(alecf)

        Attachment #147496 -
        Flags: review?(danm-moz)

    
    

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

    
    

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

    
    

    
  
(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 :-)

    
    

    
  
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?

    
    

    
  
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.

    
    

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

    
    

    
  


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

        Attachment #147496 -
        Attachment is obsolete: true

    
    

    
  
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.

        Attachment #149042 -
        Flags: review?(danm-moz)

    
  

        Attachment #147496 -
        Flags: superreview?(alecf)

        Attachment #147496 -
        Flags: review?(danm-moz)

    
    

    
  
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

Seems right, and a general logic improvement. Go for it.

        Attachment #149042 -
        Flags: review?(danm-moz) → review+

    
  

        Attachment #149042 -
        Flags: superreview?(jag)

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
  
Flags: blocking1.8a2?

    
  
Flags: blocking-aviary1.0?

    
    

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

    
  
Flags: blocking1.8a2? → blocking1.8a2-

    
    

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

    
    

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

    
    

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

    
  
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
Priority: -- → P2

    
    

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

    
    

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

    
    

    
  
If there is no checkin here in 7 days or so, missing the boat. 

    
    

    
  
Blake, why don't you sr this one, and take it on the branch if you want. But
please do asap. 

    
  
Whiteboard: [adt2][2003-06-05][a=sspitzer,asa for 1.4 branch][landed on trunk, 1.4branch] → [have patch][adt2][2003-06-05][a=sspitzer,asa for 1.4 branch][landed on trunk, 1.4branch]

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
  
Flags: blocking1.7a-
Flags: blocking1.4b-
Flags: blocking1.4+

    
    

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

    
    

    
  
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
Flags: blocking-aviary1.0PR+ → blocking-aviary1.0PR-

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
  
Flags: blocking1.8a2-

    
    

    
  
Not a "blocker"
Flags: blocking-aviary1.0+ → blocking-aviary1.0-

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
  
Blocks: 252811

    
  
No longer blocks: 252811

    
    

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

    
  
Flags: blocking-aviary1.1?

    
  
Flags: blocking1.8a6?

    
  
Flags: blocking1.8a6? → blocking1.8a6+

    
  
Flags: blocking1.8a6+ → blocking1.8a6-

    
  
Flags: blocking1.8a6- → blocking1.8a6+

    
  
Flags: blocking1.8a6+ → blocking1.8a6-

    
  
Flags: blocking1.8b?

    
    

    
  
Can we get this checked into the trunk?

    
  
Flags: blocking1.8b?
Flags: blocking1.8b+
Flags: blocking1.8a6-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0-

    
  

        Attachment #149042 -
        Flags: superreview?(jag) → superreview?(jst)

    
    

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

    
    

    
  
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

sr=jst

        Attachment #149042 -
        Flags: superreview?(jst) → superreview+

    
    

    
  
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.

    
    

    
  
*** Bug 281449 has been marked as a duplicate of this bug. ***
Alias: TabSwitchStatusBar

    
    

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

    
    

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

    
    

    
  
Neil, can we get this patch landed for 1.8b? 

    
    

    
  
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 :-[

        Attachment #149042 -
        Flags: approval1.8b?

    
    

    
  
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

a=asa for checkin to 1.8b.

        Attachment #149042 -
        Flags: approval1.8b? → approval1.8b+

    
    

    
  
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.
Flags: blocking1.8b+

    
    

    
  
Comment on attachment 149042 [details] [diff] [review]
Moved ApplyChromeFlags into nsXULWindow.cpp

OK, I checked in the missing link...

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
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.

    
    

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

    
    

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

    
  
No longer blocks: majorbugs

    
    

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

    
    

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

    
    

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

    
  
Flags: blocking-aviary1.1+ → blocking-aviary1.1-
Whiteboard: [have patch][adt2][2003-06-05][a=sspitzer,asa for 1.4 branch][landed on trunk, 1.4branch]

    
    

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

    
    

    
  
This patch is over a year old. Is this a WONTFIX or is it going to get in for 1.1?

    
    

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

    
    

    
  
(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.
Flags: blocking-aviary1.1- → blocking-aviary1.1+

    
    

    
  
@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.
Flags: blocking-aviary1.1+ → blocking-aviary1.1-

    
    

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

    
    

    
  
(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

    
    

    
  
(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 :)

    
    

    
  
(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 ;)

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
  
Flags: blocking1.8b4?

    
    

    
  
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?

    
    

    
  
Saving the status bar across tab switches is not a priority for me.

    
  
Flags: blocking1.8b4? → blocking1.8b4-

    
    

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

    
    

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

    
    

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

    
  
Flags: blocking-aviary2.0?

    
    

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

    
    

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

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        some code
        — 
          — Splinter Review
      

    


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

    
    

    
  
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.

    
    

    
  
if a patch has been approved, why hasn't it been checked in?

    
    

    
  
(In reply to comment #239)
> if a patch has been approved, why hasn't it been checked in?

Did you read comment #196?

    
    

    
  
(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

    
    

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

    
  
Flags: blocking-seamonkey1.0b?
Flags: blocking-seamonkey1.0b? → blocking-seamonkey1.0b-

    
    

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

    
    

    
  
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.


    
    

    
  
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.
Flags: blocking-aviary2? → blocking-aviary2-
Flags: blocking1.8b5-
Flags: blocking-firefox2-
Flags: blocking-aviary1.5-

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

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

    
  
Blocks: 327238

    
    

    
  
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.


    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
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.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME

    
    

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

    
    

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

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

    
  
*** Bug 343847 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey

    
    

    
  
SM2.0 on Win and Linux against http://freespace.virgin.net/rob.young/WebSight/JScript/StatusScroll.htm
Status: RESOLVED → VERIFIED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: