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: handle window.open events in BrowserView #12686

Merged
merged 3 commits into from Nov 27, 2018
Merged

fix: handle window.open events in BrowserView #12686

merged 3 commits into from Nov 27, 2018

Conversation

Anrock
Copy link
Contributor

@Anrock Anrock commented Apr 22, 2018

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 from lib/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

@Anrock Anrock requested a review from a team April 22, 2018 12:14
@Anrock
Copy link
Contributor Author

Anrock commented Apr 22, 2018

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?

@MarshallOfSound MarshallOfSound added the semver/minor backwards-compatible functionality label Apr 22, 2018
@MarshallOfSound MarshallOfSound requested a review from a team April 22, 2018 12:28

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,
Copy link
Contributor

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

Copy link
Contributor Author

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".

Copy link
Contributor Author

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?

Copy link
Contributor

@poiru poiru Apr 23, 2018

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.

@Anrock
Copy link
Contributor Author

Anrock commented Apr 24, 2018

@poiru i've added second commit that moves common handlers from BrowserView and BrowserWindow to WebContents. Also rebased on fresh master.

Copy link
Contributor

@poiru poiru left a comment

Choose a reason for hiding this comment

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

LGTM, thank you!

@Anrock
Copy link
Contributor Author

Anrock commented Apr 24, 2018

@poiru thanks. Can it be also ported to 1.7? AFAIK there were some conflicts - i can make separate PR with adapted version.

@MarshallOfSound
Copy link
Member

This is something that can't be backported right? It's semver/feature 🤔

@Anrock
Copy link
Contributor Author

Anrock commented Apr 24, 2018

@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.

@MarshallOfSound
Copy link
Member

@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

@Anrock
Copy link
Contributor Author

Anrock commented Apr 24, 2018

@MarshallOfSound ok.
Only thing that bothers me now is what should i do to get this changes to 1.7 and 1.8 branches, please advice.

@poiru
Copy link
Contributor

poiru commented Apr 26, 2018

@ckerr Can you merge?

@Anrock
Copy link
Contributor Author

Anrock commented May 11, 2018

@poiru @ckerr any eta on merge? Two weeks and no movement.

@MarshallOfSound
Copy link
Member

The failing tests are blocking this

@poiru
Copy link
Contributor

poiru commented May 12, 2018

@Anrock The test failures might be flakes. Can you rebase on top of master and force push?

@alexeykuzmin
Copy link
Contributor

@Anrock
Can you please rebase your branch onto the latest master and resolve merge conflicts?

@Anrock Anrock changed the title handle window.open events in BrowserView fix: handle window.open events in BrowserView Sep 3, 2018
@Anrock
Copy link
Contributor Author

Anrock commented Sep 3, 2018

@alexeykuzmin in progress. However i suspect that test failures are not flakes actually.

@Anrock
Copy link
Contributor Author

Anrock commented Sep 3, 2018

@alexeykuzmin done. But i don't have time to investigate test failures.

Copy link

@Akshat-Jain Akshat-Jain left a 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 :-)

@Anrock
Copy link
Contributor Author

Anrock commented Sep 21, 2018

@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.

@Anrock Anrock closed this Oct 4, 2018
@Anrock Anrock reopened this Oct 4, 2018
@Anrock
Copy link
Contributor Author

Anrock commented Oct 4, 2018

Can someone help with broken tests?
linux-arm-debug, linux-arm-testing, linux-ia32-testing: failed build with sscache error
inux-x64-testing-tests, linux-x64-testing-verify-ffmpeg: failed tests with cannot open display
osx-testing: marked as failed, but circleci build step is not even finished yet

@Anrock
Copy link
Contributor Author

Anrock commented Oct 5, 2018

@Akshat-Jain i've rewritten this from scratch, so PR needs re-review.

@Anrock
Copy link
Contributor Author

Anrock commented Oct 5, 2018

Looks like #14984 should fix part of failing linux tests.

@Anrock
Copy link
Contributor Author

Anrock commented Oct 8, 2018

@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.
Anything else i'm missing?

@Anrock
Copy link
Contributor Author

Anrock commented Oct 11, 2018

@Akshat-Jain ping

@codebytere
Copy link
Member

hi @Anrock, @akshat-jain isn't involved in this project at all; you can see his review wasn't a valid one as it was a grey check. You can ping anyone in @electron/reviewers for future review!

@Anrock
Copy link
Contributor Author

Anrock commented Oct 11, 2018

@codebytere thank you! How do i find member list of @electron/reviewers?

@codebytere
Copy link
Member

ah i mean you can literally tag @electron/reviewers!

@Anrock
Copy link
Contributor Author

Anrock commented Oct 18, 2018

@codebytere for some reason it doesn't appear in autocompletion list and not marked as mention after i manually type it.

@MarshallOfSound
Copy link
Member

@Anrock All the test failures seem related to your code changes. For instance:

BrowserWindow module "webPreferences" option "sandbox" option should inherit the sandbox setting in opened windows - should inherit the sandbox setting in opened windows

Without green builds we can't look at merging this, you can run the tests locally with npm run test to verify before pushing to our CI.

@codebytere
Copy link
Member

@Anrock are you still interested in moving forward with this?

@Anrock
Copy link
Contributor Author

Anrock commented Nov 8, 2018

@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?

@zcbenz
Copy link
Member

zcbenz commented Nov 27, 2018

I have rebased the branch and added some fixes and tests.

@zcbenz zcbenz merged commit aafbd86 into electron:master Nov 27, 2018
@release-clerk
Copy link

release-clerk bot commented Nov 27, 2018

Release Notes Persisted

Fixed child windows invisible if opened with window.open from BrowserView with nativeWindowOpen enabled

@welcome
Copy link

welcome bot commented Nov 27, 2018

Congrats on merging your first pull request! 🎉🎉🎉

@Anrock Anrock deleted the browserview-handle-window-open branch December 4, 2018 11:27
@BinaryMuse
Copy link
Contributor

/trop run backport-to 4-0-x

BinaryMuse pushed a commit that referenced this pull request Dec 13, 2018
fix: handle window.open events in BrowserView
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver/minor backwards-compatible functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

window.open windows not visible when created from BrowserView with nativeWindowOpen enabled
8 participants