Opened on 10/01/2015 at 03:06:36 PM

Last modified on 02/24/2016 at 09:47:14 AM

#3149 new change

[Adblock Browser for iOS] Feature request: Request Desktop Site

Reported by: sven Assignee:
Priority: Unknown Milestone:
Module: Adblock-Browser-for-iOS Keywords:
Cc: jand, philll, pavelz, mario, lisabielik Blocked By:
Blocking: Platform: Adblock Browser for iOS
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by sven)


If you're requesting a website, the mobile version of the website will be displayed, but sometimes you want to see the desktop version of this website.

What to change

Create a method which shows users the desktop version of a website, after it was requested. To request it, users need to click the Adblock Browser logo and in a second step, the new menu item "Request Desktop Site". This will close the menu and will reload the desktop version of this website in the same tab.

Attachments (3)

adblock browser iOS 57 quickmenu 1.png (142.0 KB) - added by sven on 10/01/2015 at 03:06:43 PM.
requestdesktopsiteicon 1.png (19.2 KB) - added by sven on 10/01/2015 at 03:06:49 PM.
Ticket_3149.png (11.7 KB) - added by lisabielik on 10/08/2015 at 03:05:05 PM.

Download all attachments as: .zip

Change History (16)

Changed on 10/01/2015 at 03:06:43 PM by sven

Changed on 10/01/2015 at 03:06:49 PM by sven

comment:1 Changed on 10/01/2015 at 03:08:07 PM by sven

  • Cc jand added
  • Description modified (diff)

comment:2 Changed on 10/01/2015 at 03:21:26 PM by sven

  • Description modified (diff)

comment:3 Changed on 10/05/2015 at 09:55:30 AM by Shikitita

  • Summary changed from Feature: Request Desktop Site to [Adblock Browser for iOS] Feature request: Request Desktop Site

comment:4 Changed on 10/06/2015 at 08:31:06 AM by pavelz

  • Cc philll added

A word of caution: this is going to have questionable results. It works reliably only on sites which declare <link rel="canonical">, like amazon, yelp, or Many high profile sites don't, i just tried There, the best we can do is to hack the User-Agent request header and cross fingers. Even when it works, it has a major UX drawback: the User Agent cannot be changed for an already running tab with an existing history. A new tab must be created. I did a quick check with Dolphin and it seems to be doing that. Nothing happens right when you ask for a desktop version, and only the newly created tab is displaying desktop versions of all subsequently loaded sites. Safari apparently, according to the internets, used to have desktop switch in iOS8, but i could not find it in iOS9. Opera and Mercury offer simply the UA change, cowardly not even linking it to the desired desktop effect. Chrome seems to be hooking only on the <link> because it retains the tab and its history, but it does display the mobile version again, more often than not.

I am open for examples of how 3rd party browsers are correctly handling the desktop version request, with an acceptable UX. I haven't seen such yet.

Last edited on 10/06/2015 at 08:31:49 AM by pavelz

comment:5 Changed on 10/06/2015 at 08:54:01 AM by sven

UX wise, the most important thing is that the desktop site is displayed after requesting it. For now it doesn't seem to make a big difference (UX wise), if it happens in the same tab or in a new active tab (and the current will be closed in the background).

Knowing this, the description text: "This will close the menu and will reload the desktop version of this website in the same tab." could be replaced, if we have a better implementation for that. I used this approach for now to be consistent with our Android browser and Safari for iOS.

comment:6 Changed on 10/06/2015 at 02:18:47 PM by sven

  • Cc pavelz added

comment:7 Changed on 10/06/2015 at 03:07:49 PM by mario

As mentioned in the meeting today I tested this feature on Firefox Mobile on Android and it worked ok-ish.
I wasn't aware of the fact that other browsers offered this feature. I was under the impression, that this should be solely handled by the website's operator, as there are far too many different ways to display a website mobile friendly.

After looking into the Firefox feature for a bit, it seems like they perform the following actions:

  1. Switch the user agent
  2. Ignore viewport meta tags
  3. Fake resolutions (I'm not sure about this one)

My assumption is based on the following discussions:

However this raises further questions:

  • How are websites handled, that forward mobile users to another site (e.g. http://domain.tld/ -> http://mobile.domain.tld/). The browser needed to guess the original site if the user was already redirected to the mobile friendly version before activating "Request Desktop site".
  • How to handle responsive websites? Ignoring viewport meta data wouldn't handle all of them (to my knowledge, i.e. media queries)

This should be elaborated in more detail. It would be great to know what Firefox does in detail but unfortunately I couldn't find that much. I'm going to give this another shot this week.

comment:8 Changed on 10/07/2015 at 10:50:25 AM by mario

  • Cc mario added

comment:9 Changed on 10/08/2015 at 03:04:46 PM by lisabielik

Please see Ticket_3149.png for text changes.

Last edited on 10/08/2015 at 03:05:29 PM by lisabielik

Changed on 10/08/2015 at 03:05:05 PM by lisabielik

comment:10 Changed on 10/08/2015 at 03:09:34 PM by philll

  • Cc lisabielik added

Please put texts for changes in the ticket description to not have them hidden in attachments and error-prone image files due to manual copy-typing texts.

comment:11 Changed on 10/09/2015 at 08:53:37 AM by mario

I've finally found the original tickets:

As assumed they switch the UA and ignore viewport meta tags. In order to resolve the redirect problem, they redirect the user from subdomains to the original domain. (e.g. to
However this still may cause problems, especially if the displayed subdomain is not due to mobile reasons (e.g. Or if users are redirected to a mobile-friendly ressource (e.g. ->
It might be possible to implement this feature, but it quite possibly also means constant maintenance: finding and resolving techniques, that aren't affected by the viewport/UA change as well as fixing wrong redirects.

comment:12 Changed on 10/12/2015 at 11:17:39 AM by mario

  • Keywords salsita added

comment:13 Changed on 02/24/2016 at 09:47:14 AM by pavelz

  • Keywords salsita removed

Feature spec needed, removed salsita keyword

Add Comment

Modify Ticket

Change Properties
as new .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from (none).
Next status will be 'reviewing'.
Note: See TracTickets for help on using tickets.