Fixes problem with the initial computed value of font-family
being empty and not matching the later value in
test_value_storage.html.
MozReview-Commit-ID: HOHvMZPP1GD
Many tests rely on the minimum size of widgets to
be set. Also, the precise size seems to matter for some
tests that have hard coded offsets.
MozReview-Commit-ID: BglZD1cKdY9
This better emulates a window manager and triggers the
required activated/deactivated events on the proper windows as
they are closed or hidden.
MozReview-Commit-ID: 1A2JTp8i4VE
This version of the sdk download is based on the previous one but includes
a new version - 1.0.39 - of adb and eliminates some files not used by the
emulator (smaller, faster download). By including adb in the sdk download used
for the emulator, the tools sdk download can be eliminated.
Since if the container is not a container node like a text node or the offset
is same as the length, child at the offset can be nullptr.
MozReview-Commit-ID: DCnFwUjNgk7
--HG--
extra : rebase_source : 48823390645d79db391dcaf64dab59e754b680a5
|selChild| should be a node which is at |curOffset| in |curNode|, however,
it's not updated when |curOffset| is updated by a call of CreateBRImpl(). So,
it should be next sibling of the created br node.
MozReview-Commit-ID: IVfTjVMp3lB
--HG--
extra : rebase_source : fbc355e3c0425a495c78c3c028308dac26617283
Please see attachments in the bug for details where the strings are.
MozReview-Commit-ID: KUv79x7O0UW
--HG--
extra : rebase_source : 75be4f9f9dd61845f5e6b23a532e4417ca962494
Anonymous nodes were previously creating duplicate stacking contexts,
one for each node in the anonymous node chain. This change eliminates
that for tables.
Additionally the use of stacking context ids based on node addresses is
no longer necessary since stacking contexts no longer control scrolling.
This is the first step in eliminating the dependency between node
addresses and ClipScrollNodes which causes issues like #16425.
<!-- 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: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they are covered by existing tests.
<!-- 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: 865b9aea357d4b51696d4a0343521a0f2a20bcf1
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f732d8c55cc80ae35de430a34fb51e9856e34839
The layout.css.stylo-blocklist.blocked_domains pref is set to "arewestyloyet.rs"
on Nightly, but empty string on Beta. Since we're going to QA the styloblocklist
add-on in Bug 1407911, we make the prefs aligned in both Beta and Nightly in this
patch.
MozReview-Commit-ID: HoleJvVYm7o
--HG--
extra : rebase_source : cb8104f3d7fdb99fe0ea6ee84781c4b421a8f421
In cases where data transfer finishes immediately after we close a request, we
can sometimes wind up overwriting that state information with
"finishedtransferringdata", which allows scripted callers to break certain
invariants and cause crashes.
MozReview-Commit-ID: Do3GttF3M9S
--HG--
extra : rebase_source : 22ef41b1655641fb5f73034d076f3bb6e148a626
extra : absorb_source : 5ca805e93d4d5feed9a5bd7e7f292104cd1bdd11
It currently isn't possible to suspend a channel from onHeadersReceived for a
cached response. And since it's not possible to add a new stream filter after
a response has started, adding a stream filter at that point will crash if the
channel is still registered.
This test is a basic sanity check for that scenario.
MozReview-Commit-ID: ALYUtxX7mci
--HG--
extra : rebase_source : 120889fd8f9edd097a7dae807b54eb3fd283f0f6
Our current StreamFilter code doesn't behave well when data delivery is
targeted to a thread pool, rather than a single thread.
Thread pools don't guarantee ordered processing of events. It's theoretically
always possible for multiple events dispatched to a pool to be processed in
parallel, or even slightly out of order.
For the most part, this should only be a theoretical concern, unless several
data events are dispatched at the same time, and the pool has enough available
threads to service all of them (which is an unlikely scenario in this code).
However, when data delivery is targeted to a thread pool, the OnDataAvailable
callbacks do not have access to the thread pool itself, only the thread that
the callback was dispatched to. This means that after each OnDataAvailable
call, we likely store a new IO thread, and writes end up queued to a different
single thread depending on exactly when they happen.
Threads in thread pools often wind up executing long-running runnables, such
as synchronous IO or network operations. Which means that we introduce
arbitrary delays for some writes, and are likely to wind up with highly
arbitrary ordering.
This patch solves both of these problems by introducing strict event queue
ordering, and also dispatching IO events to the original explicit delivery
target, rather than whatever the current thread happened to be at the time of
the last data event.
MozReview-Commit-ID: 1SdYjS6ltqw
--HG--
extra : rebase_source : a92aeff88b21ad41f2eef71a732fdf60f447789a
