862989 - "Switch Text Direction" misbehaves with contenteditable

Status: NEW

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

Description

[Uri Bernstein]

Attachment: Testcase

"Switch Text Direction" (ctrl-shift-x, or using the context menu) misbehaves in contenteditable elements, specifically when they have a "direction" style set.

See attached testcase.

There might be two different bugs here:

1. "Switch Text Direction" affects the entire page, not just the edited element.
2. If the edited element has a "direction" style set explicitly, "Switch Text Direction" does not affect it (but if it has dir="", it is affected).

Comment 1

[Amir Aharoni]

Confirmed - the test case indeed works strangely. Tested in Firefox 20 on Fedora 18.

I originally complained about this because I couldn't make Ctrl-Shift-X work in GMail's new compose interface.

Now that I saw the test case, I recall that I noticed something very similar in Twitter in Hebrew.

Comment 2

[Amir Aharoni]

Confirmed also on Nightly 23.0a1 (2013-04-12).

Comment 3

[(no longer active)]

Oh dear!  In nsEditor::SwitchTextDirection, we call GetRoot() and set the dir attribute on it.  I wrote that code for the plaintext editor, whereas you want to use GetActiveEditingHost() for the HTML editor.

Comment 4

[(no longer active)]

So, do we even want to support Ctrl+Shift+X for HTML editors?

Comment 5

[Amir Aharoni]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #4)
> So, do we even want to support Ctrl+Shift+X for HTML editors?

[Deep sigh.]

A little braindump:
* In word processors like Microsoft Word and LibreOffice the corresponding shortcut Ctrl-Shift changes the direction of the paragraph or of the selection.
* In plain text editors that support it, such as Windows Notepad and most browsers' plain textareas Ctrl-Shift(-X) changes the direction of the whole text.
* It makes perfect sense to have web-based word processors like Google Docs do something similar to desktop word processors and have a shortcut that changes the direction of the current paragraph or the current selection. It probably shouldn't change the whole text. (I care about this part very strongly, because I am involved in defining the RTL behavior for MediaWiki's forthcoming VisualEditor.)
* Intuitively, plain text that is conteneditable should behave like plain text and not like a word processor. How to implement it - I'm not sure.

Is there anything at all about these issues in any existing or draft web standard?

Comment 6

[(no longer active)]

(In reply to comment #5)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #4)
> > So, do we even want to support Ctrl+Shift+X for HTML editors?
> 
> [Deep sigh.]
> 
> A little braindump:
> * In word processors like Microsoft Word and LibreOffice the corresponding
> shortcut Ctrl-Shift changes the direction of the paragraph or of the selection.
> * In plain text editors that support it, such as Windows Notepad and most
> browsers' plain textareas Ctrl-Shift(-X) changes the direction of the whole
> text.
> * It makes perfect sense to have web-based word processors like Google Docs do
> something similar to desktop word processors and have a shortcut that changes
> the direction of the current paragraph or the current selection. It probably
> shouldn't change the whole text. (I care about this part very strongly, because
> I am involved in defining the RTL behavior for MediaWiki's forthcoming
> VisualEditor.)
> * Intuitively, plain text that is conteneditable should behave like plain text
> and not like a word processor. How to implement it - I'm not sure.
> 
> Is there anything at all about these issues in any existing or draft web
> standard?

Unfortunately not.  This is obviously desirable form the user's perspective when the right thing happens, but there's a whole lot of cases where what to do may not be trivial, for example:

* What should be done for inline contentEditable fields?
* What element needs to accept the dir attribute, should it be the first block parent at the selection point? or the contentEditable document? The former would probably make more sense, but it can break pages that do not expect it...
* What should be done if the dir attribute is already present?  What if it's present and its value is set to auto?  What if the attribute is present on a descendant of the element which will accept the attrib?

This needs some serious spec'ing....

Do you know if other UAs implement something like this?

Comment 7

[Amir Aharoni]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #6)
> * What should be done for inline contentEditable fields?

As in, a contentEditable span inside a contentEditable div? There should be a way to set its direction. I am not aware of any fully graphical user agent that allows it, although Safari kinda tries (or at least tried in the past). It isn't available in any desktop word processor either; OpenDocument disregards this completely, and Microsoft Word does some magic by auto-detecting language switching in Windows, but the user cannot really control it.

> * What should be done if the dir attribute is already present?  What if it's
> present and its value is set to auto?  What if the attribute is present on a
> descendant of the element which will accept the attrib?

Ctrl-Shift-X should change it. If there is a way to save it, it should be possible (isn't that what dirname is for?)

> This needs some serious spec'ing....

Absolutely, although the original problem description and test case in this bug report should be enough to make something saner than what Firefox does now.

Comment 8

[(no longer active)]

(In reply to comment #7)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #6)
> > * What should be done for inline contentEditable fields?
> 
> As in, a contentEditable span inside a contentEditable div? There should be a
> way to set its direction. I am not aware of any fully graphical user agent that
> allows it, although Safari kinda tries (or at least tried in the past). It
> isn't available in any desktop word processor either; OpenDocument disregards
> this completely, and Microsoft Word does some magic by auto-detecting language
> switching in Windows, but the user cannot really control it.

Yes, that is what I meant...

> > * What should be done if the dir attribute is already present?  What if it's
> > present and its value is set to auto?  What if the attribute is present on a
> > descendant of the element which will accept the attrib?
> 
> Ctrl-Shift-X should change it. If there is a way to save it, it should be
> possible (isn't that what dirname is for?)
> 
> > This needs some serious spec'ing....
> 
> Absolutely, although the original problem description and test case in this bug
> report should be enough to make something saner than what Firefox does now.

Right.  The real problem here is that nobody is currently working on the editing spec, and if somebody were, we would also need people from different engines to talk about this and see if it makes sense for them to implement, and those people don't really exist either. :(

Comment 9

[Jens Stutte [:jstutte]]

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

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.