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)
Firefox
Tabbed Browser
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+
Updated•20 years ago
|
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
Comment 2•20 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•20 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•20 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•20 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+
Comment 6•20 years ago
|
||
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.
Comment 7•20 years ago
|
||
fix some levels of indirection
Updated•20 years ago
|
Keywords: fixed-aviary1.0
Comment 8•20 years ago
|
||
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)
Comment 10•20 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•20 years ago
|
||
I believe that this bug has been resolved has it not?
Comment 12•20 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•20 years ago
|
||
I agree. I have not seen this problem lately, but it was fixed before 2004-07-17.
Comment 14•20 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•20 years ago
|
||
I have just had this occur on a 20040729 branch build...
Comment 16•20 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•20 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•20 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•20 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.
Comment 20•20 years ago
|
||
*** Bug 251315 has been marked as a duplicate of this bug. ***
Comment 21•20 years ago
|
||
*** Bug 259143 has been marked as a duplicate of this bug. ***
Comment 22•20 years ago
|
||
*** Bug 261162 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0?
Comment 23•20 years ago
|
||
*** Bug 260299 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0?
Comment 24•20 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•20 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•20 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.
Comment 27•20 years ago
|
||
*** Bug 264215 has been marked as a duplicate of this bug. ***
Comment 28•20 years ago
|
||
*** Bug 265195 has been marked as a duplicate of this bug. ***
Comment 29•20 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•20 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•20 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•20 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•20 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•20 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•20 years ago
|
||
*** Bug 275437 has been marked as a duplicate of this bug. ***
Comment 36•20 years ago
|
||
*** Bug 277238 has been marked as a duplicate of this bug. ***
Comment 37•20 years ago
|
||
Aviary Landing key word? (IE: Did it regress after Aviary landed?)
Comment 38•20 years ago
|
||
Test case from Link in Comment 2. Seems to be because of the character 'š' being in the Title.
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Updated•20 years ago
|
Whiteboard: [sg:fix]
Comment 39•19 years ago
|
||
The Product should be set to Core, as this occurs here with Mozilla. So, it isn't specific to Firefox.
Comment 40•19 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•19 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.)
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Comment 42•19 years ago
|
||
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•19 years ago
|
||
This still happens in the 1.0.4 release on windows.
Comment 44•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 years ago
|
||
This one seems to be back for me as well.
Comment 59•19 years ago
|
||
This can be a spoofing issue.
Assignee: bugs → mconnor
Status: ASSIGNED → NEW
Whiteboard: [sg:fix] → [sg:spoof]
Assignee | ||
Comment 60•19 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•19 years ago
|
Flags: blocking-aviary2.0?
Comment 61•19 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•19 years ago
|
||
OK. Reading the forums further, this is a Greasemonkey bug. Disabling Greasemonkey fixes it. I can't reproduce this now.
Comment 63•19 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•19 years ago
|
||
*** Bug 311140 has been marked as a duplicate of this bug. ***
Comment 65•19 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•19 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•19 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•19 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.]
Comment 69•19 years ago
|
||
(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•19 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•19 years ago
|
||
By the way, I'm pretty sure that bug 294902 is a duplicate of this bug.
Comment 72•19 years ago
|
||
*** Bug 294902 has been marked as a duplicate of this bug. ***
Comment 73•19 years ago
|
||
I can't reproduce this bug with Firefox 1.5 RC1 under Mac OS X.
Comment 74•19 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•19 years ago
|
||
This screenshot displays the bug's effect.
Comment 76•19 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).
Comment 77•19 years ago
|
||
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•19 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•19 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•19 years ago
|
||
I don't have StumbleUpon installed and I still have this problem.
Comment 81•19 years ago
|
||
(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•19 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.
Comment 83•19 years ago
|
||
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
Updated•19 years ago
|
Flags: blocking-aviary2?
Comment 84•19 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.
Comment 85•19 years ago
|
||
(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•19 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
Comment 87•19 years ago
|
||
If you set the javascript.options.showInConsole pref to true using about:config, do you see any errors in the JavaScript Console?
Comment 88•19 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•19 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•19 years ago
|
||
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.
Comment 91•19 years ago
|
||
(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•19 years ago
|
||
Reported as bug 315947. Note that this is similar to bug 150131.
Comment 93•19 years ago
|
||
*** Bug 315062 has been marked as a duplicate of this bug. ***
Comment 94•19 years ago
|
||
*** Bug 286019 has been marked as a duplicate of this bug. ***
Comment 95•19 years ago
|
||
*** Bug 315161 has been marked as a duplicate of this bug. ***
Comment 96•19 years ago
|
||
*** Bug 281620 has been marked as a duplicate of this bug. ***
Comment 97•19 years ago
|
||
*** 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.
Description
•