Closed Bug 232741 Opened 21 years ago Closed 19 years ago

URL location bar does not display proper URL when the system is under high load

Categories

(SeaMonkey :: Location Bar, defect)

1.0 Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: kakadu+bugzilla, Unassigned)

Details

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
Closed: 19 years ago
Resolution: --- → WORKSFORME
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.