This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Checked in as WHATWG revision r7716. Check-in comment: Clarify 'do not apply'. http://html5.org/tools/web-apps-tracker?from=7715&to=7716
> 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!
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.