arni2033 Reporter
	Description • 9 years ago

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160105030211
STR:
 (A) - bookmarks in bookmarks toolbar
1. Right-click Australis menu button (≡), enable bookmarks toolbar
2. Create new folder in bookmarks toolbar
3. Drag the tab with this bug page to the folder created in Step 2  [new bookmark will be created]
4. Hover mouse over any link on this page (any <a> element), hold left mouse button
5. Hover mouse over the folder created in Step 2   [the folder will be expanded]
6. Hover mouse over the bookmark created in Step 3 (don't move mouse after this step)
7. Press Escape key to cancel drag-n-drop   [the bookmark from Step 3 is still hovered]
8. Release left mouse button

 (B) - tiles on newtab
1. Open New Tab Page, click Gear button, enable "Include suggested sites"
2. Hover mouse over the 1st tile, hold left mouse button
3. Move mouse by 15px
4. Press Escape key to cancel drag-n-drop   [make sure that the 1st tile is still hovered]
5. Release left mouse button

 (C) - links on any web page
1. Open this "data:" url in a new tab:   data:text/html,<a href="https://ya.ru/">Link</a>
2. Hover mouse over the Link, hold left mouse button
3. Move mouse by 15px
4. Press Escape key to cancel drag-n-drop   [make sure that the Link is still hovered]
5. Release left mouse button

Result:       
 Bookmark/tile/Link was clicked, and that caused unwanted action (some url was loaded in current tab)

Expectations: 
 Nothing/nothing/nothing. BTW browser GoogleChrome 47 matches the expectations

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 1 • 9 years ago

Why shouldn't mouseup on top of the link not active it? That is what the specs currently say, as far as I know: "dispatch click event".


Chrome seems to have very different dnd behavior. One needs to drag the link a lot before
dnd operation is initiated. And before that mousedown, some mouse move  (possibly some ESC presses) and mouseup triggers the link just like in Gecko.

	arni2033 Reporter
	Comment 2 • 9 years ago

> Why shouldn't mouseup on top of the link not active it? That is what the specs currently say
1) it's expected by user. I believe you agree that in cases (A) and (B) the expected action is "nothing". Otherwise user is forced to keep an eye on what kind of UI is hovered/where did the drag target go, OR (I prefer this scenario, because it's reliable) move mouse over the window controls / Australis menu button simply to make sure nothing unwanted will happen (sic!)
2) the spec doesn't describe very good that situation when dnd was canceled, and the mouse button is still pressed, right? It looks incomplete to me
3) IE11 and Chrome can afford it

Your second paragraph, however, isn't relevant to this bug, because comment 0 doesn't mention the situation _before_ dnd starts and mouse is already pressed.
(btw, is it This situation described by the spec? Looks like these are just white spots of the spec)
> Chrome seems to have very different dnd behavior
I disagree. Gecko also has some minimal distance before the dnd (~5px) so they are... "isomorphic"?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 3 • 9 years ago

on linux/Chrome I need to mousedown/move tens of pixels before Chrome starts dnd session.

	arni2033 Reporter
	Comment 4 • 9 years ago

(In reply to Olli Pettay [:smaug] from comment #3)
> on linux/Chrome I need to mousedown/move tens of pixels before Chrome starts dnd session.
I can understand arguments "Never, because it was decided so", but (1) how is comment 3 relevant?
Well, on Firefox and Chrome I need to mousedown/move several pixels before they start dnd session.
(2) Why it this "very" different? It's just slightly different. Comment 0 doesn't mention that anyway

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 5 • 9 years ago

In the case (C) I can't start dnd in Chrome while still having cursor on top of the link.
I can do that in FF. And in both cases releasing mouse triggers click event and the link.

	arni2033 Reporter
	Comment 6 • 9 years ago

> And in both cases releasing mouse triggers click event and the link.
Oh, ok. Comment 0 only describes the situation when dnd was canceled and the left mouse button is still pressed. To reproduce (C) you could hover mouse over Link after canceling dnd OR use this link:
> data:text/html,<a href="https://ya.ru/" style="padding:400px; background:gray;">Link</a>

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 7 • 9 years ago

ok, does chrome still in that case dispatch mouseup?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 8 • 9 years ago

Would be useful to have some minimal test here logging all the dispatched events.

	arni2033 Reporter
	Comment 9 • 9 years ago

In scenario (C) both Chrome and IE11 dispatch 'mousedown' and 'mouseup' events, but not 'click' event.
Firefox dispatches all 3 events.
( Hm, _сould_ it still dispatch 'click' event, but prevent default action if the click happened after canceling drag-n-drop? Does that sound realistically? )

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 10 • 9 years ago

Would be good to know the defaultPrevented status of mouseup and also if click is dispatched and if so, what is its defaultPrevented?

	arni2033 Reporter
	Comment 11 • 9 years ago

defaultPrevented == false   for all events listed in comment 9:
'mousedown', 'mouseup' and [firefox only] 'click'

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 12 • 9 years ago

So why doesn't Edge or Chrome get click? Really odd. Do they dispatch click to some other target?
like,do you get click if there is event listener on window object?

	arni2033 Reporter
	Comment 13 • 9 years ago

This testcase shows that at least for links, images, text, and even draggable buttons
IE11 and Chrome don't dispatch 'click' anywhere
> So why doesn't Edge or Chrome get click?
In my understanding - to prevent unwanted actions like (A), (B), (C). Also, I only test IE11, not Edge