str: 1. choose View > Toolbars > Customize… (or right click in the main toolbar) 2. close the customize sheet (fails from the keyboard !). 3. try to focus the location bar from the keyboard (Cmd-L) AR: nothing happens ER: focus the location bar (many) other keyboard shortcuts that fail equally. this is broken since Gecko/20100422 Minefield/3.7a5pre (20100421 works fine) http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cdc8bf25220e&tochange=ab4c6ba5ff70 possibly bug 355375 ?

(In reply to comment #0) > possibly bug 355375 ? Unlikely... maybe bug 544277?

See also bug 577963 comment 2; perhaps these are related?

I changed the focus behavior on bug 544277, but I assumed that the change affects only for tab key navigation between documents...

I backed out the patch of bug 544277 manually, but I can still reproduce this bug.

This is technically a regression from bug 418521, but the underlying issue might not be a new regression. When the sheet opens, the iframe in which the sheet lives receives focus, but no element is focused (focusedWindow is customizeToolbar.xul, focusedElement is null). Then, when the "Done" button is clicked, the iframe gets hidden and the focus state doesn't change (the focusedWindow is still the iframe and there's no focusedElement). Prior to the behavior change done in bug 418521, the "Done" button received focus when it was clicked, and after the iframe got hidden, the "Done" button lost focus, and the browser window received the focus. I filed bug 584329 for the underlying issue.

Workaround patch coming.

Gavin: I think the test belongs to the underlying but. However, if you think this bug is worth its own test, let me know.

Mano, do you happen to know if there is a bug about the 'Done' button, which by default should react to 'enter/return' and 'esc', but doesn't ?

I cannot recall. It used to work long ago, as far as I remember. If you find a bug on that, or if you file one, please CC me and I'll look into that. Thanks!

(In reply to comment #9) > I cannot recall. It used to work long ago, as far as I remember. If you find > a bug on that, or if you file one, please CC me and I'll look into that. > Thanks! Filed bug 584336 for that.

Gavin, are you going to review this patch?

I can't reproduce this bug (mac trunk nightly). Am I missing something, or is it intermittent?

I was not able to reproduce on Fx4b4. I tried Linux and Mac.

still doesn't work here Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100823 Minefield/4.0b4pre http://hg.mozilla.org/mozilla-central/rev/34cfe33b865f (I tried with a fresh profile, for good measure)

Apparently this is 10.6-only. Any ideas why that would be?

after a short chat with gavin on irc: I tested this on 10.5 and indeed, on that OS, it works correctly. My original tests have all been on 10.6 (I also verified tabs on top ON/OFF - it does not make a difference)

Comment on attachment 462745 [details] [diff] [review] the workaround Fine as a work around, I guess.

One thing that could impact is full keyboard access being on. For that reason you also cannot reproduce on Linux, the "Done" button is always focusable there. Gavin, can you tab to the Done button on 10.5?

No, I tried with full keyboard access off and on - makes no difference.

Comment on attachment 462745 [details] [diff] [review] the workaround blocker, doesn't need approval

(In reply to comment #5) > I filed bug 584329 for the underlying issue. That bug blocking2.0 as well -- should we still take this patch?

I think we should either way (this isn't the kind of workaround I would back-out afterwards)