googlechrome / chrome-types Goto Github PK

Hello,

I'm trying to migrate an extension to manifest v3 and the following error popped up on compilation :
Property 'ShowAction' does not exist on type 'typeof declarativeContent' ts(2339)

Related code is :

// Manifest V3
chrome.runtime.onInstalled.addListener(() => {
  chrome.declarativeContent.onPageChanged.removeRules(undefined, () => {
    chrome.declarativeContent.onPageChanged.addRules([
      {
        conditions: [
          new chrome.declarativeContent.PageStateMatcher({
            pageUrl: {hostSuffix: '.example.com'},
          })
        ],
        actions: [new chrome.declarativeContent.ShowAction()]
      }
    ]);
  });
});

(code found in https://developer.chrome.com/blog/mv3-actions/)

The chrome.instanceID API states that "gcm" permissions are required. Since this is not configured in any of the _permission_features.json file, it suggests there's a bug in chrome-types or the rendering code in dcc.

Based on the official documentation here chrome.enterprise.hardwarePlatform is an official API. However, the namespace and it's types are missing.

I have just copy-pasted the official chrome extension samples into a typescript project and typescript complains eventhough the code works correctly.

tsconfig
{ "compilerOptions": { "strict": true, "target": "es6", "moduleResolution": "bundler", "module": "ES6", "esModuleInterop": true, "sourceMap": false, "rootDir": "src", "outDir": "dist/js", "noEmitOnError": true, "jsx": "react", "types": ["chrome-types"] }, }

We generally only care about release versions within 15-20 releases. We should annotate generated types with this.

If there is a method that has moved to the stable channel and then another channel, will stable still be shown?

Moved from https://bugs.chromium.org/p/chromium/issues/detail?id=1325919

This is necessary for GoogleChrome/developer.chrome.com#2117

The Chrome team is progressively adding support for Promises in Manifest V3 APIs. At the moment we flag methods that return promises, but don't indicate when promise support landed. This makes it difficult (if not practically impossible) for developers that support a range of Chrome versions to know whether it's safe for them to expect a given method to return a promise or whether they'll be introducing bugs into their product in old versions of Chrome.

For each method that returns a Promise, this project should emit the first version of Chrome that shipped with promise support.

This feature request can be generalized to expose version information for ANY change to a type, both added and removed properties.

Describe the bug
there are line breaks between each types enum in the extension API docs, and that's hard to read.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://developer.chrome.com/docs/extensions/reference/history/#type-TransitionType
2. Look at the types below the paragraph "The transition type for this visit from its referrer."

Expected behavior
Types are listed in a single paragraph.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• confirmed in Chrome/Firefox on Windows/macOS

Smartphone (please complete the following information):

• haven't checked

@types/chrome does it explicitly while you in this repo might be able to auto-generate it from source e.g. by walking idl/json files referenced in api_sources.gni. If not feasible, just copy it from @types/chrome (maybe even automatically via a plain regexp or smart parsing with acorn).

As I expected, the sendResponse callback should accept 1 param in any type but now 0.

Thus the following codes will fail to pass the type checking.

I'm not sure whether this is the right place to ask but it would be great to have an up to date JSON schema definition for the manifest.json file which would improve the authoring experience in editors like VSC. You could even consider adding it to schemastore.org.

Thanks.

Update: V2 seems to already be available: https://json.schemastore.org/chrome-manifest

Enums are marked up using a dcc feature that is intended for long quotes. (See below.) We need to find another way to render this.

We can find out the current stable release from here, as well as its branch commit and so on.

Using this, configure a GitHub action to publish to 1.chromeRelease.x when we see a new major stable version.

We can encourage users to depend on ~1 (or similar) to mean "latest stable".

Currently when extension APIs are rendered using Chrome-types (and it's code in dcc) render some bits of data in a pseudo-table format. For example:

This has several problems:

• It contains an unnecessary heading called 'Description'. I think most reader assume the first paragraph is a description. If they can't assume that it's because writers aren't doing their job.
• The headings don't show up in navigation.
• The headings lack IDs, which would allow them to be used easily in links.

These problems would be solved by formatting this material to match the rest of their containing pages. For example:

This change of layout introduces issues that will need to be solved. An example can be seen in the image above where the content after "Availability" looks like it's part of that section. As I first step, I opened this issue just to get this in writing.

Hi, I'm now migrating an extension to manifest v3 that was previously using @types/chrome, so far I have found 3 issues working with chrome-types:

1. Not really sure, but I think chrome.runtime.lastError is still a thing in manifest v3 and the types do not reflect its existence
2. For chrome.runtime.sendMessage there's a missing overload to call it only with a message and the callback, like chrome.runtime.sendMessage(message, cb)
3. Not sure if it's something intended but the types are missing adding the chrome property to the Window interface, if so, I think there should be some docs to show that

Thanks!

Have you considered merging this project with @types/chrome and using the @types/chrome NPM name going forward? Two benefits:

• No confusion around "what's the right package to use"
• TypeScript has some special handling for the @types node_modules folder which it will import automatically. This is perfect for a package like this (similar to @types/node) which also contains global type definitions. This means a user can just yarn add -D @types/chrome and doesn't have to change their tsconfig.json.

Happens on all including 0.1.155

const listener = (windowId: number) => {
      console.log(windowId);
    };

chrome.windows.onFocusChanged.addListener(listener);

chrome.windows.onFocusChanged.removeListener(listener);

chrome.windows.onFocusChanged.hasListener(listener);

addListener

removeListener

typescript error

I tried to execute

await chrome.scripting.executeScript({
  target: {tabId: tab.id},
  func: (text) => {
    (document.activeElement! as HTMLInputElement).value += (text || '');
  },
  args: [text],
});

and TypeScript tells me

TS2769: No overload matches this call.
   Overload 1 of 2, '(injection: ScriptInjection): Promise<InjectionResult[]>', gave the following error.
     Type '(text: any) => void' is not assignable to type '() => void'.
       Target signature provides too few arguments. Expected 1 or more, but got 0.
   Overload 2 of 2, '(injection: ScriptInjection, callback?: ((results: InjectionResult[]) => void) | undefined): void', gave the following error.
     Type '(text: any) => void' is not assignable to type '() => void'.

as well as

TS7006: Parameter 'text' implicitly has an 'any' type.

the type definition looks a bit too simple compared to @types/chrome

    export interface ScriptInjection {
      func?: () => void;
      args?: any[];
      ...
    }

    export type ScriptInjection<Args extends any[], Result> = {
        target: InjectionTarget;
        world?: ExecutionWorld;
        injectImmediately?: boolean;
    } & ({
        files: string[];
    } | ({
        func: () => Result;
    } | {
        func: (...args: Args) => Result;
        args: Args;
    }))

Following might also be a separate issue, but maybe add to the docs that one has to add /// <reference types="chrome-types" /> to a .d.tssince at least for me, it didn't take it automatically.

What is the difference between chrome-types and @types/chrome? Why are there 2 chrome typings packages?

Check out bluetoothSocket.CreateInfo, which is generated from this file. The description in the file is:

    // The ID of the newly created socket. Note that socket IDs created
    // from this API are not compatible with socket IDs created from other APIs,
    // such as the <code>$(ref:sockets.tcp)</code> API.

Wrapping the $(ref:sockets.tcp) in <code> tags results in broken output in the server.

We should either a) remove all instances of tags wrapping $(refs) and add a warning or b) have the output handle it appropriately.

I am not clear on how best to use this library. Do I need to make tsconfig.json changes? Or ///reference..

Do I use "typeRoots": ["./node_modules/@types", "./node_modules/chrome-types"]?

Hello everyone,

First of all, I don't really know if this is the correct place to post this, but the case is the following:

When instantiating a new Date() in the crhome console using javascript, for example, with the values '2021-01-01' the result is as it follows in the image bellow:

But, and correct if I'm wrong, the correct value should be, when considering that I'm from São Paulo - Brazil:

The differences between the environment of the two images above is:

• In the first image we're using windows 8.1
• In the second image we're using windows 10
  -all the screenshots has been taked in the same location
• Notice that the chrome versiong in the both of images are the same, 88.0.4324.104:

in windows 8:

in windows 10:

Background

It's my understanding that browser support data is transferred to the output as it is encountered. This means that the only option for displaying support information is to list support for each member of an API beneath the heading that it applies to. This is by no means a bad thing. This limitation in how chrome-types processes support data limits the way it can be used by consumers of chrome-types.

One immediate consequence of this is an inability to render a single support table or information block for a single API. This means that a potential extension developer must review APIs member by member to determine if extensions can serve a particular use case. Although this is not necessarily a problem with older APIs, it may be critical to adoption of new APIs, since new API are almost always implemented in phases. Whether they are or not, enhancements and changes are made after new API designs meet real-world problems.

Rendering a single table would have been useful during the roll-out of MV3 by making it clear to developers that conversion to MV3 could begin for their particular use case. "What's new" and the extension Google group already attempt to serve this purpose. This doesn't just require developers to pay fastidious attention to these channels. When they don't, they must also do manual searches as they would with the information provided with each API member

Requested enhancement

Output support data in chrome-types as a single data structure or structures. This will make it easier to output such data in a single reference table such as those provided by MDN for web platform APIs. (Please don't make any assumptions about the design of reference tables in our docs. I've provided the MDN link as an aid to understanding the reason for this request, not as a proposal for a design.) Outputting support data in a single structure would also enable use cases we haven't thought of yet.

Alternatives considered

Hand curation

It should go without saying that hand curation is both prone to becoming out of sync with the generated source of truth, but also prone to human error during the copy work. [MDN](https://developer.mozilla.org/en-US/'s experience with this is illustrative. Years ago, MDN used hand curated browser compatibility tables. When they converted to JSON files involved parties realized the data was so bad that Googlers working on web platform tests were repurposed to autogenerate the data. This effort to clean up MDN's browser compatibility data started more than five years ago and is still under way.

Scraping the generated output

This would tightly couple a downstream client to its source in a way that could limit the ability to change chrome-types in the future.

It's not clear what semver this should go under. We would publish this under a special NPM tag though, e.g, head.

• It could go under 1.chromeVersion.0-beta0 (and so on), in that the prerelease tags are an understood thing, and even a random nightly version of Chrome is technically attached to a (future) release.
• It could go under 0.1.x.

Enums such as those for chrome.offscreen are rendered in the same order they are entered into the IDL source file. Rather than editing all source files to put enums in alphabetical order, we should just call a sorting function at the time the IDL is rendered as API reference.

As per documentation of runtime.sendMessage and tabs.sendMessage the methods have a 4th parameter callback. At the moment this parameter is missing from the types and typescript complains.

chrome.declarativeNetRequest does not seem to be present in chrome-types while it's fairly well documented in the Manifest V3 section.

I'm wondering if it's because the feature is still flagged as beta (http://ext.123456cc.cc/static/chromeAPI/declarativeNetRequest.htm) and this lib seems to be auto generated.

Is there any chance chrome-types generates multiple packages so it's possible to use beta features as dependencies? I'm thinking something like chrome-types-beta and/or chrome-types-dev.

The API reference displays items that are in origin trials without indicating them as such. This has a number of problems.

• The existence of an origin trial is no guarantee of shipping. In eight years, I've seen features that were shipped with a different API surface, I've seen features that went through a second origin trial with a different design, and I've seen features that did not ship at all.
• Because this feature is only available in an origin trial, extension developers can't count on its availability. To even use it, host sites must have opt-in to the origin trial. In the most optimistic case, this feature is only available to 1 web site in every 1.5 million.
• Our documentation gives no indication that this is experimental, much less how I could test it if I wanted to.
• We do not publicize origin trials that affect extensions and provide no general guidance for how an extension developer can participate in an origin trial.
• Do we even want extension developer participating in origin trials?

For example, so that extensions can handle Back/Forward (sic) caching a few things have been added to extension APIs. One of them is called FrameType. One of the values of FrameType is "fenced_frame". But Fenced Frame is in an origin trial that finished by the time Chrome shipped 108 on November 29.

This issue is a request to either hide or correctly label items that are in origin trials. I favor hiding since labeling such items requires additional documentation and publicity that may or may not be useful to our developers.

Regardless of which option we chose, the first step will be making the conversion process aware of origin trials.

The devtools.panels namespace has a method called setOpenResourceHandler() that links to devtools.inspectedWindow.resource. For some reason it's rendering the last part of the link as devtools_inpsectedWindow instead of devtools.inspectedWindow.

I suspect this is a problem with links to namespaces that contain namespaces: devtools, enterprise, input and system specifically.

Dashlane's initial testing indicates that chrome-types is incomplete. We have put together an example that shows how a valid use of the API fails to compile when chrome-types is used: https://github.com/JanHett/chrome-types-bug-example.

Is this a known issue that will be addressed in upcoming releases?

cc: @tregagnon and @bradcush