Closed Bug 229138 Opened 22 years ago Closed 18 years ago

dialog box, window close button ignored sometimes - after new window

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: garylowens, Unassigned)

Details

Attachments

(1 file)

Apple Crash Reporter crash report for Mozilla
45.60 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20031220 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20031220 This just started happening in this 1.6b and this latest build. After running for a while - with a half-dozen windows open, then typically when opening a new window and typing in a URL or search string (or "open link in new window") I'll get some dialog box like "the url cannot be found". But when I click on the "OK", the botton flashes but the dialog box does NOT go away. The red window frame button to kill the window does NOT work either, but the yellow iconify button DOES work. Once this seems to happen, most other dialog boxes do the same thing and the browser gets unusable fast. The one other thing that I notice is that when the new window opens, the input focus did not appear in the url entry line. It's happened 4 or 5 times now. Since I can't get the dialog to go away, and any subsequent ones on other windows also hang, I just quick mozilla and restart it. No crash dump unfortunately. Reproducible: Sometimes Steps to Reproduce: 1. start browsing and searching - opening new windows 2. hope it screws up 3. when you get a dialog box that won't "OK" - you've hit this state. 4. note the window close botton doesn't work. 5. note the iconify (yellow frame button) does work - duh!
I have observed this behaviour intermittently for some time now, certainly since 1.3 and possibly before; currently using 1.5. This is on Linux platform. Although with modal dialogs this means you can't carry on using the browser window at all, it is still possible to bring up a new window with ctrl+N and work in that. However, when mozilla is in this state, I have also noticed that buttons in other dialog boxes produced by the new window are also broken. I have never worked out what triggers this behaviour. It seems to be associated with "the url cannot be found" dialogs, but this may be just that this is one of the more common dialogs you get in normal browsing so is the first manifestation you typically find of the bug.
Under my working environment (Windows 2000 Pro, Traditional Chinese version) it happens very often, including option dialog boxes. And I've learned how to dismiss those dialogs quickly.... simply open another Firebird window, switch back to blocked window, and the dialog boxes will be dissmissed right away.
I've noticed that the address bar auto complete might start acting weird (not working). Or when I enter a url and press return, it doesn't load until I press the "Go" button. Sometimes clicking on URLs in a page don't work eiter. This is usually when I decide to quit the browser and run into this bug. (Confirmation dialog to close multiple tabs before closing the window.) A force quit has been my only way out.
Here's a crash report from Apple's Crash Reporter (Mozilla's Talk Back didn't catch it). This is after the search in Mail stopped working, pressing return in the address field has stopped working (but pressing "Go" works) the dialogs got stuck. I hope there's some useful information in there.
This problem is particularly bad with recent builds of 1.7a. Another tip to add: double clicking in forms does not autofill them when this bug is apparently at work. I'm gonna set this to block 1.7a (if I can) until someone reviews this, also I think the severity should be upped to major.
Flags: blocking1.7a+
Update: I've tried another profile and the behavior I described before occured (address bar didn't respond to a <return> to open a newly entered URL, when closing the window with multiple tabs, confirmation dialog did not dismiss. Also to note, previously, I've noticed that http-equiv "refresh" commands (such as used after making a post on a forum) don't refresh when this behavior is being exhibited.
Update: I've tried another profile and the behavior I described before occured (address bar didn't respond to a <return> to open a newly entered URL, when closing the window with multiple tabs, confirmation dialog did not dismiss. Also to note, previously, I've noticed that http-equiv "refresh" commands (such as used after making a post on a forum) don't refresh when this behavior is being exhibited. Sorry. I forgot to mention that it did take a while for the problem to occur this time. But after I opened mail, it occurred not too long afterward (10-20 minutes with little use). Don't know if it's a factor or not.
only drivers can set (+) block flags. you can request (?) them.
Flags: blocking1.7a+
Is it just that most people don't run their browsers for days at a time? Is that why this bug isn't more prevelant? Could it be from lack of memory? I have the disk cache disabled and have memory cache set at about 24 MB. I have between 4 and 7 tabs open at once (plus the Mail app). The tabs to develop quite a bit of history. Okay, I'm gonna question the blocking thing. (?)
Flags: blocking1.7b?
not going to block the release for this unconfirmed report with no developer activity.
Flags: blocking1.7b? → blocking1.7b-
I seem to have been able to get a "handle" on the problem. I decided to start pruning the history for each tab I had open thinking that that could be a problem. This and I'm running build 2004021810. Has anybody having the problem seen any improvement?
Okay, the problem is a little more intermittant now, but it usually happens. Another thing I've noticed; when this bug is working, I cannot use an arrow key to select messages in mail (the selection moves, but the mail is not displayed and status of new mail is not changed to read), but I can still click on them to get them to actually open. Another symptom: the cursor stops blinkng. I was able to fix the problem! Sleep cycles. I was experiencing the problem just a while ago and got stuck with a dialog box. I was able to fix Mozilla by putting my computer to sleep and then waking it. The cursor now blinks, the throbber throbs, auto complete is functioning again and the dialog has gone away. Can anyone else confirm this workaround?
Here's another mention of what sounds like this bug. http://www.lowendmac.com/misc/04/0409.html#2
We've been discussing this in the mozillaZine forums as well: http://forums.mozillazine.org/viewtopic.php?p=537009#537009 I hope someone can fix this soon. I've been avoiding using Mozilla lately because of this bug. I just end up having to force quit the application several times a day.
This bug is easy to reproduce and unfortunately it works all the time: - 1. Just let the screen/display sleep, and - 2. Voila: Mozilla (1.7.x especially) is in the state of non-responsive buttons in any dialogs (red button too), urls can't autocomplete in location bar and don't load when Enter is hit (Go button works), a page doesn't show as it being loaded (in real time as usually), down arrow in location bar works only once.
Agreed - I just downloaded the new versions of Firefox and Mozilla (the latter because I was hoping it was a Firefox-specific bug), and as of now I don't think I'll be able to use either until this gets fixed - I have yet to have a session that I *didn't* have to force-quit. While it does seem to occur more frequently after some time, I have had it happen early, and by "some time" I mean like 15 minutes. Also - this problem occurs both before and after installing extensions. Installation and/or removal of extensions seems to have no effect on the bug in either Firefox or Mozilla. System Info (as of 10/27/2004) - Mozilla 1.7.3 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.6.4.0b The dialog boxes that have I have been unable to close do not respond to clicking any or all buttons and do not respond to key commands (esc, enter, etc.) They also display only the "minimize" button, which does function, when they are pop-up style - I can minimize them to the dock and retrieve them, but nothing else. The widgets function - I can check checkboxes etc. - but this does no good as I cannot dismiss the dialog. I have seen this bug with at least the following: - Find dialog - Cookie question dialog - Can't find URL dialog - Remember password dialog - Prefs dialog (it would appear to be pervasive from what I can see - probably affects all dialogs.)
Product: Browser → Seamonkey
(In reply to comment #12) Cedric wrote: > I was able to fix the problem! Sleep cycles. I was experiencing the problem just > a while ago and got stuck with a dialog box. I was able to fix Mozilla by > putting my computer to sleep and then waking it. The cursor now blinks, the > throbber throbs, auto complete is functioning again and the dialog has gone > away. Can anyone else confirm this workaround? I can confirm this workaround. Works every time and seens to fix all the symptoms. I see exactly the same symptoms as Cedric and have noticed the issue in a number of recent versions of Mozilla--very annoying. It did not happen in version 1.4. My system details: Mozilla 1.7.2 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040803 MacOS 10.2.8
I've not seen this bug anytime this year. Should we go for WORKSFORME ? Mac OS X 10.4.8 PowerBook G4 12" 1.5GHz Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 - Build ID: 2006091003
WFM per comment 18
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: