Closed Bug 229138 Opened 21 years ago Closed 16 years ago

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

Categories

(SeaMonkey :: General, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: garylowens, Unassigned)

Details

Attachments

(1 file)

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: 16 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: