AppState Browsing mode is not consistent
Categories
(Firefox for Android :: General, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox141 | --- | fixed |
People
(Reporter: rsainani, Assigned: mavduevskiy)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxdroid])
Attachments
(6 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Users of AppState.BrowsingMode won't always get the latest browsing mode. This works fine when on the HomeFragment but not otherwise. Discussion from this patch .
Comment 1•1 year ago
|
||
I wonder if, for the short term, we can add the following line:
components.appStore.dispatch(AppAction.ModeChange(mode = newMode))
to this section HomeActivity where Browsing Mode Manager is set up, so the AppStore is always updated when the manager is updated.
| Reporter | ||
Comment 2•1 year ago
|
||
That's a good idea! We should give this approach a try.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
|
||
An attempt to force users to update the mode from BrowserModeManager only, to reduce the chance of them going async.
| Assignee | ||
Comment 5•1 year ago
|
||
| Assignee | ||
Comment 6•1 year ago
|
||
It was used to update the state in two places; now that we need only update it once, the function could be removed.
| Assignee | ||
Comment 7•1 year ago
|
||
For some extra context:
- the patch follows in implementation the original [[ https://github.com/mozilla-mobile/firefox-android/pull/5502/files#diff-e9a193a65990d2de50218c9d11e0b45ad43afad7ef28fd81e47be3591fc4cc84R50 | patch ]] of :matt-tighe;
- from a discussion with Matt today: though not possible to restrict, we wanted to descourage usage of
ModeChangeoutside of the Manager by changing the name of theModeChangeaction to hint that it should only be called from the manager.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 8•1 year ago
|
||
Currently, changing a theme on homepage relies on ThemeManager restarting the activity, and the HomeFragment being created with the updated theme and content at the same time.
Allowing HomeFragment to be updated by the appstate mode change led to the content being updated, but theme updated was lagging behind and was only applied after the fragment was recreated, leading to a visual glitch.
| Assignee | ||
Comment 9•1 year ago
|
||
Comment 10•1 year ago
|
||
Comment 11•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/b7952c3b476d
https://hg.mozilla.org/mozilla-central/rev/3bbb7778c37a
https://hg.mozilla.org/mozilla-central/rev/3a5e4b77ca6f
https://hg.mozilla.org/mozilla-central/rev/e2198b52f790
https://hg.mozilla.org/mozilla-central/rev/35150c30773d
https://hg.mozilla.org/mozilla-central/rev/4d6a60329173
Description
•