Summary: | iOS: inputmode="none" disables hardware keyboard's globe key | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> | ||||
Component: | DOM | Assignee: | Ryosuke Niwa <rniwa> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | cdumez, jlewis3, ryanhaddad, simon.fraser, sroberts, thorton, tsavell, wenson_hsieh | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Ryosuke Niwa
2019-01-24 20:40:35 PST
Created attachment 360084 [details]
Unsupports inputmode=none for now
Comment on attachment 360084 [details]
Unsupports inputmode=none for now
Should we additionally remove the inputMode attribute from the HTMLElement interface?
(In reply to Wenson Hsieh from comment #3) > Comment on attachment 360084 [details] > Unsupports inputmode=none for now > > Should we additionally remove the inputMode attribute from the HTMLElement > interface? Oops, sorry — what I meant to say was, should we additionally remove support for inputmode="none" when parsing/canonicalizing the inputmode attribute? (i.e. the logic in InputMode.cpp). (In reply to Wenson Hsieh from comment #4) > (In reply to Wenson Hsieh from comment #3) > > Comment on attachment 360084 [details] > > Unsupports inputmode=none for now > > > > Should we additionally remove the inputMode attribute from the HTMLElement > > interface? > > Oops, sorry — what I meant to say was, should we additionally remove support > for inputmode="none" when parsing/canonicalizing the inputmode attribute? > (i.e. the logic in InputMode.cpp). Perhaps but I'm worried that such a change poses a more compatibility risk than not. Since inputmode is a hint, I think it's safer to ignore it. I could be proven wrong though... (In reply to Ryosuke Niwa from comment #5) > (In reply to Wenson Hsieh from comment #4) > > (In reply to Wenson Hsieh from comment #3) > > > Comment on attachment 360084 [details] > > > Unsupports inputmode=none for now > > > > > > Should we additionally remove the inputMode attribute from the HTMLElement > > > interface? > > > > Oops, sorry — what I meant to say was, should we additionally remove support > > for inputmode="none" when parsing/canonicalizing the inputmode attribute? > > (i.e. the logic in InputMode.cpp). > > Perhaps but I'm worried that such a change poses a more compatibility risk > than not. Since inputmode is a hint, I think it's safer to ignore it. I > could be proven wrong though... Fair enough. I guess we'll see! Comment on attachment 360084 [details] Unsupports inputmode=none for now Clearing flags on attachment: 360084 Committed r240497: <https://trac.webkit.org/changeset/240497> All reviewed patches have been landed. Closing bug. The following test is a flaky crash on MacOS Debug http/tests/resourceLoadStatistics/prune-statistics.html Flakiness Dashboard: https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2FresourceLoadStatistics%2Fprune-statistics.html Probable cause: Can reproduce crash starting with Debug build 240497 to current 240715 with the following command: run-webkit-tests http/tests/resourceLoadStatistics/prune-statistics.html --iterations 500 -f --debug --exit-after-n-failures=1 --no-retry-failures Crash log: https://build.webkit.org/results/Apple%20High%20Sierra%20Debug%20WK2%20(Tests)/r240710%20(6440)/http/tests/resourceLoadStatistics/prune-statistics-crash-log.txt Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.JavaScriptCore 0x000000010d3aeb10 WTFCrash + 16 (Assertions.cpp:255) 1 com.apple.JavaScriptCore 0x000000010d3aeb29 WTFCrashWithSecurityImplication + 9 2 com.apple.WebKit 0x0000000105a2a262 WTF::RefCountedBase::ref() const + 66 (RefCounted.h:43) I think you commented on a wrong bug? This change only affects iOS code so it can't possibly regress a macOS debug test. I apologize, I commented on this bug in error. (In reply to Ryosuke Niwa from comment #10) > I think you commented on a wrong bug? This change only affects iOS code so > it can't possibly regress a macOS debug test. |