451440 - nsIDOMWindowUtils::sendKeyEvent isn't the same as pressing the key

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[Larry D'Anna]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

So theoretically this should be the same as just pressing up right? 

var utils = window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils);
utils.sendKeyEvent("keydown",  KeyEvent["DOM_VK_UP"], 0, 0);
utils.sendKeyEvent("keypress", KeyEvent["DOM_VK_UP"], 0, 0);
utils.sendKeyEvent("keyup",    KeyEvent["DOM_VK_UP"], 0, 0);

but somehow google reader can tell the difference.  Try running that on a google reader tab.  It will scroll the whole frame, instead of the visible scrollbar within the page.

Reproducible: Always

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Do you have the focus set to right element/frame?
Are you executing the script in right context?
IIRC, VK_UP doesn't normally generate keypress events, only keydown/up

A *minimal* testcase would be great.

Comment 2

[Larry D'Anna]

Attachment: this is how i'm invoking the script

Comment 3

[Larry D'Anna]

Attachment: this is how i'm invoking the script

Comment 4

[Larry D'Anna]

oooops the XUL attachment doesn't seem to display right in bugzilla.  anyway here's how i'm invoking the thing.  i have a XUL overlay like this

<?xml version="1.0"?>
<overlay xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <script src="overlay.js"/>
  <keyset id="mainKeyset">
    <key modifiers="alt" key="k" oncommand="fooup()" />
  </keyset>
</overlay>

and a little javacript file like this

function fooup() {
	var utils = window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils);
	utils.sendKeyEvent("keydown",  KeyEvent["DOM_VK_UP"], 0, 0);
	utils.sendKeyEvent("keypress", KeyEvent["DOM_VK_UP"], 0, 0);
	utils.sendKeyEvent("keyup",    KeyEvent["DOM_VK_UP"], 0, 0);
}

I'll try to isolate a minimal test case.

Comment 5

[Neil Deakin]

> It will scroll the whole frame, instead of the visible scrollbar within the page.

Can you explain what you are actually expecting to scroll? Detailed steps to reproduce?

The code you gave will cause a key to occur on the chrome window. You haven't focused anything in this code, so it's not clear what you expect to have scroll.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I was hoping a minimal testcase which I could run in browser.
Use UniversalXPConnect privileges if needed.

Comment 7

[Larry D'Anna]

Neil: I guess what I expect to scroll is whatever would have scrolled if I had just pressed up.  So if I had the address bar focused, I could use alt-k to scroll up through the suggestions instead of the up arrow.   If I have the page area focused, then it should scroll the page.  If I'm in a textarea, it should move the cursor up.  All these things actually work, *except* in google reader.

Google reader has no scrollbar for the whole page, but it does have a scrollbar for the table of items inside the page.  And they've got some javascript that scrolls the table when you press up or down.  So theoretically, if I'm in a situation where pressing up would cause google reader's javascript to scroll the table up, and i sendKeyEvent a VK_UP to the window, then it should scroll the table up.  But it scrolls the whole page up instead.

Also, I've discovered that if you click on the whitespace inside an item and then press alt-k, then it scrolls the table up as expected.

Comment 8

[Neil Deakin]

In that case, it sounds like you would need to focus the scrollable area. I think you can focus a scroll area (one with css overflow) with focus()

What JavaScript is the Reader using to scroll the area?

Comment 9

[Sunil]

Hi, is there any update to this bug? I am facing the same issue


I am trying using DOMWindowUtils (https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWindowUtils)'s sendKeyEvent. I have found the following issues :

1. When I generate keydown/keyup, the return value always says that the default was prevented. Why?
2. If I generate events like left arrow/right arrow within contentEditable fields, the browser doesn't change cursor position. Why? (Note: If I generate events for chars like 'a', 'b', ... then browser appropriately updates the text within contentEditable area, so there are no obvious flaws in my code).

Sample code that can be executed in Tools->Web Developer->Scratchpad, with environment 'Browser' (code requires chrome privilege).

var doc = gBrowser.contentDocument,
    win = doc.defaultView;

var domWindowUtils = win.QueryInterface(Components.interfaces.nsIInterfaceRequestor)
                     .getInterface(Components.interfaces.nsIDOMWindowUtils);

var div = doc.getElementById('contentEditableDiv');
div.focus();

['keydown', 'keypress', 'keyup'].forEach(function(type) {
    // if I generate characters like 'a', 'b' they work
    // domWindowUtils.sendKeyEvent(type, 65, 97, 0, 0);

    // 37 is left arrow, 38 right arrow
    var defaultPrevented = domWindowUtils.sendKeyEvent(type, 37, 0, 0, 0);    
    // win.alert('Default prevented ' + defaultPrevented);
});                     

I tried using initEvent/dispatchEvent but exhibits the same result.

Is there a way I can reliably generate events and have the browser carry out all actions?

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.