Closed
Bug 783139
Opened 12 years ago
Closed 12 years ago
Crash [@ nsIView::GetViewFor]
Categories
(Core Graveyard :: Widget: Gonk, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla17
People
(Reporter: cjones, Assigned: cjones)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
(deleted),
patch
|
drs
:
review+
|
Details | Diff | Splinter Review |
(gdb) bt
#0 0x40ed8b06 in nsIView::GetViewFor (aWidget=0x0) at /home/cjones/mozilla/inbound/view/src/nsView.cpp:137
#1 0x40ed8656 in nsView::GetViewFor (aWidget=0x0) at /home/cjones/mozilla/inbound/view/src/nsView.h:80
#2 0x40edaeaa in nsView::HandleEvent (this=0x1495640, aEvent=0xbe8f4fc0, aUseAttachedEvents=false) at /home/cjones/mozilla/inbound/view/src/nsView.cpp:1054
#3 0x41784b74 in nsWindow::DispatchEvent (this=0x14956a0, aEvent=0xbe8f4fc0, aStatus=@0xbe8f4fa4) at /home/cjones/mozilla/inbound/widget/gonk/nsWindow.cpp:483
#4 0x41784644 in nsWindow::DispatchInputEvent (aEvent=...) at /home/cjones/mozilla/inbound/widget/gonk/nsWindow.cpp:288
#5 0x41780b9c in sendTouchEvent (data=...) at /home/cjones/mozilla/inbound/widget/gonk/nsAppShell.cpp:193
#6 0x417812d0 in GeckoInputDispatcher::dispatchOnce (this=0x1448868) at /home/cjones/mozilla/inbound/widget/gonk/nsAppShell.cpp:350
#7 0x41781efc in nsAppShell::ProcessNextNativeEvent (this=0x10a42d0, mayWait=false) at /home/cjones/mozilla/inbound/widget/gonk/nsAppShell.cpp:595
mUseAttachedEvents is false in nsWindow, so we go looking for a view for the widget, but the widget isn't set in the nsGUIEvent so we can't find one.
Assignee | ||
Comment 1•12 years ago
|
||
We assert in nsView.cpp because this is null, so I think this patch is correct.
Assignee: nobody → jones.chris.g
Attachment #652285 -
Flags: review?(mwu)
Comment 2•12 years ago
|
||
Comment on attachment 652285 [details] [diff] [review]
Restore setting .widget on nsGUIEvent
Review of attachment 652285 [details] [diff] [review]:
-----------------------------------------------------------------
*puts on his mwu mask*
::: widget/gonk/nsWindow.cpp
@@ +284,5 @@
>
> gFocusedWindow->UserActivity();
>
> nsEventStatus status;
> + aEvent.widget = gFocusedWindow;
Why not null check first? It seems like we're only doing this to target the focused window if there's no other widget. If new code is added which uses this, will it not have its widget overwritten?
Assignee | ||
Comment 3•12 years ago
|
||
It doesn't make sense to dispatch an input event without a focused widget. This is restoring a line of code that was removed. If it's null we can't do anything with the event and want to crash so we know we're in error.
Comment 4•12 years ago
|
||
Comment on attachment 652285 [details] [diff] [review]
Restore setting .widget on nsGUIEvent
Review of attachment 652285 [details] [diff] [review]:
-----------------------------------------------------------------
(In reply to Chris Jones [:cjones] [:warhammer] from comment #3)
> It doesn't make sense to dispatch an input event without a focused widget.
> This is restoring a line of code that was removed. If it's null we can't do
> anything with the event and want to crash so we know we're in error.
Ok
Attachment #652285 -
Flags: review?(mwu) → review+
Assignee | ||
Comment 5•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac8287aea1fb
Neil, had to push this as an emergency fix; let me know if this isn't correct.
Comment 6•12 years ago
|
||
Urph, the removal of that line was obviously not correct. r=me too.
Comment 7•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•