Bug 193040
| Summary: | HTMLInputElement.select() doesn't work in iOS Safari | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | shrpne <corsar89> |
| Component: | Forms | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | bfulgham, cdumez, corsar89, dbates, rniwa, webkit-bug-importer, wenson_hsieh |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 12 | ||
| Hardware: | iPhone / iPad | ||
| OS: | iOS 12 | ||
shrpne
HTMLInputElement.select() doesn't work in iOS Safari. While in desktop Safari it works fine.
For now, it's only modern browser without the support of `.select()` method.
`.setSelectionRange()` or `selectionStart` with `selectionEnd` should be used as workaround.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/46962874>
Chris Dumez
I can see there is not IOS specific code in our select implementation:
void HTMLTextFormControlElement::select(SelectionRevealMode revealMode, const AXTextStateChangeIntent& intent)
{
// FIXME: We should abstract the selection behavior into an EditingBehavior function instead
// of hardcoding the behavior using a macro define.
#if PLATFORM(IOS_FAMILY)
// We don't want to select all the text on iOS. Instead use the standard textfield behavior of going to the end of the line.
setSelectionRange(std::numeric_limits<int>::max(), std::numeric_limits<int>::max(), SelectionHasForwardDirection, revealMode, intent);
#else
setSelectionRange(0, std::numeric_limits<int>::max(), SelectionHasNoDirection, revealMode, intent);
#endif
}
Clearly, we have an implementation of HTMLInputElement.select() on all platforms. However, the iOS implementation is a bit different for some reason.
Ryosuke Niwa
Wenson, didn't we just fix this behavior recently?
Wenson Hsieh
(In reply to Ryosuke Niwa from comment #3)
> Wenson, didn't we just fix this behavior recently?
Yep, in https://bugs.webkit.org/show_bug.cgi?id=193758!
(Sorry for the forward dupe — I probably should've found this existing bug before filing a new one).
*** This bug has been marked as a duplicate of bug 193758 ***