675491 - When an input value is remembered, its direction should be remembered too

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[Aharon (Vladimir) Lanin]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.41 Safari/535.1




Expected results:

The HTML5 spec (http://dev.w3.org/html5/spec/Overview.html#the-session-history-of-browsing-contexts) now contains the following note:

"User agents that persist the value of form controls are encouraged to also persist their directionality (the value of the element's dir attribute). This prevents values from being displayed incorrectly after a history traversal when the user had originally entered the values with an explicit, non-default directionality."

This change was made as a result of http://www.w3.org/Bugs/Public/show_bug.cgi?id=10823, which was filed on the basis of http://www.w3.org/International/docs/html-bidi-requirements/#remember-input-dir. Here is the proposal made there:

"The HTML specification should state that whenever a user agent stores a user-provided <input> or <textarea> text value for later use (such as auto-completion), it should also store the nominal direction value the element had when displaying this value. This may be the original direction of the element, or may have been set by the user for that value via the user agent's UI, or may have been set for that value by page scripts. If the user agent later recalls and displays this value, e.g. in an auto-completion dropdown, it should be displayed in its stored direction. If the value is assigned to an element, the element's dir value should be set to its stored direction."

Please note that the spec is somewhat ambiguous in its formulation, namely "directionality (the value of the element's dir attribute)". The element's dir attribute may have the value "ltr", "rtl", or "auto" - or it may be entirely absent, in which case the element inherits its directionality (but not its dir attribute). An element's directionality, on the other hand is always either ltr or rtl - never auto or undefined. The better interpretation for the HTML5 spec is probably to use the element's dir attribute when it is present and valid, not its directionality. That way, if the dir attribute was originally auto (and was not explicitly set by the user or page scripts), it will stay auto after a history traversal, so if the user then changes it to a value of the opposite direction, its directionality will be reevaluated, instead of being left equal to that of the previous value. However, for an input without a dir attribute, it is probably best to remember the element's directionality.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Global history is what shows up in urlbar searches and the history menu.

Form state persistence is just part of the DOM.

We save various other pieces of state already (e.g. disabled state), so adding directionality might not be too bad... if it's known at the point when we're saving state.  Directionality is a property of the style, not just of the DOM, and we may no longer have styles and boxes and such available at the point during page teardown when state gets saved.

Furthermore, if an input is display:none it won't have styles available either.  The spec seems to not consider this case; maybe it should.

Comment 2

[Aharon (Vladimir) Lanin]

(In reply to comment #1)
> Directionality is a property of the style, not
> just of the DOM, and we may no longer have styles and boxes and such
> available at the point during page teardown when state gets saved.
> 
> Furthermore, if an input is display:none it won't have styles available
> either.  The spec seems to not consider this case; maybe it should.

I do not think that style is really all that important here. Directionality is more than a matter of presentation, so the recommended way to indicate it in a page is using HTML mark-up, not style. And if the user sets the direction on the input explicitly (Ctrl-Shift-X), the dir attribute should be set appropriately too (see https://bugzilla.mozilla.org/show_bug.cgi?id=675579), according to the HTML5 spec. So, if this feature ignores style, and only deals with the input's directionality as defined by HTML5, it is good enough, IMO.

Comment 3

[(no longer active)]

Fabien, can you work on this, please?  The code responsible for this is nsEditor::SwitchTextDirection.  For firing the input event, you should call FireOnInput on the element's frame, if available (see nsTextInputListener::EditAction for one and currently the only example).

Comment 4

[(no longer active)]

(In reply to comment #3)
> Fabien, can you work on this, please?  The code responsible for this is
> nsEditor::SwitchTextDirection.  For firing the input event, you should call
> FireOnInput on the element's frame, if available (see
> nsTextInputListener::EditAction for one and currently the only example).

Oh, this was totally the wrong bug; sorry for the noise!

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.