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: handle window.open events in BrowserView #12686
fix: handle window.open events in BrowserView #12686
Conversation
Also, personally i need this backported to 1.7.x and 1.8.x branches but i haven't found the docs on how to do this: from pull request guides it seems only permitted target branch is master. Is there any docs on backporting process or could someone explain it to me? |
lib/browser/api/browser-view.js
Outdated
|
||
Object.setPrototypeOf(BrowserView.prototype, EventEmitter.prototype) | ||
BrowserView.prototype._init = function () { | ||
// Make new windows requested by links behave like "window.open" | ||
this.webContents.on('-new-window', (event, url, frameName, disposition, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could just do this in lib/browser/api/web-contents.js
to share the impl between BrowserWindow/BrowserView? cc @zcbenz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that seems like a nice fix of "mindless copypaste".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@poiru how do i handle commits with fixes from review? Is it ok to fixup it all and push -f
or is it better to lay on top of existing commits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Anrock Either way is fine with me. Feel free to just make new commits. We can squash it all when merging.
@poiru i've added second commit that moves common handlers from BrowserView and BrowserWindow to WebContents. Also rebased on fresh master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
@poiru thanks. Can it be also ported to 1.7? AFAIK there were some conflicts - i can make separate PR with adapted version. |
This is something that can't be backported right? It's semver/feature 🤔 |
@MarshallOfSound i'd say it's a bugfix. At least i expect, from user perspective, that BrowserView should behave identically irregardless if nativeWindowOpen is true or false. Just like BrowserWindow does. |
@Anrock There's a line between "adding a feature that probably should have been there in the first place" and "fixing something that wasn't functioning correctly". I think this is quite nicely fitting in the first category |
@MarshallOfSound ok. |
@ckerr Can you merge? |
The failing tests are blocking this |
@Anrock The test failures might be flakes. Can you rebase on top of master and force push? |
@Anrock |
@alexeykuzmin in progress. However i suspect that test failures are not flakes actually. |
@alexeykuzmin done. But i don't have time to investigate test failures. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please resolve the conflicts. Thanks :-)
@Akshat-Jain done. I think it's time to scrap this PR and rewrite from scratch. Looks like handlers have changed multiple times and given non-trivial conflicts i suspect something is missed in action. |
Can someone help with broken tests? |
@Akshat-Jain i've rewritten this from scratch, so PR needs re-review. |
Looks like #14984 should fix part of failing linux tests. |
@alexeykuzmin regarding #15016, this PR rebased on master and in branch log i see that branch includes 918488a commit that should fix build breakage, however build is still broken. |
@Akshat-Jain ping |
hi @Anrock, |
@codebytere thank you! How do i find member list of @electron/reviewers? |
ah i mean you can literally tag |
@codebytere for some reason it doesn't appear in autocompletion list and not marked as mention after i manually type it. |
@Anrock All the test failures seem related to your code changes. For instance:
Without green builds we can't look at merging this, you can run the tests locally with |
@Anrock are you still interested in moving forward with this? |
@codebytere yes, but i really don't have time to do it - busy fixing window.opener in my app. And i guess code is gone stale again. Should i close PR then or there is someone else interested doing it? |
I have rebased the branch and added some fixes and tests. |
Release Notes Persisted
|
Congrats on merging your first pull request! 🎉🎉🎉 |
/trop run backport-to 4-0-x |
fix: handle window.open events in BrowserView
Fixes #10707
Not sure if it's a proper fix, but Work For Me™
Basically it's just a mindless copypaste of
-new-window
,-web-contents-created
,-add-new-contents
handlers fromlib/browser/api/browser-window.js
_init
along with relevant unit-tests.notes: Fixed child windows invisible if opened with window.open from BrowserView with nativeWindowOpen enabled