Sidepanel must be opened in response to a user gesture

[Cory Cooper]

After Chrome 127, some users and developer are seeing the following error:
sidePanel.open()` may only be called in response to a user gesture

We open the sidepanel from clicks in the content script and our web app app Scribehow.com and they no longer work in Chrome 127. The documentation says that you should be able to trigger an open from a click in the content script.

This appears to be a bug in a change behind some flag (not everyone can reproduce).

We're suspicious of this deprecation given the language around "3rd party storage and communications".

Any help is appreciated.

[Eduardo Fungairino]

We are observing the same behavior in our extension, our e2e test that opens the sidepanel based on user gesture is consistently failing.

[Todd Schiller]

We've opened a bug ticket because we also see Chrome crash consistently when a user gesture is performed for some users on Version 127.0.6533.73 (Official Build) (arm64): https://issues.chromium.org/issues/355266358

--
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/32f9f344-06a5-41c5-a02b-17abf004faffn%40chromium.org.

[Ja Wattanawong]

We're seeing this issue for users of our extension on Chrome 127 who also have 1Password (2.26.1) installed on both macOS and Windows.

[Patrick Kettner]

Thanks for the report!

@eduardo - can you share the specific reproduction you are seeing fail?

@Todd Can you provide specific crash IDs? You can find them in chrome://crashes/

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/90234c72-af6c-4f23-8e2c-9074937a626bn%40chromium.org.

[Graham Langford]

Here's a crash id: 71bc12c4089532de

The crash appears to require 1password to be installed _and_ the devtools to be open and docked. 

Also, if the devtools are undocked, then redocked, then the crash does not occur.

I'm currently working on a minimal reproduction. For additional context, the user is triggering an event using an affordance (button or context menu) injected by a content script. The service worker is then calling the sidePanel.open API and throwing the user gesture error. We have a fallback in case of the error to try again (user clicks a button in an injected dialog), and that is succeeding if 1password is _not_ installed. If it is installed, then the error is thrown again. 

We are not seeing this behavior in previous versions of Chrome

[Graham Langford]

I've created a minimum repro that can be found here: https://github.com/pixiebrix/chrome-user-gesture-repro

The readme includes detailed instructions to reproduce

[Graham Langford]

I should also note that the crash looks to be caused by an unhandled exception in our Extension that was exposed by the thrown user gesture error. 

We are also seeing the error be thrown with and without 1password installed. Though 1Password must be installed to replicate in the minimal repro. I'm not certain what is causing the difference

[Aaron Podolny]

@Patrick - Just wanted to emphasize that from our perspective the bigger problem here is that `sidePanel.open` no longer works from a content script, which breaks meaningful functionality in our (and other) extensions. Maybe the root cause is also what is causing the crash, but regardless hoping the Chrome team can get a fix out for this soon. Thanks for your help!

[Aaron Podolny]

@Patrick - Just wanted to emphasize that from our perspective the bigger problem here is that `sidePanel.open` no longer works from a content script, which breaks meaningful functionality in our (and other) extensions. Maybe the root cause is also what is causing the crash, but regardless hoping the Chrome team can get a fix out for this soon. Thanks for your help!

On Thursday, July 25, 2024 at 12:56:06 PM UTC-7 Graham Langford wrote:

[Aaron Podolny]

@Patrick - Just wanted to emphasize that from our perspective the bigger problem here is that `sidePanel.open` no longer works from a content script, which breaks meaningful functionality in our (and other) extensions. Maybe the root cause is also what is causing the crash, but regardless hoping the Chrome team can get a fix out for this soon. Thanks for your help!

On Thursday, July 25, 2024 at 12:56:06 PM UTC-7 Graham Langford wrote:

[Graham Langford]

It looks that the root cause of `sidePanel.open` no longer working from a content script is reproducible by including a mousedown listener in the content script. See the repro here: https://github.com/pixiebrix/chrome-user-gesture-repro. No need to have 1Password installed

[Aamir Mansoor]

I can confirm this issue affects our users on v127+ too, with no workaround available.

A bug report at https://issues.chromium.org/issues/40929586 was marked as “won’t fix”.

Any updates, Chrome team?

[Cory Cooper]

Here I have documented our learnings:

https://issues.chromium.org/issues/40929586#comment20

[Patrick Kettner]

Hi everyone!

This was a unintended side effect from this change. A fix was added yesterday, which lands it in 129.0.6628.0. The team is working on backporting it to Chrome 128, as of now it is unlikely to be fixed in 127.

patrick

--
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/bea83bf3-e415-4cb1-8b75-7742298cfa33n%40chromium.org.

[Graham Langford]

Hi Patrick, 

Thanks for the update! I've confirmed that I'm no longer able to reproduce the issue in Chrome Canary. Is there any update on backporting to Chrome 128? Also, this is a pretty major issue for our Extension, is there no chance we can get it in a hotfix for 127?

[Patrick Kettner]

Hey Graham!

No change since my last update - the team is working on backporting it to Chrome 128, as of now it is unlikely to be fixed in 127.

[Cory Cooper]

If you are calling sidepanel.open() in a callback, .then(), or after an “await”, that does not work on any occasion. You must call it synchronously after the click handler is fired (i.e. synchronously in your browser message event handler). 

On Sun, Sep 15, 2024 at 9:11 AM Kaj Kandler <confic...@gmail.com> wrote:

Hi Patrik, hi Cory,
I face this very same issue in the `chrome.action.onClicked.addListener(function () {...}`

It seems not be fixed for my use case in current Beta `Version 129.0.6668.42 (Official Build) beta (arm64)`

I try to get the current tabId (tabs.query) and get the sidepanel options for the tab, then toggle the sidepanel. All inside my worker script.

Should that case be fixed as well?

[Kaj Kandler]

Hi Patrik, hi Cory,
I face this very same issue in the `chrome.action.onClicked.addListener(function () {...}`

It seems not be fixed for my use case in current Beta `Version 129.0.6668.42 (Official Build) beta (arm64)`

I try to get the current tabId (tabs.query) and get the sidepanel options for the tab, then toggle the sidepanel. All inside my worker script.

Should that case be fixed as well?

On Wednesday, July 31, 2024 at 5:50:32 PM UTC+2 Patrick Kettner wrote:

[Kaj Kandler]

Thanks Cory for your reply

Are you sure about that? For me this works just fine (in 128...)

chrome.action.onClicked.addListener(function () {

console.log("extension button clicked");

chrome.tabs.query({ active: true, currentWindow: true }, function (tabs) {

const activeTab = tabs[0];

const tabId = activeTab.id;

console.log("open sidepanel");

chrome.sidePanel.setOptions({

tabId,

path: 'sidepanel.html',

enabled: true

});

chrome.sidePanel.open({

tabId

});

});

});

Only when I start reading the `chrome.sidepanel.getOptions();` It starts failing

[Cory Cooper]

I guess not 100% but that’s been my experience thus far. Also, I think you can run setOptions after it’s already opened which might address your issue?