Do we have any idea of where the regression might be coming from?  It looks like we are going to ship this in M-67 :-(

We haven't been able to bisect this because we can't install the Chrome app on bisect instances. So I don't have an idea what the cause could be.

> We can't install the Chrome app on bisect instances

What is the complication with installing the app on such instances? Can you use a command similar to the following so that the same profile is used across invocations?

./tools/bisect-builds.py -a linux64 -b <bad> -g <good> --use-local-cache -- --user-data-dir=/tmp/debug_castui

Thanks Demetrios, that worked! I didn't think about loading the app through --user-data-dir.

Bisect result:
You are probably looking for a change made after 545239 (known good), but no later than 545258 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/39296e726ce046a4b94719ba131a0714c3ce4e5e..e09df9251bdc1f717aa76df1629a04143971a15e

My guess is that this is due to the mac_views_browser flag turning on in crrev.com/c/969078, although the bug only reproduces when #views-browser-windows is disabled. Elly, could you take a look?

elly, any updates?

ellyjones@, ping?

The NextAction date has arrived: 2018-07-06

I don't understand the repro instructions here:

I installed https://chrome.google.com/webstore/detail/videostream-for-google-ch/cnciopoikihiagdjbjpnocolokfelagl/related?hl=en (which is *not* the same extension ID as the linked buganizer bug) then clicked the cast icon and the browser crashed instead of displaying the effect described in the report. What am I doing wrong?

If you're on Canary/Dev, it could be due to a Finch experiment we're running to replace the WebUI dialog with a Views one. Please try disabling #views-cast-dialog in chrome://flags.

I'd also appreciate it if you could send us the crash ID.

The extension ID mentioned in the buganizer bug is for the Media Router component extension and has little relevance to this particular bug. The one you linked is correct.

I installed the following Chrome app:
https://chrome.google.com/webstore/detail/videostream-for-google-ch/cnciopoikihiagdjbjpnocolokfelagl

With the default WebUI in M68 on ChromeOS, the Cast dialog appears correctly (see screenshot).

I don't have a Mac available to test with MacViews, but can check later today.

Note we are replacing this dialog in ~M70 with a Views dialog, so we should test against both the old dialog and new dialog.

Deleted: Screenshot 2018-07-18 at 10.25.01.png 142 KB

	Screenshot 2018-07-18 at 10.25.01.png 142 KB View Download

The issue reproduces on Mac M68 (Chrome 68.0.3440.68) with the WebUI dialog and no views related flags enabled.  No crashes for me.


  

Deleted: videostream mac 68 webui.png 95.3 KB

	videostream mac 68 webui.png 95.3 KB View Download

Next trying 68.0.3440.68 with various combinations of #views-browser-windows and #views-app-dialog and the WebUI.

Both enabled: Works correctly

#views-browser-window enabled and #views-app-window default: Works correctly

#mac-views-native-app-windows enabled and #views-browser-windows default: Works correctly

So, it seems like enabling either of those flags fixes the problem.  (Note that I meant "#mac-views-native-app-windows" above where I said "#views-app-dialog" and "#views-app-window".)

ellyjones@, will either of them be enabled in the M69 or M70 stable channels?

We will need to check separately that the views cast dialog renders correctly, but that is a separate issue with this bug, which was reported against WebUI.

On Chrome M69 (69.0.3495.0) I wasn't able to launch Videostream at all (clicking on the icon in chrome://apps variously closed the tab, or redirected me to the Web Store).  That's a distinct issue from this one.

#15: #views-browser-windows is likely on for M69 - see internal thread: <https://groups.google.com/a/google.com/forum/#!topic/chrome-mac-dev/z3IDlrCIeyU>

Given that the app in question doesn't seem compatible with the current build of M69, and the current position in the M68 release cycle, I don't think this is likely to get fixed in M68.  And, at any rate, it will be fixed by #views-browser-windows in M69.

If it looks like #views-browser-windows won't make M69, we can revisit.

 Issue 874091  has been merged into this issue.