shift-tab doesn't work in location suggestion
Bug #905078 reported by
gue5t gue5t
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Midori Web Browser |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Pressing tab selects the next suggestion in the location dropdown, but there's no corresponding behavior for shift-tab; it's treated the same as tab without modifiers. It should probably switch to the previous suggestion. In addition, it seems strange that tab doesn't continue once it reaches the end in this drop-down. Tab/shift-tab should probably either loop through the suggestions or focus the next widget in the UI if they pass the end of suggestions.
tags: | added: location urlbar |
Changed in midori: | |
status: | New → In Progress |
Changed in midori: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
To find a reasonable new behavior for this, I looked at other browsers and completion implementations.
The way GTK behaves in the analogous situation in its file chooser is (with up/down arrow keys, as it considers tab "next widget" or "complete to the next ambiguous point") to move from bottom downward to the entry itself, and then down again brings focuses the first entry. Going up takes the same logic, with the entry itself between the first and last completions.
Firefox does the same thing (wraps around in both directions with the entry itself as an intermediate), but allows tab like midori does.
Chrome only allows the arrow keys for up/down in selections and doesn't wrap around at all. It interprets tab as "use the selected completion", any printable character as "use the selected completion and append this character", and escape as "return to the pre-completion text".
I'd think it'd likely be best to mirror the GTK/Firefox behavior, as it'll be more consistent with other GTK programs and therefore more predictable to users.