-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sensor-tester: orientation locking does not always work #72
Comments
Surely looks like a Chrome bug, given that lock('portrait-secondary') succeeds but doesn't rotate and therefore doesn't send 'change' event. Different variations with 180 (portrait secondary) fails, eg. 270 - 180 - 90 fail It fails with AbortError. As 180 (portrait-secondary) completes with success without changing orientation, it makes sense if you read the spec text: https://w3c.github.io/screen-orientation/#dfn-apply-an-orientation-lock
There is probably a pending promise that was never dealt with as it just "completed" Additional annoyance with the orientation lock API, is that the promise resolves before the event is sent. This makes it hard to default handlers that you don't want to call in certain cases, because if you remove the handler then there is no good place to add it back in, because if you do after the promise gets resolves, it might get called as the event is still pending :-( Would be good to file on the spec, plus might also then make sense for the unlock to return a promise. |
Also, Chrome OS doesn't implement this, though Chrome OS is a tablet OS as well now, we might want to look into that. Same with sensors, btw :-) |
@kenchris, I've filed a corresponding issue in chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=888929 |
Spun off #66. Some screen locking combinations in tests such as "Accelerometer with screen coordinates" don't work: for example, locking to 180 degrees then 90 while originally in portrait mode causes the latter to fail and reset the orientation locking mechanism.
There's also additional information in #66 written by @kenchris.
We need to figure out if we're doing something wrong or whether we're hitting one or more Chromium bugs.
The text was updated successfully, but these errors were encountered: