iframe is not properly rendering for chrome extensions. Webpage is also not properly rendering after enabling "Out of process iframes" flag
Reported by
searcha...@gmail.com,
May 10 2017
|
||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Install the attached chrome extension 2. Click on the extension icon in address bar (with name of Getting started example) 3. When page is loaded, Click on the only button visible on top left. 4. Observe the webpage opened after clicking What is the expected behavior? Text inside the iframe is missing. Resize the chrome window and the text will be visible inside the iframe. What went wrong? I believe this is related to Site Isolation feature which went live in chrome 56. Moreover after enabling "Out of process iframes" experimental flag, I could reproduce this problem with webpage also (without extension) Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? Yes 55 Does this work in other browsers? N/A Chrome version: 58.0.3029.110 Channel: stable OS Version: OS X 10.12.4 Flash Version: Shockwave Flash 25.0 r0
,
May 11 2017
Tested the issue on Mac os 10.12.3, windows 7 and Ubuntu 14.04 using chrome M58 #58.0.3029.110 and M60 #60.0.3096.0 issue is reproduced. During bisect-per-revision , all builds are resulted in good builds and hence providing manual bisect range. Good Build : 58.0.3000.0 (revision : 447669) Bad Build : 8.0.3001.0 (revision : 447896) Changelog : ---------- https://chromium.googlesource.com/chromium/src/+log/58.0.3000.0..58.0.3001.0?pretty=fuller&n=10000 @ Could someone help in assigning it to the concerned owner Note : In all the bad builds , once the extension page is reloaded and clicked the iframe content is loaded. Thanks!
,
May 11 2017
Possible suspect , not sure though. ================ https://chromium.googlesource.com/chromium/src/+/6eef82663dd4619c7ea75db5bac1e87f37b64046 Assigning to the CL owners aswell as looping one one of the reviewers for further updates.
,
May 11 2017
I could test attached extension tomorrow with and without the CL, but I doubt it is an offending CL. https://codereview.chromium.org/2657023005 checks whether navigator.nfc.* methods are called from main frame, moreover, WebNFC is disabled under feature flag, in M58, under experimental web platform features. ligimole@ Does attached extension uses WebNFC APIs?
,
May 11 2017
searchatul@ could you please confirm whether the extension uses WebNFC APIs.
,
May 11 2017
ligimole@ I checked, it doesn't. Just uses chrome tabs api to open new tab with html document that has an iframe.
,
May 12 2017
ligimole@ I've tested 58.0.3029.110, same behavior with or without https://codereview.chromium.org/2657023005 CL Click extension icon => Extension opens tab Click 'Click here' link => iframe is loaded without content Resize window => text 'This is content of the iframe' becomes visible After repeating the steps, text becomes visible immediately, no need to resize window.
,
May 12 2017
I believe the issue disappear after the page is cached and when cached copy is used. I tried to disable cache of the page but it still does cache (maybe I didn't properly did it).
,
May 12 2017
ligimole@ https://codereview.chromium.org/2657023005 is not an offending issue, do you want me to continue? Maybe help with bisecting?
,
May 12 2017
Thanks shalamov@.I will request the team to try a re-bisect and get back. Hemalatha, please try a bisect again, if you are getting all good builds its incorrect.
,
May 15 2017
Tested the issue on Mac os 10.12.3 both retina and non-retina , windows 7 and ubuntu 14.04 using chrome M58 #58.0.3029.110 and issue is reproduced. But , as the issue is inconsistent in different builds , unable to find the exact bisect range. Issue behavior is different for the same builds , every time . Iframe content is loaded sometimes without any reload and sometimes after clicking on iframe , content is disappeared and sometimes even after reloads iframe content is not loaded. Attached screencast for the same. @searchatul-- Could you please provide us the testcase/jsfiddle which can be reproduced consistently , that would help us in bisecting the bug. Thanks!
,
May 16 2017
@hdodda - I am not sure what is causing this behavior. In our use case, this is happening consistently. Can you try disabling cache and try again? This should reproduce consistently with cache off.
,
May 17 2017
Tested the iasue on Mac OS 10.12.4 using chrome stable #58.0.3029.110 with disabling cache from developer tools. But still issue is reproduced inconsistently with cache off , attached screencast for reference. @searchatul-- Could you please help us in bisecting the bug , with consistent steps to reproduce the issue. Thanks!
,
May 18 2017
@hdodda - I have disabled caching from server side. Please check again. I was able to reproduce the steps every time now. If needed, I can share the screenshot. Also if needed, I can help you in bisecting the bug.
,
May 18 2017
This is an important bug for our application which needs to be fixed. So requesting you to take this into account. Thanks
,
May 19 2017
Tested this issue by disabling cache in dev tools on Mac 10.12.4 and Ubuntu 14.04 with chrome stable #58.0.3029.110 , Canary #60.0.3102.0 Issue is so inconsistent that unable to provide a reliable bisect script result, removing "needs-bisect" label for now. Attaching a screen-cast for reference. ligi@, could you please look into this and let us know if you need any more information. Note: In Chrome #55.0.2883.75, issue is not reproducible.
,
May 22 2017
@kkaluri, I can do the bisect and provide the exact version where this breaks. Is there a documentation which I can read to understand how to do tbe bisect and where to get the builds for the same.
,
May 22 2017
Thanks everyone for the updates. searchatul@ you can get the details about bisecting from here- https://www.chromium.org/developers/bisect-builds-py
,
May 22 2017
,
May 23 2017
You are probably looking for a change made after 450815 (known good), but no later than 450824 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/32e074e42207bf161510aba4c4b5539d0818d2f1..ecfcc163f15b17c9a04b1f62db1ff8cf11d9eccc
,
May 23 2017
As per the changelog, the most probable cause should be https://chromium.googlesource.com/chromium/src/+/d81f57c5700ed617cc183847ad3e0f35df1c8221 Reiterating, this is an important bug for our product and is creating a blocker bug in the product. Hence requesting to take this bug on priority. Also let me know if I can help in any other manner for speedy resolution.
,
May 24 2017
Any update for this bug? @kkaluri, @ligim?
,
May 24 2017
Based on #c22, setting component to Internals>Sandbox>SiteIsolation. Please update if this is incorrect.
,
May 24 2017
Apologies that this took so long to get triaged! rtoy@, thanks for adding the Site Isolation label, which I wish had been added much earlier given the original report. kenrb@: From a quick skim of the description, I suspect this might be a duplicate of issue 712320 , which you fixed in M59. Would you agree? I can try to repro locally to confirm. searchatul@: Do you see the bug on Chrome 59 or Chrome 60 (e.g., Chrome Canary)?
,
May 24 2017
The behavior sounds a lot like issue 712320 , so likely a dupe. Testing on current Beta or Canary should confirm.
,
May 24 2017
Looks like it's still broken on ToT (synced to r473819). I see no text in the inner frame until I resize the browser window.
,
May 24 2017
The issue is *not* fixed in 60.0.3109.0 (Official Build) canary version for Mac.
,
May 24 2017
lfg@ and I have verified that it is at least a very similar cause as issue 712320 , in that a same-process iframe within a nested OOPIF is getting frame throttled. Possibly there is a different cause where the intersection observer viewport rect propagation and we hadn't noticed it before. Investigating.
,
May 30 2017
,
May 30 2017
Fix is in review: https://codereview.chromium.org/2910023002/ (Thanks Ken!)
,
May 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f commit 1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f Author: kenrb <kenrb@chromium.org> Date: Wed May 31 02:47:40 2017 Ensure RemoteViewportIntersection rect persists across frame navigations To prevent excessive IPC messages, a parent frame of an OOPIF only updates its remote viewport intersection rect when the intersection changes. However, a frame can navigate without the parent frame being aware of it, in which case the rect is lost without being resent. To address that problem, this CL caches the rect on CrossProcessFrameConnector in the browser process, and sends it to the renderer whenever RenderWidgetHostImpl::SendScreenRects() is called. This CL also moves the rect's storage in Blink from LocalFrameView to LocalFrame so that it persists across same-process navigations. BUG= 720342 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2910023002 Cr-Commit-Position: refs/heads/master@{#475756} [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/content/browser/frame_host/cross_process_frame_connector.cc [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/content/browser/frame_host/cross_process_frame_connector.h [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/content/browser/frame_host/render_widget_host_view_child_frame.cc [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/content/browser/frame_host/render_widget_host_view_child_frame.h [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/content/browser/frame_host/render_widget_host_view_child_frame_unittest.cc [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/content/browser/renderer_host/render_widget_host_view_base.h [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/third_party/WebKit/Source/core/frame/LocalFrame.cpp [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/third_party/WebKit/Source/core/frame/LocalFrame.h [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/third_party/WebKit/Source/core/frame/LocalFrameView.cpp [modify] https://crrev.com/1e68f60e90fc7b0b12bbf884291458e5e4aa3b2f/third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp
,
May 31 2017
,
May 31 2017
This bug requires manual review: We are only 5 days from stable. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 31 2017
Ken: Did you mean to merge to M60 first?
,
May 31 2017
Yes, that makes more sense.
,
May 31 2017
Is there a build which we can try it out? Some sort of build of master?
,
May 31 2017
#37: The easiest way for you to verify it would be to download Chrome Canary on Windows or Mac, which is updated daily. This fix didn't make today's Canary, but it should be in tomorrow's.
,
May 31 2017
,
Jun 1 2017
Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 1 2017
The fix is available in latest canary -61.0.3117.0. searchatul@ would you mind verifying? You can download canary from here- https://www.google.com/chrome/browser/canary.html
,
Jun 2 2017
@ligim - Thanks for information. I downloaded and verified that the issue **has** been fixed in latest version of Canary. This also include the original issue for which a test case was created is also fixed. Thanks for your support.
,
Jun 2 2017
What is the earliest version this fix is being merged to? Is it possible to merge this fix into M59 also?
,
Jun 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3978c4d1047d5a2559a6b85de3804790872e35d9 commit 3978c4d1047d5a2559a6b85de3804790872e35d9 Author: Ken Buchanan <kenrb@chromium.org> Date: Fri Jun 02 16:23:49 2017 Ensure RemoteViewportIntersection rect persists across frame navigations To prevent excessive IPC messages, a parent frame of an OOPIF only updates its remote viewport intersection rect when the intersection changes. However, a frame can navigate without the parent frame being aware of it, in which case the rect is lost without being resent. To address that problem, this CL caches the rect on CrossProcessFrameConnector in the browser process, and sends it to the renderer whenever RenderWidgetHostImpl::SendScreenRects() is called. This CL also moves the rect's storage in Blink from LocalFrameView to LocalFrame so that it persists across same-process navigations. BUG= 720342 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2910023002 Cr-Original-Commit-Position: refs/heads/master@{#475756} Review-Url: https://codereview.chromium.org/2919903003 . Cr-Commit-Position: refs/branch-heads/3112@{#119} Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897} [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/content/browser/frame_host/cross_process_frame_connector.cc [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/content/browser/frame_host/cross_process_frame_connector.h [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/content/browser/frame_host/render_widget_host_view_child_frame.cc [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/content/browser/frame_host/render_widget_host_view_child_frame.h [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/content/browser/frame_host/render_widget_host_view_child_frame_unittest.cc [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/content/browser/renderer_host/render_widget_host_view_base.h [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/third_party/WebKit/Source/core/frame/FrameView.cpp [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/third_party/WebKit/Source/core/frame/LocalFrame.cpp [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/third_party/WebKit/Source/core/frame/LocalFrame.h [modify] https://crrev.com/3978c4d1047d5a2559a6b85de3804790872e35d9/third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp
,
Jun 6 2017
Tested the issue on Windows-10 & 7, Ubuntu 14.04 and Mac OS 10.12.5 using chrome latest Dev M60-60.0.3112.20 by following steps mentioned in the original comment. Observed that Text inside the i frame displaying as expected(As per comment #13 & 16 Issue is inconsistent.Tried multiple times(15-20) in latest Dev #60.0.3112.20 and not able to reproduce the issue).Assuming issue to be fixed. Hence adding TE-Verified label.Please find the screen cast for reference. Thank you! |
||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, May 10 2017Components: Blink
Labels: -Pri-2 Needs-Triage-M58 Needs-Bisect Pri-1