launchpad-reviewers team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

We cannot use 'keyup' because browser was already moved focus. I tested it in IE, FireFox and Chromium, watched the browser move focus out of the overlay, then the debugger stopped when it entered keyup. By catching the keydown, we also catch the repeated tabs. Opera is a different story. It uses tabs to access native/form widgets only, links are navigated using shift+arrow. Opera always could use the broken choice picker, but it can also still leave the modal overlay. I tried the "keydown keyup" and that caused the handler to be called twice as often and broke the boundary detection. I think keydown is right for this case, and it is the same kind of case where we also use keydown. I do not see any bugs implying keyup is needed...actually there where several years ago, but we switched to keydown.

Caching is not trivial. Yes I did it at first, then banged my head when I saw the pickers pull in content after the user search. We require a flag to indicate the state tree has changed. The list of visible items also changes as the user expands items in the picker.

ah! "opton' when I first wrote the test, I saw some elements not found. I looked got malformed markup, but did not see that. This probably would have failed using lucid's older webkit.

I deleted the empty string

We are not skipping the close button...users can tab to it to close the overlay. The scenario here is that the overlay opens, and the user presses shift+tab. We want focus to cycle to the last item in the overlay, not the last item in the page footer or the location bar.
-- 
https://code.launchpad.net/~sinzui/launchpad/overlay-tab/+merge/112901
Your team Launchpad code reviewers is subscribed to branch lp:launchpad.