Bug 1595641 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Drew Willcoxon :adw from comment #4)
> Actually, we do need a `focus` function... because when the extension calls `search("", { focus: false })` and then the user clicks the "Got it" button in the tip, at that point we should focus the urlbar. It doesn't happen automatically. So the extension will need to add an `onResultPicked` listener and then call a `focus` function.

This seems dangerous, the urlbar currently works off 2 states, focus and expanded, unfocused. We just removed the third state (focused and collapsed) because it was introducing a lot of complication and platform bugs.
Unfocused and expanded is likely a less problematic case, but it may still introduce unexpected regressions, because most of the code expects things to be in those 2 states (and code gets simplified by only assuming 2 states).
This may introduce complications for the expanded state, because currently we assume the urlbar is always expanded and focused.
This makes me wonder if the urlbar is the right place to show these notifications, vs a usual doorhanger...

If we really need to control focus, let's not introduce an explicit focus() method, that sounds like more of a footgun than a focus option in search, it would be too generic and mixable with any other condition. Could you just invoke search again, with focus set to true?
(In reply to Drew Willcoxon :adw from comment #4)
> Actually, we do need a `focus` function... because when the extension calls `search("", { focus: false })` and then the user clicks the "Got it" button in the tip, at that point we should focus the urlbar. It doesn't happen automatically. So the extension will need to add an `onResultPicked` listener and then call a `focus` function.

This seems dangerous, the urlbar currently works off 2 states, focus and expanded, unfocused. We just removed the third state (focused and collapsed) because it was introducing a lot of complication and platform bugs.
Unfocused and expanded is likely a less problematic case, but it may still introduce unexpected regressions, because most of the code expects things to be in those 2 states (and code gets simplified by only assuming 2 states).
This may introduce complications for the expanded state, because currently we assume the urlbar is always expanded and focused.
This makes me wonder if the urlbar is the right place to show these notifications, vs a usual doorhanger...
nvm my previous comment... a focus() method is not dangerous.

it's mostly the introduction of an unfocused & expanded state that is a bit scary.
nvm my previous comment contents... a focus() method is not dangerous.

it's mostly the introduction of an unfocused & expanded state that is a bit scary.

Back to Bug 1595641 Comment 5