Request Desktop Site should support responsive design

RESOLVED DUPLICATE of bug 1106905

Status

()

RESOLVED DUPLICATE of bug 1106905
6 years ago
3 years ago

People

(Reporter: lmandel, Unassigned)

Tracking

15 Branch
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

The Request Desktop Site feature currently functions by switching the UA. This is effective on many sites but doesn't work with sites that follow the Mozilla best practice of using responsive design. I would like to see the Request Desktop Site feature support those sites that follow this best practices by changing the viewport or in some other way rendering a site that uses responsive design as a desktop (wide) site.
Can you give more explanation? I don't follow you. We should be using a 980px wide "viewport" for desktop sites.
Let me give a concrete example. 

http://www.hillsong.co.uk uses responsive design. Visiting the site in Fennec shows a nicely layed out mobile site. If I click the Request Desktop Site option, the same mobile site is shown. In this case, I would expect to see desktop view of this site. My request is that the Request Desktop Site feature somehow support showing the desktop site in this case.
I notice that the site uses a viewport meta tag, even in the desktop page:
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1">

I think we are doing the right in this case.
Isn't it expected that the site will serve the same content to any browser (desktop and mobile) but simply render according to the device characteristics? My point, is that sites like this do not render as they do on desktop when I select the Request Desktop Site option.
Desktop does not support <meta viewport>, but mobile does. You're asking that we turn off support for <meta viewport> when requesting a desktop site? I'm not sure that is the intent of the webpage. It's trying to be responsive to the device, regardless of mobile or desktop.
(In reply to Mark Finkle (:mfinkle) from comment #5)
> Desktop does not support <meta viewport>, but mobile does. You're asking
> that we turn off support for <meta viewport> when requesting a desktop site?
> I'm not sure that is the intent of the webpage. It's trying to be responsive
> to the device, regardless of mobile or desktop.

I agree. My understanding of the Request Desktop Site feature is that we're trying to force the desktop view. We currently do that for sites that are trying to be responsive to the device and serve mobile content based on the UA. It seems logical to me that we would also play a trick for sites that are trying to be responsive and serve mobile content via our recommended best practice of using responsive design.

But, let's take a step back and look at this from the user's perspective. As a user, I have opened http://www.hillsong.co.uk in my browser. I see that it serves a mobile site but want to view it as a desktop site. When I click on the Request Desktop Site option the site reloads but again renders as a mobile site. My expectation is that it should render as it does on my desktop.
(In reply to Lawrence Mandel [:lmandel] from comment #6)

> But, let's take a step back and look at this from the user's perspective. As
> a user, I have opened http://www.hillsong.co.uk in my browser. I see that it
> serves a mobile site but want to view it as a desktop site. When I click on
> the Request Desktop Site option the site reloads but again renders as a
> mobile site. My expectation is that it should render as it does on my
> desktop.

I understand, but the site itself wants its desktop site to adapt to a small screen. I think we should let it.
(In reply to Mark Finkle (:mfinkle) from comment #7)
> I understand, but the site itself wants its desktop site to adapt to a small
> screen. I think we should let it.

I think this is a subtle difference from the UA sniffing case that we currently support. I'm not sure our users will or should understand the difference in technology behind this function. The end goal as I see it should be to render a site as it would render on a desktop. A driving function of this request is to allow sites that follow our recommended best practice of using responsive design instead of UA sniffing to take advantage of this feature in our mobile browser.
Although I think it's great that we want to serve up the best experience possible for our user - and this should be done by default, which it seems like it is as exemplified in this case - if a user specifically requests the desktop site, then that's what we should be providing. They are actively wanting to pull down the desktop site, and if we continue to serve them what they already had when they first visited the page, they will get frustrated and think there's a problem with the browser.

My feeling is that because a user actively goes into the menu and selects to view the desktop site, then that's what we should be giving them in this case.
(In reply to Karen Rudnitski from comment #9)
> Although I think it's great that we want to serve up the best experience
> possible for our user - and this should be done by default, which it seems
> like it is as exemplified in this case - if a user specifically requests the
> desktop site, then that's what we should be providing. They are actively
> wanting to pull down the desktop site, and if we continue to serve them what
> they already had when they first visited the page, they will get frustrated
> and think there's a problem with the browser.
> 
> My feeling is that because a user actively goes into the menu and selects to
> view the desktop site, then that's what we should be giving them in this
> case.

First: People are making an assumption that "Request Desktop Site" can reliably, always convince the web content provide to send down the actual desktop content. It's can't. We have several bugs on that already and we know the system is not foolproof. The platform is not designed to allow a single tab (<browser>) masquerade as a desktop browser.

Second: Responsive web sites are designed to handle whatever screensize is available. The content and the browser are doing the right thing. The UX of a true desktop site displayed on a phone-sized screen is poor at best.

Third: Request Desktop Site (RDS) is a hack. A crutch to support sending down meaningful content when otherwise the site would send down weak, watered down content that does not take advantage of the capabilities of the browser. Our main goal is getting rich, full content that takes advantage of the available screensize. RDS is a crutch for times when you get a WAP page on your phone or a phone page on your tablet.

IMO, RDS should not be seen as a way to create a mirror of desktop pages. If that is the real intent, I'll file bugs to remove it or lessen it's role as a feature. RDS the wrong direction.
I strongly agree with the points Mark has made in this bug.

Comment 12

6 years ago
If there is an option called "Request Desktop Site", the browser absolutely should do its best to display a desktop version of the site when that option is selected. It is incredibly frustrating to have this option available if it actually means "try to display the desktop version of the site unless we think the designer of the site is trying to provide rich, full content in the mobile view--we really like the idea of responsive design, so we won't take the action you requested and just reload the exact same version of the site".

Whether "Request Desktop Site" should have the effect the user expects is entirely orthogonal to whether or not it should be displayed as a top-level menu feature. The feature makes no sense and is likely to be increasingly frustrating if it does not force the browser to ignore any <meta name="viewport"> content. If the user has actively selected that option for a site, the absolute worst result is the exact same site being loaded.

I was becoming annoyed with this behavior as an end user, but I'm increasingly annoyed by it while I'm creating my first responsive design and trying to ensure users who want the desktop site can get it. Not only does the "Request Desktop Site" option not give the user a desktop viewport into the site I'm designing, but as a designer, I can't figure out a way to give the user what she's requesting through the option!
Hi, I agree with what Mark said, RDS is a hack and should let responsive design do the "magic". However, I understand user frustration to expect a result and loose its time reloading the same page. Here is my proposition:

Why don’t we just turn off the Request Desktop site button when we are in a Responsive Design page (or when we know we can't display a desktop site)? I think it’s the simplest solution to keep RDS feature, let Responsive Design do its job and avoid frustration. You probably already thought about it, but I can't find any bug related.

My 2 cents

Comment 14

5 years ago
If you're coding a site and want to offer this, you should be able to do this with a cookie that allows you to recognize that the user agent string is changing.  Here's a really simple snippet that would react to chrome/android's "request desktop site" change (which removes the "android" part of the user agent string). Sure, it's user agent sniffing... but it's responding to specific cases of user-agent fakery, so it's basically appropriate, imho.  You'd have to modify it to work with each specific browser/ua switch.

        (function(d){
            function C(k){return(d.cookie.match('(^|; )'+k+'=([^;]*)')||0)[2]}

            var ua = navigator.userAgent.toLowerCase(),
                android = /android/i.test(ua),
                wasmobile = C('wasmobile') === "was",
                ismobile  = android;

                if(ismobile){
                    d.cookie = "wasmobile=was";
                }
                else if (wasmobile){
                    d.getElementsByName('viewport')[0].setAttribute('content','user-scalable=yes, maximum-scale=2');

                }
        }(document));

Comment 15

5 years ago
Actual working version: 

(function(d){
    function C(k){return(d.cookie.match('(^|; )'+k+'=([^;]*)')||0)[2];}

    var ua = navigator.userAgent.toLowerCase(),
        android = /android/i.test(ua),
        wasmobile = C('wasmobile') === "was",
        ismobile  = android;

    if(ismobile && !wasmobile){
        d.cookie = "wasmobile=was";
    }
    else if (!ismobile && wasmobile){
        d.getElementsByName('viewport')[0].setAttribute('content','user-scalable=yes, maximum-scale=2');
    }
}(document));

Comment 16

4 years ago
Its not the function that is incorrect but the label of the menu option. Its not clearly a Request Desktop Site but Request Full Content.
Looks like my request (or close enough to it) was fixed in bug 1106905.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1106905
You need to log in before you can comment on or make changes to this bug.