Chrome 102 changes to the Windows API

[Simeon Vincent]

Greetings extension devs,
 
Starting with Chrome 102, windows created or modified by an extension must be at least 50% visible on the user's display. This change affects all windows.create() and windows.update() calls that specify the window's left, top, width, or height values. If an extension attempts to create a window in or move a window to a position where half the window's content would not be visible to the user, an error will be emitted via chrome.runtime.lastError.
 
If you have an extension that programmatically creates or modifies Chrome windows, we recommend that you test your extension in Chrome Canary and report any bugs you encounter on crbug.com/new.

Simeon - @dotproto

Chrome Extensions DevRel

[Cuyler Stuwe]

A couple of things:

1. What’s the intent?

2. It seems to me that most extension devs who are doing something like this with MV3 would be doing it to work around limitations in service workers without being obtrusive to the user. What’s your recommendation for them?

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLPqgBZHO6-aXWHKoXKq_p9P2AFPu%2Bfk%2B9PsFqXniKEWqg%40mail.gmail.com.

[Juraj M.]

Yeah, making page thumbnails just got really annoying for the end users :(

Tabs hiding API like the one in Firefox would be a great help, along with captureTab API.

Or some other way to load invisible document and make a screenshot of it, like with the `html2canvas` but actually working with all pages.

[Simeon Vincent]

1. Fighting malware.

2. It really depends on the extension, desired user experience, and motivations for having the page context. I'm game to kick around ideas if you'd like.

(Cuyler, you've probably heard most of this before.) I have some very high level recommendations that boil down to "look for ways to be minimally more obtrusive". Or to put it more kindly, look for ways to leverage the capabilities you have between the web and extensions platforms to accomplish your goals. This might mean using a tab or user-visible window as a semi-persistent execution context, creating a temporary popup that only lives for the duration of the relevant operation, embedding an iframe in relevant page(s), moving from a long-lived connection to push messages, etc.  

For example, say you have an MV2 extension that uses a wasm version of FFmpeg to transcode videos and download them in the background page. In MV3, you could use a temporary popup window that only lives for the duration of the transcode and download operation. This has the benefit of allowing the extension to display a progress bar to keep the user informed and adopting affordances like canceling the encoding/download if the user closes the window. 

Simeon - @dotproto

Chrome Extensions DevRel

[Ian Williams]

Hey Simeon, 

We've been working with MV3 from the beginning of our IME extension development and the window business hurts the user experience considerably. First, we started with the code in a service worker, but that led to the entire keyboard shutting off when the service worker sleeps. 

We migrated over to a pop-up window as you suggest here, but it obviously can't be temporary since the user needs constant access to their keyboard (IME). Is there any chance we'll get IME access in a background page? That seems to be a use case where powering down just never makes sense.

For most of our extensions, I'm with you on getting rid of constantly running processes and I've happily developed programs that expect the big sleep. But since many Chrome OS system-level apis are actually extension apis, it makes for a messy experience to have multiple tabs/windows opening to handle relatively basic functions. Especially on weaker Chromebooks. 

[Simeon Vincent]

I'm interested in learning more about the challenges you're facing when working on an IME; I'll start a direct thread with you in a few moments to discuss this further. 

Simeon - @dotproto

Chrome Extensions DevRel

[Cuyler Stuwe]

@Simeon -- I just had an external tester complain that this error is blocking the spawning of a window when has an external monitor attached. The issue goes away for him when he disconnects the external monitor. I wasn't able to get a detailed repro from him yet (hence no bug ticket), but is this maybe something that went unconsidered? The extension specifies only a reasonable size for the window (595x643), but it doesn't specify a position.

[Simeon Vincent]

Cuyler, it's definitely possible that we have a bug with multi-monitor support. It would be great if you could get a bit more info and file a bug (assuming you haven't already). 

That said, I don't quite follow what you mean by "this error is blocking the spawning of a window." If the window.create or window.update call would position the window more than 50% offscreen, Chrome should fall back to internal defaults and behave as if height, width, top, and left were not provided. This change shouldn't block window creation entirely. 

Simeon - @dotproto

Chrome Extensions DevRel

[Cuyler Stuwe]

I was on Zoom with him while we were going over how the extension works, so I can definitely say from watching his screenshare that this totally blocked the creation of the window.

I asked him for more details to reproduce after we jumped off-call and he realized that it seemed to be linked to multi-monitor, but he was too busy to do it at the time.

When he tried to repro the next day, he wasn't able to.

Hard to say on my end whether that means that something was fixed, or whether he just didn't know the chain of events to repro. I develop on Mac and he tests on Windows, in case that makes a difference. I have definitely seen a number of OS-specific Chrome API peculiarities, especially around the window APIs (e.g., like how creating a minimized window on Mac leads to an invisible window that doesn't even exist in the taskbar). Because of this, I really wouldn't be surprised if it happens to be OS-specific.

[Cuyler Stuwe]

* In my last message "minimized window" should have been "minimized popup window".

[Robbi]

If this is of any interest, with Mozilla Firefox popup windows are opened in the center of the screen.

It is useless to set the properties "left" and "top".

I don't know if this is recent or if it has always been this way.

I have not tested "normal" windows.

Also I tried (just for fun) to move the window with browser.windows.update immediately after its creation. The command is ignored.

So I encapsulated the same update command in a 3 second delay setTimeout and the update now worked.

My thoughts to mozilla:  "Thank Firefox, you did a favor by giving us the ability to create popups perfectly centered on the monitor without too much fuss,

on the other hand, you thwarted my attempt to simulate a notification with two buttons (that dear firefox do not support) with a popup window positioned at the bottom right and with two nice buttons inside. So shame on you".

My general thought to all browser vendors: "Sometimes it just seems that you don't sleep at night always thinking about new and original ways to break the fuck we developers are always forced to adapt or rewrite code (of course always in the name of greater "security")"

[Emilia Paz]

Hello!

First, salem...@ sorry for the delayed response.

The intended behavior is:

  - If an extension attempts to create or update a window in a position where half the window's content would not be visible to the user, an error will be emitted via chrome.runtime.lastError. Therefore, the window wouldn't be created.

  - Multiple displays are taken into account. `WindowBoundsIntersectDisplays(bounds)` checks for all displays 

It seems that the inputs of the user are not valid. Therefore, we could have a) multiple screens are indeed not working b) working as expected.

For a) it would be great if we can get a screencast or more info on how to reproduce it. If multiple screens are working, then we could evaluate for b) creating/updating the window to the default instead of returning an error.

Thanks for letting us know about this issue!

/ Emilia

Software Engineer @ Chrome Extensions

[Simeon Vincent]

Juraj, to be honest I'm surprised that the New Window Setup extension would change Chrome's behavior here. I wonder if there could be a race condition here where the size and position update applied by New Window Setup may or may not occur before Chrome checks the new window's size and position. Or perhaps there's not necessarily a race condition, but that the behavior you observed is not guaranteed. 

Also a small nitpick on terminology: Chrome doesn't have an Alpha release. Chrome's release channels are Stable, Beta, Dev, and Canary. 

Simeon - @dotproto

Chrome Extensions DevRel

On Wed, Jun 29, 2022 at 1:39 AM Juraj M. <juraj....@gmail.com> wrote:

OMG, I'm sorry for the confusion, my stable version has " New Window Setup" extension installed that moves new windows to the main monitor :), oops!

Deleting my confusing comments in 30s...

On Wednesday, 29 June 2022 at 10:16:41 UTC+2 Juraj M. wrote:

I see a difference in behavior in stable and Beta /Alpha.

If I load my extension in stable 102 (last week) and now 103, it won't create tab in the secondary monitor, instead it will create it in main monitor (even if the Chrome window is placed in the secondary one).

The same extension loaded in Beta 103 and now Beta 104 or Alpha 105, it will correctly create it on secondary monitor.