This repository has been archived by the owner. It is now read-only.

sendEvent for key events generates inconsistent DOM key events #11094

Open
laurentj opened this Issue Feb 24, 2013 · 12 comments

Comments

Projects
None yet
8 participants
@laurentj
Contributor

laurentj commented Feb 24, 2013

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 :

(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

This comment has been minimized.

Show comment
Hide comment
@ariya

ariya Mar 19, 2013

Owner

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

Owner

ariya commented Mar 19, 2013

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

@n1k0

This comment has been minimized.

Show comment
Hide comment
@n1k0

n1k0 May 8, 2013

Contributor

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

/poke @Vitallium

Contributor

n1k0 commented May 8, 2013

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

/poke @Vitallium

@Vitallium

This comment has been minimized.

Show comment
Hide comment
@Vitallium

Vitallium May 8, 2013

Collaborator

@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

Collaborator

Vitallium commented May 8, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@n1k0

n1k0 May 8, 2013

Contributor

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

Contributor

n1k0 commented May 8, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@JamesMGreene

JamesMGreene May 8, 2013

Collaborator

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/ariya/phantomjs/issues/11094#issuecomment-17627871
.

Collaborator

JamesMGreene commented May 8, 2013

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/ariya/phantomjs/issues/11094#issuecomment-17627871
.

@laurentj

This comment has been minimized.

Show comment
Hide comment
@laurentj

laurentj May 8, 2013

Contributor

@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)

Contributor

laurentj commented May 8, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@n1k0

n1k0 May 8, 2013

Contributor

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

Contributor

n1k0 commented May 8, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@JamesMGreene

JamesMGreene May 9, 2013

Collaborator

Perhaps PhantomJS isn't locale aware...?

Collaborator

JamesMGreene commented May 9, 2013

Perhaps PhantomJS isn't locale aware...?

@heylookltsme

This comment has been minimized.

Show comment
Hide comment
@heylookltsme

heylookltsme Jun 11, 2013

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.

heylookltsme commented Jun 11, 2013

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

This comment has been minimized.

Show comment
Hide comment
@aprescott

aprescott May 17, 2014

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

aprescott commented May 17, 2014

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

@emilioplatzer

This comment has been minimized.

Show comment
Hide comment
@emilioplatzer

emilioplatzer Jan 3, 2016

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

emilioplatzer commented Jan 3, 2016

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

@emilioplatzer

This comment has been minimized.

Show comment
Hide comment

emilioplatzer commented Jan 3, 2016

+1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.