Bug 1925496 Comment 15 Edit History

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

URLSECONDARY is used to de-emphasize the text that is not the origin, and it does that using opacity (alpha channel is set to 127 [here](https://searchfox.org/mozilla-central/rev/ec342a3d481d9ac3324d1041e05eefa6b61392d2/layout/generic/nsTextPaintStyle.cpp#289-290)).
To invert it, we should set the base color to the de-emphasized one and then set full opacity on URLORIGIN. It would probably just add some complexity to css, but it's feasible.

Though, URLSECONDARY is not working with scrollSelectionIntoView.
NORMAL works, any other type doesn't (I also tried FIND). I wonder if it's because it's not actually moving the caret.
If it can't be made working, we may have to use NORMAL.

Actually, we should not care about the caret when the url is formatted, but we use it because of autofill:
1. type moz
2. get moz[illa] filled
3. focus content
4. focus again the urlbar
5. at this point we check if the caret is at the end, and if it is we autofill

We could maybe store the caret position on blur and restore it on focus, that may free up the possibility to modify the selection while the field is blurred. There's also a few tests that for some reason check that we preserve the selection on blur, maybe related to the window losing/gaining focus.
URLSECONDARY is used to de-emphasize the text that is not the origin, and it does that using opacity (alpha channel is set to 127 [here](https://searchfox.org/mozilla-central/rev/ec342a3d481d9ac3324d1041e05eefa6b61392d2/layout/generic/nsTextPaintStyle.cpp#289-290)).
To invert it, we should set the base color to the de-emphasized one and then set full opacity on URLORIGIN. It would probably just add some complexity to css, but it's feasible.

Though, URLSECONDARY is not working with scrollSelectionIntoView, and similarly URLORIGIN wouldn't work.
NORMAL works, any other type doesn't (I also tried FIND). I wonder if it's because it's not actually moving the caret.
If it can't be made working, we may have to use NORMAL.

Actually, we should not care about the caret when the url is formatted, but we use it because of autofill:
1. type moz
2. get moz[illa] filled
3. focus content
4. focus again the urlbar
5. at this point we check if the caret is at the end, and if it is we autofill

We could maybe store the caret position on blur and restore it on focus, that may free up the possibility to modify the selection while the field is blurred. There's also a few tests that for some reason check that we preserve the selection on blur, maybe related to the window losing/gaining focus.

Back to Bug 1925496 Comment 15