Contenteditable does not set tabindex to 0
Reported by
felipe.n...@gmail.com,
Nov 1 2016
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0 Steps to reproduce the problem: 1. Open the attached file or go to http://codepen.io/anon/pen/WGVjoR 2. Look for the entry under `content-editable-div' which states "tabIndex: -1" What is the expected behavior? tabIndex should be 0 for tabbable elements: From the spec[1]: > Modulo platform conventions, it is suggested that for the following elements, the tabindex focus flag be set: > * [snip] > * Editing hosts and also[2]: **editing host**: An editing host is a node that is an HTML element with a contenteditable attribute set to something else than the false state. [1]: https://www.w3.org/TR/html5/editing.html#sequential-focus-navigation-and-the-tabindex-attribute [2]: https://w3c.github.io/editing/contentEditable.html#terminology What went wrong? The tabIndex attribute was incorrectly set on the div with contenteditable Did this work before? N/A Does this work in other browsers? Yes Chrome version: <Copy from: 'about:version'> Channel: stable OS Version: 10.0 Flash Version: There's a similar bug for Firefox[3], but IE and Edge give the correct results [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1190261
,
Nov 3 2016
Hmm, not sure what's going on that's making the test file and the codepen different. It's literally the same code on both. The correct behavior is that `tabIndex` should be 0, like Canary on codepen, but when I submitted the report I was always seeing -1. I've just upgraded from 54.0.2840.71 m (64-bit) to .87 m and am now seeing the same odd behavior.
,
Nov 4 2016
,
Nov 7 2016
Tested this issue on Windows-10 using chrome reported version #54.0.2840.87 and latest canary #56.0.2911.0. Following are the steps followed to reproduce the issue. ------------ 1. Navigated to URL: http://codepen.io/anon/pen/WGVjoR 2. Checked the entry under `content-editable-div'. 3. Observed that the value at 'content-editable-div' was 0(expected). 4. Refreshed the page and checked again the value at 'content-editable-div'. This time the value was -1. Attached a screencast for reference. Reporter@ - This issue seems to be intermittent. Could you please provide more consistent repro steps, for better triaging of the issue. Thanks....!!
,
Nov 7 2016
Here's a slimmed-down version of the test file which consistently shows the issue. Corresponding code pen here: http://codepen.io/anon/pen/NbPoOW That said, the test file is very simple and should be deterministic -- the fact that the output changes on reload is itself a bug.
,
Nov 9 2016
,
Nov 9 2016
felipe.nospam.ochoa@ thanks for the detailed report and reproduction cases. I took a brief look at this and found that .tabIndex doesn't look into "contenteditable" attribute directly, but uses isRootEditableElement() in EditingUtilities.cpp, which does more complex checking.
,
Sep 29 2017
,
Sep 29 2017
,
Oct 4 2017
,
Oct 17 2017
bulk edit to remove owner=me where I'm not actively looking at.
,
Oct 17 2017
mark it available.
,
Oct 17
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 19
Safari correctly returns 0.
,
Dec 27
This issue is reproduced on latest chromium. If this is issue is still valid and no one working on this issue, I want to pick this issue up. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by hdodda@chromium.org
, Nov 2 2016Labels: Needs-Feedback
588 KB
588 KB View Download
602 KB
602 KB View Download
833 KB
833 KB View Download
520 KB
520 KB View Download