Open
Bug 740813
Opened 13 years ago
Updated 2 years ago
Tabbing to a design mode frame focuses its document element
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
NEW
People
(Reporter: neil, Unassigned)
Details
Attachments
(1 file)
733 bytes,
text/html
|
Details |
Steps to reproduce problem:
1. Create a design mode frame
2. Tab to it
Expected result: no element has focus
Actual result: document element has focus
Additional information: clicking the frame does not focus an element.
In fact, shift+tabbing after clicking has no visual effect because internally the document element gets focus again.
Reporter | ||
Comment 1•13 years ago
|
||
Because this is content you never see a null activeElement, however you should notice that tabbing to the design mode frame should focus the HTML element while clicking on it will cause activeElement to default to the BODY element.
Comment 2•12 years ago
|
||
In case anyone's interested... An impact report:
I created/maintain a Firefox/Thunderbird extension that converts the contents of an email body. One of the steps when the user triggers the action is to find the edit element by drilling down through activeElements/contentDocuments to get to the edit box (iframe with contenteditable body). Code that does that here: https://github.com/adam-p/markdown-here/blob/master/src/common/markdown-here.js#L22
Because of this Mozilla bug, there was a bug in my extension where the users's mail body would be lost when sending, even though it visually seemed to be there when composing. My bug here: https://github.com/adam-p/markdown-here/issues/31
I had to hack around this buggy behaviour with a special check (you can see it at the first link above).
Assignee | ||
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•