Bug 193811 - iOS: inputmode="none" disables hardware keyboard's globe key
Summary: iOS: inputmode="none" disables hardware keyboard's globe key
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Ryosuke Niwa
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-01-24 20:40 PST by Ryosuke Niwa
Modified: 2019-01-31 08:32 PST (History)
8 users (show)

See Also:


Attachments
Unsupports inputmode=none for now (13.21 KB, patch)
2019-01-24 22:59 PST, Ryosuke Niwa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2019-01-24 20:40:35 PST
Setting inputmode="none" makes it impossible to change the keyboard type in hardware keyboard.
Comment 1 Ryosuke Niwa 2019-01-24 22:59:17 PST
Created attachment 360084 [details]
Unsupports inputmode=none for now
Comment 2 Ryosuke Niwa 2019-01-24 23:05:05 PST
<rdar://problem/47406553>
Comment 3 Wenson Hsieh 2019-01-25 08:22:33 PST Comment hidden (obsolete)
Comment 4 Wenson Hsieh 2019-01-25 08:25:26 PST
(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).
Comment 5 Ryosuke Niwa 2019-01-25 12:16:50 PST
(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...
Comment 6 Wenson Hsieh 2019-01-25 12:17:39 PST
(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 7 Ryosuke Niwa 2019-01-25 12:45:05 PST
Comment on attachment 360084 [details]
Unsupports inputmode=none for now

Clearing flags on attachment: 360084

Committed r240497: <https://trac.webkit.org/changeset/240497>
Comment 8 Ryosuke Niwa 2019-01-25 12:45:08 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Shawn Roberts 2019-01-30 12:13:50 PST
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)
Comment 10 Ryosuke Niwa 2019-01-30 20:01:46 PST
I think you commented on a wrong bug? This change only affects iOS code so it can't possibly regress a macOS debug test.
Comment 11 Shawn Roberts 2019-01-31 08:32:56 PST
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.