Isolating extension processes shouldn't require going via OpenURL path |
||
Issue descriptionAs a follow-up to issue 646261 we'd like to uniformly handle extension processes isolation via transfer logic (rather than relying for some aspects of the isolation to be enforced by the OpenURL path). Let's use this bug to track this work.
,
Sep 30 2016
Tentative CL for avoiding ShouldFork/OpenURL for extensions (but still using it for hosted apps) is at https://codereview.chromium.org/2386503002. At this point, there are 6 failing browser_tests: ExtensionBrowserTest.WindowOpenInvalidExtension ExtensionBrowserTest.WindowOpenNoPrivileges Both tests pass newtab_process_should_equal_opener=false to ExtensionBrowserTest::OpenWindow This expectation fails: ../../chrome/browser/extensions/extension_browsertest.cc:591: Failure Expected: (contents->GetRenderProcessHost()) != (newtab->GetRenderProcessHost()), actual: 0x6190000b4f80 vs 0x6190000b4f80 ExtensionResourceRequestPolicyTest.LinkToWebAccessibleResources Timeout. WebNavigationApiTest.CrossProcessHistory WebNavigationApiTest.CrossProcessFragment WebNavigationApiTest.CrossProcessAbort In all 3 cases above there is an unexpected onErrorOccurred (i.e. in test_crossProcessAbort.js this event was expected for SAME_SITE_URL, not for CROSS_SITE_URL).
,
Oct 3 2016
Note to self - when tweaking ShouldFork logic, we should be mindful of another possible regression that was reported in M54 - issue 651673 . We should probably touch base with kevinx@google.com to double-check everything is okay after we land further CLs.
,
Oct 14 2016
Fixing this bug should also allow to stop treating GET and POST differently in ShouldFork implementation (and possibly clean up some workarounds under blink::FrameLoader::load which trigger different behavior if request contains a form). |
||
►
Sign in to add a comment |
||
Comment 1 by lazyboy@chromium.org
, Sep 30 2016