Last Comment Bug 757284 - Issues with (large?) uploads stopping halfway (youtube, mediafire)
: Issues with (large?) uploads stopping halfway (youtube, mediafire)
: regression, reproducible
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 13 Branch
: x86 Mac OS X
: -- normal with 1 vote (vote)
: ---
Assigned To: Kyle Huey [:khuey] (
Depends on: 961804
Blocks: 725289
  Show dependency treegraph
Reported: 2012-05-21 17:13 PDT by [:Cww]
Modified: 2014-01-20 10:00 PST (History)
16 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Restore mozSlice, with a warning (for trunk) (6.31 KB, patch)
2012-05-24 11:11 PDT, Kyle Huey [:khuey] (
jonas: review+
Details | Diff | Splinter Review
Patch for beta (5.76 KB, patch)
2012-05-24 15:16 PDT, Kyle Huey [:khuey] (
jonas: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description [:Cww] 2012-05-21 17:13:58 PDT
From input:

It looks like uploads aren't working or stopping part way. Seems to be larger files(?) and 13 only.  Possibly not reliably reproducible. << mediafire << mediafire << shutterfly

And a lot of youtube:

And some facebook:

UNCO pending QA.
Comment 1 juan becerra [:juanb] 2012-05-22 13:32:15 PDT
On Mac 10.7.x from two different locations, 300mb+ upload, on Youtube, Vimeo, Smugmug:

- Fx12: Works
- Chrome: Works
- Fx13b1-4: Stops at 33% on Youtube, reproducible all the time.
- Fx15 and it also stops at 33% on Youtube

Using a 100mb+ file on

- Fx12: works
- Fx13b4: never initiates the upload, it just stays at "Queued"
Comment 2 Patrick McManus [:mcmanus] 2012-05-22 15:14:22 PDT
yumm.. I'll take a look and try and repro to see what's happening tonight or tomorrow.
Comment 3 Patrick McManus [:mcmanus] 2012-05-22 18:54:07 PDT
interesting the case is hijacking http 308 for a non-redirect purpose. I thought we heard that was over?

but its not the cause of this bug, as the new 308 handling isn't included until FF14 and I don't think it would have any impact without the location header anyhow

2082469632[7f0a8de27030]: http response [
2082469632[7f0a8de27030]:   HTTP/1.1 308 Resume Incomplete
2082469632[7f0a8de27030]:   Server: HTTP Upload Server Built on May 16 2012 12:03:24 (1337195004)
2082469632[7f0a8de27030]:   Content-Type: text/html; charset=utf-8
2082469632[7f0a8de27030]:   Access-Control-Allow-Origin:
2082469632[7f0a8de27030]:   Access-Control-Expose-Headers: Range, X-Range-MD5, Location, X-GUploader-Stats-URL
2082469632[7f0a8de27030]:   Access-Control-Allow-Credentials: true
2082469632[7f0a8de27030]:   Range: bytes=0-104857599
2082469632[7f0a8de27030]:   X-Range-MD5: 9e2ebb06c114ba0f5ca24812a6ee83af
2082469632[7f0a8de27030]:   Date: Wed, 23 May 2012 01:40:08 GMT
2082469632[7f0a8de27030]:   Pragma: no-cache
2082469632[7f0a8de27030]:   Expires: Fri, 01 Jan 1990 00:00:00 GMT
2082469632[7f0a8de27030]:   Cache-Control: no-cache, no-store, must-revalidate
2082469632[7f0a8de27030]:   Content-Length: 720
2082469632[7f0a8de27030]: ]
Comment 4 Julian Reschke 2012-05-23 00:21:35 PDT
The change we *did* in FF 13 with respect to redirects was 598304 (which changed method rewriting).

Would be good to have traces of both succeeding and failing uploads.
Comment 5 Patrick McManus [:mcmanus] 2012-05-23 05:55:18 PDT
(In reply to Julian Reschke from comment #4)
> The change we *did* in FF 13 with respect to redirects was 598304 (which
> changed method rewriting).

Thanks.. I made a build with that reverted we still failed the mediafire test (that's the one I'm using to bisect as its faster).. so probly not that.
Comment 6 Patrick McManus [:mcmanus] 2012-05-23 08:28:15 PDT
I've bisected this to be driven from bug 725289 - which changes nsIDOMFile::mozSlice to be nsIDOMFile::slice.. presumably the affected sites are using that API.

it repros with either mediafire or youtube, but testing is easier with mediafire because you can use any size document and the free personal account they offer. My youtube test is 163MB and it stalls around the 100MB mark.
Comment 7 Kyle Huey [:khuey] ( 2012-05-24 11:11:09 PDT
Created attachment 626888 [details] [diff] [review]
Restore mozSlice, with a warning (for trunk)
Comment 8 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-05-24 11:23:05 PDT
Comment 9 Kyle Huey [:khuey] ( 2012-05-24 15:16:20 PDT
Created attachment 626990 [details] [diff] [review]
Patch for beta
Comment 10 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-05-24 15:32:20 PDT
Juan, since you were able to reproduce this earlier, can you please check the Feb 16th and 18th Nightly builds? That would at least confirm comment 6. Thanks
Comment 11 Alex Keybl [:akeybl] 2012-05-24 15:38:13 PDT
This is one of our two most critical FF13 issues. Although code freeze is 5/25, we can land a confirmed fix on Monday prior to the go to build (if we want to get testing on m-c first).
Comment 12 juan becerra [:juanb] 2012-05-24 16:26:13 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #10)
> Juan, since you were able to reproduce this earlier, can you please check
> the Feb 16th and 18th Nightly builds? That would at least confirm comment 6.
> Thanks

I tested with

20120216031231: Works
20120218031156: Does not work

However I also tried mediafire and both worked.
Comment 13 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-05-24 16:43:37 PDT
Thanks Juan. I'm thinking that at least confirms Patrick's suspicion of bug 725289 and qualifies qawanted. Alex et al, please re-add the keyword if there is more QA can test around this. I'm suspecting at this point we just need to wait for and test a fix though.
Comment 14 Alex Keybl [:akeybl] 2012-05-25 12:31:40 PDT
Comment on attachment 626990 [details] [diff] [review]
Patch for beta

[Triage Comment]
Pre-approving for Beta. We'll back this out if any regressions are found.
Comment 15 Kyle Huey [:khuey] ( 2012-05-28 00:57:30 PDT
Comment 16 Kyle Huey [:khuey] ( 2012-05-28 01:01:40 PDT
Comment 17 Kyle Huey [:khuey] ( 2012-05-28 01:03:07 PDT
Comment on attachment 626990 [details] [diff] [review]
Patch for beta

We should get this in on aurora too after it's confirmed it works

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 725289
User impact if declined: Uploads to various things may break
Testing completed (on m-c, etc.): TBD
Risk to taking this patch (and alternatives if risky): Low risk
String or UUID changes made by this patch: None (uses a separate interface)
Comment 18 :Ms2ger (⌚ UTC+1/+2) 2012-05-28 03:45:06 PDT
Comment on attachment 626888 [details] [diff] [review]
Restore mozSlice, with a warning (for trunk)

Review of attachment 626888 [details] [diff] [review]:

::: content/base/src/nsDOMFile.cpp
@@ +250,5 @@
> +    nsCOMPtr<nsPIDOMWindow> window = do_QueryInterface(sgo);
> +    if (window) {
> +      nsCOMPtr<nsIDocument> document =
> +        do_QueryInterface(window->GetExtantDocument());
> +      if (document) {

window->GetExtantDoc() would have saved you a QI, fwiw.
Comment 19 Kyle Huey [:khuey] ( 2012-05-28 12:14:47 PDT
Why on earth do we have a GetExtantDoc and a GetExtantDocument?
Comment 20 Masatoshi Kimura [:emk] 2012-05-28 23:45:02 PDT
GetExtantDoc has been added by bug 756381 very recently for optimization.
Comment 21 Mihaela Velimiroviciu (:mihaelav) 2012-05-31 04:57:04 PDT
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0 (beta 6)

Verified the fix on above build: successfully uploded 900+ MB video on Youtube and Facebook (the video was removed after upload for being too long) and ~114MB video on Mediafire.

Marking verifioed for Firefox 13
Comment 22 Lukas Blakk [:lsblakk] use ?needinfo 2012-06-03 12:02:00 PDT
[Triage Comment]
Reminder that the merge day is tomorrow afternoon PT, so please land this to Aurora (14) before then.
Comment 23 Jonas Sicking (:sicking) PTO Until July 5th 2012-06-04 00:53:15 PDT
Comment 24 Jonas Sicking (:sicking) PTO Until July 5th 2012-06-04 01:54:16 PDT
Actually, the patch failed to build so I had to back it out. Seemed like a #include issue.
Comment 25 Kyle Huey [:khuey] ( 2012-06-04 11:30:01 PDT
Comment 26 Lukas Blakk [:lsblakk] use ?needinfo 2012-06-04 14:12:58 PDT
looks like the flag got reset, setting it back to 'fixed'.
Comment 27 Vlad [QA] 2012-06-12 06:22:14 PDT
I've verified this on;
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20100101 Firefox/14.0 beta 6 (build2)

Upload was performed without stopping or lagging on Youtube and also facebook using a file that had more than 900MB.

Setting the flag to Verified on Firefox 14.
Comment 28 Vlad [QA] 2012-07-23 02:21:14 PDT
I've verified this on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0 beta 1

The upload on youtube and facebook was made without any issues.

Setting the flag to Verified.

Note You need to log in before you can comment on or make changes to this bug.