Makes multiple `<br>` elements work, since those are implemented via
`before` pseudos.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 15b508ac10d0e98ba10474b6ab091017ae95804e
Layers are currently all children of the root layer, so instead of
using coordinates relative to the parent flow we should use coordinates
relative to the page.
Fixes#2061.
Source-Repo: https://github.com/servo/servo
Source-Revision: eff0de0ce12b20ffc4806d14c95777004003f2ae
Should probably use HashMap::entry() but that doesn't seem to be available with servo's current rust snapshot.
r? @Ms2ger
Source-Repo: https://github.com/servo/servo
Source-Revision: a127fcd854ae0e31d05f34232f595833ccc2ba9e
Note that using `servo --devtools http://example.org` doesn't work. In
that case either the port must be specified or the option moved to the
end. But this is the same for other such options, e.g. `--profile`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9be266270b2e8d00f4cec0f1b262efce85913640
This implements basic support for attribute selectors with namespace prefixes. I would have added a more sophisticated test covering various selectors but it seems that we don't have an XML parser yet and thus no XHTML support?
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: f49c730720a51d14dacefe9815faf50216b36b91
When we want to use Servo binaries outside of their `target` build directory, `./resources` is what we’ll need to ship with them.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 8312fde154768c4a5ce133a1aaaf1293529a5558
--HG--
rename : servo/tests/html/failure.html => servo/resources/failure.html
rename : servo/components/style/user-agent.css => servo/resources/user-agent.css
Some pages, like Google, want to set height explicitly.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 543f11b62b9da6a5362f96e5c85f660ee68acf76
The Mach test runner doesn't actually make these failures yet, which is
tracked by #3482.
Source-Repo: https://github.com/servo/servo
Source-Revision: ae946a9b762d66f01f669ff526eff5c0eaaa3404
I would have put the attribute on the binding itself, but that doesn't
appear to be possible yet.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1aa13bb31f0f1fbd8a7ac663634a222903681af9
This should make it clearer that we always pass a URL to Document::new, and
avoids an unnecessary unwrap() call.
Source-Repo: https://github.com/servo/servo
Source-Revision: 06489fcc426ca65e807ea13d0d8fcf23bee3ca75
The ScriptTask is owned by the proc in ScriptTaskFactory::create.
We started using a managed box for what would eventually become ScriptTask in
d21d27e08633b6a7f2b774a28c65c81d1eedbeaf.
Source-Repo: https://github.com/servo/servo
Source-Revision: f60e985e6b1c401730306acaf2b84152cdc7d0aa
Now that we use `JSTraceable` (defined in `script`), we can create arbitrary implementations on non-`script` types (eg `Url` or `RequestHeaderCollection`) where in the past we had to rely on `Traceable` and `Untraceable` to achieve cross-crate impls of `Encodable`.
This removes the two completely. They can be reintroduced if required, though the `untraceable!` macro should suffice.
Fixes#3469
Source-Repo: https://github.com/servo/servo
Source-Revision: b34df7c343579f200d2e67e21fc566842a4e4a91
The page_rect passed to DisplayListOptimizer is relative to the
RenderLayer origin, but the display list components are relative to the
page origin. Before passing the page rect to the display list, we
translate it by the RenderLayer position.
Source-Repo: https://github.com/servo/servo
Source-Revision: a6cd13c89054b605e1000bc3475153fbd2fde7bf
This allows setting Android toolchain paths in `.servobuild`, and also adds a `--android` option that sets the correct default target and causes `mach build` to also build the APK.
Source-Repo: https://github.com/servo/servo
Source-Revision: bf7beb4837246aa53f611492b1ff0986f221a47e
Although the computed `display` property of elements with `position:
absolute` is `block`, `position: absolute; display: inline` can still
behave differently from `position: absolute; display: block`. This is
because the hypothetical box for `position: absolute` can be at the
position it would have been if it had `display: inline`. CSS 2.1 §
10.3.7 describes this case in a parenthetical:
"The static-position containing block is the containing block of a
hypothetical box that would have been the first box of the element if
its specified 'position' value had been 'static' and its specified
'float' had been 'none'. (Note that due to the rules in section 9.7 this
hypothetical calculation might require also assuming a different
computed value for 'display'.)"
To handle this, I had to change both style computation and layout. For
the former, I added an internal property
`-servo-display-for-hypothetical-box`, which stores the `display` value
supplied by the author, before the computed value is calculated. Flow
construction now uses this value.
As for layout, implementing the proper behavior is tricky because the
position of an inline fragment in the inline direction cannot be
determined until height assignment, which is a parallelism hazard
because in parallel layout widths are computed before heights. However,
in this particular case we can avoid the parallelism hazard because the
inline direction of a hypothetical box only affects the layout if an
absolutely-positioned element is unconstrained in the inline direction.
Therefore, we can just lay out such absolutely-positioned elements with
a bogus inline position and fix it up once the true inline position of
the hypothetical box is computed. The name for this fix-up process is
"late computation of inline position" (and the corresponding fix-up for
the block position is called "late computation of block position").
This improves the header on /r/rust.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: f7d2fb6ff86afff7a5b674f751af9370a5a6b142
So far the changes to layout seem fairly well-contained; I think this is worth integrating to give us a browser that is easier to dogfood (and allows us to work on things like form submission much easier), especially since the long-term viability of WebComponents-as-forms is not assured.
Source-Repo: https://github.com/servo/servo
Source-Revision: f80096069592b864221abe112eaf2ecb6c444fda
Select the topmost layer at a given point to send mouse events and when
sending the event, ensure that they are relative to the layer origin,
rather than in absolute page coordinates.
Fixes#3504.
Source-Repo: https://github.com/servo/servo
Source-Revision: 479d8567d12aa0845c835fdae7d0dd45d7c63d4f
Now that scrolling roots are properly sized, we can simply look at the
scrolling root layer size when deciding the extents of layer scrolling.
This simplifies things a bit and further codifies the current model of
scrolling root + mask_to_bounds.
Source-Repo: https://github.com/servo/servo
Source-Revision: bfe5c34f8abcf7d8f02ef46792913e289df173a5
When interacting with Layers it is simpler to use LayerPixels, which
are unscaled pixels in the Layer coordinate system. This removes a lot
of room for error and makes things simpler.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6358b7d94e14fc61348fd56bcd5c0ff50ae11156
This also removes the unnecessary formation of a trait object.
Source-Repo: https://github.com/servo/servo
Source-Revision: 93e259227a969dbea1319d4d3ce92bc5706c6b06
This prevents iframes contents from overflowing their root layers.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4be0a07585b019d45dd83849818854566c5e118b
