Issue 1:
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 feature request that matches the one I want to file, without success.

Problem Description

In Wayland clients usually render their own decorations, they don't get SSD anymore (although there seems to be a protocol for SSD negotiation that Plasma and some compositors based on wlroots implement). The Wayland build is not very useful until Electron app windows get a proper headerbar. The headerbar can be a stock headerbar similar to old-school SSD or can be customized by the app (for example, by setting its color/theme in accordance with the app contents).

Proposed Solution

Use GTK CSD support, which is also well-integrated in Qt-based environments (mainly Plasma):

https://developer.gnome.org/gtk3/stable/GtkHeaderBar.html:

void gtk_header_bar_set_show_close_button (GtkHeaderBar *bar, gboolean setting);

Sets whether this header bar shows the standard window decorations, including close, maximize, and minimize.

https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-decoration-layout:

“gtk-decoration-layout” char *

This setting determines which buttons should be put in the titlebar of client-side decorated windows, and whether they should be placed at the left of right.

Alternatives Considered

It doesn't seem to exist much more alternatives. Maybe Qt has a native headerbar implementation, but it won't properly work inside a GTK-based environment like GNOME, while it works the other way around. See https://pointieststick.com/2019/11/30/this-week-in-kde-gtk-csd-support-and-more

Maybe xdg-decoration as suggested in some comments below. But I ignore everything about it and SSD doesn't seem to me the best alternative for Electron apps that tend to be more app-centric than platform-centric by its very nature and so, at least in major platforms, usually customize headerbars.

Additional Information

More details in discussion starting from #10915 (comment)

Issue 2:
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 an issue that matches the one I want to file, without success.

Issue Details

Electron Version:

9.2.1

Operating System:

macOS Catalina

Last Known Working Electron version:

Expected Behavior

When ipcMain.handle() return a rejected promise, no message should be printed on the main console and the error message in ipcRenderer.invoke().reject() should contain the exact error message.

Actual Behavior

When ipcMain.handle() return a rejected promise, a message like this is printed in the main console:

Error occurred in handler for '<channel>': Error: <rejected error message>

-> the attempted result here is that no message should be displayed in main console !

And the ipcRenderer.invoke().reject() error message is:

Error invoking remote method '<channel>': Error: my-error

-> the attempted error message here is only "Error: my-error"

To Reproduce

main.js

ipcMain.handle('channel', (event, options) => {
return Promise.reject(new Error('my-error'))
})

renderer.js

ipcRenderer.invoke('channel').then(result => {
console.log(result)
}).catch(err => {
console.log(err)
})