Retain or remove search mode across tabs
Categories
(Firefox :: Address Bar, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: bugzilla, Assigned: adw)
References
Details
Attachments
(1 file)
This is related to our retained results behaviour. We should be aware of edge cases around engine removal: say the user enters search mode with a particular engine, switches tabs, removes that engine, then returns to the initial tab.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
There's the question of session store too... We keep userTypedValue
in session store, so if you type something in the urlbar and restart Firefox for example, the value you typed is restored. I imagine we want to treat search mode just like that.
I'm not sure yet whether that fits into this bug or not. It's different enough conceptually for it to be its own bug, but if the fix for this bug ends up creating a userSearchMode
, which it might, then it may be more straightforward to do that here.
Assignee | ||
Comment 2•4 years ago
|
||
Ah, that's bug 1655486. And the more I think about this, I think it would be a good idea to fix this bug as narrowly as possible since we want to land this by Monday. Like, just a map in UrlbarInput
that stores search modes for browsers -- something that works well enough for initially enabling in Nightly, and then we can refine or even replace it under the hood later.
Assignee | ||
Comment 3•4 years ago
|
||
(In reply to Harry Twyford [:harry] from comment #0)
... removes that engine...
I filed bug 1657801 for this since it's orthogonal to tabs (this bug).
Assignee | ||
Comment 4•4 years ago
|
||
This is very simple, but it gets the job done. It keeps a map in UrlbarInput
from browsers to search mode objects. The map is updated in setSearchMode
, and
it's used to set the search mode in _afterTabSelectAndFocusChange
.
Assignee | ||
Comment 5•4 years ago
|
||
Comment 6•4 years ago
|
||
fwiw, long term I'd prefer us storing something in the tab's browser, similar to the typed string property. Maybe it could be a good time to introduce a browser.urlbarState object.
Assignee | ||
Comment 7•4 years ago
|
||
Yes, that's my thought too. I don't think we can get that done by Monday and that's why I chose this simple approach.
Actually, long term it would be nice to move that state out of browser and into urlbar. It's urlbar state, it should be in urlbar. When it's just a string, userTypedValue
, it's not a big deal, but we're now adding more state and who knows what else in the future.
Comment 10•4 years ago
|
||
bugherder |
Comment 11•4 years ago
|
||
(In reply to Drew Willcoxon :adw from comment #7)
Actually, long term it would be nice to move that state out of browser and into urlbar. It's urlbar state, it should be in urlbar. When it's just a string,
userTypedValue
, it's not a big deal, but we're now adding more state and who knows what else in the future.
I think the main reason for it being in browsers is SessionRestore
Assignee | ||
Comment 12•4 years ago
|
||
Yes, but I'd like to look into the possibility of hooking up urlbar to sessionstore.
Comment 13•4 years ago
|
||
I verified this issue using 82.0a1
on macOS 10.13 and Windows 10 x64 and ubuntu 20.04
Description
•