Closed Bug 1181564 Opened 9 years ago Closed 9 years ago

Crash in mozilla::WidgetGUIEvent*

Categories

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

x86_64
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla43
Tracking Status
firefox43 --- verified

People

(Reporter: Virtual, Assigned: alessarik)

References

Details

(5 keywords)

Crash Data

Attachments

(1 file)

[Tracking Requested - why for this release]: Regression
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.
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.
Would have to be either bug 1175631, bug 1175382, or bug 1175442. I suspect bug 1175631.
Flags: needinfo?(bugmail.mozilla)
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.
Assignee: nobody → alessarik
Status: NEW → RESOLVED
Closed: 9 years ago
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

Created:
Updated:
Size: