Oops!
<rdar://problem/26232464>
Created attachment 280156 [details] Proposed Fix
Comment on attachment 280156 [details] Proposed Fix It seems like this should be API-testable?
Comment on attachment 280156 [details] Proposed Fix Attachment 280156 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/1413508 Number of test failures exceeded the failure limit.
Created attachment 280160 [details] Archive of layout-test-results from ews107 for mac-yosemite-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
(In reply to comment #3) > Comment on attachment 280156 [details] > Proposed Fix > > It seems like this should be API-testable? It probably is, but I was hesitant to write one since the simulated NSEvents to send will depend on the system keyboard layout. I don't think we can assume a specific keyboard layout? If this isn't an issue, I would have to postpone writing a test until later this week at least. It could take a bit of time to get it right since we don't have any other WKWebView tests that simulate key events.
Is this bug somehow specific to Web Inspector, or are all WKWebViews affected? Simulating raw keydowns to have them translated by the OS would be wrong, as you correctly suggested. But simply verifying that -inputContext returns non-null when the web view has editable text focused would be a pretty solid regression test.
(In reply to comment #6) > (In reply to comment #3) > It probably is, but I was hesitant to write one since the simulated NSEvents > to send will depend on the system keyboard layout. I don't think we can > assume a specific keyboard layout? > > If this isn't an issue, I would have to postpone writing a test until later > this week at least. It could take a bit of time to get it right since we > don't have any other WKWebView tests that simulate key events. Those reasons don’t seem to be sufficient reasons not to write a test now. A test that works only with US keyboard layout is likely OK.
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #3) > > It probably is, but I was hesitant to write one since the simulated NSEvents > > to send will depend on the system keyboard layout. I don't think we can > > assume a specific keyboard layout? > > > > If this isn't an issue, I would have to postpone writing a test until later > > this week at least. It could take a bit of time to get it right since we > > don't have any other WKWebView tests that simulate key events. > > Those reasons don’t seem to be sufficient reasons not to write a test now. A > test that works only with US keyboard layout is likely OK. I will write the regression test as proposed by Alexey as it's very straightforward and should cover the same issue.
Created attachment 280302 [details] Proposed Fix (with Test)
Comment on attachment 280302 [details] Proposed Fix (with Test) r=me with the test disabled on iOS.
(In reply to comment #11) > Comment on attachment 280302 [details] > Proposed Fix (with Test) > > r=me with the test disabled on iOS. Oops, OK.
Committed r201592: <http://trac.webkit.org/changeset/201592>