Opened 5 years ago

Last modified 5 years ago

#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 5 years ago.
requestdesktopsiteicon 1.png (19.2 KB) - added by sven 5 years ago.
Ticket_3149.png (11.7 KB) - added by lisabielik 5 years ago.

Download all attachments as: .zip

Change History (16)

Changed 5 years ago by sven

Changed 5 years ago by sven

comment:1 Changed 5 years ago by sven

  • Cc jand added
  • Description modified (diff)

comment:2 Changed 5 years ago by sven

  • Description modified (diff)

comment:3 Changed 5 years ago by Shikitita

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

comment:4 Changed 5 years ago 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 5 years ago by pavelz (previous) (diff)

comment:5 Changed 5 years ago 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 5 years ago by sven

  • Cc pavelz added

comment:7 Changed 5 years ago 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 5 years ago by mario

  • Cc mario added

comment:9 Changed 5 years ago by lisabielik

Please see Ticket_3149.png for text changes.

Last edited 5 years ago by lisabielik (previous) (diff)

Changed 5 years ago by lisabielik

comment:10 Changed 5 years ago 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 5 years ago 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 5 years ago by mario

  • Keywords salsita added

comment:13 Changed 5 years ago by pavelz

  • Keywords salsita removed

Feature spec needed, removed salsita keyword

Note: See TracTickets for help on using tickets.