Chrome OS webview is not initialized when closing and opening the app
Reported by
aemscre...@gmail.com,
Nov 27 2017
|
|||||||||
Issue descriptionChrome Version : 62.0.3202.94 URLs (if applicable) : OS version : macOS Sierra 10.12.6 but also reproduces on Chrome OS on AOpen Chromebox mini. What steps will reproduce the problem? (1) Have a simple Chrome app/extension that loads an iframe containing a local page (2) The page loaded in the iframe has a webview (3) In the iFrame onload event check for any webview properties (such as request) This has been reproduced in a small extension that is attached. Load that extension into Chrome and click launch. You will see a black screen. Right click and inspect to see the webview not initialized error. Interestingly if you set a breakpoint (at say line 11) you will see that the webview does become initialized and displays google.com. However if you do not set a breakpoint, the webview is not initialized. What is the expected result? Webview object and properties should be available and usable (especially within an onload event). What happens instead? Webview is just a tag and not an object e.g., webview.request is undefined. There seems to be no event to identify that the webview is "ready". Ideally when an iFrame or window load event is called, all its content objects should be available for use.
,
Dec 1 2017
I can reproduce with your test case. cc'ing mcnee@ and wjmaclean@ for <webview>.
,
Dec 6 2017
It looks like simply having dev tools open is enough to cause the webview to be initialized. In the case where it's not initialized, registerGuestViewElement is not called for the subframe. In GuestViewContainer.registerElement, we have a 'readystatechange' listener to call registerGuestViewElement once the document had loaded, which may not get called for the subframe.
,
Dec 7 2017
kenrb@ - could this be related to the issues you looked at recently?
,
Dec 7 2017
So in the iframe, the document is already loaded when we get to GuestViewContainer.registerElement. If we do the registration immediately*, then webview elements will eventually be recognized as custom elements, but it still wouldn't be in time for the iframe's onload. * there's a circular dependency between web_view.js and web_view_api_methods.js that would need to be fixed first
,
Dec 7 2017
#4: I don't think this is related to any bugs that I know about.
,
Dec 8 2017
This is due to the time at which the ScriptContext for the iframe is created. In the test case's iframe ("display.html"), there are no script elements, so it doesn't get a ScriptContext. When we access the iframe's contentDocument, only then is the ScriptContext created, but it's too late to register the webview element at that point.
,
Dec 15 2017
,
Jan 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9c87118e237db47ba50dee623045ff060d162259 commit 9c87118e237db47ba50dee623045ff060d162259 Author: Kevin McNee <mcnee@chromium.org> Date: Wed Jan 24 23:36:19 2018 Ensure script context in subframes where webview needs definition If a frame has guest view custom elements defined, then any iframes also need the definition or else a webview in an iframe will not be initialized. If the iframe contains a script element, a script context will be created which allows for the definition of the custom element in the iframe. If there are no script elements, then no script context is created, so the custom element definition is not available. We make the ForceMainWorldInitialization setting available so that extension code can force the creation of a script context for any subframe of a frame which has access to guest view custom element definitions. Bug: 788914 Change-Id: Ibdd7c321b6e67dbe913f3deb2307406102d7b44a Reviewed-on: https://chromium-review.googlesource.com/828045 Commit-Queue: Kevin McNee <mcnee@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Cr-Commit-Position: refs/heads/master@{#531744} [modify] https://crrev.com/9c87118e237db47ba50dee623045ff060d162259/chrome/browser/apps/guest_view/web_view_browsertest.cc [modify] https://crrev.com/9c87118e237db47ba50dee623045ff060d162259/chrome/test/data/extensions/platform_apps/web_view/load_webview_inside_iframe/embedder.html [modify] https://crrev.com/9c87118e237db47ba50dee623045ff060d162259/chrome/test/data/extensions/platform_apps/web_view/load_webview_inside_iframe/embedder.js [modify] https://crrev.com/9c87118e237db47ba50dee623045ff060d162259/extensions/renderer/dispatcher.cc [modify] https://crrev.com/9c87118e237db47ba50dee623045ff060d162259/third_party/WebKit/Source/core/exported/WebSettingsImpl.cpp [modify] https://crrev.com/9c87118e237db47ba50dee623045ff060d162259/third_party/WebKit/Source/core/exported/WebSettingsImpl.h [modify] https://crrev.com/9c87118e237db47ba50dee623045ff060d162259/third_party/WebKit/public/web/WebSettings.h
,
Jan 25 2018
,
Aug 7
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by patricia...@chromium.org
, Nov 29 2017Labels: -OS-Mac OS-Chrome