Cloning a textarea element without a dirty value flag does not call SetValue() and thus gets no max length. This makes sure it always gets one before setting selection range.

Differential Revision: https://phabricator.services.mozilla.com/D99734

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1682313
gecko-commit: 80e51db676d263d2563f2ef10a1c50c617e2853e
gecko-reviewers: masayuki

Differential Revision: https://phabricator.services.mozilla.com/D99632

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1682159
gecko-commit: b90e93c4aa5c76dfe14a05f8e7bcbdfbcc78c24f
gecko-reviewers: edgar

When an HTMLImageElement's 'src' is set to the empty string, the state
of the image request will be 'broken', and thus the promise should be
rejected with an InvalidStateError exception per the rules at [1].

Move the intrinsic size check below the image existence check, and use
a more direct method of getting at the size (no need to go through the
BitmapImageSource interface when we're already fiddling with internals).

Also add a check for IsLoaded() to better match the spec wording
'fully decodable'.

[1] https://wicg.github.io/shape-detection-api/#image-sources-for-detection

Bug: 789511
Change-Id: I69ac4a9081cfff7f9c7c8f7edf39667e3dd1eb4d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2587165
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#837140}

…ascript url

Previous fix(https://chromium-review.googlesource.com/c/chromium/src/+/2181318)
on uninitialized frame policy in javascript url
navigation does not include a test case because it is a security
fix.

Since the fix has landed in M84 which is stable right now, this CL
adds the test case for the fix.

Bug: 1074340
Change-Id: Ia10a972183b02cdac28a2f29cabb7f13caf168e5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2297708
Commit-Queue: Charlie Hu <chenleihu@google.com>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837169}

…m capabilities. (web-platform-tests#26741)

* [wdspec] Session fixture has to deep update custom capabilities.

Differential Revision: https://phabricator.services.mozilla.com/D98459

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1680114
gecko-commit: 6e45b8c280e020d31f69085bf5b77d5b4186ce27
gecko-reviewers: webdriver-reviewers, jgraham

* Fix use of iteritems in WebDriver helpers

Differential Revision: https://phabricator.services.mozilla.com/D99253

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1680114
gecko-commit: d3fa09337a9a4cbf8233e49295baa5e57dbedd57
gecko-reviewers: whimboo, webdriver-reviewers

These APIs have been deprecated since Aug 2018 [1], disabled by default
since Oct 2019 [2], and removed from Origin Trial support since Oct
2020 [3]. This CL removes the code to support these two features
completely.

This is being done in one large CL for two reasons:
 1. It is hard to untangle all of the dependencies of this code to
    be able to land this in multiple CLs.
 2. Doing this in a single CL will allow the effects (progressions,
    hopefully, but we'll see) to be more easily tracked.

[1] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/h-JwMiPUnuU/sl79aLoLBQAJ
[2] https://chromium-review.googlesource.com/c/chromium/src/+/1850795
[3] https://chromium-review.googlesource.com/c/chromium/src/+/2458126

Bug: 937746, 1157927, 1158001
Fixed: 1129465
Fixed: 1157500
Change-Id: I45d77960fa77e2bba3f5b301e3fb7372bb659c4f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2586019
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Reviewed-by: Yu Han <yuzhehan@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837213}

This is a reland of c7326b7f5dd47cddf6ff99d98fd1b7be1f54f922

Canvases may have different color formats than N32, and when we pull
the content of them into a cpu bitmap through SkImage::toLegacyBitmap()
we need to convert that to N32 format if we're going to send the bitmap
over IPC due to security restrictions of the BitmapN32 mojom type.

This does that conversion in the blink ShapeDetector and adds a test with
a float16 color format canvas which would cause the IPC sending to be
dropped (and the renderer to crash).

TBR=dcheng

Original change's description:
> Use skia.mojom.BitmapN32 in Detection mojoms
>
> These bitmaps are safer for transport from untrustworthy sources since
> all bitmaps should be in N32 format and the browser can make bad
> assumptions as a result.
>
> R=dcheng@chromium.org, reillyg@chromium.org
>
> Bug: 1144462
> Change-Id: I7d02cb187c62be37259f445a182f8c971aa03661
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2580483
> Commit-Queue: danakj <danakj@chromium.org>
> Reviewed-by: Reilly Grant <reillyg@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#835685}

Bug: 1144462
Change-Id: I23ef3df85049a7111830c5d272c02b69f9d7cd38
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2593827
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837241}

All functionality related to InputMethodKeyboard* were designed to handle the onscreen / virtual keyboard. The class is not directly related to InputMethods. Hence, should be renamed to VirtualKeyboard*.

Bug: 1158633
Change-Id: I06569bcae62755826bfc7dcf479a29dd90db7175
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2592207
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Darren Shen <shend@chromium.org>
Commit-Queue: Keith Lee <keithlee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837272}

When an offscreen canvas doesn't have a placeholder canvas (such as
when new OffscreenCanvas(width, height) is called to create an offscreen
canvas in javascript), the corresponding C++ object is OffscreenCanvas,
not HTMLCanvasElement. This change obtains the XRSystem object from
the OffscreenCanvas so that MakeXrCompatible can be called on it.

Bug: 1154424
Change-Id: I4fb1c7005a8c3a41cc4ddcd457c81c4bec4464ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2578710
Reviewed-by: Brandon Jones <bajones@chromium.org>
Commit-Queue: Patrick To <patrto@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#837356}

This CL makes a number of improvements:

* It removes the http/https specific assumption that pathnames always
  consist of at least a leading slash.
* Resolve relative pathnames for both patterns and URL input.  This is
  only done if the baseURL is a standard URL with a pathname containing
  slashes.
* Canonicalizes URL input values.
* Validates pattern values are ASCII, but does not perform any encoding
  or canonicalization yet.

Bug: 1141510
Change-Id: I6db1afe77f6dd1d15ccb2e96a51412a31257efba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2579989
Commit-Queue: Ben Kelly <wanderview@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837371}

This CL add the logic, for both Legacy and LayoutNG, for handling
trailing ideographic spaces when the white-space CSS property is set to
'break-spaces' value.

The CSS Text specification states [1] that we must prevent handing or
collapsing the advance width of any space, including other space
separator like ideographic spaces, hence the overflowing spaces must
wrap to the next line.

However, the spec also states in the description of the 'break-spaces'
value [2] that breaking opportunities exists 'after' any space; hence,
breaking before the first ideographic space of the sequence is not
allowed, so it may overflow in that case.

[1] https://drafts.csswg.org/css-text-3/#white-space-phase-2
[2] https://drafts.csswg.org/css-text-3/#valdef-white-space-break-spaces

Bug: 1155633
Change-Id: Id34f05cb3457516fcb20a4731606425ec943a255
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2584854
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837379}

…tform-tests#26918)

Executing a javascript: URL does not commit a new document, and
executing a javascript: URL in a srcdoc iframe does not change the
fact that this is a srcdoc iframe. (cf
https://crrev.com/c/2464930). On the other side, the algorithm for
computing the referrer of a srcdoc iframe defers to the parent:
https://w3c.github.io/webappsec-referrer-policy/#strip-url

Bug: 1043895
Change-Id: I144aa288204f9e92d1b41b0f3c64bc0d6274f10f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2582045
Reviewed-by: David Van Cleve <davidvc@chromium.org>
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837504}

When parsing a referrer policy from a meta tag, we were trying to
update the PolicyContainer (and with it, the PolicyContainerHost in
the Browser process) without checking for it not to be
nullptr. However, the PolicyContainer is nullptr for LocalFrames which
have no RenderFrameHost counterpart in the browser, which are used for
rendering SVG images. As a consequence, there are cases in which a
meta tag in an SVG image made the renderer crash.

This change adds a nullptr check to fix this.

Bug: 1158034, 1130587
Change-Id: Ia0b5c51b4d1d68cfd7329da8c5e153bdef7deb3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2593000
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837507}

…e/panner-distance-clamping.html (web-platform-tests#26926)

Make sure the test prints its PASS lines in a consistent order to address flakiness as part of the
WebKit test suite.

Co-authored-by: Chris Dumez <cdumez@apple.com>

We should ignore layout shift if the object was ineligible for layout
shift tracking during the previous paint invalidation. Add
LayoutObject::ShouldSkipNextLayoutShiftTracking() and set it during
paint invalidation if the object is ineligible for layout shift
tracking. In the next paint invalidation, if the flag is true, skip
layout shift tracking and reset the flag.

This also applies to content-visibility:auto for which we cleared
LayoutBox's previous size to prevent layout shift tracking for the next
cycle. The new flag is basically equivalent to the old method, but also
covers more cases, e.g. the old method would fail if the object had
visual overflow because PreviousPhysicalVisualOverflowRect() was not
based on PreviousSize() and empty.

Bug: 1152869
Change-Id: I000489dd8093dab8d2ab3605ad4ce3bd39fd11b0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2591367
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837627}

…tem-focus.html (web-platform-tests#26845)

* Add html/interaction/focus/document-level-focus-apis/document-has-system-focus.html

* Ensure document has focus as precondition.

* Try to have popup steal focus in more browsers.

* Move event handlers earlier to avoid possible race.

This CL rewrites the tests contained in charset-tests.html,
chromium-tests.html,and comma-tests.html.

It also creates httpCookieTest (inside cookie-test.js) and rewrites
tests to use it.

The idea is that we probably want to have a domCookieTest in the future,
and this will make it less messy.

Relates to web-platform-tests#26190

Bug: 1152798
Change-Id: If5fa785b5b14c2596445ab1c7ac0926209f04314

Co-authored-by: Mike Taylor <miketaylr@chromium.org>

Source: https://github.com/w3c/webref/blob/5360e8c/ed/idl/mediastream-recording.idl
Build: https://travis-ci.org/w3c/webref/builds/209181719

This is part of adding type reflections to the WebAssembly JS-API. This
adds a new property on the WebAssembly.Memory, WebAssembly.Table &
WebAssembly.Global objects. It exposes the current type or the object in
a format which is compatible with the constructor for type's
constructor.

Differential Revision: https://phabricator.services.mozilla.com/D90702

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1651725
gecko-commit: dff33d0b33c8fb168966504f5562572ddec72a8e
gecko-reviewers: lth

Change "p3" color space to "display-p3". This is the name used in the
specification and in the CSS color level 4 specification (which is
shipping on Safari). Of note is that is that the color gamut media
queries use "p3" instead of "display-p3". This could be intentional
(reflecting the P3 *primaries* common to DCI P3 and Display P3 *color
spaces*), or may be accidental.

Change ImageDataColorSettings to ImageDataSettings. Right now all of
the settings are for color, but the spec doesn't put color in the name
because of future plans to add other settings (like premultiplied
alpha).

The largest remaining inconsistency is that "pixelFormat" versus
"storageFormat" and "uint8" versus "unorm8".

R=yiyix
TBR=fserb

Bug: 1083693
Change-Id: I8e6d476a17fd2fca8da6b7901bb1098253a61559
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2594269
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Yi Xu <yiyix@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837682}

Bug: 1152869
Change-Id: Ie68a761a3cd2a81dcdd3de6d2469d64146c3f596
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2591907
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837687}

The offsets stored in NGLink are "paint offsets", which include any
offsets caused by relative positioning. The fragment builder, on the
other hand, expects "layout offsets", which shouldn't include that. The
fragment builder adds the relative offset on its own at the right time.

I struggled with coming up with a very sensible test, since
fragmentation of out-of-flow descendants is incorrectly affected by the
inset specified on their relatively positioned containing block (see
crbug.com/1158387 and crbug.com/1158756 ).

Bug: 1079031
Change-Id: I803dd89a11be2ba9179e20ea06d0b709d08ab534
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2593005
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837692}

The block size may be a percentage, in which case we would think the
extent is definite on the final pass through this function, even if
it is an indefinite percentage. Fix this by using BlockLengthUnresolvable.

R=ikilpatrick@chromium.org, mstensho@chromium.org

Bug: 1154572
Change-Id: Ia70dc730d4fee2005904942afa4020f9074f4eee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2595248
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Auto-Submit: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837699}

This used to crash, because we ignored layout abortions on floats,
and would attempt to use the fragment (which is nullptr).

Bug: 829028
Change-Id: I04c44030d33182fd3020e8091228668d7f8a7190
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2592805
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837713}

This used to fail a DCHECK when nested multicol was specified on a
fieldset at an outer fragmentainer boundary, but apart from that, it
worked fine, because BreakBeforeChildIfNeeded() correctly detects the
situation (abortion) and inserts a break before. Just move the DCHECK a
bit down.

No code changes are required for legends, as they are monolithic. Just
replace the TODO with a proper comment, and keep the DCHECK (the legend
test also passes without the code changes in this CL).

Bug: 829028
Change-Id: I62bf97f9bd04c185f86e93103f204cc6d872c438
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2595288
Reviewed-by: Alison Maher <almaher@microsoft.com>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837755}

This CL adds an explicit [Exposed=(Window,Worker,Worklet)] declaration
to the ReadableStreamDefaultController WebIDL file as it was added
in a new version of the Streams spec, based on whatwg/streams#963.

Intent To Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/yZuxrW9zhAs/m/6bXDaW2mAwAJ

Bug: 1093862
Change-Id: I2bd0c759d856c176037231adbe7e679ccea945c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2570755
Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Nidhi Jaju <nidhijaju@google.com>
Cr-Commit-Position: refs/heads/master@{#837841}

Before this patch, <input type=checkbox> and <input type=radio> can be
left in an active state if you press the spacebar down to toggle it, and
then press tab to move focus away before releasing the spacebar.

This patch calls SetActive(false) on the blur event for these input
types, which clears the active state in this case.

The test uses test_driver.Actions(), which isn't supported by the layout
test runner but works just fine in the separate wpt runner in the wpt
github repo.
I wrote the test and verified that it works well with the separate wpt
test runner, then wrote a TestExpectations line against the bug to track
the issue with the layout test runner: crbug.com/893480

Fixed: 1157510
Change-Id: I13a0900277dbfccc87ba81ffd684b12430665e10
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2594107
Reviewed-by: Mason Freed <masonfreed@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#837867}

Bug: 1085129
Change-Id: I16ee23ac320300b2e408aca4b8a4873b1f1594ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2624674
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#842621}

This is in preparation for use of JS modules within the tests. They
share some library code with external bluetooth WPT, and that code will
soon use JS modules.

Bug: 1004256
Change-Id: I0817dde4216fa43287cde2788edf5c324cf47fe2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2622578
Commit-Queue: Ken Rockot <rockot@google.com>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Auto-Submit: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#842683}

Bug: 1004256
Change-Id: I3b2b26128d0dce591fefe323a730b827e160bb70
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2618679
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Michael Moss <mmoss@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#842698}

Previously we'd just use the intrinsic block-size to resolve gaps, and
abs-pos containing rects when we didn't know the block-size upfront.

This was slightly incorrect as there might be a min/max size constraint
growing or shrinking this final size.

This patch moves the call to ComputeBlockSizeForFragment into
PlaceItems. As a result of this there are a few small fixes:
1) When we have an indefinite available-size, we resolve the grid-gap
   against zero. (This was surprising to me grid-gutters-{010,011} was
   testing this).
2) Abspos "default" size is correctly calculated based on the final
   block-size (not intrinsic block-size).
3) Resolving gaps against the "resolved" available block-size (not the
   intrinsic block-size). This correctly respects border/padding as
   well.

Bug: 1045599
Change-Id: I6be819b8eb254fe9e8eaee4d5a9caaa500a75601
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2624032
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Kurt Catti-Schmidt <kschmi@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#842748}

…hen snapping.

…d proximity snap modes

It would be better to clarify an expected behavior how CORS behaves for
WebBundle subresource loading in the current implementation.

Note that
- The expected behavior is a tentative decision, which might
  change in the future. The spec side issue is
  WICG/webpackage#609.
- A |crossorigin| attribute is not supported yet.

BUG=1149816

Change-Id: Ic104ec039a07f864b6a60452ff42f2ec09a03c2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2617167
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#842863}

Found this while creating web-platform-tests#27129.

It looks generate-test-wbns.sh fails with two errors:

1. nested/resource.js is missing
2. cors/resource.json is wrong. It should be cors/resource.cors.json

BUG=1082020

Change-Id: I18a87f59784d6c36e050a64567c1ba671af0468a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2627209
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#842933}

A recent bug [1] showed that in SkiaRenderer, it was possible for a
backdrop-filter element to blend pixels from a neighboring (but not
underlapping) render pass, due to some clipping issues. This test
checks for this situation.

The original bug was fixed in [2], but I verified that this test
breaks pre-[2] (see patchset 1 of this CL).

[1] https://crbug.com/1162743
[2] https://chromium-review.googlesource.com/c/chromium/src/+/2611452

Bug: 1162743
Change-Id: I86d00d9831057ace40476d29848c11ba1b671a82
Fixed: 1165868
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2625156
Auto-Submit: Mason Freed <masonfreed@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#843000}

Test establishing a Bidirectional Session capability support

There was an error from tools/third_party/pytest/src/_pytest/assertion/rewrite.py
about missing _pytest._version module.
I commented out the import and hardcoded the version to 6.1.1

Test connecting to ChromeDriver session using websockets
and send a message in async/await style

1. Added a BidiSession class in webdriver client that will preset
capability for websocket connection. Created async versions of
start and end for the class to handle establishing and closing
websocket connection.
2. Modify session fixture to take an extra boolean argument "bidi"
for creating bidi session. Change the fixture to async and use
await when dealing with bidi session start/end.
3. Set event loop scope to session(assuming it would reuse the same
event loop for all tests) to avoid event loop is closed error when
closing websocket connection.
4. Added tests for different bidi/classic session creation scenario
and tested connect/send/close.

…kets

git-subtree-dir: tools/third_party/pytest
git-subtree-split: 0ad20b533ffc52ced7bb1a03fba664615e90c093

…rd_party/pytest'

…rsion'

git-subtree-dir: tools/third_party/pluggy
git-subtree-split: b1b07a309653a42a5311810f71d0addd09a4ec81

…rd_party/pluggy'

git-subtree-dir: tools/third_party/iniconfig
git-subtree-split: 4e20f6bcdef72a2ffef1f811a4540778da60733b

…rd_party/iniconfig'

git-subtree-dir: tools/third_party/websockets
git-subtree-split: 139085fe2624192a5a6c72b1e5db211dcec6ced1

…rd_party/websockets'