903770 - Achieve parity with the main thread for DOM objects.

Status: RESOLVED FIXED

(Core :: DOM: Workers, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Hang things off this bug that are needed for the same DOM code to work on both the main thread and worker threads.

Comment 1

[David Bruant]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #0)
> Hang things off this bug that are needed for the same DOM code to work on
> both the main thread and worker threads.
Just to be sure I understand, does this mean it'll be possible to do something like:
    DOMImplementation.createHTMLDocument()
in a worker?

The WebWorker spec has been (overly!) restrictive on that topic so far:
"The DOM APIs — specifically, all the interfaces defined in the DOM specification other than exceptions — must not be exposed to JavaScript if the JavaScript global environment is a worker environment."
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#apis-available-to-workers

It'd be lovely if that changed :-)

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to David Bruant from comment #1)
> (In reply to Kyle Huey [:khuey] ([e-mail]) from comment #0)
> > Hang things off this bug that are needed for the same DOM code to work on
> > both the main thread and worker threads.
> Just to be sure I understand, does this mean it'll be possible to do
> something like:
>     DOMImplementation.createHTMLDocument()
> in a worker?

No.  I'm using DOM to mean "APIs exposed to webpages" here, not "nodes".  This bug is about getting the infrastructure in place to write implementations, not to implement specific features.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I'm going to declare victory here.