10678 - [BLOCKER] blur event handlers need to know blur type

Status: VERIFIED DUPLICATE of bug 11425

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[buster]

There are at least 3 different ways for a control to lose focus:
1) a focus switch within the app,
2) a focus switch from the content area to a chrome widget (like a toolbar
button or a menu)
3) the app itself loses focus.

For the editor, each of these requires a different action.
1) when focus switches from an editor text control to another control in the
content area, selection is cleared from the editor text control.
2) when focus is switched from an editor text control to chrome, the editor does
nothing (selection is maintained and shown exactly as it was)
3) when an editor text control has focus, and the app loses focus to another
app, selection is hidden but not cleared, so that when focus is restored to the
app selection is painted as if nothing happened.

We clearly can't do these things unless the Blur event gives us a way to
differentiate.  Joki and I have had conversations about this, but I don't see it
as part of the event system, and we need it to enable GFX-rendered text widgets
properly.

Comment 1

[joki (gone)]

I believe that 1 and 3 are in fact the same.  You'll notice the behavior in 4.x
that if you select text in an edit field, hit tab to move away, and then hit
shift-tab to move back the selection is maintained.  So in the case of either
app focus lost or focus shifting within the content area, hiding the selection
for possible redisplay is sufficient.

This interesting question is switching focus to the chrome area.  Additionally,
a switch to chrome doesn't necessarily mean you keep your selection.  Switching
to the location bar, for example, is a switch to chrome which, because it can
create its own selection, would turn off selection in a text field.  This to me
indicates that either the chrome has to be involved in the decision of whether
to hide selection or we need a set of rules determining what to do for
different chrome areas.  Not saying I've solved this yet but just dumping
thoughts for now.

Comment 2

[Chris McAfee]

more consise summary

Comment 3

[buster]

There's another type of focus loss that might have different behavior for the
editor.  When the editor loses focus to a dialog, it will want to keep selection
painted. Think about find, or spell check.
So, if dialogs are considered chrome somehow, this usage would fall under the
same category.  But, would a control in a dialog really be considered chrome?
cc-ing hyatt, since this focus issue probably involves some knowledge about
chrome on the part of the focus manager.

Comment 4

[buster]

set to M10.

Comment 5

[David Hyatt]

I have an idea for doing this that might be pretty simple to implement.  I
recently added code that ensured that on a focus change resulting from a click
that the parent chain of the newly clicked item is crawled for an
nsIFocusableContent.  If one is found, then the focus gets set to that object.
Regardless, the current node loses focus.

So here's the idea.  Add a new method to nsIFocusableContent, e.g., AllowsFocus.
For special chrome elements like toolbars, this method could return false.  Then
we wouldn't lose focus.

I'm willing to try this out if joki is swamped.

Comment 6

[buster]

I don't think hyatt's it a complete solution.  While that will stop menu items,
tool bar buttons, etc. from stealing focus, it doesn't address dialogs.  We
would still have the issue where the content area needs to know it's losing
focus to a dialog (or more properly, to some as-yet-unnamed setof things of
which dialogs might not be the only member...)
To understand why this matters, consider the "Find" dialog.  When the user
interacts with the find dialog, the content area must still show selection even
though it doesn't have focus.  Otherwise, Find is pretty useless.  Focus will be
owned by one of the controls of the Find dialog.

Comment 7

[chris hofmann]

any decisions or fixes ready for this?

Comment 8

[joki (gone)]

Okay, I've talked to hyatt about this.  The current situation is that hyatt is
going to attempt his current solution.  As buster points out, this does not
handle the dialog window case.  We don't have a good answer on that one yet.
We'll keep working on it.  For now, I'm going to reassign this to hyatt so we
have a placemarker for the stuff he's working on.  After that's done I'll take
it back and we'll try to find a solution for the dialog issue but that part
will happen post M10

Comment 9

[chris hofmann]

m11

Comment 10

[leger]

Putting on [PDT+]radar.

Comment 11

[Peter Trudelle]

reassigning to saari

Comment 12

[David Hyatt]

saari, typing for hyatt -
Look at the way selection works in 4.x today... selection doesn't change. This
isn't a dogfood issue for the Find dialog example. The rest of the issues will
be fixed with my landing in M12.

Comment 13

[saari (gone)]

I landing the changes that fix all but the dialog case... which I commented on in
bug 11425 which is more focused on that problem. So, I'm marking this a dup of
that bug.


*** This bug has been marked as a duplicate of 11425 ***

Comment 14

[ckritzer (gone)]

Marking VERIFIED DUPLICATE per sarri's comments.