859630 - Crash with layers.force-active and "display: table-caption"

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Jesse Ruderman]

Attachment: testcase (requires pref)

With:
  user_pref("layers.force-active", true);
(which was added in bug 812908)

The testcase crashes with IsContentLEQ calling FindContentInDocument(NULL, ...).

Nightly: bp-3cf010b3-c1a7-4688-a1a0-febd42130409

Comment 1

[Jesse Ruderman]

Attachment: stack (minidump_stackwalk on a Tinderbox debug build)

Comment 2

[Jesse Ruderman]

Attachment: stack (gdb)

Comment 3

[Scoobidiver (away)]

On Windows: bp-b6fd9bb9-4892-4988-aeba-f1fd82130409.

Comment 4

[Scoobidiver (away)]

On 64-bit Windows build: bp-91a124a7-5259-4ef9-8294-37d6e2130409.

Comment 5

[Matt Woodrow (:mattwoodrow)]

Not entirely sure what the solution is here.

The two frames passed to IsContentLEQ are nsSubDocumentFrame and nsViewportFrame.

The latter doesn't have a Content, and we crash.

roc: What would you expect the behaviour to be in this case?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

FindContentInDocument tries to walk up to find the element in aDoc for the given item/frame. In this case the frame must be the nsViewportFrame for some subdocument, so we need to fix FindContentInDocument to find the right element in aDoc for that case.

So I think we should pass the nsDisplayItem* to FindContentInDocument, have it call GetUnderlyingFrame, if the frame has no content then call PresContext()->Document() and start the search from there (i.e. taking the "parentDoc = d->GetParentDocument(), parentDoc->FindContentForSubDocument path).

Make sense?

Comment 7

[Matt Woodrow (:mattwoodrow)]

Attachment: Use the PresShell's document

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 737354 [details] [diff] [review]
Use the PresShell's document

Review of attachment 737354 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/base/nsDisplayList.cpp
@@ +1426,5 @@
>    // of commonAncestor, because display items for subdocuments have been
>    // mixed into the same list. Ensure that we're looking at content
>    // in commonAncestor's document.
>    nsIDocument* commonAncestorDoc = commonAncestor->OwnerDoc();
> +  nsIContent* content1 = FindContentInDocument(aItem1->GetUnderlyingFrame(),

Might as well move the call to GetUnderlyingFrame into FindContentInDocument too.

Comment 9

[Matt Woodrow (:mattwoodrow)]

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

Comment 10

[Ryan VanderMeulen [:RyanVM]]

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