[composable toolbar] Using the navbar breaks searching mode
Categories
(Firefox for Android :: Toolbar, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox143 | --- | fixed |
People
(Reporter: petru, Assigned: petru)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxdroid][group3][composable toolbar])
Attachments
(2 files, 2 obsolete files)
Steps to reproduce
- Enable both the composable toolbar and the toolbar redesign feature from secret settings
- Enable the expanded toolbar layout from the "Customize" settings screen
- Tap on the toolbar from the home screen
Expected behavior
The toolbar enters in search mode
Actual behavior
Nothing happens
Assignee | ||
Comment 1•1 month ago
|
||
Looking more into this it seems to be happening because HomeNavigationBar
is instantiated before HomeToolbarComposable
and it will create a new BrowserToolbarStore
without the search related middlewares.
Ideally we should only use one BrowserToolbarStore
per screen/fragment.
Since HomeNavigationBar
only needs a simple store and HomeToolbarComposable
needs more configuration it seems like we need to have a way to have HomeToolbarComposable
instantiate first the BrowserToolbarStore
and then pass it to HomeNavigationBar
.
Assignee | ||
Comment 2•1 month ago
|
||
Setting S4 since this bug only reproduces in the context of 2 not released features.
Assignee | ||
Updated•1 month ago
|
Updated•1 month ago
|
Assignee | ||
Comment 3•1 month ago
|
||
Considered adding the navbar in the HomeToolbarComposable
/ BrowserToolbarComposable
. This could work but the contract of these classes is to return the toolbar layout
so then these would do more than expected.
Also considered just passing to HomeNavigationBar
/ BrowserNavigationBar
the BrowserToolbarStore
instance from HomeToolbarComposable
/ BrowserToolbarComposable
in a similar way to how it happens for the awesomebar but the navbar might be instantiated separately from the toolbar when the toolbar is to be shown at the top of the screen.
The easiest though is just to ensure the the navbar is instantiated after the toolbar composable. This would ensure that it will be able to access the same BrowserToolbarStore
previously setup by the toolbar composable.
Assignee | ||
Comment 4•1 month ago
|
||
This would ensure the navbar will see the BrowserToolbarStore previously set up
by the composable toolbar.
Assignee | ||
Comment 5•1 month ago
|
||
Previously both the navbar and the addressbar would build their own BrowserToolbarStore
but have this persisted as a ViewModel in the containing fragment.
This meant that whoever would try to build the store the second time would get the
initially built store, with potentially different middlewares set.
This patch brings one clear API to build the BrowserToolbarStore that can be used by multiple
separate features which would get the store instance properly configured to support them all.
Updated•1 month ago
|
Assignee | ||
Comment 7•1 month ago
|
||
This brings a matching initialization flow to what is used in the browser screen.
Comment 8•1 month ago
|
||
Comment 10•29 days ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/60e5e776efad
https://hg.mozilla.org/mozilla-central/rev/a4c712ffead5
Assignee | ||
Comment 11•28 days ago
|
||
This reverts commit 5ea4161e to get back in the state where we observed memory leaks
Updated•28 days ago
|
Description
•