Preserve per-site desktop mode preferences#8877
Conversation
…ed from the get go
RealSitePreferencesRepository now implements two interfaces (SitePreferencesRepository and MainProcessLifecycleObserver), so @ContributesBinding can no longer infer the bound type. Specify it explicitly to fix the DI codegen failure in both AnvilDagger and Metro builds (kaptGenerateStubs / Metro compile). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| // Persist the choice per-site. uri.host is the pre-rewrite host (e.g. m.example.com), whose eTLD+1 | ||
| // (example.com) matches the key the desktop-rewritten URL produces; hosts without a registrable | ||
| // domain (IPs, localhost) fall back to the raw host. The optimistic cache update means the reload | ||
| // triggered below already sees the new value. |
There was a problem hiding this comment.
nit: I'd recommend shorter comments or even skip them if code is clear
| Entity::class, | ||
| Relation::class, | ||
| DefaultBrowserPromptsAppUsageEntity::class, | ||
| SitePreferencesEntity::class, |
There was a problem hiding this comment.
Have you maybe considered creating a new module for site-preferences and a separate database? ;)
Asking because this relates to our Modularization AOI and adding new features that use AppDatabase will make it harder later to remove them. I'm not saying you need to do the new module now, just something to keep in mind.
(cc @aibrahim- )
There was a problem hiding this comment.
Do we really need a room DB for this? it seems a simple preferences store should be enough, e.g. androidx.datastore or even a SharedPreferences
There was a problem hiding this comment.
@aibrahim- It seemed like a natural choice, since the settings is per-domain, which can grow indefinitely. Plus, this would allow to store other prefs per-domain in the future. But I supposed storing it as a list of domains in a DataStore would work if the list was reasonable.
There was a problem hiding this comment.
@landomen Yeah, I suppose it could be a separate module. I can refactor it.
# Conflicts: # app/src/main/java/com/duckduckgo/app/browser/BrowserTabViewModel.kt # app/src/test/java/com/duckduckgo/app/browser/BrowserTabViewModelTest.kt
…ore the site-preferences cache is primed Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ntracts Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… remember-desktop-mode flag Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ase to version 61 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…sktop-mode read Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@landomen @aibrahim- I moved the site preferences to a separate module and tried to address the issue you noticed. It is now better but a site set to desktop mode occasionally still renders mobile because the desktop-UA reload is served from the HTTP cache, which can return a previously-fetched mobile copy (a forced refresh fixes it). This is a pre-existing limitation not introduced here, it is just easier to surface now that desktop mode is applied automatically on every initial load of a remembered site. |
…rTest so the mocked listener returns false instead of a null Boolean
Task/Issue URL: https://app.asana.com/1/137249556945/project/1214749231578703/task/1212541545715038?focus=true
Description
This PR adds a per-site desktop mode preference persistence using eTLD+1 as a key (or "localhost" or an IP address). When a desktop mode is enabled on a site, it will be always used until it's either disabled or the site is cleared using the Fire button.
Steps to test this PR
Note
Medium Risk
Changes main-frame user-agent selection and tab UI state for desktop mode, plus new persistent data that must stay aligned with fire-button and fireproof semantics.
Overview
Adds a site-preferences module that stores “desktop site” choices in Room (keyed by eTLD+1, or raw host for localhost/IPs), with an in-memory cache primed at startup and a
rememberDesktopModeremote feature toggle to fall back to session-only behavior when off.When the feature is on,
BrowserTabViewModelwrites preferences on menu toggle, applies remembered mode on navigation (so desktop mode does not leak across sites), and answersisDesktopSiteEnabled(url)from storage soWebViewRequestInterceptorpicks the correct user agent on first load. Fire / burn / domain clear paths now clear desktop preferences viaSitePreferencesDataClearer, respecting fireproofed domains like other per-site stores.Reviewed by Cursor Bugbot for commit c9180f6. Bugbot is set up for automated code reviews on this repo. Configure here.