Closed
Bug 228801
Opened 22 years ago
Closed 22 years ago
Mozilla stops responding to events such as URLs (clicked on with mouse) or URLs in address bar
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: pbergsagel, Unassigned)
References
()
Details
(Keywords: dataloss)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031215
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031215
After surfing for a while (time perios varies) Mozilla stops responding to
certian events such as clicking on a URL , entering a new URL address in the
address bar or posting text (can type in the text, but hit return or enter and
nothing) on a web form. When this happens the cursor changes (on MacOS X) to the
small black pointer with small spinning disk, not the spinning beach ball. When
this happened I opened a blank tab and typed www.apple.com (a reliable test
site) and it failed to load. I launched the activity monitor and Mozilla was
using only >10% (avg 1-2%) CPU and about 70mb of memory. The console showed no
information for Mozilla (or other useful information).
Mozilla was not frozen since some things still functioned. New tabs could be
created, and text typed in forms. A URL (using a link or address bar) fails to
load and the cursor changes to the samll arrow with spinning disk.
This bug can cause data loss since the only way to restore the browser back to
full functionality is to quit (not force quit) the browser and relaunch Mozilla.
I experience this bug 2 to 3 time during a 4 hour browsing session.
I am using MacOS X 10.3.1 with a B/W G3 - 350Mhz.
Reproducible: Sometimes
Steps to Reproduce:
1.Surf for a period of time (varies)
2.Eventually the browser will fail to respond to certian events (see "Details"
above)
3.Cursor changes to balck pointer with spinning disk.
Expected Results:
Some events stop responding (see "Details" above).
All events to respond.
Reporter | ||
Comment 1•22 years ago
|
||
Dataloss keyword is added since the only way to return full function to the
browser is by quiting the Mozilla. Website addresses, form data can be lost when
the browser is quit.
Keywords: dataloss
Comment 2•22 years ago
|
||
Since using 1.6b (I skipped 1.6a), I encounter this from time to time, too, so I
confirm this. However, it happened to me only 3 or 4 times since switching to
1.6b, which is rather seldom ...
Sadly, I failed to find a reproducible way to trigger this behaviour.
Paul, not sure whether "dataloss" is correct here: IMO, it would only be
justified if the data loss you claim cannot be prevented. However, as you say
yourself, parts of Mozilla are still functional, which (IIRC) also applies to
switching tabs, copying form content to clipboard, etc. So though re-starting
Mozilla is the only way to "fix" this, the user has the possibility to prevent
data loss. Thus, I'd say the keyword is not justified here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 3•22 years ago
|
||
Still seeing this bug in Moz 1.7a (Mozilla/5.0 (Macintosh; U; PPC Mac OS X
Mach-O; en-US; rv:1.7a) Gecko/20031224). Today I found a new event which
suddenly stopped functioning: when certian event stop responding to mouse clicks
I am unable to switch from the Browser to Mail and Newsgroups. When this
happenssometimes the browser can be restored using "quit" while at other times a
"force-quit" is required.
Frank regarding data loss ->yes maybe it should not be labeled dataloss in the
strictest sense of the word.. Nonetheless if one has multiple browser windows
open (or multiple form fields filled out) it can be quite a chore to copy all
the URLs (or data) to a text document as the clipboard is only able to hold one
URL or one textbox/form field item at a time.
Reporter | ||
Comment 4•22 years ago
|
||
Further information. I use a Wacom Graphire Tablet with the wireless mouse which
sits on top of the tablet. I believe the earlier driver for Wacom Tablets may
have had an issue with Mozilla and have been the cause of this bug. The latest
driver was just released on December 10, 2003 (version 4.78-3). I just
downloaded the driver today. I will test the driver with Mozilla for a couple of
days and if this appears to resolve the bug I will close this bug--for now I am
keeping the bug open until I am sure it is resolved.
Comment 5•22 years ago
|
||
Since the problem described here appeared somewhere between 1.5 and 1.6b, I
would like to *not* close this bug. Even if it's caused by some interaction
between Mozilla and a system driver, there was a time when everything was fine ....
Besides this, I don't have any such "exotic" :) hardware, so I doubt that it's a
problem of a hardware driver.
Reporter | ||
Comment 6•22 years ago
|
||
Frank I have been using Mozilla with the new Wacom tablet/mouse driver for about
4 or 5 hours and do have yet to experience this bug. Before the driver update I
would have experienced this bug at least once or twice. So far I am not seeing
this bug with today's nightly ( Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.7a) Gecko/20040104 ).
FRANK I will leave this bug open based on your comments above. I may be
experiencing a different bug than you are so Frank when you experience this bug
again could you try to describe as accurately just what you are experiencing? I
suspect there may be two bugs here: one caused by the Wacom driver and another
caused by something else. Is this a bug specific to 10.3? Frank which MacOS
version are you using? I am using 10.3.2 which has created some conflicts with
existing software requiring a software update for the effected program(s).
Comment 7•22 years ago
|
||
Uhoh - did I mention I am *not* using MacOS, but Windows? Sorry, I
completely overlooked that OS is "MacOS X" here.
Hmm. I amk hesitant what to do with this bug. I agree that the bug I see
may be different from what you see. Or, maybe it's the same bug, and
perhaps the latest nightly would solve this for me, too. However, I do
not really want to try this right now, since it happens too seldom to me
- I would have to use this nightly much longer than I'd normally do in a
production environment.
Okay, perhaps you should close the bug, and I can re-open or re-submit
when it keeps happening to me in later versions (at the moment, it's not
annoying enough for me to keep this bug open a long time, and nobody
else except us two complained here ...)
Reporter | ||
Comment 8•22 years ago
|
||
Closing this bug as wfm. The tablet driver update appears to have fixed this bug.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Updated•7 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•