1517467 - Crash in nsGenericHTMLFrameElement::GetContentDocument

Status: RESOLVED FIXED

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

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is
report bp-58fe023e-ea72-4010-8636-31a130190103.
=============================================================

Seen while looking at nightly crash stats: https://bit.ly/2ApkxXO. Crashes started in 20190102213721.

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0def5ac36b5bf1f7f70bd84d3398dfb64d853ba8&tochange=aa4130cac64d20bdb83805984b51037c13b4fbbd

Top 10 frames of crashing thread:

0 xul.dll nsGenericHTMLFrameElement::GetContentDocument dom/html/nsGenericHTMLFrameElement.cpp:79
1 xul.dll static bool mozilla::dom::HTMLIFrameElement_Binding::get_contentDocument dom/bindings/HTMLIFrameElementBinding.cpp:796
2 xul.dll mozilla::dom::binding_detail::GenericGetter<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3019
3 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:535
4 xul.dll js::CallGetter js/src/vm/Interpreter.cpp:730
5 xul.dll js::NativeGetProperty js/src/vm/NativeObject.cpp:2584
6 xul.dll js::GetProperty js/src/vm/Interpreter.cpp:4739
7 xul.dll static bool Interpret js/src/vm/Interpreter.cpp:3021
8 xul.dll js::RunScript js/src/vm/Interpreter.cpp:423
9 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:563

=============================================================

Comment 1

[Marcia Knous [:marcia]]

https://bit.ly/2TqPimi seems to be a similar signature showing up in Fennec, showing up in 20190103094209.

Comment 2

[Calixte Denizet (:calixte)]

There are 24 crashes (from 18 installations) in nightly 66 starting with buildid 20190102213721. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1353867.

[1] https://hg.mozilla.org/mozilla-central/rev?node=18f95c6c1eb3

Comment 3

[Boris Zbarsky [:bzbarsky]]

So what GetContentDocument used to do is:

  nsCOMPtr<nsPIDOMWindowOuter> win = GetContentWindow();
  if (!win) {
    return nullptr;
  }

  nsIDocument* doc = win->GetDoc();

What it's doing now is:

  nsIDocument* doc = bc->GetDOMWindow()->GetDoc();

Per bug 1517415 comment 8, GetContentWindow() used to sometimes return null and in the situation when it did (but also in others, possibly) bc->GetDOMWindow() will now return null.  That null-check needs to come back.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Bug 1517467. Handle us not having a subframe window in the contentDocument getter. r=nika

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4d42e4786e4f
Handle us not having a subframe window in the contentDocument getter. r=nika

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c11865063e01
fix nsGenericHTMLFrameElement.cpp CLOSED TREE

Comment 7

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/4d42e4786e4f
https://hg.mozilla.org/mozilla-central/rev/c11865063e01