757368 - moving the caret with arrow keys don't work any more in editor if a floating panel contains a focusable element

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

This bug is a regression introduced by fix for bug 669026 (verified on OS X
between revision ede336ccaed0 - working - and revision 4d0391866459 - failing).

If I launch BlueGriffon 1.4 and create a blank document, type
a few chars and open the CSS Properties panel (that is a XUL floating panel),
using the left arrow to move the caret works fine in the editor.
If I do the same with BlueGriffon 1.4.1 or even more recent (fix for the
bug 669026 is in), then the first menulist in my CSS Properties panel acquires
the focus when the left arrow key is pressed and the editor loses the focus! I
have a lot of users' feedback about this, and this is bad enough to trigger a
new minor version of BlueGriffon with a fix for that wrong behaviour.

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Bug confirmed on Windows (XP, 7, 8preview) and Linux.

Comment 2

[[e-mail]]

http://mxr.mozilla.org/comm-central/source/mozilla/dom/base/nsFocusManager.cpp#2436
// if there is no focus, yet a panel is open, focus the first item in
// the panel

Comment 3

[[e-mail]]

Attachment: Possible patch (-w)

I'm not sure what this code is trying to achieve, otherwise I'd remove it ;-)

Comment 4

[Neil Deakin]

That code is needed so that pressing tab when a panel is open cycles into the panel itself. This patch seems to make it so that navigation into the panel isn't possible.

From the bug description above, it seems that DetermineElementToMoveFocus is being called with MOVEFOCUS_CARET. If that's the case, the popup checking step could just be skipped.

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to Neil Deakin from comment #4)

> That code is needed so that pressing tab when a panel is open cycles into
> the panel itself. This patch seems to make it so that navigation into the
> panel isn't possible.

I have just tested Neil's patch in BlueGriffon:

  1. it solves the bug
  2. cycling into a panel still works as usual if the focus is already in the
     panel

Were you saying that if the focus is in the last tabbable element in the main
window, a tab should switch to the first available panel containing a tabbable
element?

Comment 6

[[e-mail]]

Attachment: Proposed patch

Sure, that seems to work too.

Comment 7

[[e-mail]]

Pushed mozilla-central changeset f6d082275253.