Change History (35)

At the moment, the only platforms for which we deny _device_can_upload() is iOS, so no need for any kind of JavaScript check.

azaozz, georgestephanis, and I ​discussed this last night, but we couldn't come to a consensus on how to consistently identify all three iOS devices. It seems the iPod Touch does not include an OS #_# indicator in its user agent, and the iOS 6 dev preview doesn't update the user agents (they still read 5.1).

Because this is not a straightforward assumption, it will miss the boat for 3.4. However, we can likely ship a fix in 3.4.1 once we can nail this down.

I was suggesting a Javascript check since I think checking if the feature is available is way better than checking for a specific user-agent.
I've seen it just work with the embedded browser in the iOS app, which has a different user agent

We do a lot of things in PHP based on whether the device can upload, so a JS check is not really feasible without doing things like setting a cookie, etc. Much easier to just parse the user agent, given there *will* be obvious signs.

We do a lot of things in PHP based on whether the device can upload, so a JS check is not really feasible without doing things like setting a cookie, etc. Much easier to just parse the user agent, given there *will* be obvious signs.

I would suggest to use browser-based tests wherever possible. Keeping track of device capabilities using fixed sets of user agents becomes a challenge over the longer term.

Isn't this a bad practice? If the browser changes its user agent (in a future release or update), then the code needs to get update. This will open up another ticket and more time is wasted doing maintenance.

I don't have an idea about the features required for mobile uploads; but why don't you test if the required JavaScript functions do actually exist, and make a device/Os/browser agnostic solution?

There's a reason that we've always based this off User Agent -- not JS tests in the browser. That is, quite simply, because we have yet to see a browser test that works.

The typical method for spotting input type support is as follows ...

test = document.createElement( 'input' );

test.setAttribute( 'type', 'file' );

if ( test.type == 'file' ) {

document.write( 'This browser supports file inputs.' );

} else {

document.write( 'This browser does NOT support file inputs.' );

}

Now, if you run that in iOS, it will always return true and yield the first output, as it recognizes that file is a valid property for input type. They just choose not to let you do anything with it.

If you look at the patch that I submitted up above, it actually tests to get the iOS version number, and compares it against version 6 -- the first version that will actually let you use the file inputs. So it won't need to be maintained in the future, it'll just be an ifcheck against older versions of iOS that don't support file uploads. Also, if the UA changes in the future, then the first part of the ifcheck will fail, and it will display the upload option! We only really need to focus on catching the existing iOS < 6, as all future versions will support it.

If we wish to address this for 3.4.1, I suggest we slip in some user agent detection into _device_can_upload(). For 3.5, we should create a new API that uses cookies to pass client-based detection information back to the server.

@nacin, to that point, I'd be happy to contribute my work on user-agent detection. I'm attaching some early code that leverages Jon Stoppani's Browscap.php library. His licensing is current MIT Open Source. My wrapper (not yet quite pluginized, but easily done) adds a bunch of conditionals such as is_ie(), is_modern() or is_mobile(). The real work is done by Gary Keith and the Browser Capabilities Project team, which regularly update a large .ini file containing every user-agent string known to man, including obscure mobile microbrowsers etc. So it is completely independent of any server-side detection. The only caveat is that this is a reasonably large download, so it gets cached and then downloaded on a periodic basis. This mechanic can probably be improved.

Anyway, here's the code, just for an audit to determine the viability of including such detection capabilities natively in core. IMO, with the browser landscape becoming ever more complex, something like this will become more and more important for responsive device-aware design and development. I'm happy to continue to build out this project beyond a plugin if the team thinks it's warranted.

To clarify, for 3.5, we can move this to be client-side. I do prefer checking capabilities. We could really use a basic framework for JS-based capability checking that can then be set in a cookie for the rest of the session. This isn't the first time such a situation has come up. Can possibly piggyback on the existing user-settings bits.

Agree. Still need to be careful the JS based capability checks actually work for all devices and are not based on browser bugs, etc. Several of the mobile browsers "lie" about certain things, uploading is one.

Chatted with nacin on IRC. I think this is the most pragmatic fix at this point.

User Agent matching to "un-blacklist" iPhone, iPad and iPod UA strings running "OS 6_0" works for me. Moving forward it would be ideal to do some JS detection, but in this specific case it isn't necessary since it was a very specifically disabling iOS user agents.

Also per IRC, the regular expression will become #OS ([\d_]+) like Mac OS X#. The current 6.0 user agent that beaucollins had did not have U; in it. Since this expression is inside a block already checking for iOS devices (rather than 20923.diff​) we can get away with this change.