Closed Bug 806755 Opened 9 years ago Closed 9 years ago
"ASSERTION: Must have view manager" scrolling and closing tab
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]
This is just a stab in the dark - does it fix it?
Just saw this on m-c as well. https://tbpl.mozilla.org/php/getParsedLog.php?id=16705071&tree=Firefox&full=1
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...
Attachment #676684 - Flags: review?(roc)
Attachment #676684 - Flags: review?(roc) → review+
Assignee: nobody → matspal
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.