Closed Bug 1181564 Opened 9 years ago Closed 9 years ago

Crash in mozilla::WidgetGUIEvent*

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla43
Tracking Flags:
Tracking Status
firefox43 --- verified

People

(Reporter: Virtual, Assigned: alessarik)

References

Details

(5 keywords)

Crash Data

Attachments

(1 file)

about;support.txt
12.08 KB, text/plain
Details 
[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: ? → ---
Crash Signature: , nsIContent**) ] [@ nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) ] → , nsIContent**) ] [@ nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) ] [@ PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**) ]
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
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
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
Would have to be either bug 1175631, bug 1175382, or bug 1175442.

I suspect bug 1175631.
Flags: needinfo?(bugmail.mozilla)
Keywords: regressionwindow-wanted
What the hell!  That's not what I typed for needinfo.  Let's try again.
WTH?  Blocking instead.
Blocks: 1175631
Flags: needinfo?(bugmail.mozilla)
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
Yes.  Disabling those two stops the crashes.
Thanks
Blocks: 1166347
No longer blocks: 1175631
Component: Graphics → DOM
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.
Flags: needinfo?(alessarik)
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
Workaround is to set to false these 2 preferences in about:config:
-dom.w3c_pointer_events.enabled
-layout.css.touch_action.enabled
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.
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?
I guess we could disable those prefs.
I'll file a followup to disable them.
Or I guess we should just backout Bug 1166347. I'll push the backout to try.
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
Maksim, would you have time to look at this?
Unfortunately, I have no long time for investigation complicated issues in nearest time.
Blocks: 1266724
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)
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)
Unfortunately crash dump has no info to understand reasons of such behavior, so I would prefer to get permanent steps to reproduce this bug.
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.
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.
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
I filed bug 1306843 for the crash you reported in comment 33.

Also, dropping stale needinfo.
Flags: needinfo?(alessarik)
(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
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.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: