Closed Bug 1383518 Opened 7 years ago Closed 7 years ago

Uploading thumbnails to YouTube, picture to Tweakers.net not working on Firefox 55+

Categories

(Core :: DOM: Core & HTML, defect, P1)

56 Branch
x86_64
Windows 10
defect

Tracking

()

VERIFIED FIXED
mozilla57
Tracking Status
firefox-esr52 --- unaffected
firefox55 blocking verified
firefox56 + verified
firefox57 --- verified

People

(Reporter: davidhollegien, Assigned: asuth)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, regression, site-compat)

Attachments

(4 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170720101431

Steps to reproduce:

1. Login to Tweakers.net
2. go to https://tweakers.net/my.tnet/fotoalbum/ ("karma" or subscription needed, dutch website.)
3. Select a picture to upload
4. Fill in title
4. Hit upload


Actual results:

No response, a post to the server is visible in the web console network tab.

A warning about the encoding is visible console view.


Expected results:

The file to be uploaded to tweakers.net, testing this with the latest stable version works (54 branch), also works in the latest Chrome.

see https://gathering.tweakers.net/forum/list_message/51998885#51998885 for bug report at Tweakers side (dutch)
OS: Unspecified → Windows 10
Hardware: Unspecified → x86
Summary: Uploading picture to Tweakers.net not working in Developer Edition. → Uploading picture to Tweakers.net not working in Developer Edition (55 branch)
Hardware: x86 → x86_64
The console warning was added in Bug 708620 so it's not new. Needs a regression range.
Component: Untriaged → HTML: Form Submission
Product: Firefox → Core
(In reply to davidhollegien from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0)
> Gecko/20100101 Firefox/55.0
> Build ID: 20170720101431
> 
> Steps to reproduce:
> 
> 1. Login to Tweakers.net
> 2. go to https://tweakers.net/my.tnet/fotoalbum/ ("karma" or subscription
> needed, dutch website.)
> 3. Select a picture to upload
> 4. Fill in title
> 4. Hit upload
> 
> 
> Actual results:
> 
> No response, a post to the server is visible in the web console network tab.
> 
> A warning about the encoding is visible console view.
> 
> 
> Expected results:
> 
> The file to be uploaded to tweakers.net, testing this with the latest stable
> version works (54 branch), also works in the latest Chrome.
> 
> see https://gathering.tweakers.net/forum/list_message/51998885#51998885 for
> bug report at Tweakers side (dutch)

Hi!
Would you please help us get where this was regressed from by the mozregression tool [1]? Thank you :)

[1] http://mozilla.github.io/mozregression/
Flags: needinfo?(davidhollegien)
(In reply to Hsin-Yi Tsai (55 Regression Engineering support) [:hsinyi] from comment #2)
> (In reply to davidhollegien from comment #0)
> > User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0)
> > Gecko/20100101 Firefox/55.0
> > Build ID: 20170720101431
> > 
> > Steps to reproduce:
> > 
> > 1. Login to Tweakers.net
> > 2. go to https://tweakers.net/my.tnet/fotoalbum/ ("karma" or subscription
> > needed, dutch website.)
> > 3. Select a picture to upload
> > 4. Fill in title
> > 4. Hit upload
> > 
> > 
> > Actual results:
> > 
> > No response, a post to the server is visible in the web console network tab.
> > 
> > A warning about the encoding is visible console view.
> > 
> > 
> > Expected results:
> > 
> > The file to be uploaded to tweakers.net, testing this with the latest stable
> > version works (54 branch), also works in the latest Chrome.
> > 
> > see https://gathering.tweakers.net/forum/list_message/51998885#51998885 for
> > bug report at Tweakers side (dutch)
> 
> Hi!
> Would you please help us get where this was regressed from by the
> mozregression tool [1]? Thank you :)
> 
> [1] http://mozilla.github.io/mozregression/
Hi,

I used the linked tool to find the commit which caused the regression:

2017-07-24T18:49:53: INFO : Narrowed inbound regression window from [c35f0ad3, 1426ecc8] (3 revisions) to [c35f0ad3, cf6065f6] (2 revisions) (~1 steps left)
2017-07-24T18:49:53: DEBUG : Starting merge handling...
2017-07-24T18:49:53: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=cf6065f64f9a8aef42144e7938c9c1aec92d8677&full=1
2017-07-24T18:49:53: DEBUG : Found commit message:
Bug 1359172 - RemoteInputStream must create a correct inputStream when used and sliced in a separate process, r=smaug

2017-07-24T18:49:53: INFO : The bisection is done.
2017-07-24T18:49:53: INFO : Stopped
Flags: needinfo?(davidhollegien)
Thanks for finding the offending commit!

baku, seems like a regression from bug 1359172.
Assignee: nobody → amarchesini
Blocks: 1359172
Flags: needinfo?(amarchesini)
Priority: -- → P1
Hi, I need help. How can I upload images? It seems that I need to have a "good" karma. How can I obtain it immediately?
I created an account: "bakutest".
Flags: needinfo?(amarchesini) → needinfo?(davidhollegien)
> baku, seems like a regression from bug 1359172.

It's not. that commit is about PBlob. Beta doesn't have PBlob code anymore.
Probably the issue is somewhere else in IPCBlob. I'll debugging as soon as I'm able to upload images on that website.
(In reply to Andrea Marchesini [:baku] from comment #5)
> Hi, I need help. How can I upload images? It seems that I need to have a
> "good" karma. How can I obtain it immediately?
> I created an account: "bakutest".

Hi, An developer of the website just gave you a two month subscription so that you can use the feature.
Flags: needinfo?(davidhollegien)
Thanks a lot!
I did some tests. I am able to upload images using FF54, FF55 and FF56.
I'm not able to reproduce this bug yet.

I'm using a translator to follow the conversation on the form. Is this message related?
"edit:// Dit bleek allemaal het probleem van mijn antivirus te zijn, sorry! [...]"

The warning you see in the console log is about the form encoding of the page. The page forces an ISO-8856-15 charset and this doesn't support all the unicode chars. This could be a problem for the encoding, but it's not for the image upload. These 2 issues are not related. Probably the website should use UTF-8 as charset.
Flags: needinfo?(davidhollegien)
(In reply to Andrea Marchesini [:baku] from comment #9)
> I did some tests. I am able to upload images using FF54, FF55 and FF56.
> I'm not able to reproduce this bug yet.

I just tried it again with the latest beta (55.0b12), still not working.

Anything i can do to help you?

> I'm using a translator to follow the conversation on the form. Is this
> message related?
> "edit:// Dit bleek allemaal het probleem van mijn antivirus te zijn, sorry!
> [...]"
No, that is an unrelated post of an other user which couldn't upload because its anti-virus was blocking it.
Flags: needinfo?(davidhollegien)
Flags: needinfo?(amarchesini)
Wondering if this is a platform specific issue or the encoding warning is a real problem.
Andrew, can you please check this with somebody else? (I'll be away for the next 3 weeks I would like to see this bug fix asap).
Currently, all my tests are happening on linux.

David, thanks for you time! I have other questions:

1. Can you please check this bug on a different platform? Mac or linux for instance?
2. How big is your image? Is it bigger than 1mb?
Flags: needinfo?(overholt)
Flags: needinfo?(davidhollegien)
Flags: needinfo?(amarchesini)
Andrew knows about blobs, right?
Flags: needinfo?(overholt) → needinfo?(bugmail)
(In reply to Andrea Marchesini [:baku] (PTO until 21st of August) from comment #11)
> Wondering if this is a platform specific issue or the encoding warning is a
> real problem.
> Andrew, can you please check this with somebody else? (I'll be away for the
> next 3 weeks I would like to see this bug fix asap).
> Currently, all my tests are happening on linux.
> 
> David, thanks for you time! I have other questions:
> 
> 1. Can you please check this bug on a different platform? Mac or linux for
> instance?
I just tried this on an Ubuntu 16.04 VM, upload works in firefox 54, not working (like on windows) on firefox 55b13.


> 2. How big is your image? Is it bigger than 1mb?
I have been testing with an image with the a size of about 20kb.
Flags: needinfo?(davidhollegien)
Because of the account issue (I created "asuthtest" since I don't know baku's creds, but I ran into the same karma deficiency).  I went looking for webcompat bugs.  I found https://webcompat.com/issues/8286 that covers failing to upload a YouTube thumbnail, which I was able to reproduce.

For the youtube thumbnail upload case, the scenario seems to be a somewhat complicated dance to use a FORM element as an async AJAX post.  (Things are made somewhat harder by the logic being closure compiled.)  Specifically, if I'm reading things right and using our devtools correctly:
- A <form> element is dynamically created "around" the <input type="file"> that got the click and selected a file to upload.
- That form element is importNode(,deep=true)d into a dynamically created iframe whose target is yet another sub-iframe, triggered via a call to its submit().  All of this happens inside the outer global inside the click handler.

I'm going to reproduce under rr now and see what's happening under the hood.
Assignee: amarchesini → bugmail
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bugmail)
Summary: Uploading picture to Tweakers.net not working in Developer Edition (55 branch) → Uploading thumbnails to youtube, picture to Tweakers.net not working in Developer Edition (55 branch)
(In reply to Andrew Sutherland [:asuth] from comment #14)
> Because of the account issue (I created "asuthtest" since I don't know
> baku's creds, but I ran into the same karma deficiency).
An developer of the site has also given your account an two month subscription so you can use the feature.
I just tried this again with the latest beta ("56.0b2"), the issue is still there.
Version: 55 Branch → 56 Branch
I'm sorry about the delays, looking into this has taken more time than expected and we had an even more serious places regression on the recently released 55 that I had to focus on.  I expect to finish investigating this and hopefully have a fix up by very late Sunday, US east-coast time.
I am here to confirm this bug still exists. 
I can not upload Thumbnails to YouTube-Videos.
I believe the crux of the problem ends up being this:
- IPCBlobInputStream::{Read,ReadSegments} can return NS_BASE_STREAM_WOULD_BLOCK when mState is eInit or ePending.
- NS_AsyncCopy can only handle NS_BASE_STREAM_WOULD_BLOCK if the source stream QI's to nsIAsyncInputStream.
  - If it doesn't QI, and it gets that error, it will (in this case) close the source and sink streams.
  - If it had QI'd, it would have done an AsyncWait() and everything would have been fine.
- mUploadStream is an nsMIMEInputStream which does not QI to nsIAsyncInputStream and also does not implement nsICloneableInputStream
- nsMIMEInputStream is wrapping an nsMultiplexStream whose children are:
  - nsStringInputStream
  - nsBufferedInputStream whose underlying stream is a IPCBlobInputStream in the eInit state
  - nsStringInputStream
- If you call HttpBaseChannel::EnsureUploadStreamIsCloneable and NS_InputStreamIsCloneable(mUploadStream) does not return true, as is the case for the nsMIMEInputStream, it'll create a new nsStorageStream using NS_NewStorageStream, invoke NS_AsyncCopy to copy the contents over, then replace mUploadStream with that stream.

This gets somewhat more interesting because youtube.com has a ServiceWorker registered whose mHandlesFetch is mozilla::dom::workers::ServiceWorkerInfo::Disabled, but we ServiceWorkerManager::DispatchFetchEvent anyways, which results in calling HttpBaseChannel::EnsureUploadStreamIsCloneable which does the above NS_AsyncCopy and replaces the old mUploadStream with the new stream, and it also breaks.

I'm still investigating, but I don't know when :baku wakes up, so I figure a progress update is in order.

This attachment is a fancy pretty print of HttpBaseChannel::EnsureUploadStreamIsCloneable prior to the storage stream being created and everything breaking.  I've also enclosed the verbose fancy backtrace.
Okay, yeah, that's what's happening.  YouTube's non-fetch-handling ServiceWorker helps us win a race to break the upload stream[1].  After interception resets, we're left with an mUploadStream that's an nsStorageInputStream with underlying nsStorageStream with mLogicalLength=164.  As expected, this is exactly the length of the first nsStringInputStream child of the nsMIMEInputStream.  However, our channel's mRequestHead's mHeaders has a "Content-Length" of "86208", so the POST is doomed.

I'm going to create a reproducing test case now and then look at uplift-friendly mitigations/fixes.

1: The fact that we don't want to intercept fetch doesn't help.  ServiceWorkerPrivate::SendFetchEvent is where we fast-path reset the interception `if (!mInfo->HandlesFetch())`.  That happens only after/as a reslt of EnsureUploadStreamIsCloneable completing (or being bypassed).  (And ServiceWorkerManager.cpp's ContinueDispatchFetchEventRunnable::Run() never gets to call SendFetchEvent() because it immediately falls into the NS_FAILED(status) check above that diverts to ContinueDispatchFetchEventRunnable::HandleError() which invokes nsIInterceptedChannel::ResetInterception()).
[Tracking Requested - why for this release]: A site compatibility regression in Firefox 55. There is also a separate upload regression, see Bug 1392580.
Depends on: 1392580
No longer depends on: 1392580
I have already seen some people complaining they can't upload thumbnails on YouTube. And YouTube is apparently asking them to use Chrome. Needs a fix ASAP.

https://twitter.com/search?f=tweets&q=youtube+thumbnail+upload
Severity: normal → critical
Summary: Uploading thumbnails to youtube, picture to Tweakers.net not working in Developer Edition (55 branch) → Uploading thumbnails to YouTube, picture to Tweakers.net not working on Firefox 55+
Track 56+ as site compatibility regression.
Thank you for mentioning that a service worker can trigger this bug, Andrew Sutherland!

As a temporary workaround, we now disable our service worker (and hence push notifications, but for us these are less important than a working file upload) in Firefox 55:

if (/Firefox\/55/.test(navigator.userAgent)) {
    navigator.serviceWorker.ready.then(function(serviceWorkerRegistration) {
        serviceWorkerRegistration.unregister();
    });
} else {
    navigator.serviceWorker.register('/service-worker.js');
}

Another possible workaround could be to upload files using XmlHttpRequest to send a File object wrapped inside a FormData object (at least the file upload in our CMS backend uses this method and seems to be unaffected).
I should have mentioned that with "we" I was referring to https://www.computerbase.de/ (not Tweakers.net or YouTube). I reported Bug 1392580 which has been marked as a duplicatae.
This test had trailing whitespace in a number of places, including one spot
inside a <textarea> that explicitly had a test expectation against it.

Since it's popular to have text editors purge trailing whitespace, this patch
converts the one significant piece of trailing whitespace to use an HTML
entity to encode a trailing ASCII space character.  This keeps that test happy.
This test causes the expected serviceworker failure messages in the child
process and then hangs the test.
Okay, the fix for this is pretty shallow and just a variation on bug 1361443 which converted nsMultiplexInputStream to conditionally implement nsIAsyncInputStream.  We just need to make nsMIMEInputStream conditionally implement nsIAsyncInputStream too.  Doing that now.
This test causes the expected serviceworker failure messages in the child
process and then hangs the test.
Attachment #8900202 - Flags: review?(bkelly)
NS_AsyncCopy aborts if it receives an NS_BASE_STREAM_WOULD_BLOCK error result
during copying and it is unable to QI the source stream to an
nsIAsyncInputStream.  IPCBlobInputStream can return this, especially if it's:
- A freshly created aggregate stream as part of form submission of a type=file
  where the Blob will come from the parent because of the file picker but the
  stream is being uploaded from the child.
- A ServiceWorker is involved, causing
  HttpBaseChannel::EnsureUploadStreamIsCloneable to trigger an NS_AsyncCopy
  very early in the process.

IPCBlobInputStream implements nsIAsyncInputStream, and nsMultiplexInputStream
does too (conditionally based on its child streams; if any are async, it takes
step to uniformly expose async behavior).  However, due to lack of sufficient
test coverage, nsMIMEInputStream did not get fixed as part of bug 1361443 when
nsMultiplexInputStream gained its nsIAsyncInputStream powers.  We address that
here in the same fashion.

Part 1 of this series addresses the test coverage issue.
Attachment #8900203 - Flags: review?(bkelly)
Attachment #8900161 - Attachment is obsolete: true
Comment on attachment 8900160 [details] [diff] [review]
Part 0: Test whitespace cleanup

:baku, you're probably a more appropriate reviewer for these, but I'm confused as to your offline schedule currently.  Please feel free to steal the reviews from :bkelly and/or iterate on the patches, etc. etc. etc.
Flags: needinfo?(amarchesini)
Attachment #8900160 - Flags: review?(bkelly)
In local testing, I've confirmed that with an 08/21 nightly I fail to upload a thumbnail to youtube and a picture to tweakers.net[1].  With my local build with the fix, I am able to upload a thumbnail to youtube and a picture to tweakers.net.  So I believe this should all be good to go if the try builds don't explode.

1: After enabling push notifications from the UI so that a ServiceWorker gets installed.  Until this is done, there are no ServiceWorkers and so there are no problems.
Status: NEW → ASSIGNED
Updates to firefox 55 for release users is paused for now so we can first get this fixed in a dot release.
Attachment #8900160 - Flags: review?(bkelly) → review+
Comment on attachment 8900203 [details] [diff] [review]
Part 2: nsMIMEInputStream should conditionally implement nsIAsyncInputStream

Review of attachment 8900203 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/base/nsMIMEInputStream.cpp
@@ +78,4 @@
>    NS_INTERFACE_MAP_ENTRY(nsISeekableStream)
>    NS_INTERFACE_MAP_ENTRY_CONDITIONAL(nsIIPCSerializableInputStream,
>                                       IsIPCSerializable())
> +  NS_INTERFACE_MAP_ENTRY_CONDITIONAL(nsIAsyncInputStream,

Wow.  I was not aware conditional QI was a thing we had.
Attachment #8900203 - Flags: review?(bkelly) → review+
Comment on attachment 8900202 [details] [diff] [review]
Part 1: Augment test_formSubmission.html test to include ServiceWorker variants

Review of attachment 8900202 [details] [diff] [review]:
-----------------------------------------------------------------

Only skimmed this.  Mostly rs+.
Attachment #8900202 - Flags: review?(bkelly) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/139bd07e900499a065e82a77c9aaa3816952f942
Bug 1383518 - Part 2: nsMIMEInputStream should conditionally implement nsIAsyncInputStream. r=bkelly

https://hg.mozilla.org/integration/mozilla-inbound/rev/20463f9b06cba70fbefc62c4df42fbeceab81784
Bug 1383518 - Part 0: Test whitespace cleanup. r=bkelly

https://hg.mozilla.org/integration/mozilla-inbound/rev/cd327f7195845af9a3335d7d48bf3d9ec8228615
Bug 1383518 - Part 1: Augment test_formSubmission.html test to include ServiceWorker variants. r=bkelly
Here's where we are:

## Trunk, Firefox 57
Just landed on inbound. Try builds are available for testing at:
https://archive.mozilla.org/pub/firefox/try-builds/bugmail@asutherland.org-e53ead091aae57a177b9945fc7541aa78879abf4/

## Release, Firefox 55
The patches graft cleanly (with 1 automatic mochitest.ini merge) onto the Firefox release branch.
I've pushed a try build of this to https://treeherder.mozilla.org/#/jobs?repo=try&revision=df13578d54e776287c72acb63142b09d6ae6ba3e (as automatically posted in comment 40)
Try builds will show up for testing at:
https://archive.mozilla.org/pub/firefox/try-builds/bugmail@asutherland.org-bc8fc6d6f2921693d54b5583e09441b7e48e3bc7/

## How to test
### Automatic
Yes, we've got automated tests!  Specifically, you can run the following test:
  mach mochitest dom/html/test/test_formSubmission.html
That test will be automatically run by CI, so this is just for local testing.  Note that when running a single test, you will have to close Firefox yourself afterwards.

### Manual Testing
#### Components if you want to re-create it yourself and are not lazy like me
- Be using e10s.
- Have a ServiceWorker registered on some domain.  The cases tracked in this bug were ServiceWorkers registered exclusively for push notifications and do not register a "fetch" listener, but any ServiceWorker that does not intercept form submissions should be enough to trigger the bug.  (A ServiceWorker that does intercept will see truncated payload too, but if it doesn't try and consume it, it might not notice.)
- Submit a multipart-encoded form POST where one of the components is an input with type=file (type=image may also work).
- Witness the POST hands or the serve receives truncated data, something like that.

#### Specific site testing:
##### YouTube
- Be using e10s.
- Have a YouTube account that's been confirmed via text message so that you're allowed to upload alternate thumbnails.
- Have one or more uploaded videos.  It's fine for them to be private.
- Edit the video, probably by going to the "Creator Studio" "Video Manager" "Videos" options and click the video's "Edit" button to the right of the thumbnail.  The URL for this page for me on a single-logged-in-Google account is https://www.youtube.com/my_videos?o=U
- The resulting video edit page URL looks like https://www.youtube.com/edit?o=U&video_id=AAAAAAAAAAAA where the A's are your video's unique id.
- To the right of the video should be 3 or 4 thumbnails.  If you didn't upload a custom thumbnail, there will be 3 with a form button below them to upload a video.  If you already uploaded a custom thumbnail, the custom thumbnail will be the bottom/4th one, and hovering over it should offer 2 links, "Download image" and "Change image".  "Change image" or the form button are what you should select, then find some image to upload.
- The spinner should show up.  In the failure case, the spinner spins forever and/or displays a red error message about JSON.  In the success case, your new thumbnail should show up.
- If you test the failure case and then switch to a fixed build, you will want to refresh the YouTube page by hitting enter in the URL bar to make sure there's no leftover error state for the page persisted in the sessionstore.  In my test repro, I had to do this otherwise I got the red error string saying something about JSON.

##### Tweakers.net
Don't test this unless you already have a tweakers.net account in good standing that has the photo library privilege.  New accounts don't have this.  Also, the UI is not in English.  If you have an account, as mentioned in comment 35, you need to enable browser notifications to test.  Reload the page by hitting "enter" in the URL bar after enabling.  Then try and upload a picture.
Flags: needinfo?(amarchesini)
Comment on attachment 8900203 [details] [diff] [review]
Part 2: nsMIMEInputStream should conditionally implement nsIAsyncInputStream

Approval Request Comment
[Feature/Bug causing the regression]:
PBlob's replacement with IPCBlob.

[User impact if declined]:
"Multipart" forms with type=file/image will fail to correctly submit under e10s when the form's action is covered by a registered ServiceWorker scope, even if the ServiceWorker does not listen for "fetch" events to intercept them.

Sites using ServiceWorkers only for push notifications are most likely to suffer from this, because it's very likely for the ServiceWorker to be registered with a very inclusive scope.

[Is this code covered by automated tests?]:
Yes!  Part 0 and Part 1 improve our automated testing coverage to trigger this bug.  I don't know how to set approval flags on multiple patches at once, so I would suggest plus'ing them both along this one.

[Has the fix been verified in Nightly?]:
I have verified it locally and a try push was happy.  I have also locally verified on a patched Firefox 55 build.

[Needs manual test from QE? If yes, steps to reproduce]: 
It does seem prudent to follow the steps described in comment 42 for the youtube case, yes.

[List of other uplifts needed for the feature/fix]:
Again, I would suggest taking the tests in part 0 and part 1.  I would suggest landing in the sequence "part 2, part 0, part 1" for bisection-friendliness.

[Is the change risky?]:
No.  I did express some concern in earlier comments, but it turns out the fix is highly localized and this was just an edge-case that didn't have sufficient test coverage.

[Why is the change risky/not risky?]:
The change is just about plumbing nsIAsyncInputStream through the mime-wrapping input stream.  Since we only conditionally QI to nsIAsyncInputStream if the unlderying stream QI's, our behavior is really only changed in cases where we previously would have broken.

[String changes made/needed]:
No string changes made.
Attachment #8900203 - Flags: approval-mozilla-release?
Attachment #8900203 - Flags: approval-mozilla-beta?
Test case in bug report #1393063 (https://bugzilla.mozilla.org/show_bug.cgi?id=1393063) that was marked duplicate of this bug earlier today, was not fixed by the Firefox 55 try build above.

It certainly sounds like the same bug, except in my case there are no service workers, just XHR request sending FormData that has couple of Blobs.
(In reply to Andrew Sutherland [:asuth] from comment #42)
> ## Release, Firefox 55
> The patches graft cleanly (with 1 automatic mochitest.ini merge) onto the
> Firefox release branch.
> I've pushed a try build of this to
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=df13578d54e776287c72acb63142b09d6ae6ba3e (as
> automatically posted in comment 40)
> Try builds will show up for testing at:
> https://archive.mozilla.org/pub/firefox/try-builds/bugmail@asutherland.org-
> bc8fc6d6f2921693d54b5583e09441b7e48e3bc7/

I just verified that we this build the issue with the tweakers.net upload is fixed.
(In reply to MiikaH from comment #44)
> Test case in bug report #1393063
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1393063) that was marked
> duplicate of this bug earlier today, was not fixed by the Firefox 55 try
> build above.

Thanks for trying out the build!  I've reopened that bug and will investigate.  Moving the bug to see also for now.
See Also: → 1393063
(In reply to davidhollegien from comment #45)
> I just verified that we this build the issue with the tweakers.net upload is
> fixed.

And thank you as well, David!  Both for testing this and your early reporting of the problem and persistence in facilitating investigation and making sure things were moving forward on the bug.  Efforts such as yours and MiikaH's are invaluable in our collective efforts to improve Firefox.

(And I do want to say that although Firefox 55 and the elimination of the aurora release stage has been more than a little bumpy, part of the reason we've had so many hiccups/glitches is that Firefox is undergoing some of the most transformative and exciting technological advancements it's ever had.  That's a little marketing-speaky, but I do want to emphasize that the future is bright, although we clearly have catch-up to do in terms of automated testing technical debt and debugging technical debt as well as the implementation technical debt we're paying down.)
Comment on attachment 8900203 [details] [diff] [review]
Part 2: nsMIMEInputStream should conditionally implement nsIAsyncInputStream

let's take this in 55.0.3 and 56.0b6
Attachment #8900203 - Flags: approval-mozilla-release?
Attachment #8900203 - Flags: approval-mozilla-release+
Attachment #8900203 - Flags: approval-mozilla-beta?
Attachment #8900203 - Flags: approval-mozilla-beta+
Attachment #8900160 - Flags: approval-mozilla-release+
Attachment #8900160 - Flags: approval-mozilla-beta+
Attachment #8900202 - Flags: approval-mozilla-release+
Attachment #8900202 - Flags: approval-mozilla-beta+
Flags: qe-verify+
I have managed to reproduce the issue described in comment 42 (by following the YouTube repro steps) using an affected Firefox 56.0a1 (BuildId:20170723030206) build.

I have verified that this issue is no longer reproducible using Firefox 57.0a1 (BuildId:20170824100243), 56.0b6 (BuildId:20170825011442) and 55.0.3 (BuildId:20170824053622) on Windows 10 64bit, macOS 10.12 and Ubuntu 16.04 64bit.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.