-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Feature/request desktop site #198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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
subsymbolic
left a comment
There was a problem hiding this 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 |
There was a problem hiding this comment.
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:
- we update the text "Request Desktop Site" to "Desktop Site"? That's what other browsers use.
- 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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use a lowercase package name here? https://kotlinlang.org/docs/reference/coding-conventions.html#naming-rules
| @Test | ||
| fun whenUserSelectsDesktopSiteThenDesktopModeCommandIssued() { | ||
| testee.desktopSiteModeToggled("http://example.com", desktopSiteRequested = true) | ||
| verify(mockCommandObserver, Mockito.atLeastOnce()).onChanged(commandCaptor.capture()) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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()) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.", "")) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spacing / formatting
There was a problem hiding this comment.
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
|
RR @subsymbolic. all feedback should be addressed or, at least, given a response. let me know if i missed any. |
There was a problem hiding this 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:
- Go to facebook
- Tap the checkbox to display a desktop site. All seems fine.
- 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.
|
@subsymbolic I think you've unearthed something bigger. It looks like 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 |
|
@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. |
|
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
|
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 |
|
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.
…request_desktop_site
subsymbolic
left a comment
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
|
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. |
subsymbolic
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!




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 them.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.yyversion information to ensure sites render well. https://app.asana.com/0/414730916066338/537987832233112Steps to Test this PR: