This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14086 - When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting that to a representation usable by the javascript application can result in freezes to t
Summary: When performing AJAX type queries, they are already asynchronous and already ...
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Web Workers (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement
Target Milestone: ---
Assignee: contributor
QA Contact: public-webapps-bugzilla
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
: 14093 14116 14137 14138 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-09-08 14:41 UTC by contributor
Modified: 2014-10-02 18:52 UTC (History)
10 users (show)

See Also:

Attachments

Description contributor 2011-09-08 14:41:49 UTC 
Specification: http://www.w3.org/TR/2011/WD-workers-20110901/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
When performing AJAX type queries, they are already asynchronous and already
occur in another thread.  However, I have found that parsing the XML reply and
converting that to a representation usable by the javascript application can
result in freezes to the GUI for large amounts of data.  When I tried to put
the processing of the AJAX reply in a web worker (I tried to put the XML
processing and marshaling to javascript amenable format in a web worker), I
found that the web worker could not use the DOM Parser and the javascript data
assembled by the web worker had to be converted to a string to be pushed back
via a message to the main thread.  So web workers do not appear to solve what
appears to be a fairly common problem - a delay processing alot of XML data
from the server.  The ability to assemble data in a handy format in one thread
and then give it to the main thread, without incurring a time penalty to
essentially recreate the data in the main thread, would be nice to have.  It
appears what we have now are multiple processes rather than threads (no data
sharing).  Why not modify the core javascript language to add threads?	(Like
C++0x or Java).  Why can't the web workers use an XML parser?

Posted from: 199.89.158.132
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Comment 1 Michael Hanson 2011-09-08 16:03:53 UTC 
This issue came up on the list in January 2011; here is a pointer to the thread: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg59

A short summary of the conversation is:
* DOMParser implementations may not be (and in most cases, are definitely not) thread safe today.
* There are features of the DOMParser that cannot easily be placed into a web worker (loading of external DTDs being a major one)
* Implementors are encouraged to experiment with pure-JS parser implementations to see what works and to provide feedback.

(Not expressing a Mozilla opinion here - just summarizing list activity to keep the pointers alive)
Comment 2 Simon Pieters 2011-09-08 20:06:15 UTC 
Seems to me like this use case is asking for async parsing APIs.
Comment 3 Simon Pieters 2011-09-13 12:19:18 UTC 
*** Bug 14137 has been marked as a duplicate of this bug. ***
Comment 4 Simon Pieters 2011-09-13 12:19:24 UTC 
*** Bug 14138 has been marked as a duplicate of this bug. ***
Comment 5 Simon Pieters 2011-09-13 12:19:29 UTC 
*** Bug 14116 has been marked as a duplicate of this bug. ***
Comment 6 Simon Pieters 2011-09-13 12:19:36 UTC 
*** Bug 14093 has been marked as a duplicate of this bug. ***
Comment 7 Jonas Sicking (Not reading bugmail) 2011-09-13 18:05:24 UTC 
I don't think this is a question of async or not, but a question of DOM or not.

It's been well established that we can't expose a DOM in workers. What we could do however is a SAX-based API. We could either create a async one that somehow ties in to XHR, or we could do a sync one which takes a string and synchronously calls callbacks.
Comment 8 Travis Leithead [MSFT] 2011-09-28 01:12:08 UTC 
Would you expect some new type of parser for Web Workers to be done in a separate spec? Such a feature could be useful for non-worker scenarios as well...
Comment 9 Ian 'Hixie' Hickson 2011-10-18 20:22:02 UTC 
I'd highly recommend just using JSON instead of XML, personally.
Comment 10 Arthur Barstow 2011-11-11 19:04:33 UTC 
I asked the following questions about this bug in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0831.html 

What, if anything, should we do with this bug?

Given it is marked as an "enhancement", does anyone consider this mandatory to address before publishing a LC? If yes, what is your proposed resolution?

Would anyone object to moving to LC/CR with this bug open?
Comment 11 Travis Leithead [MSFT] 2011-11-11 20:43:20 UTC 
I think this is a feature request. It appears to be a request for a Web Worker-friendly SAX-like XML parser. I don't believe this is something that we should try to add to the current spec.

I'd resolve this to "next version" (or equivalent) and pursue the idea in that forum. I certainly think it's a worthwhile idea to pursue.
Comment 12 David Levin 2011-11-11 21:19:15 UTC 
(In reply to comment #11)
> I think this is a feature request. It appears to be a request for a Web
> Worker-friendly SAX-like XML parser. I don't believe this is something that we
> should try to add to the current spec.

Agreed that it makes sense to not do this in the current spec and discuss later. (I work on Web Workers in Chromium.)
Comment 13 Arthur Barstow 2011-11-21 13:49:34 UTC 
Jonas, Simon, Michael, Hixie - would you please provide your feedback on whether this bug should block movement to Recommendation?
Comment 14 Ian 'Hixie' Hickson 2011-12-03 03:41:27 UTC 
I would vote for WONTFIX. I don't think this is a feature we should ever provide.
Comment 15 Ian 'Hixie' Hickson 2012-04-26 22:38:44 UTC 
Marking WONTFIX as per last comment. See comment 9.
Comment 16 brunoais 2014-10-02 17:51:52 UTC 
I'd like to revive this bug and ask for a minor alternative that might be possible and OK to go for.

The idea is to allow passing document fragments to worker threads (document fragments only).

The main idea is that, sometimes, a large amount of changes or analysis are required to be made to the DOM.

By allowing sending a fragment to a worker thread, the overhead required to translate all the DOM send into an analyzable format.
You may even require
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode
Or some work adapting the content to the worker. As long as that is made in the other thread, there's no issue on my end.

The requirements for my use-case are:

 --- Having a nearly complete document DOM --- 
This document is not connected to any interface. In other words, it acts the same way as a documentFragment towards everything (heck, it can even be an actual documentFragment, if possible).
Any changes to it only changes that DOM tree inside the worker thread.

 --- You can pass DOM objects ---
A passed DOM object is read-only on the destination until
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode
is called.
OR
Passing a DOM is made by cloning it to the document that resides in the worker thread. The result of that clone is equivalent of passing it through the importNode() method.
(I prefer the 2nd one)

If this is enabled, when the parsing work on the js side is more complicated, it may be sent to the worker thread to deal with the specifics and still have tree-like operations with Nodes that look like the interface's DOM.
Comment 17 brunoais 2014-10-02 18:00:52 UTC 
Just to keep it clear:

This is still no memory sharing, just memory transfer.
Comment 18 Anne 2014-10-02 18:12:18 UTC 
1) You're citing an obsolete version of the DOM which is not helping yoru case.

2) The DOM is not exposed in workers and won't be for the foreseeable future.

3) You should not reopen very old bugs. It's better to file a new bug with new data (not old spec links).
Comment 19 brunoais 2014-10-02 18:52:49 UTC 
I'll open a new bug