User-Agent: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040126 Firebird/0.8.0+ (.:MrC:.) I just noticed that while compiling a large software project like the Linux kernel, Firebird's URL location bar misbehaves - it doesn't switch between the URLs of each tab when the system is heavily loaded during the compilation - instead it only displays the last typed URL exactly as entered, without the addition of a protocol header like http://. After the compilation ceases, the misbehavior remains present. Reproducible: Always Steps to Reproduce: 1. Open Firebird and load a web page. 2. Start a large compilation job (example: compiling Linux 2.6.2-rc3) 3. Open a new tab, type a URL into the location bar and hit Enter. 4. After the page loads, select the original tab. Observe the typed URL, not the original URL. Actual Results: The typed URL remained displayed - if I typed "bugzilla.mozilla.org" into the location bar to load the Bugzilla home page and then switched to the Linux Kernel Archives webpage during or after the compilation, "bugzilla.mozilla.org" remains displayed, instead of "http://www.kernel.org/". Expected Results: The browser should have displayed the proper URL. I believe this has to do with the system being under high load - this has only happened when the system was heavily loaded during a large compilation job.
http://dynamic3.gamespy.com/~ff9/ikonboard/files/brokenbar.jpg This is a screenshot of the broken URL bar, taken after the compilation finished. I tried to reproduce this during the compilation of the 2.6.2-rc3 modules, but was unable to do so - this bug may not be related to system load after all.
I see a similar effect under Win2k, with release 0.8. The system is otherwise idle in my case, but the page I'm loading has lots of flash in it, which causes the CPU used by firefox to raise to 99%, so it's still possibly a CPU load issue. Test case at http://www.duo-creative.com/chrisb/test_firefox.html - that page has a single link in it. Open said link in a new tab, and the original URL remains in the URL bar.
I have seen something very much like this under Mac OSX. From time to time Firefox will get into a state where changing tabs does not change the displayed url in the location bar. I can type in a new url, but I do not get a list of possible completions and the location bar will remain exactly as I typed it. And, or course, the displayed url will not change if I switch tabs. Once in this state I also find that I can not dismiss dialog boxes, neither by clicking one of the buttons nor by hitting return/enter. If the dialog box is displayed as a sheet, quitting Firefox is about all that I can then do. I have wondered if the pdf plugin might be related, though I have never been able to confirm that in any way, nor reproduce the problem on demand. The suggestion in comment 2 did not trigger the problem for me. One possibility -- pdf files can be relatively expensive to display, and perhaps that's the connection.
WFM Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040613 Firefox/0.8.0+ System is under about 80% load right now, but even when I have had 100%, don't recall ever seeing such.
(In reply to comment #3) Am seeing exactly the same problem under Max OS X 10.2.8, Gecko/20040628 Firefox/0.9.1. I haven't noticed a common cause, but once I have been working for a while, sooner or later the location bar ceases to show the correct location when I change tabs, and dialog boxes displayed as a sheet cannot be dismissed.
This is a possible duplicate of Bug 144349, since that bug has a commenter mentioning that the bug can be reproduced on Mac OS X as well. Dunno if the related code has been forked for Firefox or not.
(In reply to comment #5) > (In reply to comment #3) > > Am seeing exactly the same problem under Max OS X 10.2.8, Gecko/20040628 > Firefox/0.9.1. I haven't noticed a common cause, but once I have been working > for a while, sooner or later the location bar ceases to show the correct > location when I change tabs, and dialog boxes displayed as a sheet cannot be > dismissed. I may have found the common cause on: Mac OS X 10.3.5 Firefox 0.9.3 I have been getting this behaviour every day when I get back from lunch. When I recently disabled the energy saving features in the System Preferences the behaviour disappeared. When I re-enabled it the behaviour returned (settings are: hard-drive sleep 15min, monitor sleep 15mins, computer sleep 1hr 15mins). So, to reproduce on my system: 1. Enable the Energy Saving features in System Preferences (not sure exactly which one) 2. Start Firefox 3. Have lunch (1 hour) 4. Open a new tab or click on an already opened tab BTW, the link in comment #2 does not generate this bug for me. I'm not sure how this relates to kernel compiles and the like, but perhaps it will give someone in the know a nudge in the right direction?
Using Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1, I have noticed that happen on occasions. I am not sure if system load is an issue, I have noticed it under lightly loaded conditions.
I ran into this bug today on Fedora Core 3 Linux with the 1.0 GTK Firefox build (Gnome). I used Firefox for about 15 minutes browsing various sites. I clicked on a link in the bookmark toolbar and the URL loaded correctly but the location bar value failed to update and remained unchanged. Additional clicks on bookmarks links also failed to update the location bar. I shutdown Firefox and reopened it and the behavior disappeared. Funky.
Moving to core->Location Bar...
Assignee: firefox → location-bar
Component: General → Location Bar
Product: Firefox → Core
Version: unspecified → 1.0 Branch
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
In that case, seeing as how I had forgotten about this bug entirely and have not experienced it since, I suspect that whatever the underlying cause was has since been repaired. -> RESOLVED/WORKSFORME
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.