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>
Avoid removing dynamic invocations in sanitizing code as we don't know what type the element and its attributes may be.
Change-Id: I057d908027befe7fd284bf4ec6c68bd1d0e977f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259108
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This reverts commit f630a7c07d.
Reason for revert: Remove the `is` check since it's more costly than removing a dynamic call for web.
Original change's description:
> Eliminate dynamic call() in html_dart2js in _EventStreamSubscription.
>
> Change-Id: Ia4a300c210bc505f71cc3bfb1a1b911c96c1aa53
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256703
> Commit-Queue: Kallen Tu <kallentu@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
> Reviewed-by: Lasse Nielsen <lrn@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I36b2f8cedc5f8b5235832ea29ea5eb40e2e8dc92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257421
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Additionally, fixed the template for html_dart2js so the generator would generate the correct code.
Change-Id: I2172bb10db413169b86690faa027365ff72e3d68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255763
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@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>
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>
This reverts commit a247b158d6.
Reason for revert: breaks google3. See 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.
>
> Change-Id: Ibe204eaabe175cbcbcb7822ca1f2bcdda72a478c
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248660
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,nbosch@google.com
Change-Id: Ic765eb1401dbff4dea6c08c007c0bf9aff186684
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249188
Reviewed-by: Oleh Prypin <oprypin@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
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.
Change-Id: Ibe204eaabe175cbcbcb7822ca1f2bcdda72a478c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248660
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Closes https://github.com/dart-lang/sdk/issues/48630
'mark' can return undefined in Firefox, and therefore needs to
return a nullable. Similarly, the different syntaxes of 'measure'
don't work in Firefox or Safari, so the incompatible ones are
removed from tests.
Change-Id: Ia137fe0d72ddbaad03ae8cf58c43736b128b3f33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237930
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/48430
Adds overloads for both methods to accept additional/different options.
Also changes return types:
- mark returns a PerformanceEntry
- measure returns a PerformanceMeasure, but this may be undefined, so it's
marked as nullable
Change-Id: I189c4613b19e214a1f5bcc5bbd780d9dc447d9e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235286
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This code was added in 2013 for what looks like the purpose of
aligning functionality across browsers.
https://codereview.chromium.org/12218111
The custom event stream provider used to wrap events is missing
any cleanup code. The interesting part (returning `.returnValue`
on the wrapped event) was removed in 2016.
https://codereview.chromium.org/1894713002
Since then it appears that the custom event stream provider no
longer provides any use.
Canceling the stream subscription that is returned from
`window.onBeforeUnload.listen()` was not actually removing the
listener on the underlying native element. The listener would
remain and its callback was never garbage collected. This is
especially a problem in apps that correctly clean up when
destroyed. After multiple hot restarts and cleanup executions,
multiple listeners and callbacks remained all holding memory
and keeping referenced elements alive.
Change-Id: I34ae78c95b6dc85eaf2b398a75b0c55a7a7bc047
Fixes: https://github.com/dart-lang/sdk/issues/48399
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/233021
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
`scrollIntoViewIfNeeded` is nested within `scrollIntoView`. The latter
method is outdated and the way to access the different ways to call
`scrollIntoViewIfNeeded`. Instead of using that method, this CL
directly exposes `scrollIntoViewIfNeeded`.
Change-Id: I38d7876a7923768ae165c29a98e514e90182b77e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231047
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/issues/25324
requestFullscreen returns a Promise and takes in an options parameter.
It also can be accessed either via `requestFullscreen` or
`webkitFullscreen` (only necessary for Safari). The bindings should be
updated to reflect this behavior.
Change-Id: I9401b6a1c8b3f9ac370aad8caac8295e0ee358b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/229381
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Adds comments warning against using extension on `dart:html`
classes, and lumps them into a separate section.
Change-Id: Ie3b2bc7cf130b42627ab29354abcc68b0dd7dd1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/224720
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
After chatting offline, we decided we don't actually need
gridRowGap and gridColumnGap since the rowGap and columnGap
properties are the preferred names. Removing the deprecated
grid versions before it becomes a breaking change to do so,
and to keep dart:html bloat minimal.
Change-Id: I75a7de40a4bb1a5479723600987d19e7e42bf69c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/224700
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Riley Porter <rileyporter@google.com>
Updates documentation now that static interop features are
available. This should be the last component before the new
`package:js` version is published.
Change-Id: I9ddb494a5723036ca699bdcf10a000f7670cdfd8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/224401
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Now that JavaScriptObject is the new parent class of the old
JavaScriptObject (now called LegacyJavaScriptObject), web classes
should extend it instead.
Change-Id: I94613177bd073e131bff70d8e00e4e6ae8e8949f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216275
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Updates which characters are allowed in the dataset name based on
external documentation, and removes restriction on not allowing the
name to start with `xml`. These restrictions are not enforced in the
name parsing in `_DataAttributeMap`. Note, there is an additional
restriction in our docs which is inconsistent with external behavior
disallowing capital letters.
Change-Id: I4143503b17673be2e038df8647fef7c9ac09e9ba
Bug: https://github.com/dart-lang/sdk/issues/43295
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219180
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Riley Porter <rileyporter@google.com>
Changes `refChild` to `child` to match parameter name and makes
`insertAllBefore` consistent with `insertBefore`. Also adds a
description of behavior given a null `child`.
Fixes: https://github.com/dart-lang/sdk/issues/46603
Change-Id: I280306018ee16fa9088d55110ef502f49ed1d66a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219122
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Riley Porter <rileyporter@google.com>
The WebSQL standard was abandoned more than 10 years ago and is not
supported by many browsers.
The `dart:web_sql` library was marked as deprecated in Dart 2.14. This
CL makes the library inaccesible, removes support for `dart:web_sql` imports,
and removes the `Window.openDatabase` API. The old code for `dart:web_sql` is
still generated by the html generators. Removing that will be handled by a
separate change.
Closes https://github.com/dart-lang/sdk/issues/46316
Change-Id: I892107396b3b227b4f33344377585aa5e5328288
Bug: https://github.com/dart-lang/sdk/issues/46316
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216080
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Bug: b/195948110
`setAttribute` stringifies any non-string value. `setAttributeNS` is
also similarly modified for consistency.
Change-Id: I883516f5ed2c977cdc591b697594817378607e53
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215621
Reviewed-by: Gary Roumanis <grouma@google.com>
Commit-Queue: Gary Roumanis <grouma@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Migrates syntax and semantics from python 2.7.
Major changes include:
- filters
- sorting
- print statements
- higher-order functions
- hashing and comparison
and other misc changes. go.sh consistently gives the libraries
in this and the previous commits with these changes.
Change-Id: I66365739887158d8f321015d36e556447da1bcd3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211542
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Using a set does not guarantee a consistent order from python 3
onwards, so use a OrderedDict to get a consistent order while
removing any duplicates.
Change-Id: I02d9aae2a82fd119f22b3a5e353b9445ffca963b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211541
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
As part of deprecating support for native extensions we are also
migrating away from legacy VM-specific `native 'name'` syntax
towards metadata based encoding which does not require any special
syntax.
This CL is a step 1 in migration:
- introduces support for `@pragma('vm:external-name', 'name')`
which serves as a direct replacement for `native 'name'`;
- all core libraries and tests are migrated to use the annotation;
Once this CL lands and rolls we will edit internal and external embedders
to eliminate uses of the native keyword (step 2) and finally remove
support for native keyword across our parsers (step 3).
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/28791
Change-Id: Id6dea878db82dd4fd81149243c425b5c5dc6df86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212461
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
