We can try detecting if the event is coming from html:select or xul:tree. It seems somewhat fragile. Perhaps somehow detect if there's the multiple attribute set.

I propose putting this on Raymond's plate.

Changing to p1; aza wants it for tonight's nightly (which will kick off around 3am PDT). Raymond: get some sleep first!

Mardak randomly blurted this into the chat: Mardak: tree seltype="multiple" Mardak: http://www.hevanet.com/acorbin/xul/top.xul Mardak: Trees, Simple from the left column Mardak: [e.target.nodeName, e.target.hasAttribute("multiple"), e.target.getAttribute("seltype")] Mardak: tree,false,multiple I figure it may have bearing on this bug, or he may have just been speaking in tongues.

(In reply to comment #2) > Changing to p1; aza wants it for tonight's nightly (which will kick off around > 3am PDT). > > Raymond: get some sleep first! Rationale: If we don't get this in we'll be training our users muscle memory wrong. Also we'd have to rewrite/bifurcate documentation. Net-effect: before b4 we need this fixed.

Finally, to give this some context: * Mardak changed to a different keyboard shortcut because Control+Space can be used to select multiple elements of a list in Windows and Linux. This way we didn't break any tests. * The new keyboard shortcut is not desirable for the reasons stated above (and more!) * To switch back and not break tests (and maintain accessibility) we need to detect when we are in a multiple-select box (i.e., one is selected) and the not perform the Tab Candy zoom out. Else, we do.

Comment on attachment 465511 [details] [diff] [review] v1 Blah. This kind of sucks to do, but such are the crowded world of keyboard shortcuts. Aza/Dao: Would it make sense to look at changing this (in a followup) to Control-Tab? That was the key combo previously used by the, err, "Control Tab" feature (bug 465076). AFAIK there are no plans to bring that back (especially now that TabCandy is around), but maybe that key combo should be taken? ISTR some people complaining that Control-Tab no longer advanced to the next tab, though. But perhaps that's a key combo that we don't need to worry about special-casing for other parts of the UI, and introducing inconsistent behavior?

We went with control-space because space is the biggest button around. And going into Tab Candy is rather a primal action. We were concerned about co-opting control-tab because it already has meaning around "move to next tab". Also, control-tab requires moving your hand away from home row (at least, my hand) where as control-space does not.

http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/96f0940b0fc8 Switch back to ctrl-space and check for certain nodes where we shouldn't handle it.

Mass moving all Tab Candy bugs from Mozilla Labs to Firefox::Tab Candy. Filter the bugmail spam with "tabcandymassmove".

http://hg.mozilla.org/mozilla-central/rev/773be5540fcf Switch back to ctrl-space and check for certain nodes where we shouldn't handle it.

The control-space is the *most popular* used to toggle between IME and non-IME mode. Using control-space combination that would impact people who use IME to input the Chinese words.

backed out http://hg.mozilla.org/mozilla-central/rev/c14d91f2d939

(In reply to comment #8) > Aza/Dao: Would it make sense to look at changing this (in a followup) to > Control-Tab? That was the key combo previously used by the, err, "Control Tab" > feature (bug 465076). AFAIK there are no plans to bring that back there are: bug 565568

Agree with yuoo2k. Some users have complained of this hotkey in Chinese user community.We have to use keyconfig extension.

We should have a check for this in Litmus FFT

in-litmus- this changed to ctrl+e besides we're trying to eliminate keyboard shortcuts from BFT's