Opened 11 years ago
Closed 10 years ago
#29602 closed defect (bug) (fixed)
Video uploads from the media modal and media-new.php are broken on iOS
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (41)
This ticket was mentioned in IRC in #wordpress-dev by rboren. View the logs.
11 years ago
#3
@
11 years ago
This appears to be relevant (and not good news): https://stackoverflow.com/questions/25510711/ios-8-beta-5-safari-multiple-photo-upload
#4
@
11 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.
11 years ago
#6
@
11 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
@
11 years ago
Thanks @thebrandonallen, that settles it. Going to revert [28847]. The other mobile browsers/OS still don't support multiple
.
#8
@
11 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In 29729:
#9
@
11 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.
#10
@
11 years ago
Placed a lazyweb call, will upgrade an iPad tomorrow if needs be.
#11
@
11 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. :)
#12
@
11 years ago
s/Safari/WebKit/ : https://twitter.com/mcdev/status/509885457367568384
#13
@
11 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.
#14
@
11 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
@
11 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
@
11 years ago
@azaozz I've tested the browser uploader as well. They both fail. For photos and videos.
#17
@
11 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.
#18
follow-up:
↓ 19
@
11 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
@
11 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).
#20
@
11 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
@
11 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:
↓ 26
@
11 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.
#24
@
11 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).
#25
@
11 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
@
11 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
@
11 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
@
11 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:
↓ 30
@
11 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
@
11 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?
#31
@
11 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.
#32
@
11 years ago
Alternatively we can detect iOS 7.x and disable multi-file upload only there, 29602.patch.
#34
@
11 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.
11 years ago
#36
@
10 years ago
- Keywords 2nd-opinion added; fixed-major commit removed
- Milestone changed from 4.0.1 to 4.1
#37
@
10 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).
#38
follow-up:
↓ 39
@
10 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
@
10 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.
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?