1181564 - Crash in mozilla::WidgetGUIEvent*

Status: VERIFIED FIXED

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

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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.

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

[Tracking Requested - why for this release]: Regression

Comment 2

[u279076]

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.

Comment 3

[mkdante381]

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

Comment 4

[IU]

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.

Comment 5

[IU]

By the way, I reproduced this using the July 28th nightly build (32-bit) on Windows 8.1

Comment 6

[u279076]

(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).

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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.

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: about;support.txt

Comment 9

[IU]

Regressed with cset: 2694ff2ace6a

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a3f280b6f8d5&tochange=2694ff2ace6a

Comment 10

[IU]

Would have to be either bug 1175631, bug 1175382, or bug 1175442.

I suspect bug 1175631.

Comment 11

[IU]

What the hell!  That's not what I typed for needinfo.  Let's try again.

Comment 12

[IU]

WTH?  Blocking instead.

Comment 13

[Kartikaya Gupta (email:[e-mail])]

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

[IU]

Yes.  Disabling those two stops the crashes.
Thanks

Comment 15

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 16

[Kartikaya Gupta (email:[e-mail])]

Ugh, mid-air.

Comment 17

[IU]

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

Comment 18

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Workaround is to set to false these 2 preferences in about:config:
-dom.w3c_pointer_events.enabled
-layout.css.touch_action.enabled

Comment 19

[IU]

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

[Olli Pettay [:smaug][[e-mail]]]

AFAIK Maksim is on vacation right now. I've needinfo?'ed him for this bug. This is a regression from his patch.

Comment 21

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Can we back the regressing patch out?

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

I guess we could disable those prefs.
I'll file a followup to disable them.

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

Or I guess we should just backout Bug 1166347. I'll push the backout to try.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Merge of backout:
https://hg.mozilla.org/mozilla-central/rev/4520f11055a7

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

Maksim, would you have time to look at this?

Comment 26

[Maksim Lebedev]

Unfortunately, I have no long time for investigation complicated issues in nearest time.

Comment 27

[Maksim Lebedev]

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).

Comment 28

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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

Comment 29

[Maksim Lebedev]

Unfortunately crash dump has no info to understand reasons of such behavior, so I would prefer to get permanent steps to reproduce this bug.

Comment 30

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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

[Nicholas Sherlock]

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.

Comment 32

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

and crashed only once for all this time
https://crash-stats.mozilla.com/report/index/06babfcf-b56d-472d-9b82-10d902160602

Comment 33

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

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

[Kartikaya Gupta (email:[e-mail])]

I filed bug 1306843 for the crash you reported in comment 33.

Also, dropping stale needinfo.

Comment 35

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Kartikaya Gupta (email:[e-mail]) 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

Comment 36

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

and readding needinfo

Comment 38

[Maksim Lebedev]

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.