Repository: electron/electron (language: cpp)

Issue:
[Bug]: Frameless window displays frame while opening
### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Electron Version

14.0.0-beta.25

### What operating system are you using?

Windows

### Operating System Version

Windows 10 21H1

### What arch are you using?

x64

### Last Known Working Electron version

14.0.0-beta.3

### Expected Behavior

Opening a frameless window and immediately revealing it (instead of waiting for `ready-to-show` event) shows no content inside of the window.

### Actual Behavior

Opening a frameless window and immediately revealing it (instead of waiting for `ready-to-show` event) shows an older style window frame with no content inside.

| 14.0.0-beta.3 | 14.0.0-beta.5 |
| --- | --- |
| ![image](https://user-images.githubusercontent.com/1656324/131413708-cc472e02-21d7-4fc8-9a6b-ca38391b7911.png) |  ![image](https://user-images.githubusercontent.com/1656324/131413746-ac2e389f-1528-4f60-886b-25a93ef8e217.png) |


https://user-images.githubusercontent.com/1656324/131413659-18c2ea6c-d1c4-489f-8182-ae19cba51bcb.mp4



### Testcase Gist URL

https://gist.github.com/4256f388d41ef0d974645a11ab72b1fe

### Additional Information

This may not be a bug, but I felt that displaying the frame while the window is opening was maybe not intentional.


Discussion / hints:
Setting backgroundColor to `#00000000` (alpha included) shows this until the window is resized:

![image](https://user-images.githubusercontent.com/1656324/131576965-0570fd1c-67a6-46bc-9cd6-7424cc1b5e78.png)

I also noticed this issue. It's reproducible in `v15.0.0-beta.1` as well
Hi 
Any news on this?
Bisected to https://github.com/electron/electron/compare/v14.0.0-beta.3...v14.0.0-beta.5
@codebytere 

Hi, am using v16.0.4 should I downgrade to v13 ?
Reopening for https://github.com/electron/electron/pull/33599
Although there is a user facing workaround, it is worth investigating why this code path regressed with the chromium roll bisected in this range https://github.com/electron/electron/issues/30760#issuecomment-1025586864
I also noticed that the actual size of the window is a turn smaller than it looks. When dragging the scrollbar with the mouse you often accidentally click on the window zoom.
![1](https://user-images.githubusercontent.com/35626141/171562345-3990b719-77f9-432b-8548-a859c6f64147.gif)
![2](https://user-images.githubusercontent.com/35626141/171562677-0d6c48b1-63a8-44da-995f-4d60d5e0d148.gif)

> I also noticed that the actual size of the window is a turn smaller than it looks. When dragging the scrollbar with the mouse you often accidentally click on the window zoom.
![1](https://user-images.githubusercontent.com/35626141/171562345-3990b719-77f9-432b-8548-a859c6f64147.gif)

But it’s been so since at least Electron 13.x.
Bisected to https://github.com/electron/electron/commit/172ac2501330c64c2a33c1004e05eb23f9658903, though a lot of things happened during that roll: https://chromium.googlesource.com/chromium/src/+log/92.0.4511.0..93.0.4530.0?n=10000&pretty=fuller

Fix patch:
diff --git a/patches/chromium/.patches b/patches/chromium/.patches
index ea04e58a07500..c9e516ffc0929 100644
--- a/patches/chromium/.patches
+++ b/patches/chromium/.patches
@@ -116,3 +116,4 @@ chore_add_electron_deps_to_gitignores.patch
 chore_allow_chromium_to_handle_synthetic_mouse_events_for_touch.patch
 add_maximized_parameter_to_linuxui_getwindowframeprovider.patch
 add_electron_deps_to_license_credits_file.patch
+feat_add_set_can_resize_mutator.patch
diff --git a/patches/chromium/feat_add_set_can_resize_mutator.patch b/patches/chromium/feat_add_set_can_resize_mutator.patch
new file mode 100644
index 0000000000000..5b2adba9ecd49
--- /dev/null
+++ b/patches/chromium/feat_add_set_can_resize_mutator.patch
@@ -0,0 +1,27 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Raymond Zhao <7199958+rzhao271@users.noreply.github.com>
+Date: Tue, 2 Aug 2022 09:30:36 -0700
+Subject: feat: Add set_can_resize mutator
+
+Adds a set_can_resize mutator to WidgetDelegate that
+doesn't emit the OnSizeConstraintsChanged event.
+This way, we can call set_can_resize from Electron before
+the widget is initialized to set the value earlier,
+and in turn, avoid showing a frame at startup
+for frameless applications.
+
+diff --git a/ui/views/widget/widget_delegate.h b/ui/views/widget/widget_delegate.h
+index 431d19f2543a9011de76b941982603ff98afa041..32e07e0c9686e6942a40c4d4775a03068cfd33b5 100644
+--- a/ui/views/widget/widget_delegate.h
++++ b/ui/views/widget/widget_delegate.h
+@@ -323,6 +323,10 @@ class VIEWS_EXPORT WidgetDelegate {
+   // be cycled through with keyboard focus.
+   virtual void GetAccessiblePanes(std::vector<View*>* panes) {}
+ 
++  // A setter for the can_resize parameter that doesn't
++  // emit any events.
++  void set_can_resize(bool can_resize) { params_.can_resize = can_resize; }
++
+   // Setters for data parameters of the WidgetDelegate. If you use these
+   // setters, there is no need to override the corresponding virtual getters.
+   void SetAccessibleRole(ax::mojom::Role role);
diff --git a/shell/browser/native_window_views.cc b/shell/browser/native_window_views.cc
index bf60cc85f0736..2fea92b1ed57a 100644
--- a/shell/browser/native_window_views.cc
+++ b/shell/browser/native_window_views.cc
@@ -281,7 +281,24 @@ NativeWindowViews::NativeWindowViews(const gin_helper::Dictionary& options,
       new ElectronDesktopWindowTreeHostLinux(this, native_widget);
 #endif
 
+  // Ref https://github.com/electron/electron/issues/30760
+  // Set the can_resize param before initializing the widget.
+  // When resizable_ is true, this causes the WS_THICKFRAME style
+  // to be passed into CreateWindowEx and SetWindowLong calls in
+  // WindowImpl::Init and HwndMessageHandler::SizeConstraintsChanged
+  // respectively. As a result, the Windows 7 frame doesn't show,
+  // but it isn't clear why this is the case.
+  // When resizable_ is false, WS_THICKFRAME is not passed into the
+  // SetWindowLong call, so the Windows 7 frame still shows.
+  // One workaround would be to call set_can_resize(true) here,
+  // and then move the SetCanResize(resizable_) call after the
+  // SetWindowLong call around line 365, but that's a much larger change.
+  set_can_resize(true);
   widget()->Init(std::move(params));
+
+  // When the workaround above is not needed anymore, only this
+  // call should be necessary.
+  // With the workaround in place, this call doesn't do anything.
   SetCanResize(resizable_);
 
   bool fullscreen = false;


Test patch: