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

Upgrade electron from 13 to 15 #1764

Merged

Conversation

PikachuEXE
Copy link
Collaborator

@PikachuEXE PikachuEXE commented Sep 30, 2021

Blocking

Pull Request Type
Please select what type of pull request this is:

  • Bugfix
  • Feature Implementation

Related issue
Closes #1640
Closes #1651
Closes #1763

Description
Upgrade electron 13.x > 15.x AND fix the issue caused by a breaking change in electron 14

Breaking change:
electron/electron#28550
Child windows no longer inherit BrowserWindow construction options from their parents.

Screenshots (if appropriate)
Nothing visible should really changed

Testing (for code that is not small enough to be easily understandable)
All Dev team members should test this in

  • Multiple OS
  • Dev version (npm run dev) and built version afterward (can trigger nightly build manually)

Desktop (please complete the following information):

  • OS: MacOS
  • OS Version: 11.6
  • FreeTube version: based on 7d0880a

Additional context
Upgrade to electron 14 had caused issue like #1636
Upgrade to electron 15 to see if it's fixed
(since our PiP implementation relies on video.js > Electron > Chromium)

References:

This might replace #1763

@PrestonN PrestonN enabled auto-merge (squash) September 30, 2021 06:04
@PikachuEXE PikachuEXE changed the title Upgrade/electron 13 to 15 Upgrade electron from 13 to 15 Sep 30, 2021
@efb4f5ff-1298-471a-8973-3d47447115dc
Copy link
Member

this closes #1640
we need to check if it also fixes #1651, maybe @LynHyper can help testing this.

i tested this and it doesnt seems to break anything else

@PikachuEXE
Copy link
Collaborator Author

For #1651

Screen.Recording.2021-10-05.at.4.34.24.PM.mov

Too lazy to try for electron 14

@efb4f5ff-1298-471a-8973-3d47447115dc

I would opt for going with v 15 if nothing breaks ofcourse. Good to see that issue is also fixed.

@PikachuEXE
Copy link
Collaborator Author

What other issues are left which are potentially linked to electron upgrade?
(i.e. probably among those spotted in 0.14.0)

@efb4f5ff-1298-471a-8973-3d47447115dc

I'm not sure anymore i thought there was another one but cant seem to remember.

I've also tested it and looks good. I think its save to say that u can add closes #1651 to the PR.

@PikachuEXE
Copy link
Collaborator Author

Added
Let's review this after 0.15.0 is officially released

Copy link
Member

Choose a reason for hiding this comment

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

Tested extensively everything seems to work! LGTM!

@efb4f5ff-1298-471a-8973-3d47447115dc
Copy link
Member

Oh oops i didnt see ur last comment. Well... This isnt going to be included in v0.15.0 anyway😁

@PikachuEXE PikachuEXE mentioned this pull request Oct 12, 2021
2 tasks
@efb4f5ff-1298-471a-8973-3d47447115dc
Copy link
Member

Maybe this also fixes #1710. Need to look into that. I dont have a pinephone tho

Comment on lines 194 to 229
webSecurity: false,
backgroundThrottling: false,
contextIsolation: false
},
show: false
}
}
const newWindow = new BrowserWindow(
Object.assign(
{
// It will be shown later when ready via `ready-to-show` event
show: false
},
commonBrowserWindowOptions
)
)

// region Ensure child windows use same options since electron 14

// https://github.com/electron/electron/blob/14-x-y/docs/api/window-open.md#native-window-example
newWindow.webContents.setWindowOpenHandler(() => {
return {
action: 'allow',
overrideBrowserWindowOptions: Object.assign(
{
// It should be visible on click
show: true
},
commonBrowserWindowOptions
)
}
})

// endregion Ensure child windows use same options since electron 14

if (replaceMainWindow) {
mainWindow = newWindow
}
Copy link
Member

@Svallinn Svallinn Oct 18, 2021

Choose a reason for hiding this comment

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

Is all of this even necessary? The app works fine without this since we don't use window.open() anywhere.

While I understand the argument of making it future-proof, it feels a bit unnecessary to do this since we're
probably never gonna use window.open() in Electron renderer windows.

There are a couple of reasons for this:

  • the url would always have to be a path to the app, we'd have to prohibit everything else
  • different types of packaging could possibly interfere with how window.open() would behave, making it have
    odd behaviors

This is just my two cents when I first saw this, not really a demand for a change.
Point is, as it stands now, the setWindowOpenHandler callback is not being used for anything because we create
"sibling" windows rather than child windows
.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is actually required to fix #1636 which is caused by the breaking change introduced in Electron 14
Feel free to try a local version without this code
I might try it again later

Copy link
Member

@Svallinn Svallinn Oct 19, 2021

Choose a reason for hiding this comment

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

I forgot about that, that does use window.open()
I always considered being able to open a window in the app like that a bug rather than a feature, but I understand that some people actually like it

We will eventually have to get rid of it though, because right now, every window reloads the subscriptions feed which can lead to rate limiting if you are a heavy multi window user
Once we get rid of that, we'll have to disallow that particular window.open() behavior

This is fine for now, though

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If you mean opening a new window for a video in a slibing window instead of a child window, I would support that and even try to implement it myself.

Otherwise I am not sure what you mean.

@PikachuEXE
Copy link
Collaborator Author

As mentioned by @PrestonN in IRC
We need to wait for electron/electron#31448 to be fixed before merging this PR

Will update description too

image

@efb4f5ff-1298-471a-8973-3d47447115dc
Copy link
Member

Closes #1843, #1664 after this is fixed electron/electron#31448

@PikachuEXE
Copy link
Collaborator Author

Just not sure what versions will that fix land on...

@efb4f5ff-1298-471a-8973-3d47447115dc

Ur right but just wanted to give u a headsup

Breaking change:
electron/electron#28550
Child windows no longer inherit BrowserWindow construction options from their parents.
@PrestonN
Copy link
Member

I'm going to go ahead and bypass our typical review process and go ahead and merge this in. The fixes from upgrading Electron are important to our next patch release and I'd really like to include these.

I was able to do a quick test with this PR and it seems to fix all of the mentioned issues with the latest Electron patch. The PiP issue actually has to do with Chromium and the only way to fix that is to update Electron itself (Which we did obviously).

Thanks again for getting this together!

@peepo5
Copy link
Contributor

peepo5 commented Nov 10, 2021

👍

@efb4f5ff-1298-471a-8973-3d47447115dc efb4f5ff-1298-471a-8973-3d47447115dc added PR: dependencies Pull requests that update a dependency file and removed electron being electron Electron related bugs and trickeries labels Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

All dragged-around elements move in slow-motion Local directory link shows in picture-in-picture
5 participants