The deque file was removed in favour of an external crate.
The sync and sync_css directories are automatically created when updating the
in-tree copies of the wpt and css tests.
Source-Repo: https://github.com/servo/servo
Source-Revision: 25c6c29a27d2a176a967ee49d97a29ad1d3a140e
Currently if Servo is built using Cygwin, it is incorrectly classified as "unknown" host, which makes downloading Rust and Cargo fail. This pull request fixes that.
Source-Repo: https://github.com/servo/servo
Source-Revision: 31bdcbe7258cfa796b88505f5e29d75920e5c708
This brings performance improvements and fixes a bug which was causing some progressive JPEGs to fail decoding.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4f08caa5a686c5ccf078c84cdf2fe459a3784f37
Fixes#8100, where sites in the hsts list were not recieving secure
cookies if the site was originally loading using a plain http url.
Source-Repo: https://github.com/servo/servo
Source-Revision: 162e89d8c6f19204e653b8d1fa83663ee710be15
There is no real reason to put this in an extension trait.
Source-Repo: https://github.com/servo/servo
Source-Revision: ebe7d9ebfb28d484ff0cce4e70cb8809f5867af5
This should enable Cargo to reuse more build artifacts between servo and geckolib.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5fbed88248069f1943399d28885249ee0adc89b2
Following having finished making Fetch asynchronous, response.body should be set asynchronously, since it's the major goal of calling Fetch. So far, I've made the body wrapped in Arc<Mutex<>>, and I've wrapped a new thread around the part where it's set. I've also discovered that the fetch_async function makes step 8 of Main Fetch obsolete, and I've commented it appropriately.
I'm currently having a hard time with the thread for setting response.body, though. @jdm suggested I have the body set continually, block by block, but my implementation for that runs so slow that I can't finish running my fetch test suite in reasonable time. @KiChjang pointed out that a lot of the lag is due to how response.body currently stores everything inside a Vec. Changing the storage container seems to be both necessary and beyond the scope of the time I have to work on this.
Source-Repo: https://github.com/servo/servo
Source-Revision: fee7cb179ee7ba2f159d87af07afaf0cd99a2161
While working on #8351 I discovered that deprecated fs::walk_dir is used in android support files.
This is my first PR to any Rust project, so any constructive feedback is more than welcome!
Thanks
Source-Repo: https://github.com/servo/servo
Source-Revision: dedae5e459724d32ada7d3f4e33d8533bddb43fa
This makes the experience for testing browserhtml super easy.
Source-Repo: https://github.com/servo/servo
Source-Revision: 69f52d0f213aeec0d498798dfdaa15f8459a9a79
One of the ways that generated code differentiates constructors is by comparing if the args are array-like. The generated code was calling a function `IsArrayLike` that no longer exists. I re-implemented it with a more rust-like naming scheme.
Source-Repo: https://github.com/servo/servo
Source-Revision: c37a0866608421d9e3afd67f0777e27091104f0f
This was originally #9428 but got accidentally reverted during rebase in
Fixes#9865.
Source-Repo: https://github.com/servo/servo
Source-Revision: 12466b87062d8a20bd134bdd5824d46c5216ee48
Previously, the flow for ticking animations was:
Compositor -> Constellation -> Layout -> Script
However, this means that the compositor <-> layout messages can thrash, meaning layout thread is very rarely idle.
This means that the script thread (which joins on the layout thread during reflow) was unable to execute and run rAF callbacks.
With this change, the flow is now:
Compositor -> Constellation -> Script (when rAF is active).
Compositor -> Constellation -> Layout (when transitions / animations are active and no rAF is present).
This makes rAF based animation *much* smoother.
Source-Repo: https://github.com/servo/servo
Source-Revision: aba500a698584e66975cd93006ca8cf745370f7d
This fixes a bug where partially loaded content is displayed to the user
before it should be, usually before stylesheets have loaded. This commit
supresses reflows until either FirstLoad or RefreshTick, whichever comes
first.
Source-Repo: https://github.com/servo/servo
Source-Revision: 37bcc161fe45bf8c1cb1172b8e0d12c7d03371b6
Flat display lists were a 2x regression on the spheres demo. This patch series fixes that.
See the individual commits for more details.
r? @mrobinson
Source-Repo: https://github.com/servo/servo
Source-Revision: 55fc48e4c46917a0f036d0054fac296bb5719434
Now we only query for the topmost node, and apply the hover state to all
of the parent elements.
This fixes things like #9705, where the hover state was applied only to
the children.
This also makes us more conformant with other browsers in the case of
taking in account margins and paddings.
For example, prior to this PR, when your mouse was over the inner
element, in the bottom part, `hover` styles didn't apply to the parent.
```html
<style>
div {
padding: 10px;
margin: 10px;
height: 15px;
background: blue;
}
div:hover {
background: red;
}
</style>
<div>
<div></div>
</div>
```
Fixes#9705
Source-Repo: https://github.com/servo/servo
Source-Revision: 056a7cf1a2284063e5d32c6627b86f6931957a74
It was introduced in 4dc9d8b1c5a4e68eee09af547ae7069455c9abe9.
Source-Repo: https://github.com/servo/servo
Source-Revision: de7c67575e5cfe71578d226026484da5c6de8707
The main reason stb_image was used for decoding JPEGs was the lack of progressive support in piston_image.
With version 0.7, piston_image gained support for decoding progressive JPEGs through use of the [jpeg-decoder](https://crates.io/crates/jpeg-decoder) crate.
This PR removes the dependency on stb_image and instead uses piston_image 0.7 for decoding JPEGs.
Source-Repo: https://github.com/servo/servo
Source-Revision: a8c321a7e0402bcfc8d8da10cc94a5b287d29ffc
Instead of producing a tree of stacking contexts, display list
generation now produces a flat list of display items and a tree of
stacking contexts. This will eventually allow display list construction
to produce and modify WebRender vertex buffers directly, removing the
overhead of display list conversion. This change also moves
layerization of the display list to the paint thread, since it isn't
currently useful for WebRender.
To accomplish this, display list generation now takes three passes of
the flow tree:
1. Calculation of absolute positions.
2. Collection of a tree of stacking contexts.
3. Creation of a list of display items.
After collection of display items, they are sorted based upon the index
of their parent stacking contexts and their position in CSS 2.1
Appendeix E stacking order.
This is a big change, but it actually simplifies display list generation.
Source-Repo: https://github.com/servo/servo
Source-Revision: 62814f7cb486bc267a796b7ce58c51d59240fad0
Two related fixes for border-collapse:
* Fix border collapsing across table-row-group flows
This fixes the border-end calculation for table rows whose borders are collapsed with rows in different rowgroups. The border collapsing code now uses an iterator that yields all the rows as a flat sequence, regardless of how they are grouped in rowgroups. It gets rid of `TableRowGroupFlow::preliminary_collapsed_borders` which was never correct. (It was read but never written.)
This may fix#8120 but I'm not 100% certain. (I haven't managed to reproduce the intermittent failure locally, and my reduced test case still fails but in a different way.)
* Fix confusing `push_or_mutate` API
This fixes a bug when recalculating border collapsing for an existing table row. The bug was caused by using `push_or_mutate` which has no effect if there is already a value at the specified index.
The fix switches incorrect `push_or_mutate` calls to use `push_or_set` instead. It also renames `push_or_mutate` to `get_mut_or_push` which I think is a less-confusing name for this method.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 1d6aece589410e13d9773d702f4426d3e197155c
I'm working on making it possible to run Fetch Asynchronously, as required for some steps, such as Main Fetch. It looks like somebody has already laid some groundwork for that, with a AsyncFetchListener trait and two async fetch functions defined, which I'm building on top of.
So far, as a sort of proof of concept, I've written a test to asynchronously retrieve a fetch response, which uses a simple function to check if the fetch response is complete or not. I'd like to be checked if I'm on the right path, to see if I need to rework anything so far, and what my next step can be.
Source-Repo: https://github.com/servo/servo
Source-Revision: 22ce878edc22360af7391694efc9e5668116d3fb
Ms2ger
Wei Tang
Ulf Nilsson
Glenn Watson
Bob
Anthony Ramine
York Xiang
Suvish Varghese Thoovamalayil
UK992
Simon Sapin
Arpad Borsos
Nikki
Rahul Sharma
Cengiz Can
Manish Goregaokar
Ravi Shankar
Lars Bergstrom
Jack Moffitt
Bobby Holley
Peter
Patrick Walton
Corey Farwell
Emilio Cobos Álvarez
Martin Robinson
Gregory Malecha
Matt Brubeck