Schooldistrict here. Manifest Version 3 will limit My Inventiory Platform

[Mark Fratto]

No more Geolocation for tracking Lost/Stolen devices.

No more monitoring battery percentage to know when a battery needs to be replaced.

These are just the ones I found so far while trying to rewrite this extension.

I have been trying to update my extension for several months now. And keep coming back to it to try to make it work. Come to find out may of the features I use are being removed in version 3.

What a bummer.  And it seems that the documentation is very lacking otherwise I would have figured this out months ago.

Anyone else find a work around for these?

[Cuyler Stuwe]

Only workaround I’m aware of is the long-shot of hoping that Google comes to their senses. 🤷‍♂️

--
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/cd46b221-aae6-4aa8-94ac-0978316c52e2n%40chromium.org.

[Mark Fratto]

Yeah. Other applications like GoGuardian theft recovery will stop working as well I would assume, and other alike. 

You'd think they'd still allow both these at least maybe by putting these under the chrome.enterprise api incombination with force installed extensions

[hrg...@gmail.com]

The only solution is to open a minimized popup window and do your work from there.

When you create a window you can specify that it's initially minimized. That way the user won't see it flashing in front of the focused window.

Once you are done, you can close the window. If you do this quickly enough, the user won't notice that a new browser window was opened at all.

[Mark Fratto]

If that is my best option then I guess it will have to do.  Thanks for the tips!!!

[Simeon Vincent]

To the best of my knowledge neither Geolocation nor Battery Status were intentionally removed in Manifest V3. Rather, they're web platform APIs that are not currently exposed to service workers (though gelocation has been requested). I've taken the liberty of opening two new feature requests to bring these capabilities to extension service workers:

• crbug.com/1279641 - Geolocation API
• crbug.com/1280007 - Battery Status API

For the moment, the most practical workaround is to create a temporary page context that you can use to access these APIs and post a message back to the extension's service worker.

Of course, another option is to put off adoption of Manifest V3 until it supports more of the capabilities you need. Since you referenced an "inventory platform," I'm assuming your school district uses enterprise policies to manage devices. In that case, the Manifest V2 support timeline docs call out that "enterprise policy can let Manifest V2 extensions run on Chrome deployments within the organization" through June 2023. Additionally, you can use self-hosting and enterprise policies to host a custom extension on your own servers and force install it on managed devices.

And it seems that the documentation is very lacking otherwise I would have figured this out months ago.

I'd love to hear your thoughts on how we could better highlight web platform capabilities that aren't exposed in service workers. 

Simeon - @dotproto

Chrome Extensions DevRel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/6075ef1b-010a-43c7-b685-20cf42b11aean%40chromium.org.

[Conrad Irwin]

For the moment, the most practical workaround is to create a temporary page context that you can use to access these APIs and post a message back to the extension's service worker.

When you say a temporary page context, is this somthing that an extension can create within itself, or does it have to be run in a browser tab as a content script?

Sent via Superhuman

On Tue, Dec 14, 2021 at 2:56 PM, Simeon Vincent <sim...@chromium.org> wrote:

To the best of my knowledge neither Geolocation nor Battery Status were intentionally removed in Manifest V3. Rather, they're web platform APIs that are not currently exposed to service workers (though gelocation has been requested). I've taken the liberty of opening two new feature requests to bring these capabilities to extension service workers:

• crbug.com/1279641 - Geolocation API
• crbug.com/1280007 - Battery Status API

For the moment, the most practical workaround is to create a temporary page context that you can use to access these APIs and post a message back to the extension's service worker.

Of course, another option is to put off adoption of Manifest V3 until it supports more of the capabilities you need. Since you referenced an "inventory platform," I'm assuming your school district uses enterprise policies to manage devices. In that case, the Manifest V2 support timeline docs call out that "enterprise policy can let Manifest V2 extensions run on Chrome deployments within the organization" through June 2023. Additionally, you can use self-hosting and enterprise policies to host a custom extension on your own servers and force install it on managed devices.

And it seems that the documentation is very lacking otherwise I would have figured this out months ago.

I'd love to hear your thoughts on how we could better highlight web platform capabilities that aren't exposed in service workers. 

Simeon - @dotproto

Chrome Extensions DevRel

On Sat, Dec 11, 2021 at 2:03 PM Mark Fratto <mark.fratto@gmail.com> wrote:

If that is my best option then I guess it will have to do.  Thanks for the tips!!!

On Saturday, November 27, 2021 at 4:45:46 PM UTC-6 hrg...@gmail.com wrote:

The only solution is to open a minimized popup window and do your work from there.

When you create a window you can specify that it's initially minimized. That way the user won't see it flashing in front of the focused window.

Once you are done, you can close the window. If you do this quickly enough, the user won't notice that a new browser window was opened at all.

On Saturday, November 27, 2021 at 4:44:40 PM UTC-3 mark....@gmail.com wrote:

Yeah. Other applications like GoGuardian theft recovery will stop working as well I would assume, and other alike. 

You'd think they'd still allow both these at least maybe by putting these under the chrome.enterprise api incombination with force installed extensions

On Saturday, November 27, 2021 at 10:03:17 AM UTC-6 salem...@gmail.com wrote:

Only workaround I’m aware of is the long-shot of hoping that Google comes to their senses.

On Fri, Nov 26, 2021 at 10:39 PM Mark Fratto <mark....@gmail.com> wrote:

No more Geolocation for tracking Lost/Stolen devices.

No more monitoring battery percentage to know when a battery needs to be replaced.

These are just the ones I found so far while trying to rewrite this extension.

I have been trying to update my extension for several months now. And keep coming back to it to try to make it work. Come to find out may of the features I use are being removed in version 3.

What a bummer.  And it seems that the documentation is very lacking otherwise I would have figured this out months ago.

Anyone else find a work around for these?

--
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/cd46b221-aae6-4aa8-94ac-0978316c52e2n%40chromium.org.

--
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-extensions+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/6075ef1b-010a-43c7-b685-20cf42b11aean%40chromium.org.

--

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-extensions+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLM8_T_s0BX9uuoA2358v9NsMVJxLC0-qvZCDQVYL-OMQg%40mail.gmail.com.

[Simeon Vincent]

When you say a temporary page context, is this somthing that an extension can create within itself, or does it have to be run in a browser tab as a content script? - Conrad

I assume by "within itself" you mean creating a page that is not visible to the end user. If so, then no, the Manifest V3 platform does not provide a way to interact with web content without it being visible to the end user. In Manifest V2 iframes in a background page were used for this purpose, but to the best of my knowledge that was not an intentionally supported use case.

Content scripts could be used to get access to geolocation data, but doing so would require that the user grant the website geolocation permissions. Instead, in this case you'd likely want to use chrome.tabs.create() or chrome.windows.create() to spawn a new page (preferably without stealing the user's focus) and setting the URL to a page inside your extension's package.

I don't believe the Battery Status API requires a special permission grant in Chrome, so this could be done transparently within a content script. 

Simeon - @dotproto

Chrome Extensions DevRel

On Tue, Dec 14, 2021 at 8:59 PM Climber Harish <harishsha...@gmail.com> wrote:

http://climberharish.blogspot.com/

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/6075ef1b-010a-43c7-b685-20cf42b11aean%40chromium.org.

--
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/CAFY0HLM8_T_s0BX9uuoA2358v9NsMVJxLC0-qvZCDQVYL-OMQg%40mail.gmail.com.

--
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/CAEEPc9mdyjW1D9pC_GLYaM3m9MrOmN3cUGNV8HCV0%3D9zYVWoFQ%40mail.gmail.com.

[Conrad Irwin]

I assume by "within itself" you mean creating a page that is not visible to the end user. If so, then no, the Manifest V3 platform does not provide a way to interact with web content without it being visible to the end user. In Manifest V2 iframes in a background page were used for this purpose, but to the best of my knowledge that was not an intentionally supported use case.

Thanks for clarifying. That's a shame, but I hope the missing APIs are added soon – for us it's particularly DOMParser

Sent via Superhuman

On Wed, Dec 15, 2021 at 5:13 PM, Simeon Vincent <sim...@chromium.org> wrote:

When you say a temporary page context, is this somthing that an extension can create within itself, or does it have to be run in a browser tab as a content script? - Conrad

I assume by "within itself" you mean creating a page that is not visible to the end user. If so, then no, the Manifest V3 platform does not provide a way to interact with web content without it being visible to the end user. In Manifest V2 iframes in a background page were used for this purpose, but to the best of my knowledge that was not an intentionally supported use case.

Content scripts could be used to get access to geolocation data, but doing so would require that the user grant the website geolocation permissions. Instead, in this case you'd likely want to use chrome.tabs.create() or chrome.windows.create() to spawn a new page (preferably without stealing the user's focus) and setting the URL to a page inside your extension's package.

I don't believe the Battery Status API requires a special permission grant in Chrome, so this could be done transparently within a content script. 

Simeon - @dotproto

Chrome Extensions DevRel

http://climberharish.blogspot.com/

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/6075ef1b-010a-43c7-b685-20cf42b11aean%40chromium.org.

--
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-extensions+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLM8_T_s0BX9uuoA2358v9NsMVJxLC0-qvZCDQVYL-OMQg%40mail.gmail.com.

--
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-extensions+unsubscribe@chromium.org.

[hrg...@gmail.com]

the Manifest V3 platform does not provide a way to interact with web content without it being visible to the end user. In Manifest V2 iframes in a background page were used for this purpose, but to the best of my knowledge that was not an intentionally supported use case.

There's no need for iframes in MV2 since the background page is itself a webpage, so you have access to all web APIs from it. Which is what the OP is asking for.

This proposal https://crbug.com/1128240 is what the OP means by "somthing that an extension can create within itself".

Unfortunately, it doesn't seem likely that such proposal becomes a feature before the MV2 end-of-life, given the slow progress in making MV3 at least production-ready.

[wOxxOm]

>  In Manifest V2 iframes in a background page were used for this purpose, but to the best of my knowledge that was not an intentionally supported use case.

It was an intentionally supported use case and it was used by thousands of extensions and probably millions of their users. FWIW, making remarks like this makes you look really really bad as though you're trying to downplay the severity of the breakage introduced by ManifestV3's ill-advised and poorly-thought switch to service workers.

[Mark Fratto]

Yes we deployed through enterprise policies in google admin. I do have the same thing self hosted but only use that for testing, otherwise smart kids could block our domain at home and extension would not be installed.

[Mark Fratto]

Simeon Vincent,

Thank you for opening the proper bug reports on these. I have done those before but wasn't sure if this was in fact a bug or intentional in MV3.

Also thank you for the information on the enterprise timeline. That gives me some relief and piece of mind as the Inventory platform I developed is pretty big and I may need time to adapt it if need be to MV3 when MV3 is finalized---ish.

[Simeon Vincent]

To the best of my knowledge, there were no “intentionally-supported use-cases” in MV2 at all, as it was designed as a platform; A set of tools and features not generally arranged or selected to support any particular software. - Cuyler

This doesn't match my experience or observations. Based on what I've seen on crbug and heard from a long time Chromies, extensions capabilities generally have a compelling use case or set of use cases that demonstrate the value of supporting a given feature. That gives us something concrete to consider and measure against as we discuss the feasibility, technical complexity, maintenance cost, potential privacy concerns, abuse cases, developer experience, flexibility of the API design, etc. of a given capability. It's also worth noting that use cases for Chrome's extensions platform are even enumerated as far back as Chrome's original Extensions Manifesto.

Use cases don't have to be exhaustive to be useful. Often it's extremely useful to just have something specific to discuss and debate. That's why when I post here I often ask developers here not just what capabilities they want, but why they want them.

Sure, some capabilities have relatively self evident uses. The Chrome team didn't need to enumerate all the reasons a developer might want to create a  tab when initially building out the tabs API. On the other hand, there are a lot of APIs in the Chrome Apps platform that weren't (and won't be) added to the extensions platform because of the different constraints of these platforms. Consideration of specific use cases is also a major component of the web platform's evolution.

It was an intentionally supported use case and it was used by thousands of extensions and probably millions of their users. FWIW, making remarks like this makes you look really really bad as though you're trying to downplay the severity of the breakage introduced by ManifestV3's ill-advised and poorly-thought switch to service workers.

You've been crawling crbug and chromium-review longer than I have; generally speaking, if I had to bet on either my impression or yours, I'll usually go (or at least start) with yours. While I haven't seen issues, CLs, or design docs that call out using iframes for offscreen browsing in an extension's background page, that doesn't mean there aren't any, just that I haven't seen them. As I said, it was not an explicitly supported use case to the best of my knowledge. 

I didn't intend to downplay this change. Rather, I was hoping to provide some context on how we're currently thinking about this capability. To that end, I'll try to be clearer: at the moment we don't plan to support a general purpose headless page context for extensions in Manifest V3. If you feel that interacting with pages without making those interactions visible to the end user is a critical feature for the platform, I'd love to dig more into that in a new thread to better understand your perspective. 

Simeon - @dotproto

Chrome Extensions DevRel

[Cuyler Stuwe]

In this manifesto, “use cases” are vague and wide open, like “content enhancement” and “features” (the only term in development more vague than “features” is “data”).

The manifesto also highlights an intent to perpetually widen support for more use cases for developers, rather than to severely restrict them.

It also mentions that it should be open and not rely on Google services (contrary to your suggestion in a different thread that we should use a hosted Google API Firebase service to work around WebSocket issues):

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLOad2i-%3DhiBpMYsdofZr0G%3DyaxxJu2SgSRrLmSpKigP0Q%40mail.gmail.com.

[wOxxOm]

Simeon, there are hundreds of use cases for extensions so it's impossible to list them, which means that your reasoning is not applicable here. What's worse, judging by the 3 years of ManifestV3, it looks like the Chromium extensions team is using the absence of such explicit list to retroactively deny the 10+ years of growth of the extensions ecosystem and say that all those thousands of extensions (and their dozens of use cases listed on WCEG) weren't intentionally/explicitly supported so there's nothing wrong in the team's decision to break them.

>  Sure, some capabilities have relatively self evident uses.

DOM-based API and features in the background script have just as evident uses, and their absence in a service worker was one of the reasons why the early attempt to switch extensions to service workers was abandoned ~10 years ago. Current chromium programmers probably don't even know about that.

[wOxxOm]

[...continued]

The team should have investigated what DOM-specific features the extensions have been using by running a query on the entire CWS archive. Then the team would see all the things that would be broken by switching to a service worker. It'd be possible to estimate beforehand how much time it would take to re-implement the missing functionality and use it to convince the management to assign more C++ developers to the extensions team, which is currently so tiny that it won't be able to solve most of the MV3 problems before 2023 kills off MV2. What happened instead is that the team broke those use cases without even knowing, which is completely irresponsible.

[hrg...@gmail.com]

 

at the moment we don't plan to support a general purpose headless page context for extensions in Manifest V3. If you feel that interacting with pages without making those interactions visible to the end user is a critical feature for the platform, I'd love to dig more into that in a new thread to better understand your perspective.

A page context gives access to ALL web capabilities. This is the reason why a page context is a critical feature.

You refer to "interacting with pages without making those interactions visible to the end user"  as if it was the main reason for the need of a page context; when in reality it's just only one of myriads of use cases.

For the last 3 years, those myriads of uses cases have been mentioned in this forum and in crbug.com more times than I could remember. And yet you now say that you'd love to dig more into why a specific use case is important.... Really?

I detect the following problem here:

The Extensions Team seems to be obsessed with tackling one use case at a time. It's almost as if they don't realize that there's a whole world of use cases that MV3 does not support. They insist into dealing with ONE. LITTLE. PROBLEM. AFTER. ANOTHER.

Do you guys really don't see that you will never make MV3 a decent replacement for MV2 if you address uses cases individually. There are too many of them!

You have one year left, according to your own deadline, and it's so obvious that, at the current pace, you won't be able to cover all those individual uses cases. crbug issues are being created faster than you can solve them.

Open your eyes please.

[Cuyler Stuwe]

What’s interesting about all of this is that extensions are literally the only reason people use Chrome over other browsers. Break extensions and suddenly Chromium is dead in the water. Might as well use Safari then. 🤷‍♂️

--
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/71e8dcd4-6914-45f2-9324-65a5350f7541n%40chromium.org.

[Simeon Vincent]

A page context gives access to ALL web capabilities. This is the reason why a page context is a critical feature.

You refer to "interacting with pages without making those interactions visible to the end user"  as if it was the main reason for the need of a page context; when in reality it's just only one of myriads of use cases.

Of course you're right that headless page interaction is just one of use cases for DOM APIs in an extension. I was focusing on this part because I thought Conrad was asking about when I wrote this reply. I realize now that I was a bit myopic and didn't quite hear what you and others were saying.

In the last WECG meeting Devlin from the extensions engineering team shared a rough sketch of how we're thinking about addressing the lack of DOM in Manifest V3. From the minutes, we're considering "adding the ability for an extension to create a temporary DOM context with an explicitly declared purpose. [This] allows the browser to surface this purpose to the end user and help reviewers detect malicious uses of this capability." I'm hoping that we'll be able to share a more concrete proposal publicly in the WECG in early 2022.

Simeon - @dotproto

Chrome Extensions DevRel

[hrg...@gmail.com]

"adding the ability for an extension to create a temporary DOM context with an explicitly declared purpose. [This] allows the browser to surface this purpose to the end user and help reviewers detect malicious uses of this capability."

That solution doesn't seem any better than opening a temporary window that's in a minimized state.

Neither Mac or Windows show any visual cue to the user when a new minimized window is opened.

The user could only become aware of this minimized window by looking at the task list, such as Alt+Tab or a similar list. If this temporary window is closed in a few seconds, the user will never know about it.

That's what I'm planning to do when I need a temporary DOM.

[Open minimized window]  -->  [Call necessary DOM APIs]  -->  [Close window]

No questions asked.

That new solution that requires "explicitly declaring a purpose" will only make me avoid such a feature.

[Conrad Irwin]

In the last WECG meeting Devlin from the extensions engineering team shared a rough sketch of how we're thinking about addressing the lack of DOM in Manifest V3. From the minutes, we're considering "adding the ability for an extension to create a temporary DOM context with an explicitly declared purpose. [This] allows the browser to surface this purpose to the end user and help reviewers detect malicious uses of this capability." I'm hoping that we'll be able to share a more concrete proposal publicly in the WECG in early 2022.

Thanks for bringing this to the meeting!

I also am concerned about the "explicitly declared purpose", I guess if it was built into the original extension install prompt it'd be less of a problem; but if it popped up every time we wanted to create one that would be hundreds (to thousands) or times a day for busy emailers!

Conrad

Sent via Superhuman

On Wed, Jan 05, 2022 at 6:07 PM, Simeon Vincent <sim...@chromium.org> wrote:

A page context gives access to ALL web capabilities. This is the reason why a page context is a critical feature.

You refer to "interacting with pages without making those interactions visible to the end user"  as if it was the main reason for the need of a page context; when in reality it's just only one of myriads of use cases.

Of course you're right that headless page interaction is just one of use cases for DOM APIs in an extension. I was focusing on this part because I thought Conrad was asking about when I wrote this reply. I realize now that I was a bit myopic and didn't quite hear what you and others were saying.

In the last WECG meeting Devlin from the extensions engineering team shared a rough sketch of how we're thinking about addressing the lack of DOM in Manifest V3. From the minutes, we're considering "adding the ability for an extension to create a temporary DOM context with an explicitly declared purpose. [This] allows the browser to surface this purpose to the end user and help reviewers detect malicious uses of this capability." I'm hoping that we'll be able to share a more concrete proposal publicly in the WECG in early 2022.

Simeon - @dotproto

Chrome Extensions DevRel

On Tue, Dec 21, 2021 at 8:35 PM Cuyler Stuwe <cuylerkstuwe@gmail.com> wrote:

What’s interesting about all of this is that extensions are literally the only reason people use Chrome over other browsers. Break extensions and suddenly Chromium is dead in the water. Might as well use Safari then.

On Tue, Dec 21, 2021 at 8:59 AM hrg...@gmail.com <hrg.wea@gmail.com> wrote:

 

at the moment we don't plan to support a general purpose headless page context for extensions in Manifest V3. If you feel that interacting with pages without making those interactions visible to the end user is a critical feature for the platform, I'd love to dig more into that in a new thread to better understand your perspective.

A page context gives access to ALL web capabilities. This is the reason why a page context is a critical feature.

You refer to "interacting with pages without making those interactions visible to the end user"  as if it was the main reason for the need of a page context; when in reality it's just only one of myriads of use cases.

For the last 3 years, those myriads of uses cases have been mentioned in this forum and in crbug.com more times than I could remember. And yet you now say that you'd love to dig more into why a specific use case is important.... Really?

I detect the following problem here:

The Extensions Team seems to be obsessed with tackling one use case at a time. It's almost as if they don't realize that there's a whole world of use cases that MV3 does not support. They insist into dealing with ONE. LITTLE. PROBLEM. AFTER. ANOTHER.

Do you guys really don't see that you will never make MV3 a decent replacement for MV2 if you address uses cases individually. There are too many of them!

You have one year left, according to your own deadline, and it's so obvious that, at the current pace, you won't be able to cover all those individual uses cases. crbug issues are being created faster than you can solve them.

Open your eyes please.

--
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-extensions+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/71e8dcd4-6914-45f2-9324-65a5350f7541n%40chromium.org.

--

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-extensions+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFY0HLNPVc%3DpK-eCspXSkwwvdZvGzepZanmcEfjLxVe%3DR%2BdENg%40mail.gmail.com.

[Simeon Vincent]

I also am concerned about the "explicitly declared purpose", I guess if it was built into the original extension install prompt it'd be less of a problem; but if it popped up every time we wanted to create one that would be hundreds (to thousands) or times a day for busy emailers! - Conrad

To be honest I was a bit hesitant to send that last email because it's so light on details. While I'm worried about giving y'all the wrong impression due to a lack of concrete details, I'm also worried about maintaining radio silence until we have every I dotted and T crossed.

The actual proposal will go into more detail, but that's not really how we're thinking about the use of the purpose. We're thinking less like a permissions prompt and more like a signal to the browser and reviewers that the extension intends to use a particular capability. Again, I'm hoping that we can share a proposal soon and begin discussing the idea with the community and other browser vendors.

Simeon - @dotproto

Chrome Extensions DevRel

On Wed, Jan 5, 2022 at 8:57 PM Conrad Irwin <con...@superhuman.com> wrote:

In the last WECG meeting Devlin from the extensions engineering team shared a rough sketch of how we're thinking about addressing the lack of DOM in Manifest V3. From the minutes, we're considering "adding the ability for an extension to create a temporary DOM context with an explicitly declared purpose. [This] allows the browser to surface this purpose to the end user and help reviewers detect malicious uses of this capability." I'm hoping that we'll be able to share a more concrete proposal publicly in the WECG in early 2022.

Thanks for bringing this to the meeting!

I also am concerned about the "explicitly declared purpose", I guess if it was built into the original extension install prompt it'd be less of a problem; but if it popped up every time we wanted to create one that would be hundreds (to thousands) or times a day for busy emailers!

Conrad

Sent via Superhuman

On Wed, Jan 05, 2022 at 6:07 PM, Simeon Vincent <sim...@chromium.org> wrote:

A page context gives access to ALL web capabilities. This is the reason why a page context is a critical feature.

You refer to "interacting with pages without making those interactions visible to the end user"  as if it was the main reason for the need of a page context; when in reality it's just only one of myriads of use cases.

Of course you're right that headless page interaction is just one of use cases for DOM APIs in an extension. I was focusing on this part because I thought Conrad was asking about when I wrote this reply. I realize now that I was a bit myopic and didn't quite hear what you and others were saying.

In the last WECG meeting Devlin from the extensions engineering team shared a rough sketch of how we're thinking about addressing the lack of DOM in Manifest V3. From the minutes, we're considering "adding the ability for an extension to create a temporary DOM context with an explicitly declared purpose. [This] allows the browser to surface this purpose to the end user and help reviewers detect malicious uses of this capability." I'm hoping that we'll be able to share a more concrete proposal publicly in the WECG in early 2022.

Simeon - @dotproto

Chrome Extensions DevRel

On Tue, Dec 21, 2021 at 8:35 PM Cuyler Stuwe <cuyler...@gmail.com> wrote:

What’s interesting about all of this is that extensions are literally the only reason people use Chrome over other browsers. Break extensions and suddenly Chromium is dead in the water. Might as well use Safari then.

On Tue, Dec 21, 2021 at 8:59 AM hrg...@gmail.com <hrg...@gmail.com> wrote:

 

at the moment we don't plan to support a general purpose headless page context for extensions in Manifest V3. If you feel that interacting with pages without making those interactions visible to the end user is a critical feature for the platform, I'd love to dig more into that in a new thread to better understand your perspective.

A page context gives access to ALL web capabilities. This is the reason why a page context is a critical feature.

You refer to "interacting with pages without making those interactions visible to the end user"  as if it was the main reason for the need of a page context; when in reality it's just only one of myriads of use cases.

For the last 3 years, those myriads of uses cases have been mentioned in this forum and in crbug.com more times than I could remember. And yet you now say that you'd love to dig more into why a specific use case is important.... Really?

I detect the following problem here:

The Extensions Team seems to be obsessed with tackling one use case at a time. It's almost as if they don't realize that there's a whole world of use cases that MV3 does not support. They insist into dealing with ONE. LITTLE. PROBLEM. AFTER. ANOTHER.

Do you guys really don't see that you will never make MV3 a decent replacement for MV2 if you address uses cases individually. There are too many of them!

You have one year left, according to your own deadline, and it's so obvious that, at the current pace, you won't be able to cover all those individual uses cases. crbug issues are being created faster than you can solve them.

Open your eyes please.

--
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/71e8dcd4-6914-45f2-9324-65a5350f7541n%40chromium.org.

--
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.

[Conrad Irwin]

To be honest I was a bit hesitant to send that last email because it's so light on details. While I'm worried about giving y'all the wrong impression due to a lack of concrete details, I'm also worried about maintaining radio silence until we have every I dotted and T crossed.

No, thank you for sending! I wouldn't have found the WECG without that mention and it's great to know it exists :D

I don't know if you can share the proposals out side of Google, but if so I'd love to have an opportunity to help design something awesome. (For me, I don't really need an entire page context, just a DOMParser; but I'm sure other people have more use-cases than just what we're up to)

Conrad

Sent via Superhuman

On Wed, Jan 05, 2022 at 11:04 PM, Simeon Vincent <sim...@chromium.org> wrote:

I also am concerned about the "explicitly declared purpose", I guess if it was built into the original extension install prompt it'd be less of a problem; but if it popped up every time we wanted to create one that would be hundreds (to thousands) or times a day for busy emailers! - Conrad

To be honest I was a bit hesitant to send that last email because it's so light on details. While I'm worried about giving y'all the wrong impression due to a lack of concrete details, I'm also worried about maintaining radio silence until we have every I dotted and T crossed.

The actual proposal will go into more detail, but that's not really how we're thinking about the use of the purpose. We're thinking less like a permissions prompt and more like a signal to the browser and reviewers that the extension intends to use a particular capability. Again, I'm hoping that we can share a proposal soon and begin discussing the idea with the community and other browser vendors.

Simeon - @dotproto

Chrome Extensions DevRel

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/71e8dcd4-6914-45f2-9324-65a5350f7541n%40chromium.org.

--
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-extensions+unsubscribe@chromium.org.

[wOxxOm]

> For me, I don't really need an entire page context, just a DOMParser; but I'm sure other people have more use-cases than just what we're up to)

In most cases parsing in DOMParser is only the first step followed by querySelector + querySelectorAll and similar methods, without which you would have to manually enumerate and check the nodes recursively like it's early '00s.

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/71e8dcd4-6914-45f2-9324-65a5350f7541n%40chromium.org.

--
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.

[Mark Fratto]

Well, I guess my self built Fleet MGMT is going to be handicapped come June.

It is a shame since we have recovered a multitude of lost and stolen chromebooks using this in MV2.

Also no more proactive battery replacements. We will have to switch to being reactive when users complain.

[wOxxOm]

Can't you use chrome.offscreen for that?

[Mark Fratto]

Hmm, was just reading about that.

EDIT: Wow that all looks super messy. Gonna have to go ahead with the ext i have without Geo and Batt until I learn how to do this cleanly. 

[Patrick Kettner]

I have a do specifically on getting this info from an offscreenDocument. When are you fetching this information currently? A timer, on some event?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/56614c07-534e-42d0-94ff-9bd08302311fn%40chromium.org.

[Mark Fratto]

a TIMER yes in the v2. and also on event of net disconnect/reconnect.

Do you have a sample of your call to offscreen document from your service worker, and a sample of your offscreen document itself? Or where you learned how to use this?

When I built on manifest version 2 there was plenty online for me to learn from.  v3 not so much.

[Patrick Kettner]

Hey Mark!

The docs will be at https://developer.chrome.com/, but they are still being reviewed. The updated code samples are available (in pr form) on github here. The only bit that is not covered in the doc that you may be interested in is adding chrome.alarms to call get-geolocation at set intervals.

~~~~~~~~~~~~~~~~~~~~~~

NOTE: This electronic mail message contains information that is or may be (a) legally privileged, confidential, proprietary, or otherwise protected by law from disclosure, and (b) intended only for the use of the addressee(s) named. If you are NOT the intended recipient you are hereby notified that reading, using, copying, or distributing any part of this message is strictly prohibited. If you ARE the intended recipient or an addressee, you are hereby notified that copying, forwarding or in any other manner distributing any part of this message is subject to the rules/regulations of Mehlville School District Board Policy. If you have received this electronic mail message in error, take the steps necessary to delete the message completely from your system and contact the sender.

[Mark Fratto]

thanks.  This will all be helpful when the review is over.  I better wait until v3 is finalized then before making any other changes.

                                        

____________________

Mark Fratto

System Administrator

Mehlville School District