// Second case (unexpected) interface C { [x:string]: number } interface D { x: number } const d: D = { x: 1 }; const c: C = d; // error // Type 'D' is not assignable to type 'C'. // Index signature is missing in type 'D'.

Seems related, currently there's no way to enforce that object should have attribute values of specific type only. Example: I want to define an abstract Table Row, basically any object limited to attribute values as primitive types. But it doesn't work // Table row export type Row = Record<string, string | number | undefined> // User interface User { name: string } const jim: User = { name: 'Jim' } const row: Row = jim // <== Error

Unexpected features “Unexpected” features are those that are unrelated to the add-on’s primary function, and are not likely from the add-on name or description to be expected by a user installing that add-on. Should an add-on include any unexpected feature that falls into one of the following categories: Potentially compromises user privacy or security (like sending data to third parties) Changes default settings like the new tab page, homepage or search engine Makes unexpected changes to the browser or web content Includes features or functionality not related to the add-on’s core function(s) Then the “unexpected” feature(s) must adhere to all of the following requirements: The add-on description must clearly state what changes the add-on makes. All changes must be “opt-in”, meaning the user has to take non-default action to enact the change. Changes that prompt the user via the permissions system don’t require an additional opt-in. The opt-in interface must clearly state the name of the add-on requesting the change.