Skip to content

Conversation

@CDRussell
Copy link
Member

@CDRussell CDRussell commented Feb 22, 2018

Asana Issue URL: https://app.asana.com/0/488551667048375/529888388192278

Description

Gives the user an option to request that the desktop site be loaded instead of a mobile-specific site. It achieves this by altering the user agent string accordingly.

Note, if the url has an obviously mobile-specific site (using the m.xxxxxxxx.com) format, we strip the m. out of the URL when jumping to the desktop version. Discussions welcomed around this.

Also included in this is the slight improvement over the general UA strings we submit; they no longer contain the device make or model in them. We do still include the rest of the details, including the Android version and AppleWebKit/xxx.yy version information to ensure sites render well. https://app.asana.com/0/414730916066338/537987832233112

Steps to Test this PR:

  1. Visit a site that redirects to a mobile-specific site (e.g., youtube.com)
  2. Verify that you end up on the mobile site (m.youtube.com)
  3. Use the overflow menu, and check to receive the desktop site
  4. Verify that you end up on the desktop site
  5. Repeat again to ensure you end up back on the mobile site

Includes removal of user device details - the make and model are omitted, though other details about the browser capabilities are retained to ensure a good browsing experience
…request_desktop_site

# Conflicts:
#	app/src/main/res/layout/popup_window_browser_menu.xml
Copy link
Contributor

@subsymbolic subsymbolic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent work @CDRussell, I can't wait to start using this

android:enabled="false"
android:text="@string/find_in_page" />

<CheckBox
Copy link
Contributor

@subsymbolic subsymbolic Feb 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look quite right visually. I'd suggest taking a screenshot and asking Mike to quickly mock it up in zeplin.

If you're keen to get the PR in right now and address design feedback later, I'd be happy to approve the PR if:

  1. we update the text "Request Desktop Site" to "Desktop Site"? That's what other browsers use.
  2. update the checkbox so it does not vertically overlap any of the menu items text (which it will after number one is done). Think of checkbox being is a different "column" to the text. Also, use the same margin/padding to the left and right of the menu. Right aligning the checkbox might give you all of this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

import com.duckduckgo.app.browser.BrowserViewModel.Command.LandingPage
import com.duckduckgo.app.browser.BrowserViewModel.Command.Navigate
import com.duckduckgo.app.browser.omnibar.OmnibarEntryConverter
import com.duckduckgo.app.browser.userAgent.UserAgentProvider
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Test
fun whenUserSelectsDesktopSiteThenDesktopModeCommandIssued() {
testee.desktopSiteModeToggled("http://example.com", desktopSiteRequested = true)
verify(mockCommandObserver, Mockito.atLeastOnce()).onChanged(commandCaptor.capture())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this command being triggered three times?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are other commands that might already fire (like ShowKeyboard) so we don't want to verify only one command which is the default Mockito flow.

webView.webChromeClient = webChromeClient

webView.settings.apply {
userAgentString = userAgentProvider.getUserAgent(defaultUserAgentString)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional: Would it make sense to instantiate the userAgentProvider with the defaultUserAgentString?

companion object {
val SHARED_PREFERENCES_FILENAME = "com.duckduckgo.app.settings_activity.settings"
val KEY_AUTOCOMPLETE_ENABLED = "AUTOCOMPLETE_ENABLED"
const val SHARED_PREFERENCES_FILENAME = "com.duckduckgo.app.settings_activity.settings"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did the same thing in my branch :)


fun Uri.isMobileSite() : Boolean = this.authority.startsWith("m.")

fun Uri.toDesktopUri(): Uri {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These extensions feel generic rather than related to the user agent. Can we move them into UriExtensions, format and unit test them?

fun Uri.isMobileSite() : Boolean = this.authority.startsWith("m.")

fun Uri.toDesktopUri(): Uri {
return if(this.isMobileSite()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need the explicit this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope; removed


fun Uri.toDesktopUri(): Uri {
return if(this.isMobileSite()) {
Uri.parse(toString().replaceFirst("m.", ""))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we protect future maintainers by adding a unit test for this to ensure that a non-mobile url with an ".m" e.g "adam.example.com" stays unchanged by this method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good thinking!

*/
class UserAgentProvider @Inject constructor() {

companion object {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we place companion objects at the bottom? I got the same feedback in my PR :) https://kotlinlang.org/docs/reference/coding-conventions.html#source-code-organization

}

private fun shouldStripRequestedWithHeader(request: WebResourceRequest): Boolean {
if(!request.isForMainFrame) return false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spacing / formatting

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed function entirely; was unused

@CDRussell
Copy link
Member Author

RR @subsymbolic. all feedback should be addressed or, at least, given a response. let me know if i missed any.

Copy link
Contributor

@subsymbolic subsymbolic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great @CDRussell. One last bit of feedback, I'm seeing some odd progress bar behavior. To reproduce:

  1. Go to facebook
  2. Tap the checkbox to display a desktop site. All seems fine.
  3. Tap the checkbox to display a mobile site. The progress bar finishes early and then there is a long delay before the mobile site is displayed which makes it seem like nothing is happening.

@CDRussell
Copy link
Member Author

CDRussell commented Feb 26, 2018

@subsymbolic I think you've unearthed something bigger.

It looks like BrowserWebViewClient.onPageFinished() is being called for every resource, including javascript ones. Therefore, it's calling through to BrowserViewModel.loadingFinished() which hides the loading indicator.

I think this is unrelated to the changes made for desktop mode but an important thing to fix. I will create a new ticket for this.

Internal reference: https://app.asana.com/0/414730916066338/572507223939055

@subsymbolic
Copy link
Contributor

@CDRussell I think it is unrelated. I'm happy to forget that last feedback - testing it again I'm now inclined to think it was a facebook oddity as I managed to reproduce it on Chrome and our site. Subsequently, I couldn't reproduce it on either.

One other issue I noticed is that https://www.theguardian.com/uk stays on mobile irrespective of option. I wonder if viewport settings have something to do with this.

@CDRussell
Copy link
Member Author

CDRussell commented Feb 26, 2018

Let's class that problem as being sometimes the cause of what you saw, and other times something else is causing it. I'd like to address that ticket soon, but I think we're agreeing it's not needed for this PR. (For reference, loading gearbest.com is a good way to cause the symptoms you describe; the progress bar will disappear early.)

On the other hand, theguardian.com is a good problem site and should be solved in this PR. I'll investigate what's going on with this tomorrow.

…request_desktop_site

# Conflicts:
#	app/src/main/java/com/duckduckgo/app/settings/db/SettingsDataStore.kt
@CDRussell
Copy link
Member Author

Identified the problem with sites like theguardian.com is that because they have a responsive web page rather than a dedicated mobile site, the content of the web page is identical for both desktop and mobile UA strings.

Instead, we have to ensure we change some WebView settings locally based on which browsing mode we are in which will affect the scale on the WebView.

@subsymbolic
Copy link
Contributor

This is really close. Portrait is looking great, landscape looks a little too "zoomed out". I have added screenshots of our app and chrome for comparison.

ourapp_bbc

ourapp_theguardian

chrome_bbc

chrome_theguardian

@subsymbolic
Copy link
Contributor

Update: I see the same for portrait websites as well when in desktop mode. Facebook is a good one to test on as it happens in both portrait and landscape modes.

The result of this is that some responsive sites do not present differently under desktop or mobile modes. theguardian.com/uk is one such example site where we render both modes identically (despite Chrome rendering them correctly for each)

Some other responsive sites do work just fine though - arstechnica.com for example renders differently for us under desktop and mobile modes.

Will revisit fixing sites like theguardian.com/uk in another task.
Copy link
Contributor

@subsymbolic subsymbolic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one comment about mobile options.

javaScriptEnabled = true
domStorageEnabled = true
loadWithOverviewMode = true
useWideViewPort = true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove these two options from mobile? Overview mode was introduced to fix an issue #70.

@CDRussell
Copy link
Member Author

The result of these changes is that some responsive sites do not present differently under desktop or mobile modes. theguardian.com/uk is one such example site where we render both modes identically (despite Chrome rendering them correctly for each)

Some other responsive sites do work just fine though - arstechnica.com for example renders differently for us under desktop and mobile modes.

Will revisit fixing sites like theguardian.com/uk in another task.

Copy link
Contributor

@subsymbolic subsymbolic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@CDRussell CDRussell merged commit b18948e into develop Feb 28, 2018
@CDRussell CDRussell deleted the feature/request_desktop_site branch February 28, 2018 16:07
aitorvs pushed a commit that referenced this pull request Nov 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants