Good Build: 56.0.2909.0
Bad Build: 56.0.2912.0

Narrow Bisect:
https://chromium.googlesource.com/chromium/src/+log/e2a093c8bd048a451e4a5db37b567e1d4aa9a79d..442077ba59d6be19e539288fea133d9bd6431ffd?pretty=fuller&n=10

Suspecting: r429762 ?

@rob.buis: Please help me to reassign this issue if your change is not cause for it.

Sorry for the delay, I was doing some internal stuff.
For me this actually hits an assert:
ASSERTION FAILED: !std::isnan(static_cast<double>(value))
../../third_party/WebKit/Source/wtf/MathExtras.h(376) : LimitType clampTo(ValueType, LimitType, LimitType) [LimitType = float, ValueType = double]
1   0x7f5dce6fb86d blink::CSSPrimitiveValue::convertToLength(blink::CSSToLengthConversionData const&) const

Related to StyleBuilderFunctions::applyValueCSSPropertyHeight(). After some debugging I noticed in CSSToLengthConversionData::zoomedComputedPixels while handling UnitType::ViewportHeight case, the viewportHeightPercent() value is -isnan. This will then later lead to the crash/assert.

I am CCing rune since this may be related, and anyway he would know @viewport handling code better:
https://chromiumcodereview.appspot.com/2420413005

Rob, didn't see this until now. Did you think my CL was related, or just evidence that I could bring something to the table here? :-)

Hi Rune, it is based on comment #3, I assume viewportHeightPercent() should never becomes (-)isnan. And since I never touched this code I do not feel any blame ;-)

I found a fix, but I'm not sure it's right: https://codereview.chromium.org/2563783003/

@rune thanks for looking into it! Seems like this is something bokan can fix. Feel free to re-assign bug to either you or bokan if so.

Ok, I'll take this over.

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

commit db2df0adddb5ab717ecbdc1c57e1e7aa958908da
Author: bokan <bokan@chromium.org>
Date: Fri Jan 06 21:05:27 2017

Fix crash with viewport units when using auto resize mode.

This crash is caused because of a divide-by-zero when calculating viewport
units. The zero width visual viewport occurs because the WebView is responsible
for resizing the VisualViewport but the autoresize code resizes the FrameView.
This does eventually lead to resizing the WebView when a layout occurs and
calls though to WebView::layoutUpdated, however, until that happens the layout
will use the 0 value.

This isn't ever a problem since the calculation that's dividing by 0 is used to
adjust the browser controls to the minimum page scale but autoresize isn't ever
used on Android, which is the only platform that uses browser controls and a
non-1 minimum page scale.

BUG= 667712 

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

[modify] https://crrev.com/db2df0adddb5ab717ecbdc1c57e1e7aa958908da/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/db2df0adddb5ab717ecbdc1c57e1e7aa958908da/third_party/WebKit/Source/web/tests/VisualViewportTest.cpp

Your change meets the bar and is auto-approved for M56. Please go ahead and merge the CL manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

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

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

commit 14d6aa23de9ae621a6df2df9045c31d3d5a8cfae
Author: David Bokan <bokan@chromium.org>
Date: Mon Jan 09 14:57:12 2017

Fix crash with viewport units when using auto resize mode.

This crash is caused because of a divide-by-zero when calculating viewport
units. The zero width visual viewport occurs because the WebView is responsible
for resizing the VisualViewport but the autoresize code resizes the FrameView.
This does eventually lead to resizing the WebView when a layout occurs and
calls though to WebView::layoutUpdated, however, until that happens the layout
will use the 0 value.

This isn't ever a problem since the calculation that's dividing by 0 is used to
adjust the browser controls to the minimum page scale but autoresize isn't ever
used on Android, which is the only platform that uses browser controls and a
non-1 minimum page scale.

BUG= 667712 

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

Review-Url: https://codereview.chromium.org/2619173003 .
Cr-Commit-Position: refs/branch-heads/2924@{#700}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/14d6aa23de9ae621a6df2df9045c31d3d5a8cfae/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/14d6aa23de9ae621a6df2df9045c31d3d5a8cfae/third_party/WebKit/Source/web/tests/VisualViewportTest.cpp

Should be fixed in next 56 push. Please speak up if you still see this.

Verified the issue on win-7 and Ubuntu 14.04 using chrome beta version #56.0.2924.59 as per the comment #0.

Observed that extension overlay opened properly after clicking on extension icon as expected.

Hence, the fix is working as expected.

Attaching screen cast for reference

Adding the verified labels.

Deleted: 667712.mp4 1.2 MB

	667712.mp4 1.2 MB View Download