Closed Bug 1099208 Opened 10 years ago Closed 3 years ago

Textbox loses selection and caret when stopping propagation on focus event in capturing event handler on document/window/documentElement

Categories

(Core :: DOM: Editor, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: info, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141113004001

Steps to reproduce:

I focused a text box in ff x dev edition. http://jsfiddle.net/bhkqnv0w/


Actual results:

Nothing.


Expected results:

The caret should be visible and selections in should be be in selected style.
Wrong link above, sorry!

And same goes for document and document body

document: http://jsfiddle.net/bhkqnv0w/1/
window: http://jsfiddle.net/bhkqnv0w/2/
document.body: http://jsfiddle.net/bhkqnv0w/1/
I'm confused. Your testcase calls stopPropagation(), and the handler is attached as a capturing handler. So the focus never arrives in the textbox. Why is this surprising or wrong?
Flags: needinfo?(info)
Keywords: testcase
Product: Firefox → Core
Version: unspecified → Trunk
I'm confused too :-). FF behaves different than all other browsers...

I tested on Windows: 
- Chrome 38.0.2125.111 m
- IE 11.0.9600.17416
- Opera 25.0.1614.71

Showing the caret has nothing to do with the focus event. 
Seems like FF uses the event to set cursor/caret/selection/range.
Flags: needinfo?(info)
Olli, can you help? :-)
Component: Untriaged → DOM: Events
Flags: needinfo?(bugs)
Summary: Textbox loses selection and caret when focus event on window object is subscribed → Textbox loses selection and caret when stopping propagation on focus event in capturing event handler on document/window/documentElement
Interesting. Sounds like an editor issue to me
Component: DOM: Events → Editor
Flags: needinfo?(bugs)
Yes, I blame nsEditorEventListener::InstallToEditor().
(In reply to Olli Pettay [:smaug] from comment #6)
> Yes, I blame nsEditorEventListener::InstallToEditor().

Should the focus and blur events, at least, "just" use system event listeners, and then check getDefaultPrevented?
Looks like a "recent" regression from bug 283897.

A patch coming.
Attached patch editor_system_events.diff (obsolete) — Splinter Review
https://tbpl.mozilla.org/?tree=Try&rev=28b689b31946

This may break quite some tests.
Another option is to not use system group, but current window's parent target and
default group's capture phase.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually, might not break anything. But let's wait for the test results.
Flags: needinfo?(bugs)
(In reply to Olli Pettay [:smaug] from comment #10)
> Actually, might not break anything. But let's wait for the test results.

Hmm, if a focus event handler of web apps sets selection range in <input> or <textarea> wouldn't it break the range at handling focus event in system group? I guess that nsFocusManager or something needs to notify editor of setting focus *before* dispatching DOM focus event.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #11)
> Hmm, if a focus event handler of web apps sets selection range in <input> or
> <textarea> wouldn't it break the range at handling focus event in system
> group?
I don't see what you mean with this.


> I guess that nsFocusManager or something needs to notify editor of
> setting focus *before* dispatching DOM focus event.
This is why I was thinking the other approach to handle these events during capture phase of
default group, but add event listener to nsPIDOMWindow::GetParentTarget
Flags: needinfo?(bugs)
Flags: needinfo?(bugs)
https://tbpl.mozilla.org/php/getParsedLog.php?id=56978024&tree=Try&full=1#error0

Masayuki, that show rather ugly bug in IME handling currently. We dispatch a composition event from
focus event listener. We should do it either before or after the focus event.
Flags: needinfo?(masayuki)
Hmm, will that be fixed if we call IMEStateManager::OnFocusInEditor() from ESM::PostHandleEvent() when it receives focus event? If so, I guess it works.
Flags: needinfo?(masayuki)
Or, just keep calling it from (new) "focus" event handler but you make new it listen in the system group.

The testcase seems to be working now. Please reopen if needed.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bugs)
Resolution: --- → WORKSFORME

Perhaps, dup of bug 1450055, but just marking this as depending on it.

Depends on: 1450055
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: