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.
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
Last Resolved: 9 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.