1109675 - Implement 'Request Desktop Site'

Status: VERIFIED FIXED

(Firefox for iOS :: Browser, defect)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Find out if we can do the 'Request Desktop Site' thing that Safari has.

(Assuming that is something we will want.)

Comment 1

[Aaron Raimist [:aaronraimist]]

Attachment: User agents from Safari and Chrome on iOS

It is possible. Placing the following code in AppDelegate will allow you to change the user agent. (I don't know if this is the best or only way)

NSUserDefaults.standardUserDefaults().registerDefaults(["UserAgent" : "Custom Agent"])

for example I can load the Facebook desktop site like this:

NSUserDefaults.standardUserDefaults().registerDefaults(["UserAgent" : "Macintosh; Max OS 10_10"])

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Aaron this is a good method to globally change the user agent. I'm not sure if it is the best way to go for Request Desktop Site though since we cannot do this per tab. Would you mind doing an experiment to see if we can change this value for individual WKWebView instances?

(In reply to Aaron Raimist [:aaronraimist] from comment #1)
> Created attachment 8539821 [details]
> User agents from Safari and Chrome on iOS
> 
> It is possible. Placing the following code in AppDelegate will allow you to
> change the user agent. (I don't know if this is the best or only way)
> 
> NSUserDefaults.standardUserDefaults().registerDefaults(["UserAgent" :
> "Custom Agent"])
> 
> for example I can load the Facebook desktop site like this:
> 
> NSUserDefaults.standardUserDefaults().registerDefaults(["UserAgent" :
> "Macintosh; Max OS 10_10"])

Comment 3

[Johannes Marbach]

Attachment: desktop-only.diff

Since this ticket is targeting iOS9, we could simply take advantage of WKWebView's customUserAgent property. The attached patch is meant as a prrof of concept and applies a custom user agent of "Macintosh; Max OS 10_10" to each newly created tab which forces all content to be loaded in the desktop representation.

Comment 4

[Johannes Marbach]

Are there any UI mocks for how to opt in and out of desktop mode?

Comment 5

[Aaron Train [:aaronmt]]

Comment on attachment 8681865 [details] [diff] [review]
desktop-only.diff

Just making sure some set of eyes sees this as I believe it's on a roadmap.

Comment 6

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Thank you Hennes. Please ask :bnicholson for a review. He has this feature on his personal roadmap but I am sure he would happily work with you if you are interested in taking this on.

Do know that we are still in the process of figuring out where the button should go. The UX team is experimenting with a place for 'tools' where things like Request Desktop Site and Find In Page can live.

So this bug may be on hold for a little while until we figure that part out.

Comment 7

[Brian Nicholson (:bnicholson)]

Comment on attachment 8681865 [details] [diff] [review]
desktop-only.diff

Hi Hennes,

When we last talked about this feature, I think the UX was to long-press the reload button to reload the current page with a desktop UA (what Safari does). I think the only visible UI was simply a small bar that floats right above the bottom toolbar that says "Request Desktop Site", which appears after the long press, and disappears when the user lets go. I think Darrin had mockups for this.

For now, a good start would be to simply implement this without any UI. That is, reload with the desktop UA after long-pressing the reload button, then reset the UA to mobile whenever the user navigates away from that page.

Comment 8

[Johannes Marbach]

Attachment: Pull request

Hi Brian,

Thanks a lot for the info. I got a basic version of what you described working in this pull request. I also have a few follow-up questions that I added in the comments of the pull request.

Comment 9

[Brian Nicholson (:bnicholson)]

Comment on attachment 8682082 [details] [review]
Pull request

Looking good! Left a few comments in the PR.

Comment 10

[Darrin Henein [:darrin]]

I think for now we want to just use a system action sheet, with one primary action ("Request Desktop Site" or "Request Mobile Site") and a system Cancel item. We lose the one gesture (long-press and then release) for two taps (long-press then tap sheet item) but I think this is fine for now.

Let me know if there are any questions.

Comment 11

[Johannes Marbach]

I added the action sheet toggling to the PR.

Comment 12

[Richard Newman [:rnewman]]

See also Bug 1222423, which is worth testing for our iOS implementation.

Comment 13

[Johannes Marbach]

(In reply to Richard Newman [:rnewman] from comment #12)
> See also Bug 1222423, which is worth testing for our iOS implementation.

I was actually already able to work this out with Brian's help. The web view gives us access to the initial unredirected URL of a page which we use for requesting the desktop (or mobile) presentation.

Comment 14

[Brian Nicholson (:bnicholson)]

Comment on attachment 8682082 [details] [review]
Pull request

This looks great...thanks for all your work so far! Left a few suggested cleanup comments in the PR, but I think this is about ready to land.

Comment 15

[Brian Nicholson (:bnicholson)]

Comment on attachment 8682082 [details] [review]
Pull request

Awesome, thanks a ton for the patch and all of the follow-up fixes! :)

Comment 16

[Brian Nicholson (:bnicholson)]

https://github.com/mozilla/firefox-ios/commit/47c076d002f2d15bd5a88c1e9305039b5f6485d8

Comment 17

[Aaron Train [:aaronmt]]

Tested via http://nytimes.com on iPhone/iPad

Comment 18

[Brian Nicholson (:bnicholson)]

v1.x: https://github.com/mozilla/firefox-ios/commit/09129e4737964e2836baf4d4c65514873ae3f2e4

Comment 19

[Brian Nicholson (:bnicholson)]

Backed out v1.x (7ed4b63) due to bug 1228547.

Comment 20

[Brian Nicholson (:bnicholson)]

Re-uplifted to v1.x: b4f1ab1e