arni2033 Reporter
	Description • 9 years ago

STR:
1. Place mouse over dark gray area and press left mouse button.
2. Move mouse outside the dark gray area.
3. Release mouse button.

RESULT: click event fires

EXPECTATIONS: click event fires for element only if I press left mouse button over an element, then maybe move my mouse, then release button over the same element

	arni2033 Reporter
	Comment 1 • 9 years ago

STR, Step 0: Open attachment page.

	Dennis Schubert [:denschub]
	Comment 2 • 8 years ago

Interesting. If the `overflow-y: auto;` is removed, the issue is no longer reproducible. As soon as there is any overflow value that's not `visible`, dragging the mouse out of the element and releasing the mouse will trigger the click event.

	Mike Taylor [:miketaylr]
	Comment 4 • 8 years ago

Nomming for platform-rel since this affects a Yandex site (see Bug 1257816).

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

This is because nsFrame::HandlePress sets CapturingContent.
I wonder how to tweak that.

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

This is tricky. Chrome for example doesn't seem to capture the mouse while dragging around a scrollable area, yet it still scrolls it.

We could possibly fix this only for cases when there isn't anything to scroll, but keep the scrolling + capturing handling as it is.

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

Or, hmm, we could have special capturing for the case when nsFrame sets it. Event handling would still work normally, but "HandleDrag" would be forwarded to whatever needs to be possibly scrolled.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 8 • 8 years ago

Hmm, sounds like this what I worked on bug 552707. When I worked on that, I tried to capture mouse with the selection root. Is the changed behavior expected by this bug?

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

I'm going to try the approach where we don't use the normal capturing here, but just mark which element's primary frame should get called when doing mousemove. That way DOM events get normal targeting, but drag-selection in scrollable areas should still work.

	arni2033 Reporter
	Comment 10 • 8 years ago

Yandex enabled a new design that doesn't have this bug.
I don't think it makes sense to list all sites that use said CSS and set platform-rel for each one...
BTW, this bug happens with video element on Youtube, and actually in any <video> with hidden controls.

	Mike Taylor [:miketaylr]
	Comment 11 • 8 years ago

(In reply to arni2033 from comment #10)
> Yandex enabled a new design that doesn't have this bug.
> I don't think it makes sense to list all sites that use said CSS and set
> platform-rel for each one...
> BTW, this bug happens with video element on Youtube, and actually in any
> <video> with hidden controls.

Please don't remove platform-rel whiteboard tags or tracking status arni2033, they're being used by a number of teams to prioritize work.

	Desigan Chinniah [:cyberdees] [:dees] [London - GMT]
	Comment 12 • 7 years ago

arni2033's profile has since been disabled. Based on Comment 10 — does this still re-produce?

	Mike Taylor [:miketaylr]
	Comment 13 • 7 years ago

Yeah, this still reproduces according to the linked testcase, but apparently not on the Yandex site in question. But, something still worth fixing.