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
After data delivery for a request has been retargeted, there's no reliable way
to get the appropriate event target to re-dispatch data events after
asynchronous processing.
While it's technically possible to retrieve the current thread from
OnDataAvailable callbacks and re-use that for later dispatch, that approach
has some issues:
1) It's not currently possible to reliably map the current thread to the
thread pool that owns it. That means that if data delivery is being targetted
to a thread pool, attempts to redispatch events to the previous delivery
thread might lead to long delays when one thread in a pool is blocked.
2) If a filter wishes to dispatch data events to the wrapped listeners before
it's recieved any data (as extensions StreamFilters sometimes do), there's no
way to determine the proper event target without waiting for initial data to
be received.
Simply returning the correct event target from the request solves both of
these problems.
MozReview-Commit-ID: CJxq7O4399R
--HG--
extra : rebase_source : db2f659ecad16daafdbcc108d7b1a51ea1af31f9
Geoff Brown
Dragana Damjanovic
Masayuki Nakano
Nevin Chen
Martin Robinson
Jeremy Chen
Sebastian Hengst
ffxbld
Joel Maher
Randell Jesup
Kris Maglione
Gabriel Luong
David Major
Jan de Mooij