sendEvent for key events generates inconsistent DOM key events

[laurentj]

ljouann...@gmail.com commented:

Which version of PhantomJS are you using? 1.8.1

What steps will reproduce the problem?

1. git clone https://github.com/laurentj/slimerjs.git
2. go into the test directory
3. run phantomjs phantomjs-test-keyevent.js

What is the expected output?

All tests should pass

What do you see instead?

Many tests are failing

Which operating system are you using?

Linux (Kubuntu 12.10) / Azerty keyboard

Did you use binary PhantomJS or did you compile it from source?

Binary

Please provide any additional information below.

Here are tests that are launched :

• https://github.com/laurentj/slimerjs/blob/master/test/test-webpage-keyevent.js
• https://github.com/laurentj/slimerjs/blob/master/test/test-webpage-keyevent2.js

(92 specs, hundreds 'expect' tests)

These tests files launch tests on webpage.sendEvent with various values on parameters, to send key events on the webpage. To summarize issues, many of failed tests show that we don't have the same behavior as in a "real" browser (Firefox, Chrome..): we don't receive same DOM events in the webpage as if we were in a real browser.

Here are these issues:

• calling sendEvent("keydown") with webpage.event.key.A, generates a DOM keydown event, but also a DOM keypress event. This DOM keypress event should not be generated. Same issue if we give a string like "a" or "é".
• calling sendEvent("keypress") with webpage.event.key.A, generates a DOM keypress event, but also a DOM keydown event and a DOM keyup event. We should not have these two last events. It is inconsistent IMHO, because it means that we don't have an easy way to simulate only a DOM keypress event. Or if for you it is consistent, then I think the "keypress" keyword is not a good choice for the phantomjs API. Same issue if we give a string like "a" or "é".
• worse issue : calling sendEvent("keypress") with webpage.event.key.A AND ctrl modifier, does NOT generate a DOM keypress event at all, but it still generates the unexpected DOM keydown and DOM keyup events. Probably ctrl+A has a specific meaning in QT/Webkit and then it "eats" the event. But it means that we cannot simulate a real CTRL+A (whereas it works well in a real browser, we receive the keypress event). We have the same issue with "keypress" + a printable character that does not correspond to a DOM keycode (like webpage.event.key.Ocircumflex), or + a non printable key (like webpage.event.key.Delete), or + a string with a single char
• calling sendEvent("keydown") with webpage.event.key.Delete, generates a DOM keydown event, but not a DOM keypress event. from my point of view, it is ok, but it is inconsistent with the first issue I list. So depending on what we send with keydown, we don't have the same behavior in terms of DOM key event. Worse, this call erase a character in the input target, although it should not since the resulting action of a key in a browser is down during a DOM keypress event (if it is not canceled by the webpage).
• We have almost the same issue when calling sendEvent("keydown") with a string longer than one character. We receive only one DOM keydown event. This is consistent, since it does not make sense to receive a DOM keydown event for each character without their keypress and keyup events. The issue here, is that we receive one keypress event, and the <input> target is filled with the entire given string. It means that character are taken account without corresponding DOM key events!

Note that we don't have this issue with the ctrl modifier. And <input> content is ok with alt modifier and shift+ctrl modifier (but we have still the keypress event in these two cases)

• we have also minor issues with sendEvent("keydown") with a string longer than one character

For details, see comments in test files.

Bonus, activate the file test-webpage-keyevent-phantom.js instead of the two test files, in phantomjs-test-keyevent.js. and you then have same tests but against results as generated by phantomjs 1.8.1. Tests succeeded with this file (but results are not good of course). Feel free to integrate these tests into your own tests suite.

The origin of some of these issues comes probably from QTwebkit, or even Webkit. Perhaps also something is missing in the use of the QT API in phantomjs. I'm not familiar enough with QT to say who is the responsible :-)

Laurent

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #1094.
🌟   3 people had starred this issue at the time of migration.

[ariya]

Thanks for the comprehensive tests! I'll need to set aside some time to investigate the issues one by one.

[n1k0]

+1, seems like key modifiers are not working the way they're expected to :/

/poke @vitallium

[vitallium]

@laurentj, @n1k0, well, all keyboard events are working in the same way as in Google Chrome or other Webkit-based browser.

UPD
I mean, Webkit has utilized keyboard events from IE. That's why we have not the same behavior like in Firefox. You can read about this more here

[n1k0]

@vitallium well I'm not sure. Take that simple exemple, using latest Chrome; in the console, run:

window.addEventListener('keypress', function(e) {console.log(e.which);})

Then type s then alt + s; that gives:

115
210

Now the same scenario using PhantomJS:

var page = require('webpage').create();
page.onConsoleMessage = function(m){console.log(m)};
page.content = '<script>window.addEventListener("keypress", function(e) {console.log(e.which);})</script>';
page.sendEvent('keypress', 's');
page.sendEvent('keypress', 's', null, null, page.event.modifier.alt);

That gives:

115
115

Did I miss something?

I'm using PhantomJS 1.9.0 on OSX ML.

[JamesMGreene]

I find odd that Chrome reports a different which value for alt + s.
AFAIK, it should report the same value for e.which but have e.altKey === true.

Sincerely,
James Greene
On May 8, 2013 2:19 PM, "Nicolas Perriault" notifications@github.com
wrote:

@vitallium https://github.com/Vitallium well I'm not sure. Take that
simple exemple, using latest Chrome; in the console, run:

window.addEventListener('keypress', function(e) {console.log(e.which);})

Then type s then alt + s; that gives:

115
210

Now the same scenario using PhantomJS:

var page = require('webpage').create();page.onConsoleMessage = function(m){console.log(m)};page.content = '<script>window.addEventListener("keypress", function(e) {console.log(e.which);})</script>';page.sendEvent('keypress', 's');page.sendEvent('keypress', 's', null, null, page.event.modifier.alt);

That gives:

115
115

Did I miss something?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11094#issuecomment-17627871
.

[laurentj]

@vitallium the page you indicate describes what Firefox does, or any browser that respects standards should do.

IMHO, the issues described here come from the QT layer or the phantomJS implementation, not from webkit itself. (I mean, it seems Webkit receives bad key informations, so it generates bad DOM events)

[n1k0]

@JamesMGreene I confirm e.altKey is correctly reported on Chrome… maybe that's because on my azerty keyboard layout, alt + s actually produces the char Ò…

But, if I'm trying something different that produces no character like ctrl + k, using this code:

window.addEventListener("keypress", function(e) {console.log(e.which, e.ctrlKey);})

Chrome, typing k then ctrl + k:

107 false
11 true

(don't ask me why 11…)

Using PhantomJS 1.9 with this script:

var page = require('webpage').create();
page.onConsoleMessage = function(m){console.log(m)};
page.content = '<script>window.addEventListener("keypress", function(e) {console.log(e.which, e.ctrlKey);})</script>';
page.sendEvent('keypress', 'k');
page.sendEvent('keypress', 'k', null, null, page.event.modifier.ctrl);

I get:

107 false
107 true

Edit: fixed sample code, so it looks it's working as expected, but differently than in Chrome.

[JamesMGreene]

Perhaps PhantomJS isn't locale aware...?

[heylookltsme]

Any progress on this? I'm also experiencing this issue.

Using PhantomJS 1.9,

var page = require('webpage').create();
page.onConsoleMessage = function(m){console.log(m)};
page.content = '<script>window.addEventListener("keypress", function(e) {console.log(e.which, e.altKey);})</script>';
page.sendEvent('keypress', 'r');
page.sendEvent('keypress', 'r', null, null, page.event.modifier.alt);

I get:

114 false
114 true

But in Chrome, I get:

114 false
174 true

This is breaking my ability to test a hotkey command. Any idea where this issue is on the roadmap or anyone know of a handy dandy work around? TIA.

[aprescott]

@heylookltsme does your Alt-R give anything except a plain ASCII r in a regular browser?

[emilioplatzer]

ctrl-k produces in chrome 11 because IBM-PC behavior (CTRL-A = 1 CTRL-B = 2 CTRL-C = 3, etc)

[emilioplatzer]

+1