[composable toolbar] Configure search terms
Categories
(Firefox for Android :: Toolbar, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | fixed |
People
(Reporter: petru, Assigned: harrisono)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [fxdroid][group3][composable toolbar])
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 |
Searched terms for the active tab are currently read from the BrowserStore and configured for how to be displayed here.
Also ensure support for editing search terms instead of navigating to home for a new search if the current tab was opened based on search terms already.
And ensure that whenever setting the url to display (inside of BrowserToolbarMiddleware) we'd pass only the url through that toDisplayUrl` API, not also the search terms.
One other detail is that whenever choosing "Paste & Go" in the popup menu from long pressing on the url we need to also update the search terms as it currently happens here.
Updated•1 year ago
|
| Reporter | ||
Updated•1 year ago
|
Updated•9 months ago
|
| Reporter | ||
Comment 1•9 months ago
|
||
Linked a recent ticket - bug 1964736 which showed that there are scenarios in which the search terms should not go through URLStringUtils.toDisplayUrl.
So whenever setting the url to display (inside of BrowserToolbarMiddleware), pass only the url through that toDisplayUrl` API, not also the search terms.
Comment 2•9 months ago
|
||
Un-assigning this from andrey since we're pairing on another bug.
| Assignee | ||
Updated•9 months ago
|
| Assignee | ||
Updated•9 months ago
|
| Assignee | ||
Comment 3•8 months ago
•
|
||
related ticket: bug 1964736
| Reporter | ||
Updated•8 months ago
|
| Assignee | ||
Comment 4•8 months ago
|
||
| Reporter | ||
Comment 5•8 months ago
|
||
We use the Environment idiom to be able to pass lifecycle based dependencies
to middlewares.
Since the browser toolbar is currently used in different contexts and with
different functionalities in the home and browser screens the concrete
environment classes were different.
But with searches being possible for search terms in the browser screen also
the search middlewares need to work with only one environment type, which now
will be BrowserToolbarEnvironment.
| Reporter | ||
Comment 6•8 months ago
|
||
| Reporter | ||
Comment 7•8 months ago
|
||
| Reporter | ||
Comment 8•8 months ago
|
||
The new try-catch is a quick fix of an existing bug in InlineAutocompleteEditText
where immediately after gaining focus the autocompleted text is considered in
reporting the original text.
And this conflicts with the composable functionality which will try to focus when
the text is updated.
| Reporter | ||
Comment 9•8 months ago
|
||
This brings the same behavior that we currently have with the toolbar view.
Updated•8 months ago
|
Updated•8 months ago
|
Comment 10•8 months ago
|
||
Comment 11•8 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ae3bcd0d61f5
https://hg.mozilla.org/mozilla-central/rev/72eb662f8fc9
https://hg.mozilla.org/mozilla-central/rev/dcc6198fb2a0
https://hg.mozilla.org/mozilla-central/rev/e9a786bba323
https://hg.mozilla.org/mozilla-central/rev/f998ce28e9c2
https://hg.mozilla.org/mozilla-central/rev/fa323df85210
Description
•