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
feat: 'will-move' event for windows. #14283
Conversation
💖 Thanks for opening this pull request! 💖 We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix. Examples of commit messages with semantic prefixes:
Things that will help get your PR across the finish line:
We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can. |
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.
Good start. Looks like a reasonable idea.
docs/api/browser-window.md
Outdated
@@ -1,1532 +1,1543 @@ | |||
# BrowserWindow |
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.
A 3000 line diff in the docs...? 😄
Please fix these side-effects
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.
Ugh, will do, must be whitespace. Thanks!
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.
@ckerr fixed
::GetWindowRect(GetAcceleratedWidget(), | ||
reinterpret_cast<RECT*>(l_param)); | ||
return true; |
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.
What does the changed return value do here?
For the most part this patch seems symmetrical with the WM_SIZING
handler except that it always returns false.
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.
Without the change in value, frameless windows can still be moved with -webkit-app-region drag and neither !movable nor preventdefault work
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.
Makes sense. Could you add a short comment in the code to this effect?
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.
@ckerr done
Any word on this? Is there anything else I need to do? Also, what would it take to get "will-resize" and this "will-move" into 3.0.X? We would like to deliver a product that uses stable electron as opposed to something that uses a 4.0 nightly. Thanks! |
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.
Thanks for the changes!
That would require a change in Electron's versioning policy. The feature set for After this feature lands in |
Release Notes Persisted
|
Congrats on merging your first pull request! 🎉🎉🎉 |
Description of Change
Added a "will-move" event to the BrowserWindow, similar to the "will-resize" event. Windows only.
Checklist
npm test
passes(https://github.com/electron/electron/blob/master/docs/development/testing.md)
Release Notes
Notes: Added "will-move" event to the BrowserWindow.