This also happens with the latest update of Chrome on macOS...

Version 55.0.2883.75 (64-bit)

And also in the latest Canary build:
Version 57.0.2939.0 canary (64-bit)

Chrome behavior on Android:

Chrome Beta Android - 55.0.2883.77 - crashes
Chrome Android - 54.0.2840.85 - works as expected

Able to reproduce this issue on windows 10, Ubuntu 14.04 and Mac 10.11.6 on latest chrome stable version 55.0.2883.75 
Issue is broken in M55. 

Bisect Info:
===========

Good build : 55.0.2879.0,  Revision Range-422347
Bad build  : 55.0.2880.0,  Revision Range-422654

After executing the per-revision-bisect script, i got the following CL's between good and bad build versions
============================================
https://chromium.googlesource.com/chromium/src/+log/c333ca777eda0f33726c8e30f1a24600f63f70df..97597159c2bdd0a378fca56750e1bc1a1defe7ed

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/97597159c2bdd0a378fca56750e1bc1a1defe7ed


From the above CL suspecting the below change
Review-Url: https://codereview.chromium.org/2374253007


rockot@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.



Thank You...

+ Alex (per comment #4 issue exists on Android)

[Bulk edit]

URGENT - PTAL ASAP.

This issue is marked as a stable release blocker for this week M55 Stable release cut, pls make sure to land the fix and get it merged to release branch ASAP.

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.


Thanks!

http://hughsk.io/north/ may be a repro (source: https://github.com/hughsk/north/blob/gh-pages/index.html).

This gives me crash go/crash/644a574f00000000 which buckets as [Renderer kill] service_manager::mojom::InterfaceProviderStubDispatch::Accept.  This was marked as fixed in issue 660772...  reviewing more now.

Visiting the same page on Android gives me go/crash/318a5e3f00000000 which buckets as [Renderer kill] shell::mojom::InterfaceProviderStub::Accept instead, which is issue 671126...  ~25 crashes / version, which puts it outside even the top 50 crashes.

That signature is unfortunately a generic one that can be triggered by
various kinds of bad IPC. It's almost definitely not the same bug as 660772.

In any case, it's an easy bug to fix if you have a consistent repro.
Building a test bulid now.

Issue 671126 has been merged into this issue.

Pre-approving https://codereview.chromium.org/2558493002/ for merge to M55 branch 2883 and M56 branch 2924.  This simply allows the interface to be called and cannot introduce negative side effects.

 Issue 671661  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/93dfb38a23ad838095e9431d6e6bfe17543b9df0

commit 93dfb38a23ad838095e9431d6e6bfe17543b9df0
Author: Ken Rockot <rockot@chromium.org>
Date: Tue Dec 06 17:53:26 2016

Add device::mojom::OrientationAbsoluteSensor to renderer spec

BUG= 671234 

Review URL: https://codereview.chromium.org/2558503002 .

Cr-Commit-Position: refs/branch-heads/2883@{#714}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/93dfb38a23ad838095e9431d6e6bfe17543b9df0/content/public/app/mojo/content_browser_manifest.json

Users experienced this crash on the following builds:

Android Beta 55.0.2883.77 -  0.30 CPM, 25 reports, 7 clients (signature [Renderer kill] shell::mojom::InterfaceProviderStub::Accept)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

+timvolodine@ who implemented the absolute orientation API in the first place.  If I understand correctly in M54 this would have just gone unnoticed, but in M55 https://crrev.com/422377 turned this into a crash.

Correct. The feature would have been silently broken before.

Why does everyone say "this used to work in M54", then?

Most likely it's because any use of the API acquires both the
OrientationSensor and OrientationAbsoluteSensor interfaces from the
browser, but common uses of the API effectively only exercise the former
interface. So although any usage of the latter would have been silently
broken, the former would still have functioned.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6259d5372564a16b859d0f09fbe7a6ebc5b01e9

commit a6259d5372564a16b859d0f09fbe7a6ebc5b01e9
Author: rockot <rockot@chromium.org>
Date: Tue Dec 06 18:49:32 2016

Add device::mojom::OrientationAbsoluteSensor interface to renderer spec

BUG= 671234 
TBR=ben@chromium.org

Review-Url: https://codereview.chromium.org/2558493002
Cr-Commit-Position: refs/heads/master@{#436662}

[modify] https://crrev.com/a6259d5372564a16b859d0f09fbe7a6ebc5b01e9/content/public/app/mojo/content_browser_manifest.json

UseCounter metrics for DeviceOrientationAbsoluteInsecureOrigin and DeviceOrientationAbsoluteSecureOrigin suggest this API is used on ~0.00056% of all page views.  So the crash should be pretty rare.

I thought maybe the "deviceorientationabsolute" API was just broken prior to M55 but I do see the event getting raised in Chrome 54 Android: http://jsbin.com/sokuvef

I stand corrected. The reason this worked in M54 is that we didn't enforce
*any* interface filtering between renderer and browser in M54.

We were able to repro crash mentioned in issue 671126 by navigating to http://hughsk.io/north/ on 55.0.2883.77 and Verified that this is fixed on 55.0.2883.84.

rockot@, we still need an M56 merge, correct?  Can you process that then mark this as fixed?

Ah, sure

Ah, sure

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/110565ca05407f9a80d2fec33ab3243c4c974929

commit 110565ca05407f9a80d2fec33ab3243c4c974929
Author: Ken Rockot <rockot@chromium.org>
Date: Wed Dec 07 00:49:20 2016

Add device::mojom::OrientationAbsoluteSensor interface to renderer spec

BUG= 671234 
TBR=ben@chromium.org

Review-Url: https://codereview.chromium.org/2558493002
Cr-Commit-Position: refs/heads/master@{#436662}
(cherry picked from commit a6259d5372564a16b859d0f09fbe7a6ebc5b01e9)

Review URL: https://codereview.chromium.org/2554233002 .

Cr-Commit-Position: refs/branch-heads/2924@{#368}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/110565ca05407f9a80d2fec33ab3243c4c974929/content/public/app/mojo/content_browser_manifest.json

Will there be a postmortem for this? How come tests did not cover this?

Verified this issue on Windows-10, Mac OS 10.11.6 and Ubuntu 14.04 using chrome latest M55 #55.0.2283.85 by following steps mentioned in the original comment.

No crash is observed.Attaching a screen-cast for your reference. Hence adding TE-Verified label.

Deleted: Issue 671234.mp4 1.5 MB

	Issue 671234.mp4 1.5 MB View Download

Verified this issue on Windows-10, Mac OS 10.11.6 and Ubuntu 14.04 using chrome latest M56 #56.0.2924.19 by following steps mentioned in the original comment.

No crash is observed.Attaching a screen-cast for your reference. Hence adding TE-Verified label.

Deleted: Issue 671234-M56.mp4 1.0 MB

	Issue 671234-M56.mp4 1.0 MB View Download

Verified this issue on Windows-10, Mac OS 10.11.6 and Ubuntu 14.04 using chrome latest M56 #56.0.2924.21 by following steps mentioned in the original comment.

No crash is observed.
Adding TE-Verified label.

Got new Chrome version 55.0.2883.87 m via auto update (Win 10)
Bug is fixed now. Thx!

Same on Mac.
I also got version 55.0.2883.87 via auto update today and can't reproduce the issue any longer.