Open Bug 962015 Opened 11 years ago Updated 2 years ago

Ctrl-Shift-X with the caret in a contenteditable sets the dir attribute on the body element

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

People

(Reporter: aharon, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: rtl)

Attachments

(1 file)

Testcase
(deleted), text/html
Details
Reproduction steps: 1. Navigate to: data:text/html,<html><body><div>Inside the border is a contenteditable.</div><div style="border:thin solid black"><div contenteditable="true">Edit me!</div></div></body></html> 2. Click on the "Edit me!". 3. Press Ctrl-Shift-X Expected outcome: - The text inside the border starts to be displayed RTL, i.e. appearing as: !Edit me - The display of the rest of the page is unaffected. Actual outcome (FF 26 and Nightly 29.0a1 (2014-01-18)): The whole page is displayed RTL! That's because a dir="rtl" attribute is added to the <body> element. Actual outcome in IE 11 (using Ctrl-RightShift in step 3): As expected. A dir="rtl" attribute is placed on the contenteditable div. Actual outcome in Chrome 32 (using Ctrl-RightShift in step 3): As expected. A new <div style="direction: rtl;"> is created around the "Edit me!" text. A Ctrl-LeftShift then changes the style to "direction: ltr;" on the now existing div. Chrome's behavior is nice (i.e. better than IE) in that it lets the user control the directionality of each paragraph separately. But their using the direction style to achieve that effect is silly - it should be the dir attribute, same as they do on <input> and <textarea>. Mozilla should place the dir attribute either on the contenteditable (like IE) or on the closest block element *within* the contenteditable, creating one if necessary (like Chrome, except using the dir attribute instead of style). IMHO, the latter is preferable, but either is vastly superior to the current behavior.
Blocks: 962022
I'm not convinced that the behavior of Chrome is better than IE here. It will lead to confusing results if the page does things such as use <br> tags to separate "paragraphs" etc.
Component: DOM → Editor
Keywords: rtl
Yeah, I forgot that Mozilla prefers to use <br> for newlines, so I guess that the Chrome way of doing things would not work particularly well here. Ok, the IE way will do.
Attached file Testcase (deleted) —
Tomer pointed out that this is causing visible and ugly changes to page layout when using Switch Text direction on Facebook and Twitter. I made this minimized testcase and then discovered that the bug was already filed. N.B: the testcase requires bidi.browser.ui=true in about:config

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5

See https://github.com/whatwg/html/issues/9244

:vhilla is currently working on dirname. I discovered this issue while testing directionality changes. It seems good to fix this, and it will be more prevalent for users when/if https://bugzilla.mozilla.org/show_bug.cgi?id=1830864 is fixed.

Flags: needinfo?(jstutte)

(In reply to Simon Pieters [:zcorpan] from comment #5)

See https://github.com/whatwg/html/issues/9244

:vhilla is currently working on dirname. I discovered this issue while testing directionality changes. It seems good to fix this, and it will be more prevalent for users when/if https://bugzilla.mozilla.org/show_bug.cgi?id=1830864 is fixed.

Happy to change severity/priority to S3/P3 for now; we shall follow once the spec issue is resolved. I assume there's no storage/worker support required, so clearing NI on Jens.

Severity: S4 → S3
Flags: needinfo?(jstutte)
Priority: P5 → P3

It should be defined clearly that which element's dir should be changed.

One of the differences between Gecko vs. the other browsers is, Gecko does not move focus automatically when selection is moved from outer contenteditable to inner contenteditable when contenteditable elements are nested with contenteditable="false" element. I guess that it's better to define that change dir of the nearest editing host from Selection.anchorNode or Selection.focusNode. If there is no selection ranges, the focused element should be used. And I also think that it should be defined that whether focused element or editing host's dir should be changed when an editable element in contenteditable has focus, e.g., <div contenteditable><button>label</button></div>.

And if you standardize new execCommand for direction change, it's be able to check in WPT without considering shortcut keys in JS. But this is optional.

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

Attachment

General

Creator:
Created:
Updated:
Size: