1325597 - Mouse click issues with pointer lock on WebGL2 demo sample page

Status: NEW

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

Description

[Petruta Horea [:phorea]]

[Affected versions]:
- Firefox 51 beta 10
- latest Aurora 52.0a2 2016-12-22
- latest Nightly 53.0a1 2016-12-22

[Affected platforms]:
- Win 10 64-bit
- Mac OS X 10.12
- Ubuntu 16.04 64-bit

[Steps to reproduce]:
1. Open the following demo page: http://clb.demon.fi/bugs/stingray-webgl-basic-2016-10-14/stingray_webgl_dev.html
2. Wait for the game to load and click Start game
3. Interact with it, then click anywhere
4. Move the mouse around or use W, A ,S ,D keys to change the view then click again

[Expected result]:
- The view should not change

[Actual result]:
- After 1-2 seconds the view is changed to the same fix point (sky in this sample)

[Regression range]:
- https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=afb47dfb71ed76d1bf86fe0101cda1a5e6038863&tochange=9ec789c0ee5bd3a5e765513c21027fdad953b022
Regressed by bug 991899

[Additional notes]:
- On Firefox 50.1.0 this is reproducible only with webgl.enable-webgl2 pref set to true.

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

Bug 991899 is unlikely the real issue. Also it seems I cannot reproduce this issue on macOS 10.12 with aurora.

That actually sounds like something I met in bug 1244546, but I expect this kind of issue only happens on HiDPI Linux with e10s enabled, so this bug seems weird to me...

Comment 2

[Astley Chen (inactive)]

I can't load the demo on macOS 10.12, firefox will be hung and I need to force quit the app.
Xidorn, looks like it's fine on your testing environment ?

Comment 3

[Astley Chen (inactive)]

Now I can reproduce this issue on macOS 10.12 with nightly and aurora.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

I read the steps to reproduce again, and now I can reproduce it... I guess this is probably because we dispatch additional mousemove events when the page requests pointerlock again.

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

My guess now is it is somehow related to bug 1254044 (probably a dup of that). It seems Chrome has fixed this additional mousemove event, and thus this doesn't happen there.

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

According to the previous comments, I feel like this is an obvious regression that we'd fix in this release, i.e. P1 bug. Does this sound right to you?

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

No, it is not a regression, it is a bug exists since long ago. Bug 991899 just enables unprefixed pointerlock API, which should not lead to change of behavior otherwise. The bug didn't exist in that website before that version probably because that website uses unprefixed pointerlock API only.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thanks for the clarification. I removed "regression" keyword then, and going to mirror the priority of the bug 1254044 (btpp-backlog --> P3). Feel free to change it if you see fit.

Comment 9

[Astley Chen (inactive)]

I'd like to keep 'regression' keyword on bug since basically it's indeed a regression from user's perspective. (50 OK, 51 NG)
Doing so can help relevant product owners/EMs to always keep an eye on it and ensure it's been correctly prioritized.

HsinYi, do you know how other implementers' status on support of this API ?

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Astley Chen [:astley] UTC+8 from comment #9)
> I'd like to keep 'regression' keyword on bug since basically it's indeed a
> regression from user's perspective. (50 OK, 51 NG)
> Doing so can help relevant product owners/EMs to always keep an eye on it
> and ensure it's been correctly prioritized.
> 
> HsinYi, do you know how other implementers' status on support of this API ?

Sorry I didn't follow this API closely, I'd defer this question to Xidorn.

Comment 11

[Xidorn Quan [:xidorn] UTC+10]

Blink has shipped this API for quite a while. Actually we do as well, although only unprefixed recently. According to caniuse.com, Edge is shipping this API unprefixed as well, and WebKit is going to ship it in its next version.

Comment 12

[Astley Chen (inactive)]

If the issue doesn't happen on Blink/Edge, we probably need to get the fix in priority before causing more compatibility problem. What do you think, HsinYi ?

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

In triage meeting: we agree with comment 12 that we'd like to see this to be fixed at a very early stage for this unprefixed API. In consideration of comment 5, looks there's a potential solution there, we'd like to see the possibility of moving this forward soon-ish.

Hi Xidorn, could you please help take this, and suggest if this blocks FF 51 or not? Thanks.

Comment 14

[Xidorn Quan [:xidorn] UTC+10]

I don't immediately have idea how to fix that. It needs some investigation on where are the events from... which I currently don't have time to...

I don't really think it blocks anything... This is a very specific case that the demo uses mousemove event to move the scene even when pointer is not locked. I don't expect this to be something very common.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Seems edge-case enough to call fix-optional then.

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information