Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298

Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1941083
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumik@intel.com>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Commit-Queue: Leon Han <leon.han@intel.com>
Cr-Commit-Position: refs/heads/master@{#720803}

Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1941083
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumik@intel.com>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Commit-Queue: Leon Han <leon.han@intel.com>
Cr-Commit-Position: refs/heads/master@{#720803}

…RecordInit#data, a=testonly

Automatic update from web-platform-tests
[webnfc] Do not use 'any' to define NDEFRecordInit#data

Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1941083
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumik@intel.com>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Commit-Queue: Leon Han <leon.han@intel.com>
Cr-Commit-Position: refs/heads/master@{#720803}

--

wpt-commits: 0ac244337ec64d16f50eb9fe8202413e76ec58c1
wpt-pr: 20527

…RecordInit#data, a=testonly

Automatic update from web-platform-tests
[webnfc] Do not use 'any' to define NDEFRecordInit#data

Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1941083
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumik@intel.com>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Commit-Queue: Leon Han <leon.han@intel.com>
Cr-Commit-Position: refs/heads/master@{#720803}

--

wpt-commits: 0ac244337ec64d16f50eb9fe8202413e76ec58c1
wpt-pr: 20527

…RecordInit#data, a=testonly

Automatic update from web-platform-tests
[webnfc] Do not use 'any' to define NDEFRecordInit#data

Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1941083
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumikintel.com>
Reviewed-by: Yuki Shiino <yukishiinochromium.org>
Commit-Queue: Leon Han <leon.hanintel.com>
Cr-Commit-Position: refs/heads/master{#720803}

--

wpt-commits: 0ac244337ec64d16f50eb9fe8202413e76ec58c1
wpt-pr: 20527

UltraBlame original commit: 84a97b774d4b8cbcd1c9ea0e1d5bc43a0e811d8b

…RecordInit#data, a=testonly

Automatic update from web-platform-tests
[webnfc] Do not use 'any' to define NDEFRecordInit#data

Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1941083
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumikintel.com>
Reviewed-by: Yuki Shiino <yukishiinochromium.org>
Commit-Queue: Leon Han <leon.hanintel.com>
Cr-Commit-Position: refs/heads/master{#720803}

--

wpt-commits: 0ac244337ec64d16f50eb9fe8202413e76ec58c1
wpt-pr: 20527

UltraBlame original commit: 84a97b774d4b8cbcd1c9ea0e1d5bc43a0e811d8b

…RecordInit#data, a=testonly

Automatic update from web-platform-tests
[webnfc] Do not use 'any' to define NDEFRecordInit#data

Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1941083
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumikintel.com>
Reviewed-by: Yuki Shiino <yukishiinochromium.org>
Commit-Queue: Leon Han <leon.hanintel.com>
Cr-Commit-Position: refs/heads/master{#720803}

--

wpt-commits: 0ac244337ec64d16f50eb9fe8202413e76ec58c1
wpt-pr: 20527

UltraBlame original commit: 84a97b774d4b8cbcd1c9ea0e1d5bc43a0e811d8b

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: François Beaufort <beaufort.francois@gmail.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/main@{#925263}

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: François Beaufort <beaufort.francois@gmail.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/main@{#925263}

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: François Beaufort <beaufort.francois@gmail.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/main@{#925263}

…at can be nested., a=testonly

Automatic update from web-platform-tests
nfc: Limit amount NDEFMessage objects that can be nested.

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: François Beaufort <beaufort.francois@gmail.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/main@{#925263}

--

wpt-commits: d02695a83d483670b3cef6f2c6e492f698212700
wpt-pr: 30896

…at can be nested., a=testonly

Automatic update from web-platform-tests
nfc: Limit amount NDEFMessage objects that can be nested.

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: François Beaufort <beaufort.francois@gmail.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/main@{#925263}

--

wpt-commits: d02695a83d483670b3cef6f2c6e492f698212700
wpt-pr: 30896

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: François Beaufort <beaufort.francois@gmail.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/main@{#925263}

…RecordInit#data, a=testonly

Automatic update from web-platform-tests
[webnfc] Do not use 'any' to define NDEFRecordInit#data

Use the following union type instead of 'any' to define
NDEFRecordInit#data.
"
typedef (DOMString or BufferSource or NDEFMessageInit)
  NDEFRecordDataSource
"

The spec change:
w3c/web-nfc#454

BUG=520391

Change-Id: Ic917be001d5e3502caeea29ff4a3401ff7197298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1941083
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumik@intel.com>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Commit-Queue: Leon Han <leon.han@intel.com>
Cr-Commit-Position: refs/heads/master@{#720803}

--

wpt-commits: 0ac244337ec64d16f50eb9fe8202413e76ec58c1
wpt-pr: 20527

…at can be nested., a=testonly

Automatic update from web-platform-tests
nfc: Limit amount NDEFMessage objects that can be nested.

Implement w3c/web-nfc#621, which adds a
hard-coded maximum of 32 NDEFMessage objects that can be in the same
chain.

w3c/web-nfc#454 (and
https://chromium-review.googlesource.com/c/chromium/src/+/1941083 on the
implementation side) ended up creating a cycle between
NDEFRecordInit.data and NDEFMessageInit, as the former can be an
NDEFMessage, which could have one or more entries pointing to the same
NDEFRecordInit. Recursion in Web IDL dictionaries are disallowed, so
this change also fixes some invalid IDL that was present in the spec and
our IDL file.

This CL attempts to optimize or modify other parts of the code as little
as possible, but the the change ended up being a bit big mainly due to
two things:
- Since NDEFRecordInit.data's type is now `any`, we need to do more type
  conversions ourselves in NDEFRecord that we used to get for free when
  using IDL unions. This means attempting to convert a V8 value into one
  or more C++ types and accounting for conversion failures.
- In order to do the above, we need access to v8::Isolate, so several
  functions in NDEFRecord that used to take an ExecutionContext needed
  to be changed to take a ScriptState instead.

The usage of ScriptState and the need to perform multiple type
conversions also caused NDEFReadingEvent's constructor to start
passing one to NDEFMessage, which at the end causes the NDEFRecords
that may get created to contain a proper `lang` attribute rather than
null. This is a user-visible change, but I could not find anything in
the spec supporting the previous behavior.

Bug: 1242274
Change-Id: Ia4de230ea45f63f903760865bf85594f79da9eb7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3169656
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: François Beaufort <beaufort.francois@gmail.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/main@{#925263}

--

wpt-commits: d02695a83d483670b3cef6f2c6e492f698212700
wpt-pr: 30896