Window titlebar sometimes fails to update to page title when browsing/creating tabs

RESOLVED WORKSFORME

Status

()

Firefox
Tabbed Browser
P2
normal
RESOLVED WORKSFORME
14 years ago
5 years ago

People

(Reporter: PikeUK, Assigned: mconnor)

Tracking

({fixed-aviary1.0, regression})

unspecified
fixed-aviary1.0, regression
Points:
---
Bug Flags:
blocking-aviary1.0PR +
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:spoof])

Attachments

(4 attachments)

(Reporter)

Description

14 years ago
As of today's Aviary builds sometimes the main window titlebar doesn't update to
match the title of a page when you create a new tab or navigate to other pages
within that tab. I haven't been able to figure out any steps to reliably
reproduce this, but if you browse around in multiple tabs it should happen
sooner or later.

This has happened on two different machines with two different builds (and also
occurs on a clean profile), it doesn't happen on yesterday's official Aviary
nightly.

Workaround: Switch to another tab then switch back again and the titlebar will
be updated.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040708
Firefox/0.9.0+
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: blocking-aviary1.0RC1+
Priority: -- → P2

Comment 1

14 years ago
for me, titles on some pages don't show up, instead the title of the page from
previous tab remains in the window titlebar..
steps to reproduce:
1. open page that displays the title correctly (mail.yahoo.com for me),
2. open page http://teraz.sme.sk in a new tab - the yahoo's title remains in the
titlebar..

is this the same bug?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

Comment 2

14 years ago
When opening a new window (and loading a page if your homepage is about:blank),
the js console displays this error:
Error: browser has no properties
Source File: chrome://global/content/bindings/tabbrowser.xml
Line: 721

This is the line var titleViaGetter = browser.blahblah
The method is setTabTitle...

Comment 3

14 years ago
I just noticed this with today's build (2004 07 09) of Firefox on WinXP.  Here
is one method I found that seems to consistently reproduce the problem:
1. Go to any site (I used www.slashdot.org).
2. Right-click a link and choose "Open link in new tab"
3. Switch to the new tab.
4. Close this tab.
5. Visit any other site, and notice the title bar contains the title from the
previous page.

I checked the Javascript console, but it shows no error messages.

Comment 4

14 years ago
I just tried these steps using the July 7 nightly and July 8 night.  July 7
nightly doesn't show this problem, but July 8 nightly does.  That should narrow
the checkin time a little.  Also see this bug on Win9x, so it's at least not
WinXP specific.

Comment 5

14 years ago
(In reply to comment #4)
> I just tried these steps using the July 7 nightly and July 8 night.  July 7
> nightly doesn't show this problem, but July 8 nightly does.  That should narrow
> the checkin time a little.  Also see this bug on Win9x, so it's at least not
> WinXP specific.

Happens on the latest Linux builds, too, because I get the same problem.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040709 Firefox/0.9.0+
Two observations -- it's not necessary to load anything in the new tab, and the
problem only seems to happen with the originally-open tab.  i.e. you can
reproduce it like this:

1. start firefox
2. open a new tab
3. close it
4. load a new url

the titlebar will not update for any urls you load now.
Created attachment 152845 [details] [diff] [review]
patch

fix some levels of indirection
Keywords: fixed-aviary1.0
creating a dependency tree for when 241705 lands on the trunk. 
Depends on: 241705

Comment 9

14 years ago
(In reply to comment #6)
> Two observations -- it's not necessary to load anything in the new tab, and the
> problem only seems to happen with the originally-open tab.  i.e. you can
> reproduce it like this:
> 
> 1. start firefox
> 2. open a new tab
> 3. close it
> 4. load a new url
> 
> the titlebar will not update for any urls you load now.
> 

nope, the titlebar does show the page title after step 4 for me.. but then I'm
not using the latest build.. (using Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7) Gecko/20040626 Firefox/0.9.1)

Comment 10

14 years ago
m., there's no need to add comments like this.  If you read the comments, you'll
see I already said this happens on builds after July 7th.

Comment 11

14 years ago
I believe that this bug has been resolved has it not?

Comment 12

14 years ago
This does seem to be fixed on the July 17th nightly branch.  At least, following
the given steps doesn't cause the problem anymore.

Comment 13

14 years ago
I agree. I have not seen this problem lately, but it was fixed before 2004-07-17.

Comment 14

14 years ago
The "fixed-aviary1.0" keyword means: It's fixed on the aviary branch. If you
click on the "View Bug Activity" link, you see that Ben added it on 2004-07-11
already.
Since the bug is not marked as fixed, it means: It's not fixed on the trunk yet.

See comment 8: "creating a dependency tree for when 241705 lands on the trunk."
In order to fix this bug on the trunk as well, bug 241705 needs to be fixed
there first. That's not a problem on the branch, since Ben doesn't need
review/superreview there.

Please ask questions on mozillazine or irc instead of adding comments here.

Comment 15

14 years ago
I have just had this occur on a 20040729 branch build...

Comment 16

14 years ago
(In reply to comment #15)
> I have just had this occur on a 20040729 branch build...

Please use the latest nightlys before commenting on a bug it is fixed in the
branch but not the trunk at least that is how it seems.

Comment 17

14 years ago
My build is 4 days old. Bugzilla guidelines define a recent build as 14 days.
Anyway, the checkin that was supposed to fix this is 3 weeks old.

I am aware this is supposed to be fixed on the branch - that's why I pointed out
that it is still broken in my branch build.

Comment 18

14 years ago
(In reply to comment #17)
> My build is 4 days old. Bugzilla guidelines define a recent build as 14 days.
> Anyway, the checkin that was supposed to fix this is 3 weeks old.
> 
> I am aware this is supposed to be fixed on the branch - that's why I pointed out
> that it is still broken in my branch build.

My bad :(

Comment 19

14 years ago
This bug happened to me when I open a page in a new tab.
The new title appear on the FireFox Main Windows Title Bar.
But when I close the tab, thus returning to the underlying tab.
This Windows Title Bar doesn't update itself.
*** Bug 251315 has been marked as a duplicate of this bug. ***

Comment 21

14 years ago
*** Bug 259143 has been marked as a duplicate of this bug. ***
*** Bug 261162 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking-aviary1.0?
*** Bug 260299 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking-aviary1.0?

Comment 24

14 years ago
Change "sometimes" to "always": I have been seeing this with 1.0PR on two
different Windows 2000 machines.  The steps: open a page, check the title in the
blue title bar at top of window.  (2) control-T to open a new tab, enter a new
URL (or centre click a link on the earlier page) a new page opens in the new tab
and a new title appears in the title bar. Select the previous tab: Result: the
title remains as it was for the second tab.  It stays at whatever it was for the
most recent opened tab. The only way I can find to fix it is to refresh the page
for the subsequently selected tab.

Comment 25

14 years ago
OK, a bit more forensics: 
Part 1: Open 1.0PR with a homepage set. -> Title shows in title bar. (2) Open a
new URL in a new tab -> new title shows in title bar. (3) Select original tab ->
title reverts to its original wording. (4) Select second tab again -> title
*doesn't* change - still shows tab1, stays like this until tab2 page is refreshed.

Part 2: As before, open 1.0PR with a home page, then open second tab with new
URL. -> same behavior as before.  (2) Seclect original tab, left click a link in
it so a new page opens in tab 1 -> new tab1 title appears. (3) open a third tab
and enter a new URL. -> new title appears. (4) select original tab -> title
*doesn't* change this time, it stays as tab3.

Comment 26

14 years ago
I can see this problem on my PowerBook under Linux with

  Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8a4) Gecko/20040916

Hardware/OS should be set to All/All.

Updated

14 years ago
OS: Windows XP → All
Hardware: PC → All
*** Bug 264215 has been marked as a duplicate of this bug. ***

Comment 28

14 years ago
*** Bug 265195 has been marked as a duplicate of this bug. ***

Comment 29

14 years ago
Same thing happens to me, on WinXP Pro
Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

(In reply to comment #25)
> OK, a bit more forensics: 
> Part 1: Open 1.0PR with a homepage set. -> Title shows in title bar. (2) Open a
> new URL in a new tab -> new title shows in title bar. (3) Select original tab ->
> title reverts to its original wording. (4) Select second tab again -> title
> *doesn't* change - still shows tab1, stays like this until tab2 page is refreshed.
> 
> Part 2: As before, open 1.0PR with a home page, then open second tab with new
> URL. -> same behavior as before.  (2) Seclect original tab, left click a link in
> it so a new page opens in tab 1 -> new tab1 title appears. (3) open a third tab
> and enter a new URL. -> new title appears. (4) select original tab -> title
> *doesn't* change this time, it stays as tab3.

Comment 30

14 years ago
I also see this on Firefox RC2 on Win XP Pro (SP1)
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103
Firefox/1.0RC2)

Comment 31

14 years ago
It looks like most of bug 241705 has landed (see bug 241705 comment 28). Now
that it's in, can we get a fix for this into the trunk as well? The bug is still
present on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6)
Gecko/20041209 Firefox/1.0+

Comment 32

14 years ago
When I open a new tab (manually or a link opened in a new tab) I get this error:

Error: Component returned failure code: 0x80004002 (NS_NOINTERFACE)
[nsIInterfaceRequestor.getInterface]
Source File: 
Line: 209

Comment 33

14 years ago
(In reply to comment #32)
> When I open a new tab (manually or a link opened in a new tab) I get this error:
> ... 
> Line: 209

Only when the titlebar is failing to update ofcourse :)

Comment 34

14 years ago
Also, when switching tabs, the last tab's info will stay with sometimes on the
second tab.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041229
Firefox/1.0+

Comment 35

14 years ago
*** Bug 275437 has been marked as a duplicate of this bug. ***

Comment 36

14 years ago
*** Bug 277238 has been marked as a duplicate of this bug. ***

Comment 37

14 years ago
Aviary Landing key word? (IE: Did it regress after Aviary landed?)

Comment 38

14 years ago
Created attachment 170571 [details]
Test Case for Comment 2

Test case from Link in Comment 2.  Seems to be because of the character 'š'
being in the Title.

Updated

14 years ago
Flags: blocking-aviary1.1?
Whiteboard: [sg:fix]

Comment 39

14 years ago
The Product should be set to Core, as this occurs here with Mozilla. So, it
isn't specific to Firefox.

Comment 40

14 years ago
This appears to have been fixed, at least in this build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050209 Firefox/1.0+

Comment 41

14 years ago
It is not fixed in:
Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8b) Gecko/20050213

(Note: I'm using Mozilla, not Firefox.)
Flags: blocking-aviary1.1? → blocking-aviary1.1+
This bug is about Firefox, since the Firefox and Seamonkey tabbrowser code is
forked.

Does anyone using a recent Firefox nightly still see this behavior? I haven't
seen this, and the initial fix for the aviary branch was checked in on the trunk
by the landing.

Comment 43

13 years ago
This still happens in the 1.0.4 release on windows.

Comment 44

13 years ago
I can't reproduce it on the trunk, at least. Windows XP, 20050519 build. I'll
check with Mac OS X tonight. Any Linux people care to comment? :)

Comment 45

13 years ago
There's still this bug in Deer Park Alpha 1(Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8b2) Gecko/20050523 Firefox/1.0+)

Comment 46

13 years ago
Following my last post about not seeing the bug, I found I had trouble
reproducing it even with old builds, so I was beginning to suspect that I was
doing something wrong. Looks like I must be.

Is there any chance you could give some exact instructions on how to reproduce
it?   Following the instructions in comment 3 or comment 6 doesn't cause the bug
for me.

cheers

Comment 47

13 years ago
Without clear steps to reproduce, it's unlikely that we're going to take any
action for 1.1. 
Flags: blocking-aviary1.1+ → blocking-aviary1.1-

Comment 48

13 years ago
(In reply to comment #47)
> Without clear steps to reproduce, it's unlikely that we're going to take any
> action for 1.1. 

Well, on Deer Park, I've been seeing this a LOT with these wierd pdf files
(they're .pdf files, but I can enter text and print them out -- I've been
applying for a lot of jobs revcently, and a lot of people are using these pdf
application forms) They seem to do it all the time anyway.

Comment 49

13 years ago
I also saw it a lot on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050613 Firefox/1.0+. It showed up as aberrant tab titles. Also, the tabs
would sometimes get stuck - unable to close them. Gack.

Comment 50

13 years ago
Neither of the last comments give a method for reproducing, though. Can either
of you produce a url or specific page which triggers this bug?

Comment 51

13 years ago
(In reply to comment #50)
> Neither of the last comments give a method for reproducing, though. Can either
> of you produce a url or specific page which triggers this bug?

FWIW, I've not seen this bug in Firefox since version 1.0PR.  Certainly no sight
of it in FF1.04 on WinXP Pro sp2 or Win2K sp4.  The steps I used to trigger it
are explained in my two posts of 5 October last year (comments 24, 25). DN

Comment 52

13 years ago
I see it on a daily basis in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.8) Gecko/20050511 Firefox/1.0.4, but it is not reproducible with any
specific site.  I currently am seeing it on InfoWorld, where I opened:
http://www.infoworld.com/article/05/05/23/21FEwebapp_1.html
then right-click opened a new tab for the second page:
http://www.infoworld.com/article/05/05/23/21FEwebapp_2.html
then right-click opened a new tab for the parent overview (link in SEE ALSO
section to the right):
http://www.infoworld.com/reports/21SRwebapp.html
then right-click opened the other two links on the page:
http://www.infoworld.com/article/05/05/23/21FEwebapppush_1.html
http://www.infoworld.com/article/05/04/13/16OPstrategic_1.html

Now, when I go back to any of those tabs, I still have the title bar of the
first page: <title>AJAX breathes new life into Web apps | InfoWorld | Analysis |
2005-05-23 | By Peter Wayner</title>

I also use Session Saver and had these tabs re-opened upon startup of my
session, and see the same behavior across application restarts.

I have not had the time to test a development build/branch, but can guarantee
that it is present in the 1.0.x tree.  I see it on many sites, regularly.

Comment 53

13 years ago
The 1.0.x branch is only getting critical security fixes at this point and is
many months behind the development tree, so it's completely irrelevant for
Bugzilla purposes.

Comment 54

13 years ago
I wonder if it was due to badly cached pages, or something like that?

Anyway, as Justin hinted at, please try a recent nightly (the "Deer Park" ones
at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/).
Hopefully you can no longer reproduce it.

cheers
 

Comment 55

13 years ago
Re comment #53, one may wonder if this bug can be used for phishing (e.g. by
using Javascript in some way to create a page with non-ASCII characters), in
which case it could be seen as a security bug.

Comment 56

13 years ago
(In reply to comment #55)
> Re comment #53, one may wonder if this bug can be used for phishing (e.g. by
> using Javascript in some way to create a page with non-ASCII characters), in
> which case it could be seen as a security bug.

Actually there is more than that. If you succeed to trigger this bug (and it is
very hard to do that in latest nightlies), then it also causes that the security
state of address bar fails to update (for example if you close tab with
bugzilla, all other tabs will appear with yellow background in address bar).

I have sent e-mail to security@mozilla.org concerning this stuff at the
beginning of year... and I don't think that they think this is securty bug, at
least I've got no answer.
(Reporter)

Comment 57

13 years ago
I just saw this (or something similar) in a nightly (no extensions installed)
for the first time in months:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050720
Firefox/1.0+

I had a PDF in the current tab and switched to the tab directly to the left, the
location bar did not update, I didn't think to look whether the titlebar had
updated or not.

The JS console error was:

Error: focusedWindow has no properties
Source File: chrome://global/content/bindings/tabbrowser.xml
Line: 587

The source line in this error actually corresponds to the following line (due to
an #ifdef XP_MACOSX section in the raw source):

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/widgets/tabbrowser.xml&rev=1.92&mark=591#591

Comment 58

13 years ago
This one seems to be back for me as well.
This can be a spoofing issue.
Assignee: bugs → mconnor
Status: ASSIGNED → NEW
Whiteboard: [sg:fix] → [sg:spoof]
(Assignee)

Comment 60

13 years ago
Can anyone reproduce this? the js error mentioned in comment 57 was fixed on
07/28, and I can't reproduce this with the testcase given.

Updated

13 years ago
Flags: blocking-aviary2.0?

Comment 61

13 years ago
I can reproduce this every day, but I can't figure out any consistent rule for
how it works. It seems like some page titles are "strong" and others are "weak."

Right now I have 2 tabs open: one for this bugzilla page, the other is a
Mozillazine forum. When I switch tabs, the Mozillazine title is ALWAYS persistent.

So I open a third tab (blank). Mozillazine and the blank tab will change the
title, but the Bugzilla page always keeps the title from the last "strong" tab.

A 4th tab: the "Show Votes" page for this bug. This page is "strong."

Very strange.

Comment 62

13 years ago
OK. Reading the forums further, this is a Greasemonkey bug. Disabling
Greasemonkey fixes it. I can't reproduce this now.

Comment 63

13 years ago
(In reply to comment #62)
> OK. Reading the forums further, this is a Greasemonkey bug. Disabling
> Greasemonkey fixes it. I can't reproduce this now.

Not always. I see this one once in a while, and don't use and never have even
come close to installing this greasemonkey thing.

Comment 64

13 years ago
*** Bug 311140 has been marked as a duplicate of this bug. ***

Comment 65

13 years ago
This may be related to bug 288620.  That bug has the advantage of being easily 
reproducible (start with a pdf file in one tab, create a new tab, the title 
remains that of the pdf file) so maybe looking at it will point the right way...

Comment 66

13 years ago
I agree with Greg Campbell #61 above, there seems to be a strong/weak
association/ persistence between pages and the title.
For example I currently have 4 tabs open ['Mozilla Firefox', Google,
'Gmail-Inbox' and 'Bug 250423 - Window...']
and, at the moment, my window title bar shows 'Bug 250423 - Window...'
I can change tab to Gmail and the window title bar continues to show 'Bug 250423
- Window...'.

But if I click on the Google tab the windows title bar changes to 'Google -
Mozilla...' and this one is now the only one I get when I click through the tabs.

If I then open a new tab e.g. 37Signals.com - 'Simple Software...', it changes
the title bar as you would expect but then changing tabs to the Gmail, Bug
250423 and Mozilla Firefox start page tabs does not change the window title.

However, changing to the Google tab changes the title. But, this time, 37signals
is also 'strong' and will change the title back if you click on it.

I had a brief look at the source of the relevant pages and it didn't seem
related to doctype or Content-type, and it doesn't appear to be related to
number or position of the tabs
Other examples of the two types of sites...

Example "Weak" sites 	- https://bugzilla.mozilla.org/show_bug.cgi?id=250423
		- http://mail.google.com/mail/
		- http://www.techcrunch.com/
		- http://news.yahoo.com/
		- http://www.memeorandum.com/
		- http://www.wired.com/

"strong" sites 	- http://www.google.com/ig
		- http://37signals.com/
		- http://webreakstuff.com/

It may be worth noting that, in certain instances (e.g. close a 'strong' & the
rest are all 'weak'), the title bar will persist even after the original tab has
been closed.

Comment 67

13 years ago
I'm experiencing this bug with the latest nightlies. It came back around the 1.5 Betas (Beta 2 definitely, Beta 1 I'm not sure about), and had never happened in Deer Park Alpha 1.

This looks like a deeper tab focus issue that goes beyond just the titles; Text searching, at least, also remains linked to the most recent "strong" tab rather than the current one. There are probably other things I haven't noticed that are messed up as a result of this.

Comment 68

13 years ago
Just found out that the title and search functions don't necessarily lock to the same "strong" tab; While viewing tab A, the window title can belong to hidden tab B, and text searches may be made in hidden tab C.

[Either the search issue deserves a new bug, or this bug needs to be generalized.]
(In reply to comment #67)
> I'm experiencing this bug with the latest nightlies. It came back around the
> 1.5 Betas (Beta 2 definitely, Beta 1 I'm not sure about), and had never
> happened in Deer Park Alpha 1.

Are you seeing this with the branch or trunk nightlies? (I'm seeing it with the trunk nightlies, myself, but I figure another data point couldn't hurt.)

Also -- and I'm not directing this to you specifically, Moti -- is bug 294902 a dupe of this?

Comment 70

13 years ago
I first noticed this bug as of 1.5 beta2, and it persists in RC1.  I'm currently using RC1 on both Windows XP and Linux (Fedora Core 4).  I'm pretty sure that beta1 didn't have it, because I noticed it pretty immediately, and I still "notice" it fairly often.  It's hard to imagine that I used beta1 for so long without seeing it.

I should mention that I only use "official" releases: 1.5 beta1, 1.5 beta2, 1.5 RC1; no nightlies or anything, and I update using the "Check for Updates" menu option.  (So it's a diff install, not a clean full install, not that that likely makes any difference.)

Comment 71

13 years ago
By the way, I'm pretty sure that bug 294902 is a
duplicate of this bug.

Comment 72

13 years ago
*** Bug 294902 has been marked as a duplicate of this bug. ***

Comment 73

13 years ago
I can't reproduce this bug with Firefox 1.5 RC1 under Mac OS X.

Comment 74

13 years ago
I can confirm/offer information on this bug. I'm using 1.5RC1.

When I select 'open in new tab' on a link, the new tab does not become the front tab. I'm using (among other things) 'tab clicking options 0.6.1' and 'duplicate tab 0.6.2'.

I have 7 tabs open:
A; Page title aaaaaa; tab was at front for entire loading of page.
B; Page title bbbbbb; tab was at front for entire loading of page.
C; Page title cccccc; tab was at front for start of loading page; tab was at back for end of loading page.
D; Page title dddddd; tab was at back for start of loading page; tab was at front for end of loading page.
E; Page title eeeeee; tab was at back for entire loading of page.
F; Page title ffffff; tab was at back for entire loading of page.
G; Page title gggggg; tab was at back at start of loading, front at some time during loading, and at back for end of loading page.

(Summary: Tabs A, B, D and G seem to be correctly behaved; tabs C, E and F apparently not)

* I switch to tab A; window title becomes aaaaaa: I switch to tab B; window title becomes bbbbbb: I switch back to tab A; window title becomes aaaaaa.

* I switch to tab A; window title becomes aaaaaa: I switch to tab C; window title remains aaaaaa.

* I switch to tab A; window title becomes aaaaaa: I switch to tab E; window title remains aaaaaa: I switch to tab F; window title remains aaaaaa: I switch to tab B; window title becomes bbbbbb.

* (***) I start tab C loading in foreground; window title becomes cccccc: I switch to tab F; window title remains cccccc: I switch to tab A; window title becomes aaaaaa: I switch to tab C; window title remains aaaaaa.

* I switch to tab A; window title becomes aaaaaa: I start I start tab D loading in the background: I switch to tab D (before it finished loading); window title becomes dddddd: I switch to tab E; window title remains dddddd: I switch to tab A; window title becomes aaaaaa: I switch back to tab D; window title becomes dddddd

* I switch to tab A; window title becomes aaaaaa: I start I start tab E loading in the background: I switch to tab G (before it finished loading); window title becomes gggggg: I switch to tab E before G finished loading; window title remains gggggg: I switch to tab A; window title becomes aaaaaa: I switch back to tab G; window title becomes gggggg

In all cases, the tab generally displays the correct title; a simple patch would be to make the window title get taken from the tab title, or whereever the tab title comes from.

Similar bugs: bug 286019, bug 281620, bug 315062, bug 315161
My system: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8) Gecko/20051025 Firefox/1.5

Comment 75

13 years ago
Created attachment 202020 [details]
Screenshot displaying effect of bug 250423

This screenshot displays the bug's effect.

Comment 76

13 years ago
I'm experiencing this bug with Firefox RC1 (non-nightly), Windows XP Home SP2. Not sure if anyone mentioned, but the address bar also doesn't update to the current tab. It only updates when going to the first tab or creating a new one.
Didn't notice this bug in Beta2 (non-nightly).
Has anyone ever experienced this bug with a clean profile or without extensions? Comment 57 was fixed in bug 287467. I suspect that for recent builds, most if not all cases of this bug are due to misbehaving extensions.

Comment 78

13 years ago
(In reply to comment #77)
> Has anyone ever experienced this bug with a clean profile or without
> extensions? Comment 57 was fixed in bug 287467. I suspect that for recent
> builds, most if not all cases of this bug are due to misbehaving extensions.

You're probably right. Similar reports in Stumbleupon forum:
https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=138&&page=comments

Then duplicate bugs: bug 303149, bug 303122, bug 304392

Anyone confirming the behaviour without having Stumbleupon extension installed?

Comment 79

13 years ago
Installing the current beta of stumbleupon fixes this for me.
  See: http://bugs.stumbleupon.com/show_bug.php?bugid=103
  and http://www.stumbleupon.com/beta/stumbleupon.xpi

Comment 80

13 years ago
I don't have StumbleUpon installed and I still have this problem.
(In reply to comment #80)
> I don't have StumbleUpon installed and I still have this problem.

Using which build? What extensions do you have installed?

Comment 82

13 years ago
Looks to be related to this: 
http://bugzilla.mozdev.org/show_bug.cgi?id=11753

Seems to not break when greasemonkey is disabled.
StumbleUpon and GreaseMonkey seem to be the main culprits. Resolving as WFM, if anyone can reproduce with a clean profile then please reopen.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
Flags: blocking-aviary2?

Comment 84

13 years ago
Please reopen the bug. I've just tested 1.5RC1 under Linux/x86, with the binary downloaded from mozilla.org, and get the problem with "Test Case for Comment 2".

I couldn't create a new profile since the options -P, -CreateProfile and -ProfileManager are all ignored.

FYI, my extensions are:
Link Toolbar 1.1.0.1
Tab Mix Plus 0.3 Alpha
LinkChecker 0.4.2
SearchStatus 1.12

I have all these extensions under Mac OS X too, where this bug doesn't occur.
(In reply to comment #84)
> I couldn't create a new profile since the options -P, -CreateProfile and
> -ProfileManager are all ignored.

Try either a new profile, or safe mode. Make sure you have Firefox completely closed before using those command line arguments.

Comment 86

13 years ago
Well, I could try with a really clean profile after renaming my .mozilla directory. And this bug occurs:
1. Open a new tab (blank).
2. Open this page in this new tab.
3. Click on "Test Case for Comment 2" above.
4. Click on the first tab (corresponding to the initial home page).
5. Click on the second tab (this is the one of the test case).
Result: the window title is still the old one.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
If you set the javascript.options.showInConsole pref to true using about:config, do you see any errors in the JavaScript Console?

Comment 88

13 years ago
I just have the following messages in the Javascript Console:

No chrome package registered for chrome://navigator/locale/navigator.properties .
No chrome package registered for chrome://navigator-region/locale/region.properties .
No chrome package registered for chrome://communicator-region/locale/region.properties .

Comment 89

13 years ago
In case this is important, I'm using the window manager FVWM2 under ISO-8859-1 locales. I don't know what Firefox tries to do, but if it tries to set the window title with an invalid character, then this may be the problem.

Comment 90

13 years ago
Created attachment 202537 [details]
Valid test case

The bug also occurs with this valid test case. Note that the Euro symbol is not in ISO-8859-1. The bug does not occur with ISO-8859-1 characters.
(In reply to comment #90)
> The bug also occurs with this valid test case. Note that the Euro symbol is not
> in ISO-8859-1. The bug does not occur with ISO-8859-1 characters.

Vincent, that bug sounds absolutely valid, but you should file a new bug and attach your testcase there, this one has gotten rather unwieldy.

Comment 92

13 years ago
Reported as bug 315947. Note that this is similar to bug 150131.
*** Bug 315062 has been marked as a duplicate of this bug. ***
*** Bug 286019 has been marked as a duplicate of this bug. ***
*** Bug 315161 has been marked as a duplicate of this bug. ***
*** Bug 281620 has been marked as a duplicate of this bug. ***
*** Bug 318263 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.