Closed Bug 241973 Opened 20 years ago Closed 14 years ago

Coinciding problems with browser navigation after using browser for a while...

Categories

(SeaMonkey :: General, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: miken, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421

This appears to be a memory leak or some other condition that builds up to a
breaking point either through lack of resources or some other event triggered by
cookie setting or the like on a given web page.  I frequently travel to sites
like ebay, etc.

Anyway, the browser usually starts up fine and doesn't have any problems with
navigation.  At some point though a whole slew of problems manifest themselves,
and they require me killing off the browser in order to restore proper browser
functionality.  The following symptoms occur:

1) If a window has a warning popup (such as CGI submissions of for data asking
for "OK" or "Cancel" to continue) comes up but pressing the "OK" or "Cancel"
button does nothing and the popup stays over the window.  The window controls
for this window aren't accessable and therefore the window is "locked" until the
application is quit.
2) animated gifs don't animate.
3) Typing in an URL in the URL at the top and hitting return in newer windows
doesn't launch that URL or do anything.  Window stays where it is.
4) Sometimes a "Force Quit" is needed to kill the application.

This is annoying.  I've downloaded like three different revs recently of the 1.7
build, and they all have this problem.  I'm considering backing up to an earlier
version of the browser, which didn't have this problem, as this really is
annoying having to quit many different window contexts and restart the browser
when this condition occurs.

I'm running OSX Jaguar.

Reproducible: Couldn't Reproduce
Steps to Reproduce:
I cannot reproduce other than just working with it over time.  It has happened
over time pretty much everytime I've used the 1.7x builds of the browser at some
point.  It just isn't predictable when it happens.  It's just darn serious in my
opinion.  Let me know if there are other system configuration or usage details
that you need to help reproduce it if necessary.  I suppose I could download a
debug version of the browser if you think that would help too.
Actual Results:  
Couldn't "reproduce" scientifically.

Expected Results:  
Obviously shouldn't be locking up or manifesting the behavior above as all of
them are functionality or serious navigation deterrents.

I also use Mail.app with large amounts of email going through it, and at times I
run textedit or terminal windows alongside it.  I have popup windows blocked too
now with the newer installs.
I'm running 1.7 RC1 right now on my MacOS 10.3.3 iBook G4.  
I use it all the time.  It's _way_ less stable than 1.6 final was (which I also
ran on 10.3.3).  (No, I can't make it hang reproducibly,
but 1/2 the time it wakes up from sleeping, Mozilla 1.7 RC1 displays the
spinning wheel of death.) I'm also close to going back to 1.6.
Let's see what we have in common.  I use WiFi and move from home to work with my
iBook a lot.  I use MailNews.  Hanging is usually when I wake if from sleep
mode. You?  You've made sure there isn't a hidden dialog box locking up the app
(use Command-`)?  When mine hangs, Mozilla is non-responsive to Command-`.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This problem occurs regularly on all of our Macs (combination of 3 PowerBooks
and 4 iMacs) using Mozilla 1.6 through the latest Mozilla 1.7.2 release.

Although I can not exactly generate the error on demand, it does happen at least
few times a day in our office.

An addendum to the #3 item in the opening comment, I have found that URLs
specifying the protocol will sometimes work when the the URL without the
protocol does not work (ie use http://mydomain.com vs simply "mydomain.com"). 
Oddly, it also seems to help if your cursor is somewhere in the middle of the
URL instead of having the cursor at the end of the line (which is where it would
typically be after you finish typing in the URL).  

BTW, if it makes any difference, hitting the Search button does not fare any
better than hitting the Return key.  However, File->Open Web Location does
continue function correctly provided that you have an open browser window that
has not become locked due to symptom #1 as described in the initial bug report here.

Another symptom of this problem is that URL auto completion stops functioning.

All of these things are definitely connected somehow, but I have no idea how to
figure how.  I would welcome any suggestions on how to narrow down the cause.
Product: Browser → Seamonkey
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.