Bug 20171 - There is no clear statement when APIs for the text field selections can be applied
There is no clear statement when APIs for the text field selections can be ap...
Status: RESOLVED FIXED
Product: WHATWG
Classification: Unclassified
Component: HTML
unspecified
PC Windows NT
: P2 major
: Unsorted
Assigned To: Ian 'Hixie' Hickson
contributor
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-30 12:11 UTC by Egor Khalimonenko
Modified: 2013-02-11 17:09 UTC (History)
2 users (show)

See Also:


Attachments
Different behavour between {FireFox, Opera} and Chrome (1.48 KB, text/html)
2012-11-30 12:11 UTC, Egor Khalimonenko
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Egor Khalimonenko 2012-11-30 12:11:51 UTC
Created attachment 1251 [details]
Different behavour between {FireFox, Opera} and Chrome

Spec say: "For input elements, calling these methods while they don't apply, and getting or setting these attributes while they don't apply, must throw an InvalidStateError exception."
No browser has implemented InvalidStateError error. And the is no clear statement, that does "while they don't apply" mean.

Can we call element.setSelectionRange while element has no focus?

The are two different model in browsers I tested:

1. FireFox and Opera, set selectionStart and selectionStart values without setting focus.
2. Chrome, set selectionStart and selectionStart values with setting focus to current element.

Both behavior seams wrong. But Chrome behavior is worse, due it broke events queue.
Comment 1 contributor 2013-02-09 21:35:15 UTC
Checked in as WHATWG revision r7716.
Check-in comment: Clarify 'do not apply'.
http://html5.org/tools/web-apps-tracker?from=7715&to=7716
Comment 2 Ian 'Hixie' Hickson 2013-02-09 21:56:35 UTC
> attachment 1251 [details]

Looks like Opera's the one that gets this right.


> Spec say: "For input elements, calling these methods while they don't apply,
> and getting or setting these attributes while they don't apply, must throw
> an InvalidStateError exception."
> No browser has implemented InvalidStateError error.

They vary in what exception they throw, but I got an exception in all the browsers I tested (Firefox, Chrome, Opera) on this test:
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2090


> And the is no clear statement, that does "while they don't apply" mean.

I've hyperlinked it to a clearer definition. Let me know if it's still not clear.


> Can we call element.setSelectionRange while element has no focus?

Sure, the spec doesn't say anything about focus having an effect here.


> The are two different model in browsers I tested:
> 
> 1. FireFox and Opera, set selectionStart and selectionStart values without
> setting focus.
> 2. Chrome, set selectionStart and selectionStart values with setting focus
> to current element.
> 
> Both behavior seams wrong. But Chrome behavior is worse, due it broke events
> queue.

Chrome definitely is wrong here, yes. Please file a bug on Chrome!


Let me know (by commenting on this bug and reopening it) if you see anything wrong in the spec at this point. Thanks!
Comment 3 Egor Khalimonenko 2013-02-11 17:09:42 UTC
There was a misunderstanding due I don't specify the type of input. My original question was about 'input type=text' or 'textarea'. I was frustrated by Chrome behavior and Spec was the last hope to understand the right behavior.

But it's still unclean for me. Can browser apply setSelectionRange on input[type=text] element that doesn't have focus? I guess it depend on browser, but Spec need to say something about it. Something like: "User agent can apply selectionRange methods on inactive input element, but without changing current active input element".

And thanks for http://html5.org/r/7716 clarification, it's important for me too.