Breaking changes to draggable app-regions

[Amanda Baker]

Hey embedder-dev,

I’m working on a change that addresses a performance issue due to collecting the draggable regions defined using the app-region CSS property:

• Only collect app regions for Window Controls Overlay and Borderless apps (4814003) · Gerrit Code Review (googlesource.com)
• 1447586 - Umbrella bug: `app-region` performance issues & specification (chromium.org)

This CL changes the default behavior such that, by default, blink does not collect app-regions, and it only does so if the browser sets a boolean indicating that it supports app regions. Changes would need to be made in the Electron codebase to continue supporting draggable regions.

Do you have any concerns with this approach? If so, an alternative solution is doing the opposite: continuing to collect app regions by default and setting supports_app_region to false for browser tabs. This wouldn’t require any Electron-specific changes, but it may have a small perf impact on the normal browser scenario due to setting supports_app_region to false for each tab added to the tabstrip.

 

-Amanda

[Marshall Greenblatt]

On Oct 23, 2023, at 19:43, 'Amanda Baker' via Chromium Embedders <embedd...@chromium.org> wrote:



How will this configuration work for embedders at the //content layer (eg. WebContents or views::WebView)?

Will the configuration transfer automatically to new popup browsers?

 

-Amanda

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/b7f00f84-4e34-4e46-b573-ba29210d7359n%40chromium.org.

[Amanda Baker]

There is nothing implemented in the //content layer to re-enable app-regions. Instead, this change enables app-regions directly from the //chrome layer, and we may also have to do something similar for //extensions to support NativeAppWindows if they still use draggable regions. For the Electron case, I assume app-region would be reenabled somewhere near where draggable regions are collected from the renderer in ElectronRenderFrameObserver::DraggableRegionsChanged().

I'm not sure what you mean by "new popup browsers", but if they rely entirely on //content and blink, then yes, the disabled configuration would apply to popup browsers, and they would also need to explicitly enable app-regions if they wanted to use the drag/no-drag regions defined by the CSS property.