Navigator.deviceMemory is missing #192
Labels
Comments
This was referenced Feb 29, 2024
Closed
|
This was removed as part of 3f1285e. We proactively removed a number of APIs that are not fully supported (here, However, this was on the more conservative side. We're working on instead requiring that APIs not be experimental and be on the standards track, which That being said, it's easy to workaround missing APIs by declaring your own member in the meantime e.g. extension on Navigator {
external double get deviceMemory;
} |
|
Thanks a lot for the response! Meanwhile, I'll try the extension method. |
srujzs
added a commit
to srujzs/web
that referenced
this issue
May 13, 2024
The current implementation only emits APIs that are on the standards track and supported in Chrome, Firefox, and Safari. This leaves out widely used APIs like Trusted Types, so this change relaxes those requirements. In order to support this change, a number of changes are included: - BrowserCompatData is modified to handle some slight discrepancies in how compatibility data is stored, including global APIs, namespaces, static members, and event handlers. - Interfaces and namespaces are generated based on whether they are standards track and experimental. If they are not generated, any references to them will be replaced by the equivalent JS type. - Likewise, inheritance for interfaces is modified to subtype the first generated interface in the inheritance hierarchy. - Dictionaries and typedef-like types are generated based on whether they are used as they don't have compatibility data. In order to determine this, whenever we generate a _RawType, we mark it as used, and recursively generate the types needed. - For each API within an interface, compat data in that interface and its superinterfaces are used to determine if an API is generated. - In order to support the above changes, intermediate representations for some members (attributes, fields, constants) are added. There are other members that might be worth moving to an IR, but that refactoring can be done in a future CL. Closes a number of issues: dart-lang#209 dart-lang#234 dart-lang#216 dart-lang#205 dart-lang#203 dart-lang#192
srujzs
added a commit
that referenced
this issue
May 21, 2024
* Only emit APIs that are standards track and not experimental The current implementation only emits APIs that are on the standards track and supported in Chrome, Firefox, and Safari. This leaves out widely used APIs like Trusted Types, so this change relaxes those requirements. In order to support this change, a number of changes are included: - BrowserCompatData is modified to handle some slight discrepancies in how compatibility data is stored, including global APIs, namespaces, static members, and event handlers. - Interfaces and namespaces are generated based on whether they are standards track and experimental. If they are not generated, any references to them will be replaced by the equivalent JS type. - Likewise, inheritance for interfaces is modified to subtype the first generated interface in the inheritance hierarchy. - Dictionaries and typedef-like types are generated based on whether they are used as they don't have compatibility data. In order to determine this, whenever we generate a _RawType, we mark it as used, and recursively generate the types needed. - For each API within an interface, compat data in that interface and its superinterfaces are used to determine if an API is generated. - In order to support the above changes, intermediate representations for some members (attributes, fields, constants) are added. There are other members that might be worth moving to an IR, but that refactoring can be done in a future CL. Closes a number of issues: #209 #234 #216 #205 #203 #192 * Generate APIs based on standards track and not experimental * Handle some TODOs that came up when addressing #209 - Removes an unnecessary null-check - Refactors getTypeForUnionCalculation to a shared _getJSTypeEquivalent function - Avoids shadowing an instance variable * Address some lints * Update CHANGELOG and README * Add types to the field declaration
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello team,
I am working on the migration of
device_info_plustowebpackage, and noticed that one of the properties we access to is missing.In this case, is the
deviceMemoryfrom theNavigatorinlib/src/dom/html.dart.This property existed in
dart:html.References:
The text was updated successfully, but these errors were encountered: