Created attachment 360084 [details] Unsupports inputmode=none for now

<rdar://problem/47406553>

(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.