LayoutTests/fast/events/mouse-event-buttons-attribute.html - Issue 727593003: Implement MouseEvent buttons attribute.

Side by Side Diff: LayoutTests/fast/events/mouse-event-buttons-attribute.html

Issue 727593003: Implement MouseEvent buttons attribute. (Closed) Base URL: https://chromium.googlesource.com/chromium/blink.git@master

Patch Set: Created 6 years, 1 month ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
(Empty)
	1 <!DOCTYPE html>

	2 <script src="../../resources/js-test.js"></script>

	3 <script>

	4

	5 if (window.testRunner)

	6 testRunner.waitUntilDone();
	Rick Byers 2014/11/14 19:48:09 eventSender works synchronously, you can simplify eventSender works synchronously, you can simplify the test by removing this async stuff. zino 2014/11/18 14:19:35 Done. Show quoted text On 2014/11/14 19:48:09, Rick Byers wrote: > eventSender works synchronously, you can simplify the test by removing this > async stuff. Done.
	7

	8 window.addEventListener('mousedown', function() {
	Rick Byers 2014/11/14 19:48:09 Please add handlers for the other event types too Please add handlers for the other event types too and test that they include correct buttons values. At least: - mousemove - both before and after a button is depressed - click, dblclick, mouseenter, mouseleave, mouseover and mouseout - all of which blink synthesizes on and will need to propagate the button state explicitly for Also can you manually verify on at least one chrome platform what the behavior is for mouseup? The spec doesn't seem entirely clear on this, but I assumed it should be 0 when releasing a button. However testing Firefox on Linux I see the 'buttons' value represents the state BEFORE the button is released - perhaps I missed the explanation for this in the spec? Obviously this is a chromium-side bug/change, not directly applicable to this blink CL. Also you need a test for creating mouse events from javascript with non-zero buttons values. What should the behavior of 'buttons' be for MouseEvent objects created with the legacy initMouseEvent API? Eg. if you create a mousedown event with that, is it OK for buttons to still be 0? The spec seems silent on this, please check what IE and/or FireFox do here. zino 2014/11/18 14:19:35 Done. Show quoted text On 2014/11/14 19:48:09, Rick Byers wrote: > Please add handlers for the other event types too and test that they include > correct buttons values. At least: > - mousemove - both before and after a button is depressed > - click, dblclick, mouseenter, mouseleave, mouseover and mouseout - all of > which blink synthesizes on and will need to propagate the button state > explicitly for Done. Show quoted text > > Also can you manually verify on at least one chrome platform what the behavior > is for mouseup? The spec doesn't seem entirely clear on this, but I assumed it > should be 0 when releasing a button. However testing Firefox on Linux I see the > 'buttons' value represents the state BEFORE the button is released - perhaps I > missed the explanation for this in the spec? Obviously this is a chromium-side > bug/change, not directly applicable to this blink CL. > Sorry, I couldn't find your mentioned part. Could you let me know the explanation in the spec? Anyway, currently new implementation seems to have the same behavior. Show quoted text > Also you need a test for creating mouse events from javascript with non-zero > buttons values. What should the behavior of 'buttons' be for MouseEvent objects > created with the legacy initMouseEvent API? Eg. if you create a mousedown > event with that, is it OK for buttons to still be 0? The spec seems silent on > this, please check what IE and/or FireFox do here. I'm not sure but the current spec doesn't seem to say that. Firefox also doesn't support for them. Please see this: https://hg.mozilla.org/mozilla-central/file/7913c9392c5f/dom/events/MouseEven... Rick Byers 2014/11/18 20:29:18 The spec (http://www.w3.org/TR/DOM-Level-3-Events/ Show quoted text On 2014/11/18 14:19:35, zino wrote: > On 2014/11/14 19:48:09, Rick Byers wrote: > > Please add handlers for the other event types too and test that they include > > correct buttons values. At least: > > - mousemove - both before and after a button is depressed > > - click, dblclick, mouseenter, mouseleave, mouseover and mouseout - all of > > which blink synthesizes on and will need to propagate the button state > > explicitly for > > Done. > > > > > Also can you manually verify on at least one chrome platform what the behavior > > is for mouseup? The spec doesn't seem entirely clear on this, but I assumed > it > > should be 0 when releasing a button. However testing Firefox on Linux I see > the > > 'buttons' value represents the state BEFORE the button is released - perhaps I > > missed the explanation for this in the spec? Obviously this is a > chromium-side > > bug/change, not directly applicable to this blink CL. > > > > Sorry, I couldn't find your mentioned part. > Could you let me know the explanation in the spec? The spec (http://www.w3.org/TR/DOM-Level-3-Events/#widl-MouseEvent-buttons) says that 'buttons' indicates which buttons "are currently being pressed". So what is the correct interpretation for a mouseup event where a button was just released? Eg. try clicking with the left mouse button at http://www.rbyers.net/eventTest.html on a couple browsers. In Firefox and IE on Windows I get: mousedown: ... button=0 buttons=1 ... mouseup: ... button=0 buttons=0 ... click: ... button=0 buttons=0 ... mousemove[28]: ... button=0 buttons=0 ... But in Firefox on Linux I get: mousedown: ... button=0 buttons=1 ... mouseup: ... button=0 buttons=1 ... click: ... button=0 buttons=1 ... mousemove[28]: ... button=0 buttons=0 ... The former seems correct according to the spec to me, the latter is probably a bug in Firefox. Which behavior does Chromium have? Show quoted text > Anyway, currently new implementation seems to have the same behavior. > > > Also you need a test for creating mouse events from javascript with non-zero > > buttons values. You still need this. Eg. 'var evt = new MouseEvent( {.... buttons: 2 }); shouldBeNumber("buttons", "evt.buttons"); Show quoted text > What should the behavior of 'buttons' be for MouseEvent > objects > > created with the legacy initMouseEvent API? Eg. if you create a mousedown > > event with that, is it OK for buttons to still be 0? The spec seems silent on > > this, please check what IE and/or FireFox do here. > > I'm not sure but the current spec doesn't seem to say that. > Firefox also doesn't support for them. > > Please see this: > https://hg.mozilla.org/mozilla-central/file/7913c9392c5f/dom/events/MouseEven... Yeah I think this is fine. I tried this on IE - see http://jsbin.com/tesopu/65/edit?js,output. On IE it displays: mousedown button=2 buttons=0 Technically this could confuse some code (buttons should never be 0 in a mousedown event), but it's probably not worth trying to do something about this. zino 2014/11/24 13:07:07 Okay, I've addressed the bug. Show quoted text On 2014/11/18 20:29:18, Rick Byers wrote: > The spec (http://www.w3.org/TR/DOM-Level-3-Events/#widl-MouseEvent-buttons) says > that 'buttons' indicates which buttons "are currently being pressed". So what > is the correct interpretation for a mouseup event where a button was just > released? Eg. try clicking with the left mouse button at > http://www.rbyers.net/eventTest.html on a couple browsers. In Firefox and IE on > Windows I get: > > mousedown: ... button=0 buttons=1 ... > mouseup: ... button=0 buttons=0 ... > click: ... button=0 buttons=0 ... > mousemove[28]: ... button=0 buttons=0 ... > > But in Firefox on Linux I get: > > mousedown: ... button=0 buttons=1 ... > mouseup: ... button=0 buttons=1 ... > click: ... button=0 buttons=1 ... > mousemove[28]: ... button=0 buttons=0 ... > > The former seems correct according to the spec to me, the latter is probably a > bug in Firefox. Which behavior does Chromium have? Okay, I've addressed the bug. Show quoted text > You still need this. Eg. 'var evt = new MouseEvent( {.... buttons: 2 }); > shouldBeNumber("buttons", "evt.buttons"); Done. Rick Byers 2014/11/25 17:44:27 I was thinking this would be addressed in chromium Show quoted text On 2014/11/24 13:07:07, zino wrote: > On 2014/11/18 20:29:18, Rick Byers wrote: > > The spec (http://www.w3.org/TR/DOM-Level-3-Events/#widl-MouseEvent-buttons) > says > > that 'buttons' indicates which buttons "are currently being pressed". So what > > is the correct interpretation for a mouseup event where a button was just > > released? Eg. try clicking with the left mouse button at > > http://www.rbyers.net/eventTest.html on a couple browsers. In Firefox and IE > on > > Windows I get: > > > > mousedown: ... button=0 buttons=1 ... > > mouseup: ... button=0 buttons=0 ... > > click: ... button=0 buttons=0 ... > > mousemove[28]: ... button=0 buttons=0 ... > > > > But in Firefox on Linux I get: > > > > mousedown: ... button=0 buttons=1 ... > > mouseup: ... button=0 buttons=1 ... > > click: ... button=0 buttons=1 ... > > mousemove[28]: ... button=0 buttons=0 ... > > > > The former seems correct according to the spec to me, the latter is probably a > > bug in Firefox. Which behavior does Chromium have? > > Okay, I've addressed the bug. I was thinking this would be addressed in chromium, but adding additional protection in blink (so we're not sensitive to which way chromium behaves here) makes sense. Thanks!
	9 if (window.eventSender) {

	10 window.result = event.buttons;

	11 shouldBe('result', '3');

	12 } else {

	13 debug('event.buttons = ' + event.buttons);

	14 }

	15

	16 if (window.testRunner)

	17 testRunner.notifyDone();

	18 }, false);

	19

	20 if (window.eventSender) {

	21 eventSender.mouseMoveTo(10, 10);

	22 eventSender.mouseDown(1, ['leftButton', 'rightButton']);

	23 }

	24

	25 </script>

OLD	NEW

« no previous file with comments | « no previous file | LayoutTests/fast/events/mouse-event-buttons-attribute-expected.txt » ('j') | Source/core/events/WheelEvent.cpp » ('J')