Threaded data provider: Support main thread data notifications (Blink side)

Threaded data provider: Support main thread data notifications (Blink side)

The threaded data receiver will now receive notifications about received data packets on the main thread (needed for the progress indicator to work properly), and can optionally specify that it wants to receive a full copy of the data (needed when the Inspector is attached).

Also removed the unused data parameter from ProgressTracker::incrementProgress

Chrome side patch: https://codereview.chromium.org/689713004
BUG=398076
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=188925

[oystein (OOO til 10th of July), 2014-10-29 21:20:00]

oysteine@chromium.org changed reviewers:
+ abarth@chromium.org

[oystein (OOO til 10th of July), 2014-10-29 21:22:34]

Patchset #1 (id:1) has been deleted

[oystein (OOO til 10th of July), 2014-10-29 21:28:42]

Patchset #1 (id:20001) has been deleted

[oystein (OOO til 10th of July), 2014-10-29 21:36:57]

abarth: Are you still the guy to review this stuff, or could you suggest someone
else? :)

[vsevik, 2014-10-30 13:47:38]

Can we add a test that even switching to background parser we still have the
main thread notifications?
For instance this could be something similar to
LayoutTests/http/tests/inspector-enabled/resource-tree/main-resource-content.html
but we need force background parser on some smaller content and check that it is
still loaded.

[oystein (OOO til 10th of July), 2014-11-05 21:29:06]

On 2014/10/30 13:47:38, vsevik wrote:
> Can we add a test that even switching to background parser we still have the
> main thread notifications?
> For instance this could be something similar to
>
LayoutTests/http/tests/inspector-enabled/resource-tree/main-resource-content.html
> but we need force background parser on some smaller content and check that it
is
> still loaded.

You mean tests for non-main-resource notifications, or just smaller main
resources?

[oystein (OOO til 10th of July), 2014-11-12 01:55:54]

Patchset #2 (id:60001) has been deleted

[oystein (OOO til 10th of July), 2014-11-12 01:56:51]

oysteine@chromium.org changed reviewers:
+ vsevik@chromium.org

[oystein (OOO til 10th of July), 2014-11-12 01:56:52]

vsevik: New version up, with a test added. PTAL :)

abarth: Is this still you, or can you suggest another reviewer?

[yurys, 2014-11-12 06:47:09]

yurys@chromium.org changed reviewers:
+ yurys@chromium.org

[yurys, 2014-11-12 06:47:09]

https://codereview.chromium.org/690793003/diff/80001/Source/core/html/parser/...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/80001/Source/core/html/parser/...
Source/core/html/parser/HTMLDocumentParser.cpp:84: m_needMainthreadDataCopy =
InspectorInstrumentation::hasFrontends();
It is safe to read InspectorInstrumentation::hasFrontends() on any thread so you
don't need to save its value in a field.

[vsevik, 2014-11-12 06:57:22]

>
https://codereview.chromium.org/690793003/diff/80001/Source/core/html/parser/...
> Source/core/html/parser/HTMLDocumentParser.cpp:84: m_needMainthreadDataCopy =
> InspectorInstrumentation::hasFrontends();
> It is safe to read InspectorInstrumentation::hasFrontends() on any thread so
you
> don't need to save its value in a field.
Other than that inspector changes lgtm

[oystein (OOO til 10th of July), 2014-11-17 18:41:42]

eseidel: Could you recommend a reviewer for the non-inspector bits here?

https://codereview.chromium.org/690793003/diff/80001/Source/core/html/parser/...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/80001/Source/core/html/parser/...
Source/core/html/parser/HTMLDocumentParser.cpp:84: m_needMainthreadDataCopy =
InspectorInstrumentation::hasFrontends();
On 2014/11/12 06:47:09, yurys wrote:
> It is safe to read InspectorInstrumentation::hasFrontends() on any thread so
you
> don't need to save its value in a field.

Done.

[eseidel, 2014-11-17 19:10:31]

eseidel@chromium.org changed reviewers:
+ eseidel@chromium.org

[eseidel, 2014-11-17 19:10:31]

kouhei or adamk.

[oystein (OOO til 10th of July), 2014-11-17 19:13:05]

oysteine@chromium.org changed reviewers:
+ adamk@chromium.org

[oystein (OOO til 10th of July), 2014-11-17 19:13:19]

On 2014/11/17 19:10:31, eseidel wrote:
> kouhei or adamk.

Awesome, thanks.

adamk: mind taking a look?

[adamk, 2014-11-17 21:11:20]

adamk@chromium.org changed reviewers:
+ kouhei@chromium.org
- adamk@chromium.org

[adamk, 2014-11-17 21:11:21]

Sorry to give you the runaround, but kouhei is definitely who you want for this.

[kouhei (in TOK), 2014-11-18 04:49:55]

kouhei@chromium.org changed reviewers:
+ haraken@chromium.org

[kouhei (in TOK), 2014-11-18 04:49:55]

https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:104: {
please add ASSERT(isMainThread());

https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:112:
WeakPtrWillBeRawPtr<Document> m_document;
This would not work on Oilpan, as RawPtr is not nuked when Document is
destructed.
I'm not sure how to solve this though...

haraken: Do you have any ideas?

https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:733: if
(RuntimeEnabledFeatures::threadedParserDataReceiverEnabled()) {
I think this is still marked as experimental and not enabled by default.

[haraken, 2014-11-18 04:57:28]

https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:112:
WeakPtrWillBeRawPtr<Document> m_document;
On 2014/11/18 04:49:55, kouhei wrote:
> This would not work on Oilpan, as RawPtr is not nuked when Document is
> destructed.
> I'm not sure how to solve this though...
> 
> haraken: Do you have any ideas?

Can't this simply be a RefPtr?

In the first place, I don't understand why Document::contextDocument() returns a
WeakPtrWillBeRawPtr. It's error-prone to pass WeakPtr around, so I think
Document::contextDocument() should just return a Document*. It looks like almost
all call sites of Document::contextDocument() are interested in a Document*
pointer, not WeakPtr<Document>.

[oystein (OOO til 10th of July), 2014-11-20 23:24:57]

On 2014/11/18 04:57:28, haraken wrote:
>
https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
> File Source/core/html/parser/HTMLDocumentParser.cpp (right):
> 
>
https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
> Source/core/html/parser/HTMLDocumentParser.cpp:112:
> WeakPtrWillBeRawPtr<Document> m_document;
> On 2014/11/18 04:49:55, kouhei wrote:
> > This would not work on Oilpan, as RawPtr is not nuked when Document is
> > destructed.
> > I'm not sure how to solve this though...
> > 
> > haraken: Do you have any ideas?
> 
> Can't this simply be a RefPtr?
> 
> In the first place, I don't understand why Document::contextDocument() returns
a
> WeakPtrWillBeRawPtr. It's error-prone to pass WeakPtr around, so I think
> Document::contextDocument() should just return a Document*. It looks like
almost
> all call sites of Document::contextDocument() are interested in a Document*
> pointer, not WeakPtr<Document>.


You mean it should return a Document* even without oilpan? It's possible for
ParserDataReceiver to slightly outlive its owning Document, since destruction
has to bounce via the I/O thread. With Oilpan I believe it gets iffy since the
ParserDataReceiver is only pointed to from outside of Chrome (it's owned by the
ThreadedDataResolver in content).

I'm not sure what the sideeffects would be of a ParserDataReceiver keeping
Document alive by itself via a RefPtr.

https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:733: if
(RuntimeEnabledFeatures::threadedParserDataReceiverEnabled()) {
On 2014/11/18 04:49:55, kouhei wrote:
> I think this is still marked as experimental and not enabled by default.

Yes, I put it behind the flag when we discovered this bug. It should be the only
blocker for the feature.

[kouhei (in TOK), 2014-11-26 05:16:49]

On 2014/11/20 23:24:57, Oystein wrote:
> On 2014/11/18 04:57:28, haraken wrote:
> >
>
https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
> > File Source/core/html/parser/HTMLDocumentParser.cpp (right):
> > 
> >
>
https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
> > Source/core/html/parser/HTMLDocumentParser.cpp:112:
> > WeakPtrWillBeRawPtr<Document> m_document;
> > On 2014/11/18 04:49:55, kouhei wrote:
> > > This would not work on Oilpan, as RawPtr is not nuked when Document is
> > > destructed.
> > > I'm not sure how to solve this though...
> > > 
> > > haraken: Do you have any ideas?
> > 
> > Can't this simply be a RefPtr?
> > 
> > In the first place, I don't understand why Document::contextDocument()
returns
> a
> > WeakPtrWillBeRawPtr. It's error-prone to pass WeakPtr around, so I think
> > Document::contextDocument() should just return a Document*. It looks like
> almost
> > all call sites of Document::contextDocument() are interested in a Document*
> > pointer, not WeakPtr<Document>.
> 
> 
> You mean it should return a Document* even without oilpan? It's possible for
> ParserDataReceiver to slightly outlive its owning Document, since destruction
> has to bounce via the I/O thread. With Oilpan I believe it gets iffy since the
> ParserDataReceiver is only pointed to from outside of Chrome (it's owned by
the
> ThreadedDataResolver in content).
> 
> I'm not sure what the sideeffects would be of a ParserDataReceiver keeping
> Document alive by itself via a RefPtr.

Sorry for slow response.

I think this should be a weak reference in Oilpan too.
Weak reference in Oilpan is only supported using WeakMember<>, so it looks like
we have to move ParserDataReceiver to Oilpan first.

[oystein (OOO til 10th of July), 2015-01-07 06:52:45]

On 2014/11/26 05:16:49, kouhei wrote:
> On 2014/11/20 23:24:57, Oystein wrote:
> > On 2014/11/18 04:57:28, haraken wrote:
> > >
> >
>
https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
> > > File Source/core/html/parser/HTMLDocumentParser.cpp (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
> > > Source/core/html/parser/HTMLDocumentParser.cpp:112:
> > > WeakPtrWillBeRawPtr<Document> m_document;
> > > On 2014/11/18 04:49:55, kouhei wrote:
> > > > This would not work on Oilpan, as RawPtr is not nuked when Document is
> > > > destructed.
> > > > I'm not sure how to solve this though...
> > > > 
> > > > haraken: Do you have any ideas?
> > > 
> > > Can't this simply be a RefPtr?
> > > 
> > > In the first place, I don't understand why Document::contextDocument()
> returns
> > a
> > > WeakPtrWillBeRawPtr. It's error-prone to pass WeakPtr around, so I think
> > > Document::contextDocument() should just return a Document*. It looks like
> > almost
> > > all call sites of Document::contextDocument() are interested in a
Document*
> > > pointer, not WeakPtr<Document>.
> > 
> > 
> > You mean it should return a Document* even without oilpan? It's possible for
> > ParserDataReceiver to slightly outlive its owning Document, since
destruction
> > has to bounce via the I/O thread. With Oilpan I believe it gets iffy since
the
> > ParserDataReceiver is only pointed to from outside of Chrome (it's owned by
> the
> > ThreadedDataResolver in content).
> > 
> > I'm not sure what the sideeffects would be of a ParserDataReceiver keeping
> > Document alive by itself via a RefPtr.
> 
> Sorry for slow response.
> 
> I think this should be a weak reference in Oilpan too.
> Weak reference in Oilpan is only supported using WeakMember<>, so it looks
like
> we have to move ParserDataReceiver to Oilpan first.

Sorry for the even slower response, other stuff (and holidays) got in the way
:).

I'm coincidentally in Tokyo this week; maybe we can have a chat tomorrow on how
to solve this, Oilpan is still somewhat mysterious to me!

[haraken, 2015-01-07 07:19:36]

On 2015/01/07 06:52:45, Oystein wrote:
> On 2014/11/26 05:16:49, kouhei wrote:
> > On 2014/11/20 23:24:57, Oystein wrote:
> > > On 2014/11/18 04:57:28, haraken wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
> > > > File Source/core/html/parser/HTMLDocumentParser.cpp (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/690793003/diff/100001/Source/core/html/parser...
> > > > Source/core/html/parser/HTMLDocumentParser.cpp:112:
> > > > WeakPtrWillBeRawPtr<Document> m_document;
> > > > On 2014/11/18 04:49:55, kouhei wrote:
> > > > > This would not work on Oilpan, as RawPtr is not nuked when Document is
> > > > > destructed.
> > > > > I'm not sure how to solve this though...
> > > > > 
> > > > > haraken: Do you have any ideas?
> > > > 
> > > > Can't this simply be a RefPtr?
> > > > 
> > > > In the first place, I don't understand why Document::contextDocument()
> > returns
> > > a
> > > > WeakPtrWillBeRawPtr. It's error-prone to pass WeakPtr around, so I think
> > > > Document::contextDocument() should just return a Document*. It looks
like
> > > almost
> > > > all call sites of Document::contextDocument() are interested in a
> Document*
> > > > pointer, not WeakPtr<Document>.
> > > 
> > > 
> > > You mean it should return a Document* even without oilpan? It's possible
for
> > > ParserDataReceiver to slightly outlive its owning Document, since
> destruction
> > > has to bounce via the I/O thread. With Oilpan I believe it gets iffy since
> the
> > > ParserDataReceiver is only pointed to from outside of Chrome (it's owned
by
> > the
> > > ThreadedDataResolver in content).
> > > 
> > > I'm not sure what the sideeffects would be of a ParserDataReceiver keeping
> > > Document alive by itself via a RefPtr.
> > 
> > Sorry for slow response.
> > 
> > I think this should be a weak reference in Oilpan too.
> > Weak reference in Oilpan is only supported using WeakMember<>, so it looks
> like
> > we have to move ParserDataReceiver to Oilpan first.
> 
> Sorry for the even slower response, other stuff (and holidays) got in the way
> :).
> 
> I'm coincidentally in Tokyo this week; maybe we can have a chat tomorrow on
how
> to solve this, Oilpan is still somewhat mysterious to me!

I'd be happy to.

[oystein (OOO til 10th of July), 2015-01-15 22:00:06]

Patchset #4 (id:120001) has been deleted

[oystein (OOO til 10th of July), 2015-01-15 22:01:29]

haraken: The ParserDataReceiver in HTMLDocumentParser.cpp now uses a document
lifecycle observer instead; was it something like this you meant?

[haraken, 2015-01-16 01:01:59]

https://codereview.chromium.org/690793003/diff/140001/Source/core/html/parser...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/140001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:88:
document->lifecycleNotifier().addObserver(this);

This won't be needed. DocumentLifecycleObserver's constructor will register the
observer to the notifier.

https://codereview.chromium.org/690793003/diff/140001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:94:
m_document->lifecycleNotifier().removeObserver(this);

Ditto. DocumentLifecycleObserver's destructor will do the removal.

https://codereview.chromium.org/690793003/diff/140001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:129: Document* m_document;

Remove this. Instead you should use
DocumentLifecycleObserver::lifecycleContext().

[oystein (OOO til 10th of July), 2015-01-16 04:31:49]

Thanks!

https://codereview.chromium.org/690793003/diff/140001/Source/core/html/parser...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/140001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:88:
document->lifecycleNotifier().addObserver(this);
On 2015/01/16 01:01:59, haraken wrote:
> 
> This won't be needed. DocumentLifecycleObserver's constructor will register
the
> observer to the notifier.

Done.

https://codereview.chromium.org/690793003/diff/140001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:94:
m_document->lifecycleNotifier().removeObserver(this);
On 2015/01/16 01:01:59, haraken wrote:
> 
> Ditto. DocumentLifecycleObserver's destructor will do the removal.

Done.

https://codereview.chromium.org/690793003/diff/140001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:129: Document* m_document;
On 2015/01/16 01:01:59, haraken wrote:
> 
> Remove this. Instead you should use
> DocumentLifecycleObserver::lifecycleContext().

Done.

[haraken, 2015-01-16 04:58:36]

The DocumentLifecycleObserver part LGTM.

https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:32: #include
"core/dom/DocumentLifecycleNotifier.h"

DocumentLifecycleNotifier.h => DocumentLifecycleObserver.h

https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:739: // TODO(oysteine): Disabled
due to crbug.com/398076 until a full fix can be implemented.

TODO => FIXME

[oystein (OOO til 10th of July), 2015-01-16 05:04:37]

Thanks haraken!

kouhei: Last bits are yours I think :).

https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
File Source/core/html/parser/HTMLDocumentParser.cpp (right):

https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:32: #include
"core/dom/DocumentLifecycleNotifier.h"
On 2015/01/16 04:58:36, haraken wrote:
> 
> DocumentLifecycleNotifier.h => DocumentLifecycleObserver.h

Done.

https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
Source/core/html/parser/HTMLDocumentParser.cpp:739: // TODO(oysteine): Disabled
due to crbug.com/398076 until a full fix can be implemented.
On 2015/01/16 04:58:36, haraken wrote:
> 
> TODO => FIXME

Done.

[kouhei (in TOK), 2015-01-16 05:41:36]

lgtm. Great work! Looking forward for perf improvements.

[oystein (OOO til 10th of July), 2015-01-17 00:50:55]

The CQ bit was checked by oysteine@chromium.org

[commit-bot: I haz the power, 2015-01-17 00:52:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/690793003/180001

[commit-bot: I haz the power, 2015-01-17 00:58:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-01-17 00:58:15]

Try jobs failed on following builders:
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/2...)

[oystein (OOO til 10th of July), 2015-01-17 01:40:11]

oysteine@chromium.org changed reviewers:
+ chrishtr@chromium.org

[oystein (OOO til 10th of July), 2015-01-17 01:40:12]

+chrishtr for public/

[chrishtr, 2015-01-17 01:40:39]

lgtm

[oystein (OOO til 10th of July), 2015-01-17 01:43:16]

On 2015/01/17 01:40:39, chrishtr wrote:
> lgtm

27 seconds latency; I'm impressed :).

Thanks!

[oystein (OOO til 10th of July), 2015-01-17 01:45:38]

The CQ bit was checked by oysteine@chromium.org

[commit-bot: I haz the power, 2015-01-17 01:45:56]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/690793003/180001

[commit-bot: I haz the power, 2015-01-17 03:00:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-01-17 03:00:34]

Try jobs failed on following builders:
  linux_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/4...)

[oystein (OOO til 10th of July), 2015-01-17 03:43:40]

The CQ bit was checked by oysteine@chromium.org

[commit-bot: I haz the power, 2015-01-17 03:44:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/690793003/200001

[commit-bot: I haz the power, 2015-01-17 04:58:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-01-17 04:58:24]

Try jobs failed on following builders:
  linux_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/4...)

[oystein (OOO til 10th of July), 2015-01-24 09:07:34]

The CQ bit was checked by oysteine@chromium.org

[commit-bot: I haz the power, 2015-01-24 09:08:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/690793003/200001

[commit-bot: I haz the power, 2015-01-24 10:27:47]

Committed patchset #7 (id:200001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=188925

[sof, 2015-01-24 15:56:35]

On 2015/01/16 04:58:36, haraken wrote:
> The DocumentLifecycleObserver part LGTM.
> 
>
https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
> File Source/core/html/parser/HTMLDocumentParser.cpp (right):
> 
>
https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
> Source/core/html/parser/HTMLDocumentParser.cpp:32: #include
> "core/dom/DocumentLifecycleNotifier.h"
> 
> DocumentLifecycleNotifier.h => DocumentLifecycleObserver.h
> 
>
https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
> Source/core/html/parser/HTMLDocumentParser.cpp:739: // TODO(oysteine):
Disabled
> due to crbug.com/398076 until a full fix can be implemented.
> 
> TODO => FIXME

This will require some amount of rework to be Oilpan-compatible --
DocumentLifecycleObserver is a GC mixin with Oilpan enabled, so passing out a
raw reference to something on the Oilpan heap is not going to work.

(Builds are currently breaking due to it.)

[sof, 2015-01-24 19:23:20]

On 2015/01/24 15:56:35, sof wrote:
> On 2015/01/16 04:58:36, haraken wrote:
> > The DocumentLifecycleObserver part LGTM.
> > 
> >
>
https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
> > File Source/core/html/parser/HTMLDocumentParser.cpp (right):
> > 
> >
>
https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
> > Source/core/html/parser/HTMLDocumentParser.cpp:32: #include
> > "core/dom/DocumentLifecycleNotifier.h"
> > 
> > DocumentLifecycleNotifier.h => DocumentLifecycleObserver.h
> > 
> >
>
https://codereview.chromium.org/690793003/diff/160001/Source/core/html/parser...
> > Source/core/html/parser/HTMLDocumentParser.cpp:739: // TODO(oysteine):
> Disabled
> > due to crbug.com/398076 until a full fix can be implemented.
> > 
> > TODO => FIXME
> 
> This will require some amount of rework to be Oilpan-compatible --
> DocumentLifecycleObserver is a GC mixin with Oilpan enabled, so passing out a
> raw reference to something on the Oilpan heap is not going to work.
> 
> (Builds are currently breaking due to it.)

Handling via https://codereview.chromium.org/863113004/