Bug 195626 - [iOS] No DOM keypress event emitted for cursor key commands when non-editable element is focused
Summary: [iOS] No DOM keypress event emitted for cursor key commands when non-editable...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Local Build
Hardware: iPhone / iPad iOS 12
: P2 Normal
Assignee: Daniel Bates
URL:
Keywords: InRadar, PlatformOnly
Depends on:
Blocks: 190571
  Show dependency treegraph
 
Reported: 2019-03-12 09:42 PDT by Daniel Bates
Modified: 2019-03-18 10:59 PDT (History)
4 users (show)

See Also:


Attachments
Patch and tests (71.21 KB, patch)
2019-03-12 10:44 PDT, Daniel Bates
no flags Details | Formatted Diff | Diff
To land (70.23 KB, patch)
2019-03-18 10:59 PDT, Daniel Bates
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Bates 2019-03-12 09:42:22 PDT
Steps To Reproduce:

The following assumes you are using an iOS device with a hardware keyboard.

1. Visit <https://unixpapa.com/js/testkey.html>.
2. Ensure modifiers and DOM 3 attributes are shown.
3. Press Control + a.

No keypress event is emitted for 'a'. But a keypress event should be emitted as we do on Mac.
Comment 1 Daniel Bates 2019-03-12 09:42:51 PDT
<rdar://problem/48810626>
Comment 2 Daniel Bates 2019-03-12 10:44:03 PDT
Created attachment 364404 [details]
Patch and tests
Comment 3 Daniel Bates 2019-03-12 10:49:59 PDT
Bots will likely be red. Will fix up patch based on the bots.
Comment 4 Wenson Hsieh 2019-03-15 16:35:30 PDT
Comment on attachment 364404 [details]
Patch and tests

View in context: https://bugs.webkit.org/attachment.cgi?id=364404&action=review

> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:2725
> +    // UIKit IPI do not forward to the WebView.

As we chatted about earlier, this could read a bit nicer (e.g. "These are UIKit IPI methods, so we don't forward them to the web view.")
Comment 5 Daniel Bates 2019-03-18 10:44:27 PDT
(In reply to Daniel Bates from comment #3)
> Bots will likely be red. Will fix up patch based on the bots.

Nope, they won't because we skip fast/events/ios on OpenSource per <https://trac.webkit.org/browser/trunk/LayoutTests/TestExpectations?rev=242724#L37> :D and no longer mark this directory as Pass in any iOS TestExpectation file o_O. That works out well for me and the tests in this patch since they depend on UIKit fixes. However, that appears to be a regressions from <https://trac.webkit.org/changeset/190368/webkit#file7>.
Comment 6 Daniel Bates 2019-03-18 10:54:58 PDT
(In reply to Daniel Bates from comment #5)
> (In reply to Daniel Bates from comment #3)
> > Bots will likely be red. Will fix up patch based on the bots.
> 
> Nope, they won't because we skip fast/events/ios on OpenSource per
> <https://trac.webkit.org/browser/trunk/LayoutTests/
> TestExpectations?rev=242724#L37> :D and no longer mark this directory as
> Pass in any iOS TestExpectation file o_O. That works out well for me and the
> tests in this patch since they depend on UIKit fixes. However, that appears
> to be a regressions from
> <https://trac.webkit.org/changeset/190368/webkit#file7>.

The tests were timing out on so we removed the PASS entry for fast/events/ios from the iOS TestExpectation file in <https://trac.webkit.org/changeset/194059/webkit> (bug #152134). So, now we do not run these tests at all, at least on the OpenSource bots.
Comment 7 Daniel Bates 2019-03-18 10:59:29 PDT
Created attachment 365031 [details]
To land
Comment 8 Daniel Bates 2019-03-18 10:59:57 PDT
Committed r243082: <https://trac.webkit.org/changeset/243082>