WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#29602 closed defect (bug) (fixed)

Video uploads from the media modal and media-new.php are broken on iOS

Reported by: ryan Owned by: azaozz
Milestone: 4.1 Priority: normal
Severity: normal Version: 4.0
Component: Media Keywords: 2nd-opinion
Focuses: Cc:

Description

Video uploads from the media modal or media-new.php quietly noop on iOS devices.

http://make.wordpress.org/flow/2014/09/09/uploading-a-video-from-an-ios-device-wp-4-0-wp-ios-4-3/

Attachments (2)

slack_for_ios_upload.png (100.4 KB) - added by stephdau 5 years ago.
iOS 8 final against current trunk
29602.patch (1.5 KB) - added by azaozz 5 years ago.

Download all attachments as: .zip

Change History (41)

This ticket was mentioned in IRC in #wordpress-dev by rboren. View the logs.


5 years ago

#2 @azaozz
5 years ago

Confirmed. This is still the same old bug in iOS7 with <input type="file" multiple>. It was broken in iOS7.0, seemingly fixed in iOS 7.0.4, and broken again in 7.1.2??

Reduced test: http://jsfiddle.net/4BgFm/2/

So for 4.0.1 our choices are either to make it possible to upload videos or make it possible to upload multiple images.

A third choice is to have two upload buttons in iOS, one for images with multiple and another for videos without... That would need more changes (including UI), not sure it should be in a point release.

Currently can't test this in iOS8 (coming out in about a week), maybe apple has finally fixed this basic functionality bug there?

Last edited 5 years ago by azaozz (previous) (diff)

#4 @ryan
5 years ago

If iOS8 is busting multi-select again, then the choice is easier. Drop multi-select in favor of video. And with the iOS app not supporting video, the media modal should fill the video lack.

This ticket was mentioned in IRC in #wordpress-dev by MarkJaquith. View the logs.


5 years ago

#6 @thebrandonallen
5 years ago

I can confirm this as an issue on iOS 8 GM. On multi-select (media-new.php), videos error with "A problem occurred with this webpage so it was reloaded." For photos (single and multiple), they appear to be uploading, but ultimately end in "HTTP Error."

As far as the JSFiddle goes, each button allows you to select photos, and file sizes are correctly reported. For video, the multiple button results in the same "A problem occurred with this webpage so it was reloaded." The single button works and reports the correct file size.

#7 @azaozz
5 years ago

Thanks @thebrandonallen, that settles it. Going to revert [28847]. The other mobile browsers/OS still don't support multiple.

#8 @azaozz
5 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from new to closed

In 29729:

Media: revert enabling of multi-file uploading for mobile devices. Currently only iOS Safari supports it but has a bug that prevents uploading of videos. Fixes #29602

#9 @azaozz
5 years ago

  • Keywords needs-testing fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopen for 4.0.1.

Would be great if this is tested in iOS 8 GM before 4.0.1.

Last edited 5 years ago by azaozz (previous) (diff)

#10 @stephdau
5 years ago

Placed a lazyweb call, will upgrade an iPad tomorrow if needs be.

#11 @stephdau
5 years ago

So far I got a report of an HTTP error (iOS 8b5, getting log, unlikely to be the same), and a Safari crash report.

Guess I'm in for an iPad upgrade in the morning. :)

#13 @stephdau
5 years ago

So it's not boding very well for iOS 8 so far...

I had the user with the HTTP error mentioned above log in to a test instance of mine (trunk as of this morning), and although DreamHost didn't show me the details in the error_log, I did see a 500 on /wp-admin/async-upload.php at every upload attempt.

[glendronach]$ cat access.log | grep iPad | grep 500
[user IP] - - [11/Sep/2014:07:59:43 -0700] "POST /wp-admin/async-upload.php HTTP/1.1" 500 632 "http://trunk/wp-admin/post-new.php" "Mozilla/5.0 (iPad; CPU OS 8_0 like Mac OS X) AppleWebKit/600.1.3 (KHTML, like Gecko) Version/8.0 Mobile/12A4345d Safari/600.1.4" 
[user IP] - - [11/Sep/2014:08:08:14 -0700] "POST /wp-admin/async-upload.php HTTP/1.1" 500 632 "http://trunk/wp-admin/post-new.php" "Mozilla/5.0 (iPad; CPU OS 8_0 like Mac OS X) AppleWebKit/600.1.3 (KHTML, like Gecko) Version/8.0 Mobile/12A4345d Safari/600.1.4" 
[user IP] - - [11/Sep/2014:08:10:26 -0700] "POST /wp-admin/async-upload.php HTTP/1.1" 500 632 "http://trunk/wp-admin/post-new.php" "Mozilla/5.0 (iPad; CPU OS 8_0 like Mac OS X) AppleWebKit/600.1.3 (KHTML, like Gecko) Version/8.0 Mobile/12A4345d Safari/600.1.4" 

I, on the other hand, am totally fine uploading to the same instance from an iPad Mini running iOS 7.1.2, using either upload method, (no HTTP error).

In the process of wrangling in more dev/testers. Will follow up.

Last edited 5 years ago by stephdau (previous) (diff)

#14 @stephdau
5 years ago

Update, a 3rd tester is reporting what the 1st one was: "Safari crash".
From what I understand, the page "flashes", then reloads.
Trying to get a Safari Crash Report, or some Safari Mobile Console Output when linked via xcode/safari desktop.

Another strange iOS thing to mention: I had 2 users tell me they couldn't get to my test instance. Got a Safari "Server not found" error (with screenshots). Yet I could see them accessing the site in my access_log, then nothing. Again, iOS8 specific in my experience. DNS propagation fail wouldn't allow for log entries.

#15 @azaozz
5 years ago

This looks bad. 7.1.2 works well here too.

Don't think testing in other iOS browsers is necessary. As far as I know Apple doesn't allow other JS engines, so all iOS browsers use Safari under the hood (that's why there is no Firefox for iOS).

Thinking it's worth it trying the "browser uploader" from Media=>Add New screen to confirm whether this is a Plupload problem. Contacted the Plupload devs too.

#16 @thebrandonallen
5 years ago

@azaozz I've tested the browser uploader as well. They both fail. For photos and videos.

#17 @stephdau
5 years ago

I suspect the testers who got "the white flash" were not accessing instances that had the above fix, hence were getting the 4.0 behavior.

When accessing the latest trunk, that 3rd tester keeps getting HTTP timeout errors (408), with any video length (ven 2 seconds), but no report of them in the UI, just shows the list (media library).

[User IP] - - [11/Sep/2014:09:41:00 -0700] "POST /wp-admin/media-new.php HTTP/1.1" 408 402 "http://trunk/wp-admin/media-new.php" "Mozilla/5.0 (iPad; CPU OS 8_0 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12A365 Safari/600.1.4" 
[User IP] - - [11/Sep/2014:09:43:27 -0700] "POST /wp-admin/media-new.php HTTP/1.1" 408 402 "http://trunk/wp-admin/media-new.php" "Mozilla/5.0 (iPad; CPU OS 8_0 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12A365 Safari/600.1.4" 
[User IP] - - [11/Sep/2014:09:46:20 -0700] "POST /wp-admin/media-new.php HTTP/1.1" 408 402 "http://trunk/wp-admin/media-new.php" "Mozilla/5.0 (iPad; CPU OS 8_0 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12A365 Safari/600.1.4" 

From the tester, when inspecting in xcode:

I see the progress bar stall in the URL UITextField
and then I get a Request TImeout error page

Which sounds like Tester 2 iOS 8b5, but he was getting 500s (see above). iOS 8 GM is getting 408s. iOS 7.1.2 is all peachy.

Last edited 5 years ago by stephdau (previous) (diff)

#18 follow-up: @stephdau
5 years ago

Clarif: the 408s mentioned above were from the old-style browser uploader (/wp-admin/media-new.php, no error report in UI, 408 in log).

When using the newer style uploader from post-new or the top of the media lib, same tester gets the same HTTP Error in the UI as tester 2, and gets a 408 on /wp-admin/async-upload.php.

[User IP] - - [11/Sep/2014:10:09:45 -0700] "POST /wp-admin/async-upload.php HTTP/1.1" 408 402 "http://trunk/wp-admin/upload.php" "Mozilla/5.0 (iPad; CPU OS 8_0 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12A365 Safari/600.1.4" 

#19 in reply to: ↑ 18 @stephdau
5 years ago

One more clarif: tester 2 and 3 all got HTTP Errors, regardless of what WP 4 trunk instance they accessed, not just one (although I only have logs for one wp instance, cited above).

Last edited 5 years ago by stephdau (previous) (diff)

#20 @stephdau
5 years ago

Update:

  • I have some server side logging code, which I'll post result for when I get iOS 8 hits on my test instance (expecting later today).
  • We were provided with client side logs for the full upload, and all seems good on that end (except for the binary data, but we suspect the dev tool this was copied from just truncated the value. We shall see).

#21 @stephdau
5 years ago

PHP-level server-side logging, as the 1st line of _wp_handle_upload() is not triggered when posting from IOS8*, so that function is not even being entered...

#22 follow-up: @thebrandonallen
5 years ago

Finally had some time to dig into this. While [29729] does fix the "A problem occurred with this webpage so it was reloaded," that @stephdau, his testing helpers, and myself have seen, I'm not sure it's necessary.

I started by testing the iOS 8 simulator in the most recent Xcode beta, and there are absolutely no issues. Whether I'm on pre-[29729] trunk, or post. All photos and videos upload, and even multi-upload works without a hitch. So, obviously, it's not something I could debug in that manner.

After a further debugging, I had a hunch that something was wonky the POST request. From there I decided to route my hardware iOS 8 through Charles proxy to try and get some more data. Sure enough, a POST request is made to the server, but it's more or less empty. The server is supplied with a filename, and a content-type, but the file data isn't actually sent. This would explain the timeouts, as the server is waiting around for a file that never arrives, and eventually gives up.

Just to make sure it wasn't an issue specific to WP, I created a generic form, and was able to reproduce the issue there as well.

I've filed a bug report with Apple detailing the issue, and I'll keep this ticket up-to-date with anything I hear concerning the issue. Unfortunately, that leaves in wait-and-see mode, crossing our fingers that something changes by Wednesday.

#23 @stephdau
5 years ago

Thanks! Looking forward to hearing what Apple comes back with. :)

Last edited 5 years ago by stephdau (previous) (diff)

@stephdau
5 years ago

iOS 8 final against current trunk

#24 @stephdau
5 years ago

I don't run iOS myself, but I just had the opportunity to try a video upload on a friend's shiny new iPhone 6.

Tried to upload a 1 second video, but the process stayed stuck as attachment:slack_for_ios_upload.png shows (upload UX, no progress, no error).

Last edited 5 years ago by stephdau (previous) (diff)

#25 @azaozz
5 years ago

Yes, uploading with the web browser (which is locked to Safari/webview) was not fixed in iOS 8.0 final. Cannot upload anything even from a simple <input type="file">.

#26 in reply to: ↑ 22 @helen
5 years ago

Replying to thebrandonallen:

After a further debugging, I had a hunch that something was wonky the POST request. From there I decided to route my hardware iOS 8 through Charles proxy to try and get some more data. Sure enough, a POST request is made to the server, but it's more or less empty. The server is supplied with a filename, and a content-type, but the file data isn't actually sent. This would explain the timeouts, as the server is waiting around for a file that never arrives, and eventually gives up.

Looks like you are absolutely correct, thank you for digging in so thoroughly. Another report here: http://blog.uploadcare.com/post/97884147203/you-cannot-upload-files-to-a-server-using-mobile-safari

#27 @thebrandonallen
5 years ago

It's a known issue on their end. The bug report I submitted was closed as a dupe. However, Apple only let's you track reports you've submitted, so I don't know when a resolution will occur, or a possible workaround.

#28 @azaozz
5 years ago

  • Keywords commit added; needs-testing removed
  • Priority changed from highest omg bbq to normal
  • Severity changed from major to normal

Opened #29735 to continue tracking the iOS 8.0 broken uploads.

The original purpose of this ticket was to fix uploading of videos in iOS 7.x which works as expected now.

#29 follow-up: @ryan
5 years ago

From the 8.0.2 release notes: "Fixes a bug that prevented uploading photos and videos in Safari."

Has anyone checked this out with 8.0.2?

#30 in reply to: ↑ 29 @ocean90
5 years ago

Replying to ryan:

From the 8.0.2 release notes: "Fixes a bug that prevented uploading photos and videos in Safari."

Has anyone checked this out with 8.0.2?

See comment:ticket:29735:2.

#31 @azaozz
5 years ago

  • Keywords fixed-major commit removed

Confirmed multi-files uploading of videos works as expected in iOS 8.0.2.

Considering that nearly all devices that run iOS 7.x can (and probably will) be updated to 8.0.2, we should revert [29729] for trunk. That would disable selecting the camera as direct source, but we've agreed that support for uploading multiple files is a higher priority.

Last edited 5 years ago by azaozz (previous) (diff)

@azaozz
5 years ago

#32 @azaozz
5 years ago

Alternatively we can detect iOS 7.x and disable multi-file upload only there, 29602.patch.

#33 @azaozz
5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 29776:

Media: disable multi-file uploading in iOS 7.x Safari as it prevents uploading of videos. Fixes #29602 for trunk.

#34 @azaozz
5 years ago

  • Keywords fixed-major commit added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopen for 4.0.1

This ticket was mentioned in IRC in #wordpress-dev by rboren. View the logs.


5 years ago

#36 @nacin
5 years ago

  • Keywords 2nd-opinion added; fixed-major commit removed
  • Milestone changed from 4.0.1 to 4.1

Given how long it's taken us to get 4.0.1 out, with iOS 8.0.2 fixing this, I think I'm going to leave this as is for 4.0.1. I'm a bit concerned the currently-in-trunk checks have not been tested enough for us to backport and ship in a hurry.

Should we revert [29729] and [29776] in trunk?

#37 @azaozz
5 years ago

As far as I know iPhone 4 cannot be updated to iOS 8.x. Not sure how many are still in use but it would be good to keep the old uploader fix for them. The $_SERVER['HTTP_USER_AGENT'] tests are quite specific, but even if they fail the worst case scenario would be no multi-file upload in iOS 8 or no video upload in iOS 7 (same as reverting the above commits).

Last edited 5 years ago by azaozz (previous) (diff)

#38 follow-up: @DrewAPicture
5 years ago

@azaozz: So what's the status here? Sounds like maybe disabling video upload in IOS7, leaving IOS8 alone might be the way to go?

#39 in reply to: ↑ 38 @azaozz
5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to DrewAPicture:

Right, this is currently in trunk and works as expected as far as I see.

Note: See TracTickets for help on using tickets.