@simongraf29: Please provide sample html file as attached file in comment#0 got deleted. Any further information on reproducing the issue would help in better triaging.

Thanks!

The attached html/javascript example displays the results of deviceorientation events. When the file is opened from file:///storage/emulated/0/download/compass-2.html , the function is not called in the new Chrome (in older versions it worked as expected)

Deleted: 15836 2.3 KB

15836 2.3 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Assigning to myself to try reproducing.

When I open a demo page[1] through a file:// URL the events are fired correctly. However, when I open the page through the Android Files app it uses a content://com.android.providers.downloads.document URL and there the events are not fired.

Simon, can you confirm how you are opening the file?

[1] https://github.com/reillyeon/scraps/blob/master/deviceorientation.html

Oh, you're right:
- When I open the file via Android files app, the path is “content://media/external/file/14248“ and the event is not fired (I usually do it this way - here the behavior has changed). 

- When opening the file via “file:///storage/emulated/0/...“ the event is indeed triggered.

Sorry for the confusion. I wasn't aware that the file app opens the file differently

This needs further investigation as it does not appear to be a Secure Origin or Feature Policy issue.

I did a bit of debugging and it looks like the feature policy checks in the render process succeed (DeviceOrientationController::DidAddEventListener) but the feature policy checks in the browser process fail (SensorProviderProxyImpl::GetSensor). It appears that the url::Origin for a content:// URL is a unique origin and the 'self' policy check fails because unique origins are not same-origin with themselves.

Adding iclelland@ for input.

Reading url::Origin it seems like the |nonce| field might be what is responsible for the check passing in the render process but that field is not serialized over Mojo to the browser process.

That sounds likely -- unique origins have been equal to themselves inside of a single renderer, but we've had to apply some hacks to get that to work in the browser, or between renderer processes. |nonce| is intended to help fix that.

I have an in-progress CL to pass that field over IPC + mojo between processes. I'll update that (since dcheng has been landing some CLs in that area, it may need some work to rebase) and see if it addresses this particular use case.