Registering custom elements are already broken -- see: https://github.com/dart-lang/sdk/issues/49536. There are plans on deleting this code at some point. This current change cleans up dynamic invocations in the deprecated code.
Removes cruft on already-deprecated code and doing it now because I assume dynamic clean up will finish before the issue resolves.
Change-Id: Ic6250c139c5d9b08d88650110f55442a7bf5dd42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259247
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Both the production and try builders for the Windows SDK have been
migrated to the new recipe that doesn't use the test matrix.
Bug: b/247507699
Change-Id: I7a603e716492ffa272a43eea959b721c8c4a8f1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259842
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Both the production and try builders for the macOS SDK have been
migrated to the new recipe that doesn't use the test matrix.
Bug: b/236109661
Change-Id: I4f578a162c866da6673b228023adb5966f1ca505
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259423
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
Adds a flag `--generate-prototype-events` to the dart:html generation
scripts, which causes a `prototype_events.dart` file to be generated
with EventStreamProviders and extensions for all events generated
in legacy dart:html. The generated file can be copied and pasted into `html_events.dart` to be used in the new dart:html prototype.
The script `prototype_htmleventgenerator.py` reuses as much common functionality as possible from the `htmleventgenerator.py`.
There were many edge cases to consider, like:
- de-conflicting names with different event types (e.g. ProgressEvent onError vs SpeechRecognitionErrorEvent onError)
- hiding deprecated types that don't appear in the Web IDL and haven't been needed in the glue code prototype yet
- renaming extension on-types that have been renamed from the Web IDL
- hiding custom events, which then need to be added to the prototype by hand
- prefixing some events with the correct web library
Change-Id: I6ab944d74ede6d8a2178bbf9aa580a6ab7d67a77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259063
Commit-Queue: Riley Porter <rileyporter@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
* Remove find_base_commit.dart script, this script will be supplied via
the CIPD package instead.
* The packages use "latest", to stay in sync with the current
infrastructure rather than pinning them to an old version.
Bug: b/242960194
Change-Id: Iafa229e26b8926bc406758a79d22fe1410e1db96
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255681
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Also cleans up and unifies some behavior across the backends:
- avoiding reinstantiating JsInteropChecks for every library
- having the native classes as a member instead of recomputing on dart2js
Now that these checks exist, we can add lib/js/static_interop_test to
the test directories the wasm trybot runs.
Change-Id: I912aae988afe7915e80cc13d00b8c47818dfa520
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255760
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Generates a `tools/dom/scripts/prototype_css_properties.dart` file
with a JS interop extension with the intersection of all the dart:html
CSS property getters and setters from CssStyleDeclaration and
CssStyleDeclarationBase.
Change-Id: Ic616cdd5111eb169206a31c40e62356a7fb32150
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254561
Commit-Queue: Riley Porter <rileyporter@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Invocations of the spec parser used to exit with an error code (245)
in the case where no files were specified. This was considered to be a
useless type of invocation, and the spec parser would print out a help
message.
However, it is perfectly possible for a Gerrit CL to give rise to
invocations like that, e.g., when the CL deletes some files and does
nothing else. Also, it causes no known issues to report a success exit
code (0) in the case where no files are specified, and hence this CL
changes the spec parser accordingly.
Change-Id: I9bd75839f1a8052b3daa62fa5440451e46fb59e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253280
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The `registerElement` APIs in `dart:html` are legacy APIs based on a
deprecated Web Components v0.5 specification. These methods don't work
on modern browsers and can only be used with a polyfill.
The latest Web Components specification is supported indirectly via
JSInterop and doesn't have an explicit API in the `dart:html` library.
This change marks these APIs as deprecated. We intend to remove them in
the future (see https://github.com/dart-lang/sdk/issues/49536)
Fixes https://github.com/dart-lang/sdk/issues/48973
Change-Id: I2e96d36e95c9971b59cde80bc4da49b63d12b17c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252840
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
This reverts commit 4d750a862d.
Reason for revert: breaks google3 (b/236665701)
Original change's description:
> Make `nullFuture` be per-zone.
>
> We introduced a `nullFuture` during the null-safety migration where
> we changed some methods to no longer allow returning `null`,
> and they therefore had to return a `Future`.
> That affected timing, because returning `null` was processed
> synchronously, and that change in timing made some tests fail.
> Rather that fix the fragile tests, we made the function return
> a recognizable future, a canonical `Future<Null>.value(null)`,
> and then recognized it and took a synchronous path for it.
>
> That caused other issues, because the future was created in the
> root zone. (Well, originally, it was created in the first zone
> which needed one, that was worse. Now it's created in the root zone.)
> Some code tries to contain asynchrony inside a custom zone, and
> then the get a `nullFuture` and calls `then` on it, and that
> schedules a microtask in the root zone.
> (It should probably have used the listener's zone, and not store
> a zone in the future at all, but that's how it was first done,
> and now people rely on that behavior too.)
>
> This change creates a `null` future *per zone* (lazily initialized
> when asked for). That should be sufficient because the code recognizing
> a returned `null` future is generally running in the same zone,
> but if any other code gets the `nullFuture`, it will be in the
> expected zone for where it was requested.
>
> This is a reland of commit a247b158d6
>
> Change-Id: Ia113756de1f6d50af4b1abfec219d6b4dcd5d59b
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249488
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,nbosch@google.com
Change-Id: I02d62d58bae33d6a606a80eb3eee2e8e721a8e20
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249620
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Aske Simon Christensen