Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Electron 5 webview with no contextIsolation and nativeWindowOpen fails to load a preload in a popup window in the correct context #17989

Closed
3 tasks done
Tim91084 opened this issue Apr 26, 2019 · 4 comments
Closed
3 tasks done

Electron 5 webview with no contextIsolation and nativeWindowOpen fails to load a preload in a popup window in the correct context #17989

Tim91084 opened this issue Apr 26, 2019 · 4 comments
Labels
5-0-x blocked/need-info ❌ Cannot proceed without more information bug 🪲 platform/windows
Projects
5.0.x

Comments

@Tim91084
Copy link

Tim91084 commented Apr 26, 2019 •
edited

Preflight Checklist

  • I have read the Contributing Guidelines for this project.
  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

  • Electron Version:
    • 5.0.0
  • Operating System:
    • Windows (didn't test anywhere else)
  • Last Known Working Electron version::
    • ? not sure.

Expected Behavior

When opening a popup window from a webview with contextIsolation=no,nativeWindowOpen=yes, the preload script for that webview should load in the popup window in the correct context

Actual Behavior

The preload script appears to fail to load in the correct context, causing things like fetch to fail with the following error: TypeError: Failed to execute 'fetch' on 'Window': The global scope is shutting down.

To Reproduce

index.html

<webview src="webview-test.html"
      style="height:100%; width: 100%"
      allowpopups
      preload="preload.js"
      webPreferences="contextIsolation=no,nativeWindowOpen=yes"></webview>

webview-test.html

<html>
<body>
  <script>
    window.openGoogle = function () {
      window.open('https://www.google.com')
    }
  </script>
  <button onclick="openGoogle()" type="button">window.open('https://www.google.com')</button>
</body>
</html>

preload.js

// window.location.href always reports about:blank in this situation for some reason
console.log('window.location.href', window.location.href)
fetch('https://www.google.com')
    .then(x => console.log('success', x.text()))
    .catch(x => console.log('error', x))

forked quick start repo with reproduction

https://github.com/Tim91084/electron-window-open-bug

Screenshots

image

image
@sofianguy sofianguy added this to Unsorted Issues in 5.0.x Apr 26, 2019
This was referenced Apr 29, 2019
Merged
Closed
@hugomano
Copy link

hugomano commented Apr 30, 2019 •
edited

We observed that preloads scripts are not executed after a window.open only when the opener and the opened window shares the same origin domain. But, after navigating the opened window to a different domain, preloads are executed. More details here

It really looks like #15821 has something to do with that:
When a new WebContents is created in an existing browsing instance, will renderer initialization scripts (responsible for preload scripts execution) be executed?

@ppontes @deepak1556 @zcbenz any idea?

@alexstrat
Copy link
Contributor

Wouldn't this condition on Opener() be preventing the execution of renderer initialization scripts?

electron/atom/renderer/atom_renderer_client.cc

Lines 76 to 79 in 53f6cbc

// Do not load node if we're aren't a main frame or a devtools extension
// unless node support has been explicitly enabled for sub frames
bool is_main_frame =
render_frame->IsMainFrame() && !render_frame->GetWebFrame()->Opener();

@jeremyspiegel jeremyspiegel mentioned this issue Apr 30, 2019
Closed
3 tasks
@electron-triage
Copy link

Thank you for taking the time to report this issue and helping to make Electron better.

The version of Electron you reported this on has been superseded by newer releases.

If you're still experiencing this issue in Electron 6.x.y or later, please add a comment specifying the version you're testing with and any other new information that a maintainer trying to reproduce the issue should know.

I'm setting the blocked/need-info label for the above reasons. This issue will be closed 7 days from now if there is no response.

Thanks in advance! Your help is appreciated.

@electron-triage electron-triage added the blocked/need-info ❌ Cannot proceed without more information label Feb 19, 2020
@electron-triage
Copy link

Thank you for your issue!

We haven't gotten a response to our questions in our comment above. With only the information that is currently in the issue, we don't have enough information to take action. I'm going to close this but don't hesitate to reach out if you have or find the answers we need, we'll be happy to reopen the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
5-0-x blocked/need-info ❌ Cannot proceed without more information bug 🪲 platform/windows
Projects
No open projects
5.0.x
Unsorted Issues
Milestone
No milestone
Development

No branches or pull requests
5 participants
@alexstrat @hugomano @sofianguy @Tim91084 @electron-triage