Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

requestFullscreen and enterFullscreen on HTMLVideoElement #216

Closed
deepak786 opened this issue Mar 29, 2024 · 3 comments
Closed

requestFullscreen and enterFullscreen on HTMLVideoElement #216

deepak786 opened this issue Mar 29, 2024 · 3 comments

Comments

@deepak786
Copy link

Currently I'm migrating the code to use web package.
I have video element.

final videoElement = web.HTMLVideoElement();

requestFullscreen and enterFullscreen methods are not available on HTMLVideoElement

videoElement.requestFullscreen();
videoElement.enterFullscreen();
@deepak786 deepak786 changed the title How to use requestFullscreen on HTMLVideoElement using web package requestFullscreen and enterFullscreen on HTMLVideoElement Mar 29, 2024
@deepak786
Copy link
Author

Similarly exitFullscreen

@deepak786
Copy link
Author

For now I have used the extension

extension on web.HTMLVideoElement {
  external JSPromise requestFullscreen();

  external JSPromise enterFullscreen();
}

@srujzs
Copy link
Contributor

srujzs commented May 10, 2024

requestFullscreen and exitFullscreen should be addressed in #209, but I'm not sure enterFullscreen still exists as part of the spec: https://developer.mozilla.org/en-US/docs/Web/API/Document/exitFullscreen.

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
@srujzs srujzs closed this as completed May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants