774190 - element.setCapture cease to work on device

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: General, defect)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

https://github.com/mozilla-b2g/gaia/issues/2447


https://developer.mozilla.org/en/DOM/element.setCapture

setCapture is a method to redirect mouse events to a specific target even if the cursor/finger had move out of the specified element.

For recent weeks this method failed to work on devices, resulting breakage of the lock screen unlock gesture, the utility tray, and card view.

STR:

1. turn on B2G with a fresh baked Gecko and Gaia
2. attempt to unlock the device by moving the handle, but don't move it to the unlock target
3. Move your finger out of the handle (e.g., move to the clock), and then stop touching the screen

Expected (B2G Desktop):

1. A mouseup event fired on the handle, resulting the handle bounce back to it's original place.

Actual (B2G devices, currently):

1. mouseup event fired on the actual visible element (e.g., clock), making the handle to stick on it's last place.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I've removed setCapture from the lock screen, so people should find STR in the UI test app.

Comment 2

[Dietrich Ayala (:dietrich)]

Asked in Gaia issue if we can ship the workaround or not. Leaving nominated until we get more information there.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think setCapture is used a lot on the web, so might not be blocking. However I'm concerned that this might be used a lot in mobile websites which definitely would make it a blocker. I don't have any data or hunches either way.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

It's best for our Web-based phone behavior the same way as the real web.

The only thing in Gaia that cannot ship with the workaround is the pull down tray from the status bar (the Utility Tray), but strangely setCapture seems to be working on that particular part of Gaia for no reason... so I guess we are fine?

Comment 5

[Dietrich Ayala (:dietrich)]

Web platform code should run in B2G browser just like our other browsers. Blocking+.

Comment 6

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

We use it for the keyboard application and this is hard to do without it.

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

With a quick investigation mousemove events are dispatched correctly. It seems only mouseup is busted.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

There is something weird with TouchEvents. If I disable them in widget/gonk/nsAppShell.cpp then it works again.

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

This patch does not release capture when TOUCH_END is fired, only on mouse up.

I think this is fine per spec but I would like Jonas to confirm.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 647311 [details] [diff] [review]
Patch

Olli is a better reviewer for this stuff

Comment 11

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

(In reply to Jonas Sicking (:sicking) from comment #3)
> I don't think setCapture is used a lot on the web, so might not be blocking.
> However I'm concerned that this might be used a lot in mobile websites which
> definitely would make it a blocker. I don't have any data or hunches either
> way.

IIRC setCapture is Trident/Gecko only.

Comment 12

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

So, is the problem that touchend releases capture so that mouseup ends up firing on a wrong target?

Comment 13

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

Comment on attachment 647311 [details] [diff] [review]
Patch

This should be ok, but needs tests.

Comment 14

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

Actually, wesj is about to fix this issue in another bug.

Comment 15

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Olli Pettay [:smaug] from comment #14)
> Actually, wesj is about to fix this issue in another bug.

Nice. Do you have the bug number handy?

Comment 16

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

Hmm, I think it got fixed already :) but I don't have the bug# here.