webExtension module #778

chrmod · 2024-09-18T20:00:40Z

addresses #548

We aim to provide a capability and a command to install a web-extension in the session.

This is a pre-requisite to allow WedDriver Bidi to interact with the extension background pages and service workers.

jgraham

Thanks for the PR! Quite a few comments, but this does look like it's heading in the right direction, so don't be put off :)

index.bs

jgraham · 2024-09-19T08:06:10Z

index.bs

+<pre class="cddl remote-cddl local-cddl">
+ExtensionDetails = {
+   extension: Extension,
+   ? installTemporary: bool .default true


I think we might be better off only supporting temporary installs at first. I don't really have an automation use case in mind where it makes sense to permanently install an extension in a specific profile, and we can always add it if there is one.

@jgraham would a temporary install be something new defined by the webdriver bidi spec or do you already have a notion of "temporary" extensions in Firefox (I guess they auto-uninstall)?

@oliverdunk do we have something like this within extensions?

I think having this set to false would be the current behavior - unpacked extensions stay installed between restarts as long as you use the same profile. I can imagine how true might work but I'm not sure I'm convinced of the value of that, at least for the MVP.

index.bs

jgraham · 2024-09-19T08:16:35Z

index.bs

+1. Let the |extension| be the value of the <code>extension</code> field of
+   |command parameters|.
+
+1. [=Try=] to install web-extension with |session| and |extension|.


So there's quite a few bits missing here:

It's possible this command isn't supported, so you need to say something like "If installing |extension| isn't supported for any reason return error with error code unsupported operation".

You need to explictly deal with the different input types, so that end up with some abstract representation of the set of files that make up the extension.

It would probably be good to make some checks explicit here. For example if there's no manifest.json file in the root that should return an error.

You need to handle the other data passed in e.g. the private browsing mode flag.

You need a bit more detail on what it means to install a web extension. It's going to be "implementation defined steps", but it should probably describe what the outcome is supposed to be. This will still need to be entirely fallible (i.e. there's a possibility of the install failing for implemenation-specific reasons), as in the current text.

index.bs

Rob--W · 2024-09-19T14:44:22Z

FYI: There is prior context in the WECG to discuss the desired characteristics of extension loading functionality. For reference, here are the meeting notes:

Related issues:

request: APIs and infrastructure to simplify cross-browser automated testing of extensions webextensions#19
Is there any interest in creating extension-specific test harness like the WPT one? webextensions#441

chrmod · 2024-09-19T20:41:31Z

Thanks for the PR! Quite a few comments, but this does look like it's heading in the right direction, so don't be put off :)

@jgraham thank you very much for the review. I will need a moment to unpack all comments, but sure to receive progress soon.

whimboo · 2024-10-02T13:00:46Z

@jgraham thank you very much for the review. I will need a moment to unpack all comments, but sure to receive progress soon.

Hi Krzysztof. I wanted to check back if you already had some time to distill the feedback from James. If not no worries, but let us know in case you don't have the time to continue on this PR. Thanks!

chrmod · 2024-10-02T18:57:26Z

@jgraham @whimboo it took me a while to learn more on how to write such documents, sorry for keeping you waiting. I'm pretty sure that the current result is still not merge ready. Please guide me on how it should be improved.

index.bs

chrmod · 2024-10-03T07:33:37Z

index.bs

+1. Let |path| be a value of <code>path</code> field of |install path spec| if the value of <code>type</code> of the |install path spec| is equal to <code>path</code>,
+   otherwise perform any implementation-defined steps to create a temporary folder and make its path to be the value of |path|.
+
+1. Let |archive path| be a value of <code>path</code> field of |install path spec| if the value of <code>type</code> of the |install path spec| is equal to <code>archive-path</code>,
+   otherwise if the value of <code>type</code> of the |install path spec| is equal to <code>archive-path</code> perform any implementation-defined steps to create a temporary file
+   being a result of Base64 decodeing of the value of <code>value</code> filed of |install path spec| and make its path to be the value of |archive path|,
+   otherwise |archive path| is null.


I do realize this is overly complicated, but wasn't sure how to express it otherwise. Please advise.

I'm confused by the flow of this, since each step has something along the lines of "If A do this, otherwise if A do that". I would have expected something like:

If the type is "path", return the path.

Otherwise, if the type is "archive-path", extract the archive and return the path to the temporary directory.

Otherwise, if the type is "base64", decode this as a zip and return the path to the temporary directory.

Is it better now? or you would rather remove the intermediate data structure?

The extraction process is much clearer now, thanks - I'm happy with that as long as we are comfortable having a switch vs a series of if/else if (cc/ @jgraham). I'm still a little unclear why we need |extension files| and |extension archive|. Is there a reason for that?

oliverdunk

Thanks for this! It's really great to see an external contribution and it lines up nicely with our goal in the WebExtensions Community Group to write cross-browser tests for extension APIs.

I've left some feedback but please prioritize addressing anything from @jgraham who is the one with spec experience :)

oliverdunk · 2024-10-04T00:42:42Z

index.bs

+
+1. Let |extension files| be a value of <code>files<code> field of |extension archive|.
+
+1. If |extension files| does not include entry <code>manifest.json</code> return [=error=] with code [=invalid extension=]


I would lean towards dropping this, and in the subsequent step having something that allows the browser to return an error if anything goes wrong. There are many ways an extension can be invalid beyond the manifest.json not being present (e.g an unsupported manifest_version) and I don't think we want to list them all here.

I think we could delete it; as you say there are many failure cases and we can't enumerate them all. On the other hand, it's also clear that if there isn't a manifest.json at all the install must fail, so assuming it's not hard to specify I think checking the file exists is reasonable, and makes the spec more precise (by defining at least one case where failure is mandatory).

index.bs

oliverdunk · 2024-10-04T00:47:00Z

index.bs

+1. Let |path| be a value of <code>path</code> field of |install path spec| if the value of <code>type</code> of the |install path spec| is equal to <code>path</code>,
+   otherwise perform any implementation-defined steps to create a temporary folder and make its path to be the value of |path|.
+
+1. Let |archive path| be a value of <code>path</code> field of |install path spec| if the value of <code>type</code> of the |install path spec| is equal to <code>archive-path</code>,
+   otherwise if the value of <code>type</code> of the |install path spec| is equal to <code>archive-path</code> perform any implementation-defined steps to create a temporary file
+   being a result of Base64 decodeing of the value of <code>value</code> filed of |install path spec| and make its path to be the value of |archive path|,
+   otherwise |archive path| is null.


I'm confused by the flow of this, since each step has something along the lines of "If A do this, otherwise if A do that". I would have expected something like:

If the type is "path", return the path.

Otherwise, if the type is "archive-path", extract the archive and return the path to the temporary directory.

Otherwise, if the type is "base64", decode this as a zip and return the path to the temporary directory.

chrmod · 2024-10-08T19:46:59Z

@oliverdunk thank you for all the suggestions! Happy to contribute to WECG goals.

OrKoN · 2024-10-09T17:47:50Z

index.bs

+<pre class="cddl remote-cddl local-cddl">
+extensions.Extension = {
+   installPath: extensions.ExtensionPath / extensions.ExtensionArchivePath / extensions.ExtensionBase64Encoded,
+   ? allowPrivateBrowsing: bool .default false,


@oliverdunk do you know if we have an equivalent of what allowPrivateBrowsing is expressing here?

In Chromium this is called "Allow in Incognito"

I see, thanks! I wonder if alternatively we could specify a user context ID to install an extension to? (I would need to check if it's implementable though)

I don't believe that per-user-context containers would be possible in the current Firefox implementation. I'd propose dropping this from the initial proposal since we don't really have the concept of private browsing exposed elsewhere in the specification.

Maybe we then rename the property to temporary to indicate that the extension will not be installed permanently? That also uses a name that is not tied too much to a given browser.

Btw. we also use this name for our current implementation for WebDriver classic in Firefox.

Actually my last answer was wrong. Temporary actually means that the web extension is not persistent and can be installed even when it isn't signed (like for developers), and that is indeed a feature that we support in Firefox.

But we do not yet support the private browsing mode installation. So both things are different.

@OrKoN How does Chrome handle the installation of unsigned web extensions?

In Chrome, you enable "Developer Mode" with a toggle on the chrome://extensions page and then load a directory or zip file with a "Load unpacked" button. Unlike Firefox, we don't couple the concept of unsigned and temporary extensions. An unsigned extension will always persist until it is removed - just like with a signed extension.

Given that, I would be against having a temporary property which is required for loading an unpacked extension. That is coupling two unrelated concepts.

I believe as implemented, the Extensions.loadUnpacked CDP command would fail for a packed extension.

Given that, I wonder if we could do one of a few options:

Scope the MVP to just unpacked extensions. We wouldn't need any additional flags.

Have the browser autodetect packed or unpacked. We also wouldn't need any additional flags.

Have a flag that is specifically named to decide which path we go down trying to load the extension.

For all of this, I think whether this ends up being temporary or not can be for the user-agent to decide. Let me know if I'm wrong but I don't think there is much presidence for tests that span across browser sessions? If you care about having a clean state you should be creating a new profile directory.

OrKoN · 2024-10-09T17:49:27Z

index.bs

+
+<pre class="cddl remote-cddl local-cddl">
+extensions.Extension = {
+   installPath: extensions.ExtensionPath / extensions.ExtensionArchivePath / extensions.ExtensionBase64Encoded,


In Chrome, we currently only allow installing extensions if the client is local to the browser (i.e., connected via pipes instead of the WebSocket). We could probably relax this based on a command line argument but I wonder if it makes sense to start with the extensions.ExtensionPath only?

cc @oliverdunk for additional thoughts

Could that be managed by the webdriver? Archives (zip/crx) and Base64 strings are can effectively be unpacked to a temporary folder, and then run as from any other path.

the driver process and the browser might not be running on the same machine so, in a general case, we probably should not handle it in the driver. I think a remote-end path to an archive or to an unpacked folder is less of a concern but installing an extension from base64 would mean writing something to the filesystem that was not present there originally.

@OrKoN, I'm fairly certain Selenium currently supports loading an extension from base64 in WebDriver. Do you have any idea how that was implemented?

base64 is probably the only useful format if you're trying to install things on a remote browser; in that case you might well want to specifically disallow access to filesystem paths.

It should certainly be allowed for implementations to return Unsupported operation for any variant they don't support here.

@OrKoN, I'm fairly certain Selenium currently supports loading an extension from base64 in WebDriver. Do you have any idea how that was implemented?

they probably decode it and unpack it to the local filesystem and provide the path as the launch arg for Chrome. I don't think they use the CDP method to install extensions at runtime.

do we have any concerns that base64-encoded extensions could be too large for transporting as JSON over the protocol? I do not know how large is a typical extension bundle.

I think extension installation here is similar to input.setFiles which currently also supports only remote-end absolute paths.

Extensions can be quite big. I think AdblockPlus is around 60mb while Ghostery is around 12mb.

OrKoN · 2024-10-09T17:53:11Z

index.bs

+<pre class="cddl remote-cddl local-cddl">
+ExtensionDetails = {
+   extension: Extension,
+   ? installTemporary: bool .default true


@jgraham would a temporary install be something new defined by the webdriver bidi spec or do you already have a notion of "temporary" extensions in Firefox (I guess they auto-uninstall)?

@oliverdunk do we have something like this within extensions?

OrKoN · 2024-10-09T18:00:38Z

I noticed the IPR bot message:

PR has contribution issues. The following users were not in the repository's groups: @chrmod.

I believe you plan to join the group @chrmod?

Or is there a different workaround?

chrmod · 2024-10-09T19:20:53Z

I noticed the IPR bot message:

PR has contribution issues. The following users were not in the repository's groups: @chrmod.

I believe you plan to join the group @chrmod?

Or is there a different workaround?

My plan was to join the group and I've made a request to W3C. In result I was added to WECG group, but not to webdriver. Not sure whom to ask fix it. Can you recommend a contact?

chrmod · 2024-10-09T19:24:00Z

re #778 (comment)
@OrKoN in Firefox, Temporary Extension are similar to Chrome's unpacked ones - they can be loaded from a path or base64. The point of temporary is that they wont be stored in the profile and will be removed when the browsing session ends.

OrKoN · 2024-10-09T19:27:53Z

re #778 (comment) @OrKoN in Firefox, Temporary Extension are similar to Chrome's unpacked ones - they can be loaded from a path or base64. The point of temporary is that they wont be stored in the profile and will be removed when the browsing session ends.

thanks for details so it's different from unpacked extensions in Chrome because they persist in the profile.

OrKoN · 2024-10-09T19:37:35Z

I noticed the IPR bot message:

PR has contribution issues. The following users were not in the repository's groups: @chrmod.

I believe you plan to join the group @chrmod?
Or is there a different workaround?

My plan was to join the group and I've made a request to W3C. In result I was added to WECG group, but not to webdriver. Not sure whom to ask fix it. Can you recommend a contact?

I think this link should lead to a form to join the browser testing and tools working group https://www.w3.org/groups/wg/browser-tools-testing/join

index.bs

jgraham · 2024-10-09T16:30:33Z

index.bs

+
+1. Let |extension files| be a value of <code>files<code> field of |extension archive|.
+
+1. If |extension files| does not include entry <code>manifest.json</code> return [=error=] with code [=invalid extension=]


I think we could delete it; as you say there are many failure cases and we can't enumerate them all. On the other hand, it's also clear that if there isn't a manifest.json at all the install must fail, so assuming it's not hard to specify I think checking the file exists is reasonable, and makes the spec more precise (by defining at least one case where failure is mandatory).

index.bs

jgraham · 2024-10-10T13:55:55Z

index.bs

+
+<pre class="cddl remote-cddl local-cddl">
+extensions.Extension = {
+   installPath: extensions.ExtensionPath / extensions.ExtensionArchivePath / extensions.ExtensionBase64Encoded,


base64 is probably the only useful format if you're trying to install things on a remote browser; in that case you might well want to specifically disallow access to filesystem paths.

It should certainly be allowed for implementations to return Unsupported operation for any variant they don't support here.

index.bs

jgraham · 2024-10-10T14:09:57Z

index.bs

+    <dt>"<code>archive-path</code>"
+    <dd>
+      1. Let |archive path| be a value of <code>path</code> field of |install path spec|.
+      1. Perform any implementation-defined steps to extract the archive from <code>archive path</code> to a temporary directory and let |path| be the path to that temporary directory.


This definitely doesn't have to require a temporary directory (that is: doing this entirely in-memory should be permitted). Also this seems to allow an unbounded range of archive formats, whereas I guess we only actually want to support zip? Zip isn't well-specified afaik, so actually talking about how to decode that might be a problem (but it needs to be falliable, in case the file is invalid).

Not quite sure how to achieve that. Can you please check the latest version to verify if I go into right direction?

index.bs

whimboo

Thank you, @chrmod, for all your hard work! It's looking great, but there are a few items I'd like to discuss and see addressed. All of them can be found inline.

index.bs

whimboo · 2024-10-17T09:16:53Z

index.bs

+
+1. Let |extension data spec| be a value of <code>extensionData</code> field of the |command parameters|.
+
+1. Let |extension directory entry| be the result of [=trying=] to [=expand a extension data spec=] with |extension data spec|.


Should the directory entry part reference the other spec?

isn't it enough if |expand a extension data spec| returns a [=directory entry=]?

index.bs

Co-authored-by: Henrik Skupin <[email protected]>

Co-authored-by: jgraham <[email protected]>

chrmod · 2024-11-18T12:53:39Z

@whimboo done and tests are green now.

chrmod · 2024-11-22T15:35:20Z

@jgraham can you please take a look?

whimboo

Overall this looks fine to me. Just two nits where I would also like to see what @jgraham thinks about.

@chrmod thanks a lot for working on this PR!

index.bs

whimboo · 2024-11-25T21:33:36Z

index.bs

+webExtension.Extension = text
+</pre>
+
+The <code>webExtension.Extension</code> type represents a web extension id within a browser.


@jgraham should we actually use remote end for all those cases instead of browser to be consistent?

I think remote end is marginally better, but arguably only an actual browser can have an extension. I think honestly we're not 100% consistent already (e.g. with the browser module)

jgraham

This is nearly ready; I tried to make some fixups, but apparently you didn't grant write access to the branch so I can't. But I suggest applying the following patch:

diff --git a/index.bs b/index.bs
--- index.bs
+++ index.bs
@@ -633,9 +633,9 @@
   <dt><dfn for=errors export>no such user context</dfn>
   <dd>Tried to reference an unknown [=user context=].
 
   <dt><dfn for=errors export>no such web extension</dfn>
-  <dd>Tried to interact with not installed web extension.
+  <dd>Tried to reference and unknown web extension.
 
   <dt><dfn for=errors export>unable to close browser</dfn>
   <dd>Tried to close the browser, but failed to do so.
 
@@ -11385,15 +11385,15 @@
 <pre class="cddl remote-cddl local-cddl">
 webExtension.Extension = text
 </pre>
 
-The <code>webExtension.Extension</code> type represents a web extension id within a browser.
+The <code>webExtension.Extension</code> type represents a web extension id within a [=remote end=].
 
 ### Commands ### {#module-webExtension-commands}
 
 #### The webExtension.install Command #### {#command-webExtension-install}
 
-The <dfn export for=commands>webExtension.install</dfn> command installs a web extension for the browser.
+The <dfn export for=commands>webExtension.install</dfn> command installs a web extension in the [=remote end=].
 
 <dl>
    <dt>Command Type</dt>
    <dd>
@@ -11462,20 +11462,25 @@
    <dl>
     <dt>|type| is the string "<code>path</code>"
     <dd>
       1. Let |path| be |extension data spec|["<code>path</code>"].
-      1. Let |entry| be a [=directory entry=] representing the directory with that |path|.
+      1. Let |locator| be a [=directory locator=] with [=file system locator/path=] |archive path| and [=file system locator/root=] corresponding to the root of the file system.
+      1. Let |entry| be [=locate an entry=] given |locator|.
 
     <dt>|type| is the string "<code>archivePath</code>"
     <dd>
       1. Let |archive path| be |extension data spec|["<code>path</code>"].
-      1. Perform implementation defined steps to read |bytes| from a file located at |archive path|.
+      1. Let |locator| be a [=file locator=] with [=file system locator/path=] |archive path| and [=file system locator/root=] corresponding to the root of the file system.
+      1. Let |archive entry| be [=locate an entry=] given |locator|.
+      1. If |archive entry| is null, return null.
+      1. Let |bytes| be |archive entry|'s [=file entry/binary data=].
       1. Let |entry| be the result of [=trying=] to [=extract a zip archive=] given |bytes|.
 
     <dt>|type| is the string "<code>base64</code>"
     <dd>
       1. Let |bytes| be [=forgiving-base64 decode=] |extension data spec|["<code>path</code>"].
       1. Let |entry| be the result of [=trying=] to [=extract a zip archive=] given |bytes|.
+      1. If |entry| is failure, return null.
 
    </dl>
 
 1. Return |entry|.
@@ -11490,8 +11495,10 @@
 1. Let |extension data spec| be |command parameters|["<code>extensionData</code>"].
 
 1. Let |extension directory entry| be the result of [=trying=] to [=expand a web extension data spec=] with |extension data spec|.
 
+1. If extension directory entry| is null, return [=error=] with [=error code=] [=invalid web extension=].
+
 1. Perform implementation defined steps to install a web extension from |extension directory entry|. If this fails, return [=error=] with [=error code=] [=invalid web extension=]. Otherwise let |extension id| be the unique identifier of the newly installed web extension.
 
 1. Let |result| be a [=/map=] matching the
    <code>webExtension.InstallResult</code> production with the
@@ -11526,11 +11533,11 @@
 The [=remote end steps=] with |command parameters| are:
 
 1. Let |extension| be |command parameters|["<code>extension</code>"].
 
-1. If the browser has no web extension with an id equal to |extension|, return [=error=] with [=error code=] [=no such web extension=].
+1. If the [=local end=] has no web extension with id equal to |extension|, return [=error=] with [=error code=] [=no such web extension=].
 
-1. Perform any implementation-defined steps to remove the web extension from the browser. If this fails, return [=error=] with [=error code=] [=unknown error=].
+1. Perform any implementation-defined steps to remove the web extension from the [=local end=]. If this fails, return [=error=] with [=error code=] [=unknown error=].
 
 1. Return [=success=] with data null.
 
 </div>

jgraham · 2024-11-26T10:34:29Z

index.bs

+webExtension.Extension = text
+</pre>
+
+The <code>webExtension.Extension</code> type represents a web extension id within a browser.


I think remote end is marginally better, but arguably only an actual browser can have an extension. I think honestly we're not 100% consistent already (e.g. with the browser module)

whimboo · 2024-11-26T16:37:00Z

This is nearly ready; I tried to make some fixups, but apparently you didn't grant write access to the branch so I can't. But I suggest applying the following patch:
[..]

Tried to interact with not installed web extension.

Tried to reference and unknown web extension.

<dd>Tried to reference an unknown web extension.

-1. If the browser has no web extension with an id equal to |extension|, return [=error=] with [=error code=] [=no such web extension=].
+1. If the [=local end=] has no web extension with id equal to |extension|, return [=error=] with [=error code=] [=no such web extension=].

Should this really be local end here? The client doesn't have extensions installed but the remote end.

jgraham · 2024-11-26T17:51:09Z

You're quite right, it should always be [=remote end=].

Co-authored-by: Henrik Skupin <[email protected]>

jgraham · 2024-11-28T10:29:26Z

Also I just noticed in the base64 bit the diff should be

       1. Let |bytes| be [=forgiving-base64 decode=] |extension data spec|["<code>path</code>"].
+      1. If |bytes| is failure, return null.
       1. Let |entry| be the result of [=trying=] to [=extract a zip archive=] given |bytes|.

chrmod · 2024-11-28T11:59:09Z

@jgraham @whimboo thank you for all the comments and improvements. The patch is applied. Can you please review once again?

index.bs

chrmod · 2024-11-28T12:45:40Z

@jgraham I've check github documentation and we should be able to grant you write access to ghostery fork https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork, but somehow I don't see that option to be available for this PR.

Instead this message is shown:

For this PR it probably does not make sense to investigate more, but it would be best if we make it work for the feature ones.

jgraham

Just one cleanup, but otherwise I think we're good to go.

index.bs

Co-authored-by: jgraham <[email protected]>

chrmod · 2024-11-28T16:39:50Z

Fantastic! Thank you all!

SHA: 9eaa877 Reason: push, by jgraham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

chrmod marked this pull request as draft September 18, 2024 20:01

chrmod marked this pull request as ready for review September 18, 2024 20:01

jgraham requested changes Sep 19, 2024

View reviewed changes

chrmod changed the title ~~WebExtension installation~~ Extensions module Sep 19, 2024

css-meeting-bot mentioned this pull request Sep 26, 2024

Web Extensions: install / uninstall #548

Closed

chrmod requested a review from jgraham October 2, 2024 19:02

chrmod force-pushed the web-extensions branch from 16931a1 to fe23c3b Compare October 2, 2024 19:03

chrmod commented Oct 2, 2024

View reviewed changes

index.bs Outdated Show resolved Hide resolved

chrmod commented Oct 2, 2024

View reviewed changes

index.bs Outdated Show resolved Hide resolved

chrmod commented Oct 3, 2024

View reviewed changes

oliverdunk suggested changes Oct 4, 2024

View reviewed changes

OrKoN reviewed Oct 9, 2024

View reviewed changes

PolariTOON mentioned this pull request Oct 10, 2024

Testing Web extensions web-platform-tests/interop#893

Open

jgraham requested changes Oct 10, 2024

View reviewed changes

chrmod force-pushed the web-extensions branch from 608978e to da00aa5 Compare October 10, 2024 17:06

chrmod changed the title ~~Extensions module~~ WebExtensions module Oct 11, 2024

OrKoN reviewed Oct 11, 2024

View reviewed changes

index.bs Outdated Show resolved Hide resolved

chrmod force-pushed the web-extensions branch from be3fb96 to 5a87256 Compare October 11, 2024 15:27

chrmod requested a review from jgraham October 16, 2024 13:30

whimboo requested changes Oct 17, 2024

View reviewed changes

chrmod and others added 5 commits November 18, 2024 13:48

Reorder algorithms

e9099c2

Update index.bs

e583028

Co-authored-by: Henrik Skupin <[email protected]>

Use browser instead of the session

42570bc

Apply suggestions from code review

e683f60

Co-authored-by: jgraham <[email protected]>

Define extact from zip

edfa91f

chrmod force-pushed the web-extensions branch from ebec014 to edfa91f Compare November 18, 2024 12:48

whimboo approved these changes Nov 25, 2024

View reviewed changes

jgraham requested changes Nov 26, 2024

View reviewed changes

Update index.bs

5ddb11e

Co-authored-by: Henrik Skupin <[email protected]>

chrmod added 4 commits November 28, 2024 12:29

Apply jgraham's patch

58ea10d

Replace local end with remote end

97ed7ea

Fix base64 error handling

e7957f0

fix path name

000ce14

chrmod requested a review from jgraham November 28, 2024 11:56

remove patch file

14670b5

chrmod commented Nov 28, 2024

View reviewed changes

index.bs Outdated Show resolved Hide resolved

Update index.bs

b877da6

jgraham approved these changes Nov 28, 2024

View reviewed changes

index.bs Outdated Show resolved Hide resolved

Update index.bs

0c770e2

Co-authored-by: jgraham <[email protected]>

jgraham merged commit 9eaa877 into w3c:main Nov 29, 2024
5 checks passed

github-actions bot added a commit that referenced this pull request Nov 29, 2024

webExtension module (#778)

fa883fc

SHA: 9eaa877 Reason: push, by jgraham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

whimboo mentioned this pull request Dec 2, 2024

Extend roadmap: web extensions #421

Open


		1. Let \|extension files\| be a value of <code>files<code> field of \|extension archive\|.

		1. If \|extension files\| does not include entry <code>manifest.json</code> return [=error=] with code [=invalid extension=]


		1. Let \|extension data spec\| be a value of <code>extensionData</code> field of the \|command parameters\|.

		1. Let \|extension directory entry\| be the result of [=trying=] to [=expand a extension data spec=] with \|extension data spec\|.

webExtension module #778

webExtension module #778

Conversation

chrmod commented Sep 18, 2024 • edited by pr-preview bot Loading

jgraham left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Rob--W commented Sep 19, 2024

chrmod commented Sep 19, 2024

whimboo commented Oct 2, 2024

chrmod commented Oct 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oliverdunk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrmod commented Oct 8, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OrKoN commented Oct 9, 2024

chrmod commented Oct 9, 2024

chrmod commented Oct 9, 2024

OrKoN commented Oct 9, 2024

OrKoN commented Oct 9, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

whimboo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrmod commented Nov 18, 2024

chrmod commented Nov 22, 2024

whimboo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgraham left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

whimboo commented Nov 26, 2024

jgraham commented Nov 26, 2024

jgraham commented Nov 28, 2024

chrmod commented Nov 28, 2024

chrmod commented Nov 28, 2024

jgraham left a comment

Choose a reason for hiding this comment

chrmod commented Nov 28, 2024

chrmod commented Sep 18, 2024 •

edited by pr-preview bot

Loading