odejesush@ to reproduce.

I have been able to reproduce the issue with a small difference to the given steps. The box does not move initially until a listener is added to the top level frame. Once the listener is added, the box will move. I can remove the listener and refresh multiple times and the box will still move. From this point, performing the steps to reproduce behaves exactly as described.

Any progress on this? The workaround stopped working on Chrome 70.

I have only reproduced it. I plan to investigate it more closely soon.

Also running into this issue, Is there a timeframe for this issue getting fixed? 

The issue is being investigated. We cannot provide a timeline for delivering a fix until the root cause is known.

Workaround for Chrome >= v70 would be to catch events on the top window and dispatch them to an iframe's window.

top.addEventListener('deviceorientation', function (evt) {
    var syntheticEvent = new Event('deviceorientation', { 'bubbles': true, 'cancelable': true });
       
    syntheticEvent.alpha = evt.alpha;
    syntheticEvent.beta = evt.beta;
    syntheticEvent.gamma = evt.gamma;
    iframeWindow.dispatchEvent(syntheticEvent);
});

I tested the sample page using a Pixel 3.

The bug occurs in the current stable release of Chrome 70.0.3538.80.
However, it seems to have been fixed in the beta release of Chrome 71.0.3578.31 and onward.

andrej.premrn@, please check if the bug still occurs in a beta, dev, or canary release of Chrome. I will run a bisect to figure out the cause of the bug.

Thank you

It feels like this could be related to this bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=783586

> The device motion/orientation events now use the the same backend as
the generic sensors API. This broke these events in cross-origin
iframes because of checks to prevent such usage in the generic sensors
API.

I assume some restrictions that have been placed on Generic Sensor API invocation may also be incorrectly being applied to 'deviceorientation', 'devicemotion' and 'deviceorientationabsolute' event listener handling?

Interesting side-note: It seems injecting _sourceless_ iframe contents (e.g. injecting code via 'srcdoc' or 'document.write') is preventing these device motion and orientation events from firing, even thought sourceless iframes belong to the top-level page's origin and should be able to receive these events. 

All other versions of Chrome on Android (< version 70) and all browsers on iOS have always correctly flowed device motion and orientation events in to such sourceless iframes. Chrome 70 has broken this flow for the first time among browsers and I expect a lot of code is affected (e.g. motion sensor dependent code loaded in SafeFrames: https://www.iab.com/guidelines/safeframe/).

> All other versions of Chrome on Android (< version 70) and all browsers on iOS have always correctly flowed device motion and orientation events in to such sourceless iframes. Chrome 70 has broken this flow for the first time

I just want to clarify that even if you "warm-up" the device sensors in Chrome 70 (according to the injection via 'srcdoc' as described in this initial bug report comment) the sensors still do not work.

If you "warm-up" the device sensors in Chrome < 70 (according to the injection via 'srcdoc' as described in this initial bug report comment) the sensors will work.

Adding the following files to provide demonstrations of the bugs addressed in my previous comment:

`iframe_motion_srcdoc_test.html - sourceless iframe injection via `srcdoc`, "warm-up" the sensors prior to calling `srcdoc` and then run a devicemotion event test within that injected iframe.

iframe_motion_documentwrite_test.html - sourceless iframe injection via `document.write`, "warm-up" the sensors prior to calling `document-write` and then run a devicemotion event test within that injected iframe.

In Chrome < 70 for Android both demos print: "Motion events are flowing" thanks to the "warm-up" workaround suggested in this bug.

In Chrome 70 for Android both demos print: "Motion events are not flowing" despite the "warm-up" workaround suggested in this bug.

Demo files:

Deleted: iframe_motion_srcdoc_test.html 1.2 KB

iframe_motion_srcdoc_test.html 1.2 KB View Download

Deleted: iframe_motion_documentwrite_test.html 1.6 KB

iframe_motion_documentwrite_test.html 1.6 KB View Download

Rich, per comment #12 can you verify whether this issue has been fixed in Chrome 71. We are working on a bisect to determine what broke (and fixed) this issue and we want to make sure that it really is working in all the cases people have reported.

This bug was introduced by the following commit: https://chromiumdash.appspot.com/commit/94c082d42d63ce1e43c126057c627dfedf2990bd

and was fixed by the following commit:
https://chromiumdash.appspot.com/commit/5e9f806410de4daa95cc0f57061e12270391fdff

Upon further investigation, I found that the first commit changed the permission check to use PermissionManager::RequestPermission. This eventually failed in PermissionContextBase::RequestPermission because the requesting origin passed into this method was invalid [1]. The requesting origin was retrieved in SensorProviderProxyImpl::GetSensor using RenderFrameHost::GetLastCommittedURL. Therefore, it seems that this method returns an empty URL when the iframe is loaded using srcdoc.

The reason that the second commit fixed the bug is because the commit enables Permission Delegation, which requires users to only make permission decisions about the top level origin of a website. PermissionManager::RequestPermission uses PermissionManager::GetCanonicalOrigin to determine the requesting origin to use in the actual permission request. When the Permission Delegation flag is enabled, this method returns the embedding origin. [2] As a result, the requesting origin is valid, since it is now the embedding origin.

[1]https://cs.chromium.org/chromium/src/chrome/browser/permissions/permission_context_base.cc?l=124
[2] https://cs.chromium.org/chromium/src/chrome/browser/permissions/permission_manager.cc?l=341