714587 - "ASSERTION: unexpected disconnected nodes" with full screen, selectAllChildren

Status: RESOLVED FIXED

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

Description

[Jesse Ruderman]

Attachment: testcase

Sometimes, this testcase causes an assertion during shutdown. Moving the mouse while Firefox enters full-screen might make it more likely.

###!!! ASSERTION: unexpected disconnected nodes: 'mIsDetached', file content/base/src/nsRange.cpp, line 796

nsRange::Reset [content/base/src/nsRange.cpp:839]
nsRange::cycleCollection::Unlink [content/base/src/nsRange.cpp:347]
nsCycleCollector::CollectWhite [xpcom/base/nsCycleCollector.cpp:2145]
nsCycleCollector::FinishCollection [xpcom/base/nsCycleCollector.cpp:2973]
nsCycleCollector::Collect [xpcom/base/nsCycleCollector.cpp:2821]
nsCycleCollector::Shutdown [xpcom/base/nsCycleCollector.cpp:3049]
nsCycleCollector_shutdown [xpcom/base/nsCycleCollector.cpp:3764]
mozilla::ShutdownXPCOM [xpcom/build/nsXPComInit.cpp:672]
ScopedXPCOMStartup::~ScopedXPCOMStartup [toolkit/xre/nsAppRunner.cpp:1114]
XRE_main [nsCOMPtr.h:809]
main [browser/app/nsBrowserApp.cpp:201]

Comment 1

[Mats Palmgren (inactive)]

http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsRange.cpp#779
this assertion can only occur if IsInSelection() is true.   We need to make
sure the range is removed from the Selection before Unlink is called.

Comment 2

[Mats Palmgren (inactive)]

Attachment: fix

I guess I thought the nsTypedSelection UNLINK handler would be called
before the nsRange's (since there is a strong pointer from the
selection to the range), but I guess my assumption was wrong and that
there is no guaranteed ordering of these calls.
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsSelection.cpp#3438
http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsRange.cpp#345

Comment 3

[Andrew McCreight [:mccr8]]

(In reply to Mats Palmgren [:mats] from comment #2)
> I guess I thought the nsTypedSelection UNLINK handler would be called
> before the nsRange's (since there is a strong pointer from the
> selection to the range), but I guess my assumption was wrong and that
> there is no guaranteed ordering of these calls.
The CC computes everything that is dead in a single go, which can include something and the things that it strongly holds.  If two things are identified as garbage in a single CC, then the order their unlinks are called in is arbitrary.

Comment 4

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0529bd4e33bd

Comment 5

[Joe Drew (not getting mail)]

https://hg.mozilla.org/mozilla-central/rev/0529bd4e33bd