This patch introduces a series of web element abstraction types for
representing web element references.
Adds a series of new types for representing web element references
in Marionette: ChromeWebElement, ContentWebElement, ContentWebFrame,
and ContentWebWindow. The last three are direct representations of
web element, web frame, and web window definitions described in the
Webdriver specification. The first is a custom Marionette type as
we also support retrieving XUL elements from chrome space and must
be considered proprietary.
Each of the classes extend the WebElement abstract type, which is
the primary entry point when unmarshaling JSON input from the client.
Based on the characteristics of the JSON Object, one of the different
concrete types will be constructed.
The purpose of this change is to make marshaling of elements and
WindowProxies easier, both when we receive web element reference
objects from clients and when transporting them over IPC internally.
The WebElement.fromUUID function should be considered a temporary
workaround until we have fixed the current Marionette clients to send
web element reference JSON Objects as input, instead of plain {id:
<uuid>, …} fields.
MozReview-Commit-ID: FGcRq5H1Tzp
--HG--
extra : rebase_source : fe82087e8935adb519e2934fc37f1d46c21d9187
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 91077ee4185b4917f5f67bf7ebe7ea03ca3e7241
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 8086d3b411e9c203784fd3f8b210079d3a251a3d
The dump file isn't in the expected location in firefox tests, but is in
thunderbird tests, so the preference to disable loading wasn't originally
implemented.
MozReview-Commit-ID: HvFqfC69yMQ
--HG--
extra : rebase_source : 1d358292f0ab94299e444f4d3e3454a2259d1a64
Many of the 'test' tasks key the entire 'mozharness' section by-test-platform.
This is bad because:
A) Configuration under 'mozharness' can't be shared across platforms
B) We can't use the 'job-defaults' simplification since merging is naive
Instead of keying the entire 'mozharness' section, this change keys only the
specific configuration that needs it.
MozReview-Commit-ID: EaPlOzsESQ3
--HG--
extra : rebase_source : 12d81013fd4e18403799c92df06f855bf7162a05
Every task that uses the desktop_unittest.py or android_emulator_unittest.py
mozharness scripts needs to pass in either --<suite>-suite=<flavor>, or
--test-suite=<flavor> respectively.
In almost all cases, <suite> and <flavor> are identical to the value that is
already specified under the test['suite'] key. This means we can use a
transform to append these command line arguments and reduce the complexity of
the yaml files.
MozReview-Commit-ID: EaPlOzsESQ3
--HG--
extra : rebase_source : 1fc5523323774ab429f1377880204df51d53ccef
The `rust-lang-ci` S3 bucket is ephemeral. `static-rust-lang-org.s3.amazonaws.com` is not going away soon, but using `static.rust-lang.org` when possible keeps things working if it ever does.
https://internals.rust-lang.org/t/updates-on-rusts-ci-uploads/6062https://internals.rust-lang.org/t/public-stable-rust-services/6072
We’ll still need to find a solution for "alt" rustc builds. In the meantime, this is a step.
Source-Repo: https://github.com/servo/servo
Source-Revision: 041bd626ace013f93fa7fe101c70f36543fc9b0d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : af6533ade663a50e140f1630aef427666617f3ba
We were getting the filter state after dispatching the action, which made
all the filters to have an enabled state. Getting the state before dispatching
fixes the issue.
This patch enhance the Service mock in order to have a better idea of what is going on
with prefs. This allow us to introduce some tests to make sure prefs are updated in
reaction to given actions.
MozReview-Commit-ID: Byay0TwF25I
--HG--
extra : rebase_source : fd9e022c872783e2c6baa6ee0be5bf98f7eced78
This patch adds test cases for testing favicons of allTabs menu in terms of originAttributes.
It adds tests in existing tests, browser_favicon_userContextId.js and browser_favicon_firstParty.js.
The test will open tabs with different originAttributes and trigger the popup of
allTabs menu. Then it will verify that whether the network requests of favicon
have correct originAttributes.
MozReview-Commit-ID: 4Aa7RDFdosA
--HG--
extra : rebase_source : 407c1c356387f9f05e2fca37cd74339521f2d2f2
This goes with a crashtest, as soon as I get a usable build.
MozReview-Commit-ID: LqmPWoJZ7AJ
--HG--
extra : rebase_source : a2f2e4b0b2f3cfa4c0f53bc5110d31f0fb86667f
From https://bugzilla.mozilla.org/show_bug.cgi?id=1408311, reviewed there by Xidorn.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7b61e3b6ee62a96f151483f4fc229fa0c03a54d8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c5a3d2d9b2c644c71590b08cff540e9c89095204
This is the Servo side change of [bug 1397644](https://bugzilla.mozilla.org/show_bug.cgi?id=1397644).
Source-Repo: https://github.com/servo/servo
Source-Revision: b1e6f05ae455748f6091ddf81c1c0488e09546a1
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bccb30f361f44fe3da55d5f4fe7c0cde61550524
This is kind of a band-aid because not all the media features chrome code uses
happen to be banned from content pages. But I'll change that soon.
Meanwhile this fixes scrollbars and such.
MozReview-Commit-ID: IVHljzpxc2z
--HG--
extra : rebase_source : 89329ad8b9991057e906b2d21a8120ed0c1e2b7d
