Suggestions? - Workaround? - Help about converting to the MV3 Chrome extension

[Stefan vd]

Hi developers,

I am the developer of the most popular Turn Off the Lights browser extension. It is the accessibility tool to dim the web page and highlight the video player if it is available on the current web page.

A) Accessibility is one of the key points for our users to get the best web experience their way. Inside the browser extension, we have the "Camera Motion" and "Speech Recognition" features to control the web in a different way.

Camera Motion = it can dim the web page with the movement of your hand gesture. The background page uses a canvas and HTML5 video element.

Speech Recognition = it can control the current web page with your voice, so you can control the current multimedia player by saying "Hey browser, pause this video". The code behind is the Speech Recognition API and the HTML5 audio player on the background page.

However, with the new upcoming MV3 this feature will not work anymore on the HTML background page. This is a huge problem for our users that have a disability, so they can not easily control the web in a comfortable way. Is there a solution or workaround to get this feature working in MV3?

https://chrome.google.com/webstore/detail/turn-off-the-lights/bfbmjmiodbnnpllbbbfblcplfjjepjdn

B) Help

Is there a way (or workaround) to open my own custom protocol, such as turnoffthelights://welcome?title=new&location=europe

And when it opens this HTML page (from inside the Chrome extension) it receives this data. And show this data in a dialog box. Any example code with much appreciated.

C) Currently in MV2 we have the double click menu, so when you click 2X on the gray lamp button it will open the popup panel. That is our mini settings panel to adjust live the current opacity or color. And with a 1X click, it will just dim the web page. In the upcoming MV3 this feature will not work anymore.

https://github.com/turnoffthelights/Turn-Off-the-Lights-Chrome-extension/blob/master/src/js/background.js#L243

Any suggestions or ideas to get this unique feature working on MV3?

Thanks,

Stefan
www.stefanvd.net

[Simeon Vincent]

For A), the Manifest V3 platform as it exists today does not provide a way for extensions to have a page context that isn't exposed to the user. As such, the most practical way to continue using the webcam and microphone is to create an extension page from which you can call the relevant APIs. The two paths to consider are 1) creating a new tab or window or 2) injecting an iframe into an existing page. Option 1) is easier and more direct, but also directly surfaces the platform's limitations to the end user. Option 2) will require more work to choose which page the iframe should be injected into and to recover when the user closes the tab currently handling the audio/video feed, but this approach may allow you to retain the same end user experience that you have today. I also want to note that we're considering changes to enable use cases that currently require DOM APIs.

With regard to B), to the best of my knowledge it's not possible to do this with only a Chrome extension. OSs allow applications to register arbitrary protocol handlers, but Chrome does not expose this capability to extensions. As such, the two ways you could potentially accomplish this are to either 1) use a companion desktop app to handle your custom scheme and pass messages to your extension via native messaging or 2) use the web's navigator.registerProtocolHandler. Be aware that registerProtocolHandler only supports web+ prefixed schemes or a limited allow list of predefined schemes. It's also worth noting that the user must grant you permission to register your protocol handler and this isn't exposed to workers. As such, this request would best be requested by presenting the user with a new tab or dialog window after an update.

As for C), can you share more about why this feature won't work? Looking over the click handler, the only things that stand out to me are window.setTimeout and chrome.extension.getViews. The first can be addressed by using setTimeout without a prefix. The latter is a bit tricker as there no direct equivalent to getViews, but the first thing I'd try is sending a message from the popup to the background. Alternatively, maybe you could use storage.local to set a flag when the popup opens/closes and check that in your setTimeout callback. Might also be worth opening a feature request for a method to check if the popup is open.

Simeon - @dotproto

Chrome Extensions DevRel

--
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/849c7ebc-c590-4714-9ebf-f39126188da1n%40chromium.org.

[Stefan vd]

Hi Simeon,

Thank you for the suggestions and workarounds.

About A)

If there is a public crbug link, I would like to star/bookmark it (to get updates).

About C)

For the double click action, I use this code:

var popups = chrome.extension.getViews({type: "popup"});

And that API does not work anymore in MV3, as result, the Chrome extension can not detect if the popup is already open or not. However, if Chrome does support this code: chrome.action.openPopup(); Then there is a solution for this issue. But according to Mozilla [1], only Firefox v57 (and higher) support this API code.

[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/browserAction/openPopup

Thanks,

Stefan
www.stefanvd.net

[wOxxOm]

To detect the popup you can probably use the standard service worker API: `clients.matchAll()`. It's asynchronous though. Another possibility is to use chrome.runtime port's onDisconnect event just like we did in MV2 however you'll also need to regularly reconnect the port before 5 minutes elapse, otherwise the service worker will unload, evidently because MV3 paradigm assumes that extensions are third-rate citizens in the browser ecosystem and thus aren't qualified to control lifetime of their background script. Hopefully, it'll change in the future when MV3 team starts a proper investigation into the actual real-life impact of their ideas.

[Cuyler Stuwe]

Just go with the solution that exposes the MV3 platform’s flaws most directly, but include an explainer that it’s Google’s fault, and include a link to complain. 🤷‍♂️

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/b851f3b8-9eb1-4594-b7cf-15a1eb44e273n%40chromium.org.

[Simeon Vincent]

Stefan, we don't currently have an issue for the changes that we're considering regarding DOM APIs use, but assuming things proceed well, I intend to share more here and in our docs when I can.

With regard to C), in my last post I mentioned using either the messaging or storage APIs to notify the background that the popup is open. wOxxOm's suggestion of using clients.matchAll() may also be viable since you're using chrome.storage.sync.get to asynchronously dispatch the "masterclick" message to the tab. As for action.openPopup(), you may be happy to hear that we're actively working on implementing this feature (crbug.com/1245093). 

Simeon - @dotproto

Chrome Extensions DevRel

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.