nsXMLHttpRequest::Send defeats DEFER_OPEN optimization for file streams by calling Available on the main thread

NEW
Unassigned

Status

()

Core
DOM
6 years ago
2 months ago

People

(Reporter: khuey, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Snappy:P2])

XHR.send calls Available on the postdata stream, and if the page does xhr.send(file) that results in statting the file on the main thread.
I think the solution is to have XHR get the size from the File object, and then handle the sync i/o problems in the DOM file code.
Blocks: 711887

Updated

6 years ago
Whiteboard: [Snappy] → [Snappy:P2]
Is this for the nsIInputStream case here:

http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#2500

?  I don't see where you're suggesting to get the file object from.  It looks like the stream is always opened before providing it to send().
Flags: needinfo?(khuey)
I don't know if this bug is still relevant.  This code has changed a lot in the last 15 months.
Flags: needinfo?(khuey)

Comment 4

5 years ago
GetResponseBody for an nsIInputStream still calls Available on the main thread.
(Assignee)

Updated

5 years ago
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core

Comment 5

2 months ago
Is this still relevant? I see no reference to Available() in dom/xhr anymore, and dom/fetch seems to only call Available() in FetchStream::OnInputStreamReady.
Flags: needinfo?(josh)

Comment 6

2 months ago
There's a call to Available in https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/HttpBaseChannel.cpp#1017 which is invoked from InitiateFech (https://dxr.mozilla.org/mozilla-central/rev/7e962631ba4298bcefa571008661983d77c3e652/dom/xhr/XMLHttpRequestMainThread.cpp#2631). It's not clear to me whether that actually invokes the kind of behaviour that we are concerned about, though.
Flags: needinfo?(josh)
You need to log in before you can comment on or make changes to this bug.