Closed
Bug 1181564
Opened 8 years ago
Closed 8 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)
12.08 KB,
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.
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 1•8 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•8 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**) ]
Comment 3•8 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
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
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•8 years ago
|
Keywords: steps-wanted
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 7•8 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•8 years ago
|
||
Would have to be either bug 1175631, bug 1175382, or bug 1175442. I suspect bug 1175631.
Flags: needinfo?(bugmail.mozilla)
Keywords: regressionwindow-wanted
Comment 11•8 years ago
|
||
What the hell! That's not what I typed for needinfo. Let's try again.
Comment 13•8 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•8 years ago
|
||
Yes. Disabling those two stops the crashes. Thanks
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•8 years ago
|
Version: 42 Branch → 40 Branch
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•8 years ago
|
Version: 40 Branch → 41 Branch
Comment 15•8 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•8 years ago
|
Flags: needinfo?(alessarik)
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•8 years ago
|
status-firefox39:
? → ---
status-firefox40:
? → ---
status-firefox41:
affected → ---
status-firefox42:
affected → ---
Version: 41 Branch → Trunk
Comment 17•8 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
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 18•8 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•8 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•8 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•8 years ago
|
||
I guess we could disable those prefs. I'll file a followup to disable them.
Comment 23•8 years ago
|
||
Or I guess we should just backout Bug 1166347. I'll push the backout to try.
Comment 24•8 years ago
|
||
Merge of backout: https://hg.mozilla.org/mozilla-central/rev/4520f11055a7
Assignee: nobody → alessarik
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox43:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•8 years ago
|
Status: RESOLVED → VERIFIED
Comment 25•8 years ago
|
||
Maksim, would you have time to look at this?
Assignee | ||
Comment 26•8 years ago
|
||
Unfortunately, I have no long time for investigation complicated issues in nearest time.
Assignee | ||
Comment 27•8 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)
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 28•8 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•8 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.
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 30•8 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•8 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.
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 32•7 years ago
|
||
and crashed only once for all this time https://crash-stats.mozilla.com/report/index/06babfcf-b56d-472d-9b82-10d902160602
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 33•7 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•7 years ago
|
||
I filed bug 1306843 for the crash you reported in comment 33. Also, dropping stale needinfo.
Flags: needinfo?(alessarik)
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 35•7 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
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Comment 36•7 years ago
|
||
and readding needinfo
Flags: needinfo?(alessarik)
Assignee | ||
Comment 38•7 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.
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•7 years ago
|
Flags: needinfo?(alessarik)
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•6 years ago
|
Keywords: nightly-community
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•6 years ago
|
QA Contact: Virtual
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•4 years ago
|
Keywords: crashreportid
You need to log in
before you can comment on or make changes to this bug.
Description
•