Bugzilla

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

Comment 1

•

8 years ago

Posted the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/prefixed-xmlhttprequest-response-types-will-be-removed/

Keywords: site-compat

Reporter

Updated

•

7 years ago

Depends on: 1335365

Yury Delendik (:yury)

Comment 2

•

7 years ago

The PDF.js project is using moz-chunked-arraybuffer a lot. There is no Fetch and Stream API alternative API yet AFAIK. Shall we block this on bug 1147061 or bug (if exists) that will implement Streams API support for fetch()?

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

Reporter

Updated

•

7 years ago

Blocks: xhr

Summary: Remove support for moz-prefixed XHR responseTypes → Remove support for moz-prefixed XHR responseTypes (moz-blob, moz-chunked-text, and moz-chunked-arraybuffer)

Olli Pettay [:smaug][bugs@pettay.fi]

Comment 4

•

7 years ago

https://developer.mozilla.org/nl/docs/Web/API/XMLHttpRequest does not (yet) indicate these are considered to be removed.

I'm doing server-push (long polling), and sending multiple parts of binary data by doing FCGX_FFlush() on the server and then handling the data on the XMLHttpRequest onprogress event in the client.
The remaining response types do not allow access to the received data, only indicate the number of bytes received. Is there a working alternative once the moz-prefixed types are removed?

Comment 5

•

7 years ago

MDN doesn't indicate that yet since we need first some telemetry data whether they can be removed
(bug 1335365).

Could you use WebSocket or EventSource?

(last time I looked at, fetch() wasn't too good for this)

Comment 6

•

7 years ago

I would love a more portable solution, but have not found one yet.
I looked into WebSockets, but then need to compile (and maintain) a patched version of lighttpd. EventSource is included in lighttpd but as far as I can see is not suitable for binary data.
(For completeness, I'm using the moz-chunked-arraybuffer type, and an FCGI C-program on the server.)

Anne (:annevk)

Comment 7

•

7 years ago

I think for moz-chunked-arraybuffer usage fetch() is actually what you want, but we'd need to implement and ship bug 1128959 first. Doing that before removal seems reasonable to me.

Comment 8

•

7 years ago

Will fetch() work when my C back-end is connected to the lighttpd webserver using FCGI on Linux? If these things are not clear yet, I may as well wait for support for webSockets in lighttpd.

Anne (:annevk)

Comment 9

•

7 years ago

fetch() is basically the new XMLHttpRequest, an API for doing HTTP requests and responses with some extras. And since your setup works with the latter, it'll work with fetch().

Comment 10

•

7 years ago

Thank you, that is very interesting and also looks more portable. I'll see if I can use fetch() instead.

Thomas Wisniewski

Updated

•

6 years ago

Depends on: 1397151

Thomas Wisniewski

Updated

•

6 years ago

Depends on: 1397145

Andrew McCreight [:mccr8]

Comment 11

•

6 years ago

Updated the site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2017/prefixed-xmlhttprequest-response-types-including-moz-blob-are-no-longer-supported/

Marion Daly [:mdaly]

Updated

•

5 years ago

Priority: -- → P3

Comment 12

•

5 years ago

A subtest of wpt/xhr/historical.html checks that moz-chunked-arraybuffer does not exist, and this fails, of course, only in Firefox.

Blocks: wpt.fyi-firefox-fails

David Burns :automatedtester

Updated

•

5 years ago

Keywords: parity-chrome, parity-safari

Nobody; OK to take it and work on it

Assignee

Comment 13

•

5 years ago

Yury, does PDF.js still need -moz-chunked-arraybuffer, now that ReadableStreams should be working? Should we try removing it now?

Flags: needinfo?(ydelendik)

Updated

•

5 years ago

Component: DOM → DOM: Core & HTML

Andrea Marchesini [:baku]

Assignee

Comment 14

•

5 years ago

baku, it seems that pdf.js is no longer a concern as far as removing platform support for -moz-chunked-arraybuffer (as per bug 1411865 comment 5). Did we know of any other reason to not try removing it, now that we support ReadableStreams?

Flags: needinfo?(ydelendik) → needinfo?(amarchesini)

Comment 15

•

5 years ago

(In reply to Thomas Wisniewski [:twisniewski] from comment #14)

baku, it seems that pdf.js is no longer a concern as far as removing platform support for -moz-chunked-arraybuffer (as per bug 1411865 comment 5). Did we know of any other reason to not try removing it, now that we support ReadableStreams?

No other reasons. I still see browser/extensions/pdfjs/content/PdfJsNetwork.jsm using moz-chunk-arraybufer here:
https://searchfox.org/mozilla-central/rev/56705678f5fc363be5e0237e1686f619b0d23009/browser/extensions/pdfjs/content/PdfJsNetwork.jsm#102

If this can be removed, we can remove the support for moz-chunk-arraybuffer.

Flags: needinfo?(amarchesini)

Assignee

Comment 16

•

5 years ago

In that case I suspect that we just need someone to review the patch on bug 1411865 so it can land.

Rob Wu [:robwu]

Comment 17

•

5 years ago

"moz-chunked-arraybuffer" usage is conditional on the onProgressiveData callback being set.
In mozilla-central this callback is never set: https://searchfox.org/mozilla-central/search?q=onProgressiveData&redirect=false

The callback is only set when used in the generic web version of PDF.js: https://github.com/mozilla/pdf.js/blob/9b5a937f78418ad6b114ca66d062cf2ae416d05f/src/display/network.js#L321-L322

So removing "moz-chunked-arraybuffer" will not affect the built-in PDF.js. At most it affects old PDF.js versions on the web that haven't been updated to use the streams API. In this case, the library will fall back to Range requests. Although not optimal, the basic functionality still works, so that shouldn't block the removal of this.

ExE Boss

Updated

•

5 years ago

Depends on: 1411865

Assignee

Comment 18

•

5 years ago

Attached file Bug 1120171 - remove support for XMLHttpRequest moz-chunked-arraybuffer response type; r?baku — Details

remove support for XMLHttpRequest moz-chunked-arraybuffer response type

Assignee

Comment 19

•

5 years ago

A try run seems fine: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0391a9b1bf367f6f78e8684438583e83cf5780f4

https://hg.mozilla.org/mozilla-central/rev/3ff9e491c530

Assignee

Updated

•

5 years ago

No longer depends on: 1411865

Comment 21

•

5 years ago

Pushed by twisniewski@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3ff9e491c530
remove support for XMLHttpRequest moz-chunked-arraybuffer response type; r=baku

Raul Gurzau (:RaulG)

Comment 22

•

5 years ago

bugherder

Status: NEW → RESOLVED

Closed: 5 years ago

status-firefox68: --- → fixed

Resolution: --- → FIXED

Target Milestone: --- → mozilla68

BugBot [:suhaib / :marco/ :calixte]

Updated

•

5 years ago

Assignee: nobody → twisniewski

Comment 23

•

4 years ago

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2019/xhr-moz-chunked-arraybuffer-response-type-is-no-longer-supported/

Rob Wu [:robwu]

Comment 24

•

4 years ago

The alternative to the functionality moz-chunked-arraybuffer is not arraybuffer, but using fetch and readable streams.

XMLHttpRequest + responseType = "moz-chunked-arraybuffer" offered the ability to receive the response in chunks (as an ArrayBuffer; other types are available as moz-chunked-text and moz-chunked-blob, but the latter are not documented on MDN).
XMLHttpRequest + responseType = "arraybuffer" offers the response as an ArrayBuffer, but only once the full request has been received.
fetch + readable streams offers the ability to read the response in chunks - see https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams#Consuming_a_fetch_as_a_stream

Could you update the webcompat article?

We should also update the "moz-chunked-arraybuffer" section of https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseType , to mention the deprecation and link to the alternative.

Flags: needinfo?(kohei.yoshino)