streamable.com - see bug description

[webcompat-bot]

URL: https://streamable.com/

Browser / Version: Firefox Mobile 62.0
Operating System: Android 8.0.0
Tested Another Browser: Yes

Problem type: Something else
Description: The upload doesn't start. The device is a Galaxy A5 2017.
Steps to Reproduce:

From webcompat.com with ❤️

[adamopenweb]

I can reproduce this issue in Firefox 62 for Android on a Pixel 2. In Firefox it just sits there, but Chrome the upload begins immediately.

Firefox

Chrome

[karlcow]

This is working with Firefox Desktop + RDM + Firefox Android UA.

bt.a.createElement("input", {
                        key: "fileInput",
                        type: "file",
                        multiple: !this.props.ios,
                        ref: "fileInput",
                        onChange: function() {
                            var e = t.refs.fileInput.files;
                            e.length && Object(Pt.e)(t.props.dispatch, e, t.props.group).then(function() {
                                t.formRef.reset()
                            })
                        }
                    })), bt.a.createElement("button", {
                        key: "uploadButton",
                        className: "blue-button",
                        onClick: function(e) {
                            e.preventDefault(), t.refs.fileInput.click()
                        }

@adamopenweb just to be sure
It seems indeed it never completed the upload. And if I access it tries to reload this page indefinitely https://streamable.com/8vpc5 which is quite bad for their server.

Back on track. There's a poll function which makes it harder to diagnose.

  // start polling
  setInterval(
    () => {
      store.dispatch(pollUploads())
    },
    5000,
  )

and

export function pollUploads() {
  return (dispatch, getState) => {
    const uploads = getUploads(getState())
    if (uploads.filter((v => !v.status || v.status < 2)).length) {
      fetch(`${process.env.REACT_APP_API_HOST}/poll`, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          Pragma: 'no-cache',
          'Cache-Control': 'no-cache',
        },
        body: JSON.stringify(uploads.map(v => v.shortcode)),
        credentials: 'include',
      })
      .then(response => response.json())
      .then((json) => {
        dispatch(createAction(FETCH_UPLOADS)(json))
      })
      .catch((error) => {
        console.log("ERROR fetching uploads")
      })
    }
  }
}

https://statics.streamable.com/static/node_modules/redux-actions/es/createAction.js

@wisniewskit Though I'm not sure why it fails on Firefox Android device.

[wisniewskit]

Doesn't happen in responsive design mode. I see this error in the console on a live device:

InvalidStateError: XMLHttpRequest state must be OPENED.    main.f0314024.js:1
n   video.js:44:4
r    retry.js:145

The line in question is:

xhr.send(task.data)

Based on the stack trace, it's likely that while re-trying, they are not re-opening the XMLHttpRequest before trying to re-send it. That would be site error. But why the XHR fails in the first place is even more interesting.

The POST request to upload the video to Streamable's transcoding server is never actually made, it is blocked by CORS:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://transcoder7.streamable.com/upload/js97a. (Reason: CORS request did not succeed).

Of course, now the question becomes why it's only blocked on Firefox on Android, and not desktop?

I see the same types of requests being made to the server on desktop and mobile:

XHR OPTIONS https://ajax.streamable.com/videos/1ymd5
XHR OPTIONS https://transcoder8.streamable.com/upload/1ymd5
XHR PATCH   https://ajax.streamable.com/videos/1ymd5
XHR POST    https://transcoder8.streamable.com/upload/1ymd5
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://transcoder8.streamable.com/upload/1ymd5. (Reason: CORS request did not succeed).
InvalidStateError: XMLHttpRequest state must be OPENED.

The only difference for me seems to be the precise transcoding server the request is made to, but all of them are returning the same OPTIONS headers (aside from the Date, of course):

Access-Control-Allow-Methods	GET,HEAD,PUT,PATCH,POST,DELETE
Access-Control-Allow-Origin	*
Connection			keep-alive
Date				Thu, 04 Oct 2018 16:02:00 GMT
Server				nginx
Vary				Access-Control-Request-Headers
X-Powered-By			Express

Also, the request headers being sent by both requests are essentially the same, aside from the user-agent:

Accept		*/*
Accept-Encoding	gzip, deflate, br
Accept-Language	en-US,en-CA;q=0.7,en;q=0.3
Connection	keep-alive
Content-Length	2498975
Content-Type	multipart/form-data; boundary=…13113184127859698641565678929
Host		transcoder8.streamable.com
Origin		https://streamable.com
Referer		https://streamable.com/
User-Agent	Mozilla/5.0 (Android 8.0.0; Mo…63.0) Gecko/63.0 Firefox/63.0

And when I change my mobile user-agent to a desktop browser UA, it is still blocked.

So I have no idea why the request is being blocked by CORS. @ckerschb, any clues here? Is there any way to get the precise reason why CORS rejected it?

[wisniewskit]

This still reproduces. I've filed bz-1533605 in the hopes of getting some clues.