806755 - "ASSERTION: Must have view manager" scrolling and closing tab

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Jesse Ruderman]

Attachment: this is not a testcase

I can't reproduce this on my laptop, despite getting a "reduced testcase" from the build machines (which means they didn't have any trouble reproducing it).

I'm pretty sure the DOM fuzzer decided to trigger an arrow keypress (in a contenteditable area) and close the window right around the same time.

###!!! ASSERTION: Must have view manager: '!isSafeToFlush || mViewManager', file ../../../layout/base/nsPresShell.cpp, line 3817

mozilla::Selection::ScrollIntoView(short, nsIPresShell::ScrollAxis, nsIPresShell::ScrollAxis, int) [nsCOMPtr.h:472]
mozilla::Selection::ScrollSelectionIntoViewEvent::Run() [nsSelection.cpp:5274]
nsThread::ProcessNextEvent(bool, bool*) [nsThread.cpp:620]
NS_ProcessPendingEvents_P(nsIThread*, unsigned int) [nsThreadUtils.cpp:170]
nsBaseAppShell::NativeEventCallback() [nsBaseAppShell.cpp:98]
nsAppShell::ProcessGeckoEvents(void*) [nsAppShell.mm:399]
CoreFoundation + 0x12b51
CoreFoundation + 0x123bd
CoreFoundation + 0x391a9
CoreFoundation + 0x38ae6
HIToolbox + 0x23d3
HIToolbox + 0x958f
HIToolbox + 0x94ca
AppKit + 0x93f1
-AppKit + 0x8cf5
-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] [nsAppShell.mm:164]
-AppKit + 0x562d
nsAppShell::Run() [nsAppShell.mm:752]
nsAppStartup::Run() [nsAppStartup.cpp:290]
XREMain::XRE_mainRun() [nsAppRunner.cpp:3799]
XREMain::XRE_main(int, char**, nsXREAppData const*) [nsAppRunner.cpp:3866]
XRE_main [nsAppRunner.cpp:3941]
main [nsBrowserApp.cpp:174]

Comment 1

[Mats Palmgren (inactive)]

Attachment: fix?

This is just a stab in the dark - does it fix it?

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Just saw this on m-c as well.
https://tbpl.mozilla.org/php/getParsedLog.php?id=16705071&tree=Firefox&full=1

Comment 3

[Mats Palmgren (inactive)]

Comment on attachment 676684 [details] [diff] [review]
fix?

I'm pretty sure this will fix it.  The theory is that Selection::GetPresShell
finds a non-null mPresShellWeak and return that, even after Destroy() was
called on the shell, because weak refs are only nulled out when it's finally
deleted/collected.  mFrameSelection->GetShell() is nulled by an explicit
DisconnectFromPresShell() call in PresShell::Destroy (which also nulls
out mViewManager and is what causes the assertion).

Yeah, this is a mess - I intend to clean it up in bug 750070 once I can
find some time...

Comment 4

[Phil Ringnalda (:philor)]

https://tbpl.mozilla.org/php/getParsedLog.php?id=16710293&tree=Mozilla-Inbound

Comment 5

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e5d4cfce296c

Comment 6

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/e5d4cfce296c