electron/patches/chromium/fix_remove_caption-removing_style_call.patch
electron-roller[bot] 0e4e9dc98c
chore: bump chromium to 121.0.6116.0 (main) (#40490)
* chore: bump chromium in DEPS to 121.0.6116.0

* chore: update patches

* Update webIDL to support close event.

Refs https://chromium-review.googlesource.com/c/chromium/src/+/4970653

* Remove uses of implicit conversion of ScopedTypeRef

Refs https://bugs.chromium.org/p/chromium/issues/detail?id=1495439

* Add GlobalRenderFrameHostToken

Refs https://chromium-review.googlesource.com/c/chromium/src/+/5001743

* [DevTools] Console Insights: move from build flag to Feature API

Refs https://chromium-review.googlesource.com/c/chromium/src/+/5002232

* [Extensions] Use script serialization in scripting API

Refs https://chromium-review.googlesource.com/c/chromium/src/+/4968680
Refs https://chromium-review.googlesource.com/c/chromium/src/+/4998265

* [api] Remove AllCan Read/Write

https://chromium-review.googlesource.com/c/v8/v8/+/5006387

* chore: update libcxx files

* chore: address nan compilation error

* spec: use nan dependency from third_party

It is easier to get fixes for spec modules depending on nan

* ci: publish nan artifact for woa

* fix: bad patch update

* chore: update nan resolution

* Revert "chore: update nan resolution"

This reverts commit 786cdb858c9fc8a038a8f3e16068ee5b4a050137.

---------

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: deepak1556 <hop2deep@gmail.com>
2023-11-14 13:21:32 -08:00

48 lines
2.4 KiB
Diff

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Raymond Zhao <7199958+rzhao271@users.noreply.github.com>
Date: Wed, 17 Aug 2022 13:49:40 -0700
Subject: fix: Adjust caption-removing style call
There is a SetWindowLong call that removes WS_CAPTION for frameless
windows, but Electron uses WS_CAPTION even for frameless windows,
unless they are transparent.
Changing this call only affects frameless windows, and it fixes
a visual glitch where they showed a Windows 7 style frame
during startup.
The if statement was originally introduced by
https://codereview.chromium.org/9372053/, and it was there to fix
a visual glitch with the close button showing up during startup
or resizing, but Electron does not seem to run into that issue
for opaque frameless windows even with that block commented out.
diff --git a/ui/views/win/hwnd_message_handler.cc b/ui/views/win/hwnd_message_handler.cc
index 04a4699302522da271fb4935606d9823a2816ec9..f233b50629796be30962977f1b53f54cace4f783 100644
--- a/ui/views/win/hwnd_message_handler.cc
+++ b/ui/views/win/hwnd_message_handler.cc
@@ -1733,7 +1733,23 @@ LRESULT HWNDMessageHandler::OnCreate(CREATESTRUCT* create_struct) {
SendMessage(hwnd(), WM_CHANGEUISTATE, MAKELPARAM(UIS_CLEAR, UISF_HIDEFOCUS),
0);
- if (!delegate_->HasFrame()) {
+ LONG is_popup =
+ GetWindowLong(hwnd(), GWL_STYLE) & static_cast<LONG>(WS_POPUP);
+
+ // For transparent windows, Electron removes the WS_CAPTION style,
+ // so we continue to remove it here. If we didn't, an opaque rectangle
+ // would show up.
+ // For non-transparent windows, Electron keeps the WS_CAPTION style,
+ // so we don't remove it in that case. If we did, a Windows 7 frame
+ // would show up.
+ // We also need this block for frameless popup windows. When the user opens
+ // a dropdown in an Electron app, the internal popup menu from
+ // third_party/blink/renderer/core/html/forms/internal_popup_menu.h
+ // is rendered. That menu is actually an HTML page inside of a frameless popup window.
+ // A new popup window is created every time the user opens the dropdown,
+ // and this code path is run. The code block below runs SendFrameChanged,
+ // which gives the dropdown options the proper layout.
+ if (!delegate_->HasFrame() && (is_translucent_ || is_popup)) {
SetWindowLong(hwnd(), GWL_STYLE,
GetWindowLong(hwnd(), GWL_STYLE) & ~WS_CAPTION);
SendFrameChanged();