-
Notifications
You must be signed in to change notification settings - Fork 16.5k
Open
Labels
30-x-y31-x-y32-x-ybug 🪲component/WebContentsViewcomponent/draggable-regionshas-repro-gistIssue can be reproduced with code at https://gist.github.com/Issue can be reproduced with code at https://gist.github.com/platform/macOSplatform/windowsstatus/confirmedA maintainer reproduced the bug or agreed with the featureA maintainer reproduced the bug or agreed with the feature
Description
Preflight Checklist
- I have read the Contributing Guidelines for this project.
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for a bug report that matches the one I want to file, without success.
Electron Version
30+
What operating system(s) are you using?
Windows, macOS
Operating System Version
Windows 10, macOS 13.6
What arch are you using?
x64
Last Known Working Electron version
No response
Expected Behavior
After designating the red area of the BrowserWindow as a draggable region with webkit-app-region:drag, when a WebContentView is added to the BrowserWindow.contentView, the blue area also becomes draggable.
This happens even if the blue area has been set as a non-draggable region with no-drag, indicating that it's still influenced by the draggable settings of the BrowserWindow.
Actual Behavior
When a BrowserWindow or another WebContentView adds a childView, the drag response is done according to the webkit-app-region behavior of the top childView.
Testcase Gist URL
https://gist.github.com/ksky521/091af6d9782583141564278002b6d235
Additional Information
No response
Metadata
Metadata
Assignees
Labels
30-x-y31-x-y32-x-ybug 🪲component/WebContentsViewcomponent/draggable-regionshas-repro-gistIssue can be reproduced with code at https://gist.github.com/Issue can be reproduced with code at https://gist.github.com/platform/macOSplatform/windowsstatus/confirmedA maintainer reproduced the bug or agreed with the featureA maintainer reproduced the bug or agreed with the feature