Closed Bug 1152432 Opened 8 years ago Closed 5 years ago

SelectionCarets needs to deal with stuff being destroyed after Flush_Layout


(Core :: DOM: Selection, defect)

Not set





(Reporter: MatsPalmgren_bugz, Unassigned)



The FlushPendingNotifications call on line 465 might lead to
Destroy() on mPresShell which calls Terminate on |this| and
then nulls out its reference which might delete |this|.
So we should proabably move this Flush to the start of the
method and make sure all callers of UpdateSelectionCarets()
holds a strong reference on the object they use for the
call (and bail out if mPresShell is null after that call).
We also need to make sure all callers of those methods
deals with it, recursively.

There is another Flush_Layout call here:
We need to fix this in the same way.

Also, callers of FlushPendingNotifications are required to
hold a strong ref on the shell for the duration of the call,
for example by holding a strong ref on the stack.
Mark this as WONTFIX because SelectionCarets are replaced by AccessibleCaret.
Closed: 5 years ago
Resolution: --- → WONTFIX
AccessibleCaretManager::FlushLayout() has essentially the same problem though...
but I guess we'll fix that by removing the flush in bug 1445794.
We had ensured all the entry points of AccessibleCaretEventHub' holds an extra strong reference in bug 1248847, and AccessibleCaretEventHub owns AccessibleCaretManager [1]. I think that implies AccessibleCaretManager's validity after layout flush, right?

True, but even if AccessibleCaretManager/AccessibleCaretEventHub is
robust against layout changes from the flush doesn't mean everything
else is.  It was used to trigger bug 1484559 and bug 1490561 just
recently for example.
You need to log in before you can comment on or make changes to this bug.