928893 - Provide an API for processing DOM trees without blocking the main thread

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect, P5)

Description

[David Teller [:Yoric] - still alive but not very active]

The standard API for DOMParser is blocking and consumes strings. That's two reasons that make it ill-suited for main thread use, but a very good candidate for workers. Admittedly, there are very good reasons to not expose it to workers, but it would be great if we could have a DOMParser subset for workers.

Main application scenario: read document off the main thread, apply some pre-treatment (e.g. localization, validation, script sanitization, etc.), then pass the data in some efficient manner (yet to be determined) to the main thread for actual display.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

It's a terrible candidate for workers. None of the Node classes can be used off the main thread, so there's nothing useful for it to do in workers.

However, there was a suggestion from abarth recently to create a variant of parseFromString that return a promise. That seems more feasible, if people want to implement that.

Comment 2

[David Teller [:Yoric] - still alive but not very active]

(Note that I wrote *subset*, I'm aware that we won't have everything, far from it.)

While parseFromString with a promise would certainly be useful (provided the implementation is non-blocking), I would really want to apply any kind of pre-treatment to my document without blocking the main thread. This means doing it in a Web Worker, or something equivalent, perhaps a hidden sandboxed iframe – assuming that is non-blocking.

Comment 3

[Henri Sivonen (:hsivonen)]

(In reply to David Rajchenbach Teller [:Yoric] from comment #2)
> (Note that I wrote *subset*, I'm aware that we won't have everything, far
> from it.)

Well, the output of DOMParser is a DOM tree and those can't live in Workers, so it's pretty hard to have a subset.

If a subset means a second DOM implementation for Workers, then the part about passing the data to the main thread in an *efficient manner* becomes a problem.

> or something equivalent, perhaps a hidden
> sandboxed iframe

That's totally different.

> assuming that is non-blocking.

Does e10s allow sandboxed iframes to be in a separate process?

Comment 4

[Florian Quèze [:florian]]

(In reply to Henri Sivonen (:hsivonen) from comment #3)

> > or something equivalent, perhaps a hidden
> > sandboxed iframe
> 
> That's totally different.
> 
> > assuming that is non-blocking.
> 
> Does e10s allow sandboxed iframes to be in a separate process?

Setting the remote="true" attribute on an iframe will make e10s load it in a separate process. See http://hg.mozilla.org/mozilla-central/annotate/23c23b472a4f/toolkit/components/social/FrameWorker.jsm#l185 for an example in SocialAPI.

Comment 5

[David Teller [:Yoric] - still alive but not very active]

(In reply to Henri Sivonen (:hsivonen) from comment #3)
> (In reply to David Rajchenbach Teller [:Yoric] from comment #2)
> > (Note that I wrote *subset*, I'm aware that we won't have everything, far
> > from it.)
> 
> Well, the output of DOMParser is a DOM tree and those can't live in Workers,
> so it's pretty hard to have a subset.
> 
> If a subset means a second DOM implementation for Workers, then the part
> about passing the data to the main thread in an *efficient manner* becomes a
> problem.

Indeed. If the API is meant to be for pre-processing only, TypedObjects might possibly be useful.

> > or something equivalent, perhaps a hidden
> > sandboxed iframe
> 
> That's totally different.

You are right, this is totally different. Adapting the bug topic to I am concentrating on the feature ("I want to apply pre-processing to my DOM tree without causing reflows or otherwise blocking the UI"), rather than the implementation mechanism.

> 
> > assuming that is non-blocking.
> 
> Does e10s allow sandboxed iframes to be in a separate process?

I'll ask around.

Comment 6

[David Teller [:Yoric] - still alive but not very active]

(In reply to Florian Quèze [:florian] [:flo] from comment #4)
> > Does e10s allow sandboxed iframes to be in a separate process?
> 
> Setting the remote="true" attribute on an iframe will make e10s load it in a
> separate process. See
> http://hg.mozilla.org/mozilla-central/annotate/23c23b472a4f/toolkit/
> components/social/FrameWorker.jsm#l185 for an example in SocialAPI.

Apparently, that's not fully implemented yet - bug 879475.

Comment 7

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 8

[Henri Sivonen (:hsivonen)]

Seem unlikely that we'd add a browser-provided DOM-like thing for Workers that would provide enough value compared to such things implemented in pure JS.