Bug 158227 – REGRESSION(r191907): Can't enter combining diacritic marks in Web Inspector fields

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Blaze Burg]

Oops!

[Blaze Burg]

<rdar://problem/26232464>

[Blaze Burg]

Created attachment 280156 [details]
Proposed Fix

[Tim Horton]

Comment on attachment 280156 [details]
Proposed Fix

It seems like this should be API-testable?

[Build Bot]

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.

[Build Bot]

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

[Blaze Burg]

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

[Alexey Proskuryakov]

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.

[Darin Adler]

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

[Blaze Burg]

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

[Blaze Burg]

Created attachment 280302 [details]
Proposed Fix (with Test)

[Alexey Proskuryakov]

Comment on attachment 280302 [details]
Proposed Fix (with Test)

r=me with the test disabled on iOS.

[Blaze Burg]

(In reply to comment #11)
> Comment on attachment 280302 [details]
> Proposed Fix (with Test)
> 
> r=me with the test disabled on iOS.

Oops, OK.

[Blaze Burg]

Committed r201592: <http://trac.webkit.org/changeset/201592>