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.

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

fix: window.open doesn't work correctly in child window #25080

Merged
merged 1 commit into from Oct 7, 2020

Conversation

CezaryKulakowski
Copy link
Contributor

Description of Change

If speculative render view host is deleted during naviagation to
page we try to open with call to window.open window is destroyed
right after it is created. It may happen when naviagation triggers
redirect from http to https. To void that we should emit event
current-render-view-deleted only when render view host which was
destroyed is the current webcontent's rvh.

Checklist

Release Notes

Notes: Fixed window.open called from child window

Copy link
Member

@MarshallOfSound MarshallOfSound left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a test for this to indicate the failure behavior

@electron-cation electron-cation bot removed the new-pr 🌱 PR opened in the last 24 hours label Aug 22, 2020
@zcbenz
Copy link
Member

zcbenz commented Aug 23, 2020

@ppontes Can you take a look at this change? The related code was first added in #15821 and I'm not sure if this change would cause side effects.

@CezaryKulakowski
Copy link
Contributor Author

@MarshallOfSound I've attached sample application to this ticket: #25079. I will try to create unit test for it.

@CezaryKulakowski
Copy link
Contributor Author

@MarshallOfSound I've pushed fixup with unit test. I couldn't use external page like www.google.com in the test but I noticed the the problem also occurs when we use url with invalid protocol in second call to window.open so I used it in the test. Unfortunately I used timeout as I didn't find a proper way to check if child window was destroyed without using it. If you have an idea how to achieve that please let me know.

@@ -1155,6 +1155,10 @@ describe('webContents module', () => {
res.end();
} else if (req.url === '/redirected') {
res.end('<html><script>window.localStorage</script></html>');
} else if (req.url === '/first-window-open') {
res.end(`<html><script>window.open('${serverUrl}/second-window-open', 'first child');</script></html>`);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this have to open another child window in /second-window-open to repro the issue, wouldn't it repro if you used res.end(<html><script>window.open('${serverUrl}/redirect-cross-site', 'first child');</script></html>); ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that and it didn't work (i.e. problem doesn't reproduce). It should reproduce if there would be redirection from http to https (first reproduction and the most probable in normal usage was on http://www.google.com which redirects to https://www.google.com) but to achieve it in the test it would be necessary to start https server with valid certificate next to http server.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the protocol doesn't matter here http://www.google.com/ and https://www.google.com/ are different origins for chromium, it is required for a cross origin redirect to repro this issue. But weird, maybe the testing needs a network delay. Anyways the current test is good, wanted to see if we can simplify it. Thanks!

Copy link
Member

@ppontes ppontes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ppontes Can you take a look at this change? The related code was first added in #15821 and I'm not sure if this change would cause side effects.

Thanks for the notification, @zcbenz . I like this approach more as it's simpler and more explicit and can't recall why we didn't use it in the first place. I don't see side effects and the fact that the existing tests aren't broken hopefully confirms that.

spec-main/api-web-contents-spec.ts Outdated Show resolved Hide resolved
window.webContents.on('current-render-view-deleted' as any, renderViewDeletedHandler);
});
parentWindow.loadURL(`${serverUrl}/first-window-open`);
setTimeout(() => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we listen on navigation events on the childWindow before closing the parentWindow ? In this case it would be did-fail-load since the second url is a invalid url. I am bit worried about setTimeout being a potential for flaky tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've checked that did-fail-load is not emitted for this url. I've tried to find another event which we could use but with no luck so far.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If speculative render view host is deleted during naviagation to
page we try to open with call to window.open window is destroyed
right after it is created. It may happen when naviagation triggers
redirect from http to https. To void that we should emit event
current-render-view-deleted only when render view host which was
destroyed is the current webcontent's rvh.
@CezaryKulakowski
Copy link
Contributor Author

I've pushed branch rebased to the newest master (there was a conflict in one file so it was necessary) and with all fixups squashed. It should be ready to be merged to master.

@CezaryKulakowski
Copy link
Contributor Author

@MarshallOfSound test was created. Could you close the change request if it is sufficient for you?

@MarshallOfSound MarshallOfSound merged commit 73adeef into electron:master Oct 7, 2020
@release-clerk
Copy link

release-clerk bot commented Oct 7, 2020

Release Notes Persisted

Fixed window.open called from child window

@trop
Copy link
Contributor

trop bot commented Oct 7, 2020

I have automatically backported this PR to "11-x-y", please check out #25816

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants