Regression:Unable to open Google docs on freshly installed chrome for first instance
Reported by
shruti.j...@etouch.net,
Sep 22 2017
|
||||
Issue descriptionChrome Version:63.0.3222.0 7754c77f5af465147885e57c6ba7fc4e9095d842-refs/heads/master@{#503582}(32/64 Bit). OS: Windows(7,8,8.1,10), Linux (14.04 LTS), Mac(10.12.6) What steps will reproduce the problem? 1.Freshly launch chrome, navigate to chrome://apps 2.Click on Google Docs app and observe Actual:Unable to open Google docs app for first instance after clicking on it Expected: Google docs app should open. This is a regression issue, broken in ‘M 56’ and using per-revision bisect providing the bisect result: Good build: 56.0.2905.0(Revision:428612) Bad build : 56.0.2906.0(Revision:428890) You are probably looking for a change made after 428746 (known good), but no later than 428747 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/37af9ea6080ce52e001189255512bd5bfa1c6c45..f9bc386d7f73366b45cb85848d27b4343facf45d Suspect: https://chromium.googlesource.com/chromium/src/+/f9bc386d7f73366b45cb85848d27b4343facf45d @rdevlin: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
,
Sep 22 2017
Revision f9bc386d7f73366b45cb85848d27b4343facf45d shouldn't have affected the NTP. Over to estade@ for triage as owner of chrome/browser/ui/webui/ntp/.
,
Sep 22 2017
I dunno, that CL looks fairly suspicious to me. It's not the NTP that's broken; it's launching the (packaged?) app. I don't know how to test this because my local build doesn't come with pre-installed apps. I would suggest re-running the bisect to be sure but the above CL seems suspicious enough to me not to discount it out of hand as the cause of the regression.
,
Sep 29 2017
Hmm... I dug into this a bit, and it looks like what's happening (at least for me) is content verification is disabling the extension. Some notes: First off, I always only able to reproduce this in an official build of chrome (in order to get the default apps installed) and only if I tried to open the docs app *very* quickly after profile creation. (The video shows the flow - create a new person, go to chrome://apps, and open docs.) My suspicion is that the time dependency is because it needs to happen while *something* is still going on in terms of downloading/installing the extension. What's happening here is that the user clicks on the app icon to launch the app, and the NTP webui launches the app through AppLauncherHandler::HandleLaunchApp() [1]. That results in opening the app in the same tab, which overtakes the tab. Then, the extension system disables the extension for corruption (a content verification failure). This results in the extension being unloaded, and that, in turn, results in closing all the extension tabs. [2] To the user, this appears like just closing the tab. [1] https://chromium.googlesource.com/chromium/src/+/ff9d46ff7d4406fcb3544a2eb5b14f14e896c1be/chrome/browser/ui/webui/ntp/app_launcher_handler.cc#483 [2] https://chromium.googlesource.com/chromium/src/+/ff9d46ff7d4406fcb3544a2eb5b14f14e896c1be/chrome/browser/ui/browser.cc#2069 Assigning to lazyboy@ for content verification, but also lowering priority since I was only able to reproduce this by clicking on the apps icon within a couple seconds of starting up a new profile, which I assume is pretty rare. If this is more widespread, we can re-evaluate. One shot-in-the-dark idea (quite probably incorrect): I'm not sure if content verification jobs run on the shared extension file task runner? If not, it might result in an inability to verify the file? |
||||
►
Sign in to add a comment |
||||
Comment 1 by shruti.j...@etouch.net
, Sep 22 2017