Closed Bug 250423 Opened 20 years ago Closed 19 years ago

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

Categories

(Firefox :: Tabbed Browser, defect, P2)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: me, Assigned: mconnor)

References

Details

(Keywords: fixed-aviary1.0, regression, Whiteboard: [sg:spoof])

Attachments

(4 files)

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
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
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...
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.
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.
(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.
Attached patch patchSplinter Review
fix some levels of indirection
creating a dependency tree for when 241705 lands on the trunk. 
Depends on: 241705
(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)
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.
I believe that this bug has been resolved has it not?
This does seem to be fixed on the July 17th nightly branch.  At least, following
the given steps doesn't cause the problem anymore.
I agree. I have not seen this problem lately, but it was fixed before 2004-07-17.
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.
I have just had this occur on a 20040729 branch build...
(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.
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.
(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 :(
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. ***
*** Bug 259143 has been marked as a duplicate of this bug. ***
*** Bug 261162 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0?
*** Bug 260299 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0?
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.
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.
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.
OS: Windows XP → All
Hardware: PC → All
*** Bug 264215 has been marked as a duplicate of this bug. ***
*** Bug 265195 has been marked as a duplicate of this bug. ***
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.

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)
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+
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
(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 :)
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+
*** Bug 275437 has been marked as a duplicate of this bug. ***
*** Bug 277238 has been marked as a duplicate of this bug. ***
Aviary Landing key word? (IE: Did it regress after Aviary landed?)
Test case from Link in Comment 2.  Seems to be because of the character 'š'
being in the Title.
Flags: blocking-aviary1.1?
Whiteboard: [sg:fix]
The Product should be set to Core, as this occurs here with Mozilla. So, it
isn't specific to Firefox.
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+

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.
This still happens in the 1.0.4 release on windows.
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? :)
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+)
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
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-
(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.
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.
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?
(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

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.
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.
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
 
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.
(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.
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
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]
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.
Flags: blocking-aviary2.0?
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.
OK. Reading the forums further, this is a Greasemonkey bug. Disabling
Greasemonkey fixes it. I can't reproduce this now.
(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.
*** Bug 311140 has been marked as a duplicate of this bug. ***
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...
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.
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.
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?
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.)
By the way, I'm pretty sure that bug 294902 is a
duplicate of this bug.
*** Bug 294902 has been marked as a duplicate of this bug. ***
I can't reproduce this bug with Firefox 1.5 RC1 under Mac OS X.
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
This screenshot displays the bug's effect.
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.
(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?
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
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?
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
Closed: 19 years ago
Resolution: --- → WORKSFORME
Flags: blocking-aviary2?
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.
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?
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 .
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.
Attached file 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.
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.

Attachment

General

Created:
Updated:
Size: