Using the per-revision bisect providing the bisect results,
Good build:55.0.2841.0(Revision: 414854).
Bad build: 55.0.2842.0 (Revision: 414942).

Issue is also seen in Mac OS 10.11.6

You are probably looking for a change made after 414875 (known good), but no later than 414876 (first known bad).

CHANGELOG URL:
  
https://chromium.googlesource.com/chromium/src/+log/9009fb22a7b7a80cb28164d0bef8d47daa2ef81e..0f97e6f1d883e094b4fd92da0b255226647b7053

From the CL above, assigning the issue to the concern owner 

@alph - Could you please check whether this is caused with respect to your change, if not please help us in assign it to the right owner.

Review-Url: https://codereview.chromium.org/2286963002

Note : Adding RB-stable for now , please feel free to edit it.

Thanks!

alph@, could you please take a look and fix this ASAP as this is marked as M55 stable blocker.

Thank you.

I believe the bisect is wrong. My change is pure DevTools frontend code which is never run for the testcase.

I made a bisect that points to "Enable Site Isolation for Extensions."
https://chromium.googlesource.com/chromium/src/+/d8f0aefde00132b06bd97cb17555f2ec89a0c203

Sounds like this is due to the startup cost of the OOPIF.  That said, I don't actually see a delay in the attached video.  There's maybe a single frame of the video (as the popup is still fading in) where the Tweet button isn't fully drawn, which seems pretty low impact.  Maybe it gets worse than the video demonstrates?  I don't really observe it in practice, FWIW.

In general, we'd value ways to make the startup faster, but having some process startup cost for the OOPIF is fundamental.  Part of the value of OOPIFs is that the parent page can finish rendering without being slowed down by cross-site subframes, so there's value to this as well.

Nasko, do you see anything worth doing here?

On my system, I was able to repro a consistent 20 second delay before the
Tweet button shows up. This didn't happen immediately, but after clicking
the button very frequently, and now it happens consistently in this window.

In net-internals events, I see an ERR_CACHE_LOCK_TIMEOUT that is happening
with what looks like a big jump in delta-t:

12987: URL_REQUEST
https://platform.twitter.com/widgets/tweet_button.39f7ee9fffbd122b7a37a520dbdaebc6.en.html#dnt=false&hashtags=music4chrome&id=twitter-widget-0&lang=en&original_referer=chrome-extension%3A%2F%2Ffheglbjjlikcmbifdhdmhfjogjofhakp%2Fhtml%2Fpopup.html&size=l&text=Check%20out%20these%20music%20extensions%20for%20Chrome!&time=1476743285204&type=share&url=https%3A%2F%2Fplus.google.com%2F108126838540149369329
Start Time: 2016-10-17 15:28:05.179

t= 4223 [st=    0] +REQUEST_ALIVE  [dt=20150]
t= 4223 [st=    0]    DELEGATE_INFO  [dt=0]
                      --> delegate_info = "NavigationResourceThrottle"
t= 4223 [st=    0]    URL_REQUEST_DELEGATE  [dt=0]
t= 4223 [st=    0]    URL_REQUEST_START_JOB  [dt=1]
                      --> load_flags = 256 (VERIFY_EV_CERT)
                      --> method = "GET"
                      --> priority = "HIGHEST"
                      --> url =
"https://platform.twitter.com/widgets/tweet_button.39f7ee9fffbd122b7a37a520dbdaebc6.en.html#dnt=false&hashtags=music4chrome&id=twitter-widget-0&lang=en&original_referer=chrome-extension%3A%2F%2Ffheglbjjlikcmbifdhdmhfjogjofhakp%2Fhtml%2Fpopup.html&size=l&text=Check%20out%20these%20music%20extensions%20for%20Chrome!&time=1476743285204&type=share&url=https%3A%2F%2Fplus.google.com%2F108126838540149369329"
t= 4224 [st=    1]   +URL_REQUEST_START_JOB  [dt=20061]
                      --> load_flags = 256 (VERIFY_EV_CERT)
                      --> method = "GET"
                      --> priority = "HIGHEST"
                      --> url =
"https://platform.twitter.com/widgets/tweet_button.39f7ee9fffbd122b7a37a520dbdaebc6.en.html#dnt=false&hashtags=music4chrome&id=twitter-widget-0&lang=en&original_referer=chrome-extension%3A%2F%2Ffheglbjjlikcmbifdhdmhfjogjofhakp%2Fhtml%2Fpopup.html&size=l&text=Check%20out%20these%20music%20extensions%20for%20Chrome!&time=1476743285204&type=share&url=https%3A%2F%2Fplus.google.com%2F108126838540149369329"
t= 4224 [st=    1]      URL_REQUEST_DELEGATE  [dt=0]
t= 4224 [st=    1]      HTTP_CACHE_GET_BACKEND  [dt=0]
t= 4224 [st=    1]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
t= 4224 [st=    1]      HTTP_CACHE_ADD_TO_ENTRY  [dt=20000]
                        --> net_error = -409 (ERR_CACHE_LOCK_TIMEOUT)
t=24224 [st=20001]     +HTTP_STREAM_REQUEST  [dt=42]
t=24224 [st=20001]        HTTP_STREAM_REQUEST_STARTED_JOB
                          --> source_dependency = 12995 (HTTP_STREAM_JOB)
t=24266 [st=20043]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                          --> source_dependency = 12995 (HTTP_STREAM_JOB)
t=24266 [st=20043]     -HTTP_STREAM_REQUEST

Comment 6: I can't repro that, but it seems like that's a concerning bug in cross-process transfers that's separate from the issue being reported.  (There's no 20 second delay in the video.)  Can you file that as a separate bug?  I think we want to get to the bottom of it and make sure it gets fixed.

I think this particular bug is a WontFix.  Yes, the painting of the OOPIF is a fraction of a second slower than a same process frame, but we consider that ok for the security benefit (and other performance isolation behavior).  I'll also note that we can do better by implementing  issue 512560 , where we consolidate the two subframes (google.com and twitter.com) into the same process, separate from the extension process.

And adharap@etouch.net: Correct me if you were filing this bug about a 20 second delay before the Twitter button is shown.  It sounds like that's a separate issue, though, and that you were just noticing the flicker.