Closed
Bug 1181564
Opened 9 years ago
Closed 9 years ago
Crash in mozilla::WidgetGUIEvent*
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
mozilla43
Tracking | Status | |
---|---|---|
firefox43 | --- | verified |
People
(Reporter: Virtual, Assigned: alessarik)
References
Details
(5 keywords)
Crash Data
Attachments
(1 file)
(deleted),
text/plain
|
Details |
For a some time I'm getting crash with "mozilla::WidgetGUIEvent*" in crashlog report signature
https://crash-stats.mozilla.com/report/index/88af6c76-e030-4310-b950-c43102150627
https://crash-stats.mozilla.com/report/index/2f4a38f5-0fb1-4f5b-9445-fbbbb2150704
https://crash-stats.mozilla.com/report/index/a690c907-8730-451d-9b30-c0c462150708
The crashes mostly happens when I drag and drop moved tab into another window.
Reporter | ||
Comment 1•9 years ago
|
||
[Tracking Requested - why for this release]: Regression
status-firefox41:
--- → unaffected
status-firefox42:
--- → affected
tracking-firefox42:
--- → ?
Keywords: regression,
regressionwindow-wanted
Version: Trunk → 42 Branch
Total volume of all these signatures is really low so I don't think it necessitates tracking, regression or not. Can you please investigate the Nightly where these crashes first began? It would also help to have more detailed steps to reproduce and a copy of about:support so this can be investigated further.
tracking-firefox42:
? → ---
Updated•9 years ago
|
Crash Signature: , nsIContent**) ]
[@ nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) ] → , nsIContent**) ]
[@ nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) ]
[@ PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**) ]
Reporter | ||
Updated•9 years ago
|
Comment 3•9 years ago
|
||
FF 40beta7
https://crash-stats.mozilla.com/report/index/bp-a80fbd28-0923-4fcb-939f-33fe32150725
I will try autocomplete login and password with addon LastPass
Reporter | ||
Updated•9 years ago
|
I'm able to reliably trigger this crash using the following STR:
NOTE: although this STR references a particular site and link, this works with any standard HTML page and link
1. Visit http://www.kicad-pcb.org/display/KICAD/Installing+KiCad#InstallingKiCad-Windows
2. Click the link "Building KiCad on Windows" and immediately also click and hold it. NOTE: you must of course click and hold the link before the page transitions and continue holding while the page loads, so you have to perform both clicks quickly.
3. Once the page has loaded, release the mouse button.
4. Crash.
Keywords: reproducible
By the way, I reproduced this using the July 28th nightly build (32-bit) on Windows 8.1
(In reply to IU from comment #5)
> By the way, I reproduced this using the July 28th nightly build (32-bit) on
> Windows 8.1
This does not reproduce for me. If you can reproduce this reliably, would you be willing to find a regression window? I'd be happy to walk you through the process.
Note, we should really only use the reproducible keyword for bugs which are reliably reproducible (this bug is not).
Keywords: reproducible
Reporter | ||
Updated•9 years ago
|
Keywords: steps-wanted
Reporter | ||
Comment 7•9 years ago
|
||
OK, I can reproduce it with these modified STR from Comment 4.
STR:
1. Open this URL website - http://www.kicad-pcb.org/display/KICAD/Installing+KiCad#InstallingKiCad-Windows
2. Click the link "Building KiCad on Windows" with your left mouse button and immediately also click it again, hold it and drag it away from the original link placement and hold it.
3. Once the webpage has loaded, press the right mouse button.
4. Crash.
Keywords: steps-wanted → reproducible
Regressed with cset: 2694ff2ace6a
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a3f280b6f8d5&tochange=2694ff2ace6a
Comment 10•9 years ago
|
||
Flags: needinfo?(bugmail.mozilla)
Keywords: regressionwindow-wanted
Comment 11•9 years ago
|
||
What the hell! That's not what I typed for needinfo. Let's try again.
Comment 13•9 years ago
|
||
According to the crash report this is a release-after-free when leaving the sPointerEventEnabled block of code at [1]. Therefore it was most likely regressed by enabling pointer events (bug 1166347) which is also in the regression range in comment 9.
Whoever can reproduce this bug - can you check to see if you still hit the crash if you disable the following two prefs and restart the browser? If you don't hit the crash that will confirm that it's a pointer events bug.
dom.w3c_pointer_events.enabled
layout.css.touch_action.enabled
Thanks!
[1] http://hg.mozilla.org/mozilla-central/annotate/d45440221297/layout/base/nsPresShell.cpp#l6999
Comment 14•9 years ago
|
||
Yes. Disabling those two stops the crashes.
Thanks
Reporter | ||
Updated•9 years ago
|
Version: 42 Branch → 40 Branch
Reporter | ||
Updated•9 years ago
|
Version: 40 Branch → 41 Branch
Comment 15•9 years ago
|
||
Since bug 1166347 enables pointer events on nightly only, this bug is nightly-only. Technically it is a security vulnerability also so I'm tagging it as csectype-uaf and CC'ing :mccr8.
The crash listed in comment 3 (and anything that's not on 41/42 nightly) is probably from a different root cause and should be tracked by a different bug if necessary. Any fix in this bug will likely not fix those issues.
Updated•9 years ago
|
Flags: needinfo?(alessarik)
Reporter | ||
Updated•9 years ago
|
status-firefox39:
? → ---
status-firefox40:
? → ---
status-firefox41:
affected → ---
status-firefox42:
affected → ---
Version: 41 Branch → Trunk
Comment 17•9 years ago
|
||
It would be great if someone would finally fix this. I just got a related crash with the signature: [@ mozilla::OwningNonNull<T>::~OwningNonNull<T>() ]
bp-a78e9bf6-de44-43f3-a4e3-427762150820
I was dragging a link, but didn't realize a click was registered. The page loaded and, once I let go of the left mouse button, CRASH!
Frame Module Signature Source
0 xul.dll mozilla::OwningNonNull<mozilla::dom::PeerConnectionLifecycleCallback>::~OwningNonNull<mozilla::dom::PeerConnectionLifecycleCallback>() mfbt/nsRefPtr.h
1 xul.dll PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**) layout/base/nsPresShell.cpp
2 xul.dll nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) view/nsViewManager.cpp
3 xul.dll nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool) view/nsView.cpp
4 xul.dll nsWindow::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&) widget/windows/nsWindow.cpp
5 xul.dll nsBaseWidget::DispatchInputEvent(mozilla::WidgetInputEvent*) widget/nsBaseWidget.cpp
6 xul.dll nsWindow::DispatchMouseEvent(unsigned int, unsigned int, long, bool, short, unsigned short) widget/windows/nsWindow.cpp
7 xul.dll nsWindow::ProcessMessage(unsigned int, unsigned int&, long&, long*) widget/windows/nsWindow.cpp
8 xul.dll nsWindow::WindowProcInternal(HWND__*, unsigned int, unsigned int, long) widget/windows/nsWindow.cpp
9 xul.dll CallWindowProcCrashProtected xpcom/base/nsCrashOnException.cpp
10 xul.dll nsWindow::WindowProc(HWND__*, unsigned int, unsigned int, long) widget/windows/nsWindow.cpp
11 user32.dll _InternalCallWinProc
12 user32.dll UserCallWinProcCheckWow
13 user32.dll DispatchMessageWorker
14 user32.dll DispatchMessageW
15 xul.dll nsAppShell::ProcessNextNativeEvent(bool) widget/windows/nsAppShell.cpp
16 xul.dll nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) widget/nsBaseAppShell.cpp
17 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp
18 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp
19 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc
20 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc
21 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp
22 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp
23 xul.dll nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp
24 xul.dll XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp
25 xul.dll XREMain::XRE_main(int, char** const, nsXREAppData const*) toolkit/xre/nsAppRunner.cpp
26 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp
27 firefox.exe do_main browser/app/nsBrowserApp.cpp
28 firefox.exe NS_internal_main(int, char**) browser/app/nsBrowserApp.cpp
29 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp
30 firefox.exe __tmainCRTStartup f:/dd/vctools/crt/crtw32/startup/crt0.c:255
31 kernel32.dll BaseThreadInitThunk
32 ntdll.dll __RtlUserThreadStart
33 ntdll.dll _RtlUserThreadStart
Reporter | ||
Comment 18•9 years ago
|
||
Workaround is to set to false these 2 preferences in about:config:
-dom.w3c_pointer_events.enabled
-layout.css.touch_action.enabled
Comment 19•9 years ago
|
||
I know there is a workaround, but you'd think it would make more sense to actually fix the bug -- unless Mozilla has decided they really don't care about the feature anymore (in which case they should just rip it out or default it to disabled).
Left as is, it will eventually make it into the official builds.
Comment 20•9 years ago
|
||
AFAIK Maksim is on vacation right now. I've needinfo?'ed him for this bug. This is a regression from his patch.
Can we back the regressing patch out?
Comment 22•9 years ago
|
||
I guess we could disable those prefs.
I'll file a followup to disable them.
Comment 23•9 years ago
|
||
Or I guess we should just backout Bug 1166347. I'll push the backout to try.
Comment 24•9 years ago
|
||
Merge of backout:
https://hg.mozilla.org/mozilla-central/rev/4520f11055a7
Assignee: nobody → alessarik
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox43:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Reporter | ||
Updated•9 years ago
|
Status: RESOLVED → VERIFIED
Comment 25•9 years ago
|
||
Maksim, would you have time to look at this?
Assignee | ||
Comment 26•9 years ago
|
||
Unfortunately, I have no long time for investigation complicated issues in nearest time.
Assignee | ||
Comment 27•9 years ago
|
||
Could you please check described behavior one more time with latest sources (I mean in latest Nightly).
(But before testing turn on w3c_pointer_events and touch_action in preferences and restart browser).
Flags: needinfo?(bernesb)
Reporter | ||
Comment 28•9 years ago
|
||
Unfortunately, yes and now it's harder to reproduce, as website page from STR is not available.
[@ PresShell::HandleEvent ]
https://crash-stats.mozilla.com/report/index/8131bbb4-6be3-42a7-9cc0-fc1a92160423
[@ nsCOMPtr_base::~nsCOMPtr_base | PresShell::HandleEvent ]
https://crash-stats.mozilla.com/report/index/0205be22-20e1-41b2-8f4c-7e9372160426
Crash Signature: , nsIContent**) ]
[@ nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) ]
[@ PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**) ] → , nsIContent**) ]
[@ nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) ]
[@ PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**) ]
[@ PresShell::HandleEvent ]
[@ nsCOMPtr_base::~β¦
Flags: needinfo?(bernesb)
Assignee | ||
Comment 29•9 years ago
|
||
Unfortunately crash dump has no info to understand reasons of such behavior, so I would prefer to get permanent steps to reproduce this bug.
Reporter | ||
Comment 30•9 years ago
|
||
Permanent STR are in Comment 7, but now this website page is not available, as much time passed from the report.
I will look for another one with reproducible behavior like the one before.
In the end, we at least know, that the issue is still there.
Comment 31•9 years ago
|
||
I can reproduce this on 45.0.1 and 46.0 on my website:
http://www.chickensmoothie.com/
If I click any of the links (say, the blue links to forum posts on the left), then before the new page loads, click and drag the link, then release the mouse once the new page has loaded, it crashes.
However, the bug no longer reproduces on this site on nightly 49.0a1 (2016-04-26).
I'm on Mac OS X 10.11.4 in case this is relevant.
Reporter | ||
Comment 32•8 years ago
|
||
and crashed only once for all this time
https://crash-stats.mozilla.com/report/index/06babfcf-b56d-472d-9b82-10d902160602
Reporter | ||
Comment 33•8 years ago
|
||
Just followup FYI, I want to add, that setting dom.w3c_pointer_events.enabled to true, still crashing the Firefox - https://crash-stats.mozilla.com/report/index/5d81208d-c12e-442e-a20c-13c602160819
Comment 34•8 years ago
|
||
I filed bug 1306843 for the crash you reported in comment 33.
Also, dropping stale needinfo.
Flags: needinfo?(alessarik)
Reporter | ||
Comment 35•8 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #34)
> I filed bug 1306843 for the crash you reported in comment 33.
>
> Also, dropping stale needinfo.
Ups, I posted wrong URL of crashlog report, here's the correct one - https://crash-stats.mozilla.com/report/index/715e6d64-8619-4cfa-8142-190f22160921
Assignee | ||
Comment 38•8 years ago
|
||
Unfortunately, I cannot reproduce this bug.
Some info:
https://hg.mozilla.org/mozilla-central/annotate/e2d2897e4a74/layout/base/nsPresShell.cpp#l7298
Crash in that line, so it means, that crash happened during destroying
nsCOMPtr<nsIContent> targetContent;
Related code:
https://hg.mozilla.org/mozilla-central/annotate/e2d2897e4a74/layout/base/nsPresShell.cpp#l7807
https://hg.mozilla.org/mozilla-central/annotate/e2d2897e4a74/layout/base/nsPresShell.cpp#l4387
Maybe, code needs some additional conditions at that places, for example checking document life.
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(alessarik)
Reporter | ||
Updated•7 years ago
|
Keywords: nightly-community
Reporter | ||
Updated•7 years ago
|
QA Contact: Virtual
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Reporter | ||
Updated•5 years ago
|
Keywords: crashreportid
You need to log in
before you can comment on or make changes to this bug.
Description
•