Closed Bug 717562 Opened 8 years ago Closed 5 months ago
Search service should use async XHR instead of DOMParser::parse
nsIDOMParser::parseFromStream needs to go away in order to unblock an XML code path rewrite and in any case chrome code shouldn't be doing synchronous IO on the main thread. Please migrate toolkit/components/search/nsSearchService.js to use asynchronous XHR instead of nsIDOMParser.
The search service currently depends on sync IO to fulfill API promises. Bug 699856 (or its followup bugs) is going to try to address that. If you need to unblock bug 717561 before that lands, we can consider moving to Sync XHR, I guess, but I'd like to avoid that.
Sync XHR is worse than nsIDOMParser::parseFromStream. It doesn't make sense to move to sync XHR even as an intermediate step. Let's make this one wait for bug 699856 then.
Depends on: jsonSearchSvc
Assignee: nobody → dteller
Whiteboard: [Snappy] → [Snappy:P2]
I actually had a prototype of the search service using XHR in some parts. Once bug 699856 + followups have landed, I will get to work on this.
I actually had a prototype of the search service using XHR in some parts. Once bug 699856 + followups have landed, I will get to work on generalizing this.
No time to work on this.
Assignee: dteller → nobody
I don't mind helping with this, if it's worth converting parseFromStream over to a sync XHR. Or is it possible to make these parts async while we're at it? From what I gather it doesn't look like it...
Well, as per comment 2, sync XHR is not a good idea. So if you want to make it async, that would be nicer.
2 years ago
Depends on: 1405671
Summary: Search service should use async XHR instead of nsIDOMParser::parseFromStream → Search service should use async XHR instead of DOMParser::parseFromStream
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.