Open
Bug 1143029
Opened 10 years ago
Updated 3 years ago
Contenteditable link loses focus immediately on click on pseudo-content, if the 'focus' handler has any reflow-causing operations
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
NEW
People
(Reporter: listtad, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
|
1.07 KB,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045
Steps to reproduce:
I understand it's quite a rare situation.
1. Create a link.
2. Make it contenteditable
3. In CSS give it any display in idle state and change the display value on :focus
4. Add some content with a pseudo element;
5. Assign a handler for a *focus* event, in which access some information like target's offsetTop, getBoundingClientRect() etc. (I was originally stuck on getBoundingClientRect(), but presumably Reflow-causing operations from this list http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html would do here)
6. Try clicking the content, generated by the pseudo element.
Attached is a testcase, the same it here: http://jsfiddle.net/L7dhzj6c/2/
Actual results:
The link doesn't get focus.
Some debugging has shown, that focus does happen but is lost immediately.
Furthermore, this happens only when the pseudo element's content is clicked. If the link has padding and a user clicks there, or on the link's actual content, the focus isn't lost
Expected results:
The link should get focused, with a cursor appearing.
Comment 1•10 years ago
|
||
Thanks for the testcase! I don't even know what component to move this into...
I've managed to reproduce this on the latest release(43.0) and latest Nightly(45.0a1). This test case works correctly on Chrome and IE.
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151208100201
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20151217072309
Considering this, I will mark this issue as New and assign the appropriate component.
If anyone considers that the component is not the right one, please change it to a more appropriate one.
Status: UNCONFIRMED → NEW
Component: Untriaged → Event Handling
Ever confirmed: true
| Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•