Closed Bug 806755 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: DOM: Selection, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: jruderman, Assigned: mats)

References

(Blocks 2 open bugs)

Details

(Keywords: assertion)

Attachments

(2 files)

Attached file 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]
Attached patch fix?Splinter Review
This is just a stab in the dark - does it fix it?
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)
https://hg.mozilla.org/mozilla-central/rev/e5d4cfce296c
Assignee: nobody → matspal
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Blocks: fuzz-keys
You need to log in before you can comment on or make changes to this bug.