| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
mirrors that column is tidied when showing results
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is essentially the best we can get without taking advantage
of literally brand new navigation APIs, if we don't want to get
reeeeeeeeeeally futzy.
This approach is strictly oriented around the back/forward cache
and does not store anything in history state (replaceState etc).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We meant to make incorporate a change like this from the start,
but uh, forgot *lol*
|
|
|
|
|
|
This commit is a bit misleading because the work here
actually replaced an attempt at using .select().
|
|
|
|
Some code paths knida just take us here no matter what's
actually entered into the input, so it's easiest to just
dismiss empty queries every time.
|
|
HTMLInputElement: selectionchange still not available, boo hoo
although this is probably appropriate wrt selection moving
literally anywhere else - should also cancel focus-first-result
|
|
|
|
...rather than tracking value changes, which is finnicky and
broke how we detected pressing enter/return to acivate search
(on 'change' event)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
