Closed
Bug 66457
Opened 24 years ago
Closed 23 years ago
Cursor stays a watch after cancel page display
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: keith, Assigned: blizzard)
Details
Attachments
(1 file)
919 bytes,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3mdk i686; en-US; m18) Gecko/20010124 BuildID: 20010124 When a page is being displayed, the cursor turns into a watch. Pressing the Escape key interrupts page display, however the cursor remains a watch. It changes back to a pointer only when the mouse is moved. Reproducible: Always Steps to Reproduce: While a page is in the middle of being displayed, press the Escape key to interrupt it. The interruption will be successful, however the cursor will remain looking like a watch until the mouse is moved. The cursor should change back to a pointer upon successful interruption (i.e. right after pressing the Escape key).
Comment 1•24 years ago
|
||
Confirmed Platform: PC OS: Linux 2.2.16 Mozilla Build: 2001012706 This only occurs as long as you dont move the cursor after pressing Escape. After that it changes back to the normal pointer. Marking NEW.
Severity: normal → trivial
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•24 years ago
|
||
reassign.
Assignee: asa → vishy
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Comment 4•24 years ago
|
||
hm, isn't this a dup...? [couldn't find it after searching a bit.]
Comment 5•24 years ago
|
||
wow, this is incredibly minor. this probably has something to do with x events not firing until the mouse moves. reassign to blizzard
Assignee: alecf → blizzard
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 6•24 years ago
|
||
I did some poking. This doesn't seem to be X related. |SetCursor| doesn't get called until the mouse is moved so it's not related to the X buffer not being flushed. In fact it kind of sounds like bug 67989. Alec, what do you think?
Assignee | ||
Comment 7•23 years ago
|
||
A tale of two stack traces: Here's a good stack trace where the SetCursor happens at then end of a document load: #0 nsWindow::SetCursor (this=0x85d7918, aCursor=eCursor_standard) at ../../../../mozilla/widget/src/gtk/nsWindow.cpp:951 #1 0x40f8e958 in nsDocShell::OnStateChange (this=0x85d2a08, aProgress=0x85d7b74, aRequest=0x8a27fe0, aStateFlags=786448, aStatus=0) at ../../../mozilla/docshell/base/nsDocShell.cpp:2570 #2 0x40f9bb0c in nsWebShell::OnStateChange (this=0x85d2a08, aProgress=0x85d7b74, request=0x8a27fe0, aStateFlags=786448, aStatus=0) at ../../../mozilla/docshell/base/nsWebShell.cpp:950 #3 0x40eb8c8b in nsDocLoaderImpl::FireOnStateChange (this=0x85d7b60, aProgress=0x85d7b74, aRequest=0x8a27fe0, aStateFlags=786448, aStatus=0) at ../../../mozilla/uriloader/base/nsDocLoader.cpp:1308 #4 0x40eb76c4 in nsDocLoaderImpl::doStopDocumentLoad (this=0x85d7b60, request=0x8a27fe0, aStatus=0) at ../../../mozilla/uriloader/base/nsDocLoader.cpp:736 #5 0x40eb73a8 in nsDocLoaderImpl::DocLoaderIsEmpty (this=0x85d7b60, aStatus=0) at ../../../mozilla/uriloader/base/nsDocLoader.cpp:631 #6 0x40eb7128 in nsDocLoaderImpl::OnStopRequest (this=0x85d7b60, request=0x8608880, aCtxt=0x0, aStatus=0, aMsg=0x40191b34) at ../../../mozilla/uriloader/base/nsDocLoader.cpp:561 #7 0x40ca48aa in nsLoadGroup::RemoveRequest (this=0x85d7bf0, request=0x8608880, ctxt=0x0, aStatus=0, aStatusArg=0x40191b34) at ../../../../mozilla/netwerk/base/src/nsLoadGroup.cpp:518 #8 0x40cf231d in nsHTTPChannel::ResponseCompleted (this=0x8608880, aListener=0x0, aStatus=0, aStatusArg=0x40191b34) at ../../../../../mozilla/netwerk/protocol/http/src/nsHTTPChannel.cpp:2378 #9 0x40cfd6ee in nsHTTPServerListener::OnStopRequest (this=0x88993c0, request=0x8ae1028, i_pContext=0x8608880, i_Status=0, aStatusArg=0x40191b34) at ../../../../../mozilla/netwerk/protocol/http/src/nsHTTPResponseListener.cpp:700 #10 0x40c96e2c in nsOnStopRequestEvent::HandleEvent (this=0x42006788) at ../../../../mozilla/netwerk/base/src/nsStreamObserverProxy.cpp:178 #11 0x40c96b5f in nsStreamObserverEvent::HandlePLEvent (aEvent=0x42006788) at ../../../../mozilla/netwerk/base/src/nsStreamObserverProxy.cpp:78 #12 0x4011a7b0 in PL_HandleEvent (self=0x42006788) at ../../../mozilla/xpcom/threads/plevent.c:588 #13 0x4011a5c5 in PL_ProcessPendingEvents (self=0x80a6cb0) at ../../../mozilla/xpcom/threads/plevent.c:518 #14 0x4011c762 in nsEventQueueImpl::ProcessPendingEvents (this=0x80a6c88) at ../../../mozilla/xpcom/threads/nsEventQueue.cpp:361 #15 0x40772980 in event_processor_callback (data=0x80a6c88, source=7, condition=GDK_INPUT_READ) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:168 #16 0x4077255f in our_gdk_io_invoke (source=0x81f1928, condition=G_IO_IN, data=0x81f1918) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:61 #17 0x4094212e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #18 0x409438f3 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #19 0x40943f38 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #20 0x409440fc in g_main_run () from /usr/lib/libglib-1.2.so.0 #21 0x4085d983 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #22 0x40773051 in nsAppShell::Run (this=0x80a5100) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:360 #23 0x405208e1 in nsAppShellService::Run (this=0x80a9460) at ../../../../mozilla/xpfe/appshell/src/nsAppShellService.cpp:407 #24 0x08053e5f in main1 (argc=1, argv=0xbffff90c, nativeApp=0x0) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1004 #25 0x08054ae3 in main (argc=1, argv=0xbffff90c) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1298 #26 0x4034fd4c in __libc_start_main (main=0x80548e0 <main>, argc=1, ubp_av=0xbffff90c, init=0x804ef80 <_init>, fini=0x805f4c4 <_fini>, rtld_fini=0x4000d730 <_dl_fini>, stack_end=0xbffff8fc) at ../sysdeps/generic/libc-start.c:129 and a stack trace where the cursor never changed but it does from a mouse move: #0 nsWindow::SetCursor (this=0x840b910, aCursor=eCursor_standard) at ../../../../mozilla/widget/src/gtk/nsWindow.cpp:951 #1 0x4124853e in nsEventStateManager::SetCursor (this=0x8660f48, aCursor=1, aWidget=0x840b910, aLockCursor=0) at ../../../../mozilla/content/events/src/nsEventStateManager.cpp:1634 #2 0x412482c6 in nsEventStateManager::UpdateCursor (this=0x8660f48, aPresContext=0x86804a0, aEvent=0xbffff3b0, aTargetFrame=0x88e50ac, aStatus=0xbffff270) at ../../../../mozilla/content/events/src/nsEventStateManager.cpp:1535 #3 0x41242e2e in nsEventStateManager::PreHandleEvent (this=0x8660f48, aPresContext=0x86804a0, aEvent=0xbffff3b0, aTargetFrame=0x88e50ac, aStatus=0xbffff270, aView=0x8840660) at ../../../../mozilla/content/events/src/nsEventStateManager.cpp:316 #4 0x419b29fe in PresShell::HandleEventInternal (this=0x88f19d0, aEvent=0xbffff3b0, aView=0x8840660, aFlags=1, aStatus=0xbffff270) at ../../../../../mozilla/layout/html/base/src/nsPresShell.cpp:5054 #5 0x419b26c0 in PresShell::HandleEvent (this=0x88f19d0, aView=0x8840660, aEvent=0xbffff3b0, aEventStatus=0xbffff270, aForceHandle=0, aHandled=@0xbffff208) at ../../../../../mozilla/layout/html/base/src/nsPresShell.cpp:4995 #6 0x41b925d1 in nsView::HandleEvent (this=0x8840660, event=0xbffff3b0, aEventFlags=8, aStatus=0xbffff270, aForceHandle=0, aHandled=@0xbffff208) at ../../../mozilla/view/src/nsView.cpp:359 #7 0x41b92564 in nsView::HandleEvent (this=0x88dbde8, event=0xbffff3b0, aEventFlags=8, aStatus=0xbffff270, aForceHandle=0, aHandled=@0xbffff208) at ../../../mozilla/view/src/nsView.cpp:343 #8 0x41b92564 in nsView::HandleEvent (this=0x8726a98, event=0xbffff3b0, aEventFlags=28, aStatus=0xbffff270, aForceHandle=1, aHandled=@0xbffff208) at ../../../mozilla/view/src/nsView.cpp:343 #9 0x41ba5b33 in nsViewManager2::DispatchEvent (this=0x8316ce8, aEvent=0xbffff3b0, aStatus=0xbffff270) at ../../../mozilla/view/src/nsViewManager2.cpp:1422 #10 0x41b91bf4 in HandleEvent (aEvent=0xbffff3b0) at ../../../mozilla/view/src/nsView.cpp:67 #11 0x40786f25 in nsWidget::DispatchEvent (this=0x840b910, aEvent=0xbffff3b0, aStatus=@0xbffff33c) at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:1471 #12 0x40786b46 in nsWidget::DispatchWindowEvent (this=0x840b910, event=0xbffff3b0) at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:1362 #13 0x40786fe7 in nsWidget::DispatchMouseEvent (this=0x840b910, aEvent=@0xbffff3b0) at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:1498 #14 0x40787667 in nsWidget::OnMotionNotifySignal (this=0x840b910, aGdkMotionEvent=0x81f24b0) at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:1732 #15 0x4078e907 in nsWindow::HandleGDKEvent (this=0x840b910, event=0x81f24b0) at ../../../../mozilla/widget/src/gtk/nsWindow.cpp:1443 #16 0x4077ea8e in dispatch_superwin_event (event=0x81f24b0, window=0x840b910) at ../../../../mozilla/widget/src/gtk/nsGtkEventHandler.cpp:1007 #17 0x4077e5d1 in handle_gdk_event (event=0x81f24b0, data=0x0) at ../../../../mozilla/widget/src/gtk/nsGtkEventHandler.cpp:837 #18 0x40913b7f in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0 #19 0x409438f3 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #20 0x40943f38 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #21 0x409440fc in g_main_run () from /usr/lib/libglib-1.2.so.0 #22 0x4085d983 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #23 0x40773051 in nsAppShell::Run (this=0x80a5100) at ../../../../mozilla/widget/src/gtk/nsAppShell.cpp:360 #24 0x405208e1 in nsAppShellService::Run (this=0x80a9460) at ../../../../mozilla/xpfe/appshell/src/nsAppShellService.cpp:407 #25 0x08053e5f in main1 (argc=1, argv=0xbffff90c, nativeApp=0x0) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1004 #26 0x08054ae3 in main (argc=1, argv=0xbffff90c) at ../../../mozilla/xpfe/bootstrap/nsAppRunner.cpp:1298 #27 0x4034fd4c in __libc_start_main (main=0x80548e0 <main>, argc=1, ubp_av=0xbffff90c, init=0x804ef80 <_init>, fini=0x805f4c4 <_fini>, rtld_fini=0x4000d730 <_dl_fini>, stack_end=0xbffff8fc) at ../sysdeps/generic/libc-start.c:129 The second stack trace is telling. I think what's happening here is that the DocShell is not updating the cursor at the end of the document load. I'm going to do some printf debugging and I'll update in the bug.
Assignee: blizzard → blizzard
Assignee | ||
Comment 8•23 years ago
|
||
Assignee | ||
Comment 9•23 years ago
|
||
Patch is attached. The problem wasn't that the doc shell wasn't setting the cursor, it was. It was just setting the cursor on the wrong window. The assumption is made that the cursor is global like on win32. In X it's based on which window you set the cursor on. So if you've set the cursor on an inner window it stays there until you explicitly change it. In the finished load case for the docshell it was setting the cursor for the docshell window which is the toplevel window. Inner windows had already set the cursor to something else so the docshell change wasn't reflected in the current state because the cursor was still on an inner window. I discovered that for every mouse move event we reset the cursor which is why it would be set when the mouse was moved. If you don't set the cursor on a window it's inherited from the parent so if I just set the cursor on the parent it plays like it's global. Plugins should be fine, too. Adding alecf since he thought it would be "incredibly minor" but it wasn't and bryner in hopes of eeking out a review.
Status: NEW → ASSIGNED
Comment 10•23 years ago
|
||
with blizzard's explanation, I this seems to make sense. r=alecf
Comment 11•23 years ago
|
||
r=bryner
Assignee | ||
Comment 12•23 years ago
|
||
Checked in. Thanks, guys.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•