Open Bug 520040 Opened 15 years ago Updated 2 years ago

[faceted search] When doing "search all messages", pressing <tab> in Quick Search Box should cycle autocomplete suggestions as in FF QS box (contacts, messages mentioning...)

Categories

(Thunderbird :: Search, defect)

defect

Tracking

(Not tracked)

People

(Reporter: thomas8, Unassigned)

References

Details

This is followup of bug 516543. 1 enable "search all messages" mode 2 enter a search term in Quicksearch (QS) box -> we show autocomplete matches (existing contacts, or "messages mentioning...") 3 Press tab Actual behaviour - tab sets focus on first tab's header (main mail win) Expected - tab should cycle through the available autocomplete suggestions (dropdown options), as Firefox does for quicksearch autocomplete.
Flags: wanted-thunderbird3?
This is an usability and accessibility problem, I believe must be corrected in TB3.0
Flags: blocking-thunderbird3?
(In reply to comment #1) > This is an usability and accessibility problem, I believe must be corrected in > TB3.0 In Firefox you can use tab or up/down arrow to cycle through the results. In Thunderbird 3 you can use the up/down arrow to cycle through the results. Therefore the only thing that is slightly different is that the tab key doesn't do the same as Firefox. The drop down is still completely accessible via the keyboard. Hence not blocking on this as it isn't a significant problem. On a side note, I expect we may get a fix for free for this bug when we finish fixing bug 360648 (which will hopefully be after 3.0).
Depends on: 360648
Flags: wanted-thunderbird3?
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
I believe both autocompletes support tabscrolling="true" for this.
(In reply to comment #3) > I believe both autocompletes support tabscrolling="true" for this. this would be very cool - like many people I would bet, I hate arrowing
Severity: normal → minor
This is trickier than it looks. We subclass the autocomplete widget and tabScrolling's actual logic is in the superclass's onKeyPress handler which seems to be unwilling to do the right thing even if we try and explicitly notch a capturing VK_TAB handler to dispatch to onKeyPress.
I was doing some test in Thunderbird 3.1: - Setting the attribute 'tabScrolling' to 'true' in the xul element definition of the search box don't work (in Thunderbird\chrome\messenger\content\messenger\extraCustomizeItems.xul, line 70 element textbox#searchInput) + tabScrolling="true" - Setting to 'true' the property 'tabScrolling' to the element 'searchInput' in javascript, with an extension in the load event: works! The code line: window.addEventListener("load", function(){document.getElementById("searchInput").tabScrolling = true}, false); I implemented it in my extension 'Unified Search' version 0.2+ (the option 'tabScrolling' can be enable and disable from the extension options) Someone knows Why works from javascript but not from xul?
(In reply to comment #7) > - Setting the attribute 'tabScrolling' to 'true' in the xul element definition > - Setting to 'true' the property 'tabScrolling' to the element 'searchInput' > in javascript, with an extension in the load event: works! > Someone knows Why works from javascript but not from xul? Interesting. Does someone know? Either way, does this mean this bug could be fixed by adding a single line?
(In reply to comment #7) > Someone knows Why works from javascript but not from xul? Ben, looking at the source code from comment 9, could you tell why "tabScrolling" attribute works if set with load event from javascript but not if defined from xul?
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.