I don't believe there is a case where it would make sense to drop the
ScriptReflow struct without joining the script thread. This approach should
be somewhat more robust, and avoids the code smell of a RAII guard in an
otherwise unused variable.
Source-Repo: https://github.com/servo/servo
Source-Revision: db94fda10e3351c96a0df61099d2fdfa481cc62b
Stylesheets for `HTMLLinkElement`s are now loaded by the resource task, triggered by the element in question. Stylesheets are owned by the elements they're associated with, which can be `HTMLStyleElement`, `HTMLLinkElement`, and `HTMLMetaElement` (for `<meta name="viewport">).
Additionally, the quirks mode stylesheet (just as the user and user agent stylesheets a couple of commits ago), is implemented as a lazy static, loaded once per process and shared between all documents.
This all has various nice consequences:
- Stylesheet loading becomes a non-blocking operation.
- Stylesheets are removed when the element they're associated with is removed from the document.
- It'll be possible to implement the CSSOM APIs that require direct access to the stylesheets (i.e., ~ all of them).
- Various subtle correctness issues are fixed.
One piece of interesting follow-up work would be to move parsing of external stylesheets to the resource task, too. Right now, it happens in the link element once loading is complete, so blocks the script task. Moving it to the resource task would probably be fairly straight-forward as it doesn't require access to any external state.
Depends on #7979 because without that loading stylesheets asynchronously breaks lots of content.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7ff3a17524e0e703e3ac279441729c185444be24
Always produce a DisplayList when processing nodes for display list
construction. StackingContexts are now added to the positioned content
section of DisplayLists. This makes the code a bit simpler and opens up
the possibility of producing a StackingContext in another section of
the DisplayList. This doesn't change behavior, but is a cleanup
prerequisite for proper inline stacking context support.
Source-Repo: https://github.com/servo/servo
Source-Revision: da25b8c848886d2fc875008de5adcaf13d7c9e99
This was causing a bunch of tests in tests/wpt/web-platform-tests/html/semantics/embedded-content/the-canvas-element/size.attributes* to fail. They were returning "auto" instead of the correct size. They still fail because the returned size is off by a few pixels, not sure why yet. But this is more correct and may fix other failing tests.
Source-Repo: https://github.com/servo/servo
Source-Revision: b6850853da5fc677ecfa15d273159371a909ac6c
After all these changes are applied, Hacker News and GitHub only repaint and reflow nodes that actually have hover styles applied when the mouse moves over them.
r? @mbrubeck
cc @bholley
Source-Repo: https://github.com/servo/servo
Source-Revision: 36c5dd4c8c543ed6767fe9dd367281b292d68dba
As per #8238 I changed `layout_interface::Msg::Reflow` to store `ScriptReflow` rather than `Box<ScriptReflow>`
I ran the tests and believe everything passed but this is my first commit to the project so sorry if I messed up the protocol!
Source-Repo: https://github.com/servo/servo
Source-Revision: 601169c0e5b0207805bb316b21e556f5ab67df9b
This reduces some unnecessarily tight coupling, makes it clearer what these functions do, and may help avoid bugs where we would return from such a function without updating the relevant field.
It is also a precondition for some future experimentation I'm thinking of doing with this querying design.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3a254b7e20c37e4ce7b614abea9ebd4687c65f98
This isn't doing anything right now, and we're not even setting it properly
in dirty_impl the |dirty_subtree(self)| was causing us to hit the skip case
for step 3.
Source-Repo: https://github.com/servo/servo
Source-Revision: 50ec2353845bf2a3971d5b01db37d2c3741d3912
This doesn't change any functionality, but it's the first step towards removing SubpageId.
Adding this change now will allow us to gradually change over code referencing subpage id rather than in one massive PR.
Introduces a namespace for pipeline ID generation - there is a namespace for the constellation thread, and one per script thread.
Source-Repo: https://github.com/servo/servo
Source-Revision: 098bdb5f22500a6e856b085a1140090f63ef8645
StackingContexts are added to layers when it is necessary to maintain
their ordering on top of other layered StackingContexts. Instead of
tracking the information about a layer scattered around into different
structs, combine it all into LayerInfo. LayerInfo will be used in the
future to hold layer information for DisplayItems that are layerized
independently of StackingContexts.
Source-Repo: https://github.com/servo/servo
Source-Revision: 27d468b6674b81c396aa0a13d8fe9eb410c12d6e
Translate <meta name=viewport> as according to [CSS Device Adaption § 9](http://dev.w3.org/csswg/css-device-adapt/#viewport-meta)
Note: as the PR currently stands, handling `<meta name=viewport>` elements always occurs. This is probably not desired for some contexts (e.g. desktop), but I'm unsure of how to conditionally handle elements based on that.
Source-Repo: https://github.com/servo/servo
Source-Revision: a7743052cad0387733c90940fa91733ede32772c
The old code that attempted to do this during layout wasn't able to work
for multiple reasons: it couldn't know where the iframe was going to be
on the page (because of nested iframes), and at the time it was building
the display list for a fragment it couldn't know where that fragment was
going to be in page coordinates.
This patch rewrites that code so that only the size of an iframe is
determined during layout, and the position is determined by the
compositor. Layout layerizes iframes and marks the iframe layers with
the appropriate subpage ID so that the compositor can place them
correctly.
Closes#7377.
Source-Repo: https://github.com/servo/servo
Source-Revision: a0cb657fe80859dd8862361631268479d1045432
(#[cfg(debug)] is false in every normal servo configuration, and the
code in question doesn't compile.)
Source-Repo: https://github.com/servo/servo
Source-Revision: d4f5948294545860a88d6a266acaa4cf9b9ea1c6
There were two problems here:
(1) The animation state update function was only called when nodes were dirty or there were new animations.
(2) When all animations for a node expired, the entry from the hash table was not removed.
The result was that once an animation began, the compositor would be running as fast as it can forever.
Fixes#7721.
Source-Repo: https://github.com/servo/servo
Source-Revision: b4b3cedc10cec47d95880bfbe55f2dbc37cd910e
This is a direct extract from my abandoned PR for a lint (#7546), along with some rather clumsy modifications (only on `components/script/dom/mod.rs` and `components/style/lib.rs`), because I had to sort some of the files again to make peace with tidy, which hasn't been educated about sorting yet!
Source-Repo: https://github.com/servo/servo
Source-Revision: a7208869f2903e36f9b2f540b55b50283d7df466
Currently pseudo-elements, like the fragments created for ::before and
::after, with layers will have the same LayerId as the body of their
owning fragments. Instead all LayerIds should be unique.
Fixes#2010.
Source-Repo: https://github.com/servo/servo
Source-Revision: cf13e806fe2f4cf5ad5f30efd16d7bd3f501f8b3
Support `var()` in shorthand properties, and fix various bugs.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 1b6d4daf85d672265824a014dba99c94c8c08814
Known issues:
* The caret doesn't show up if there's no text present, because we don't create text runs in that case. This should be a followup.
* Text runs don't support decomposing ligatures into their constituent subglyphs for advance computation, so the caret won't appear inside a ligature. This is a text run bug.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 6cd098da302db85975d0967ddee836f04eae3bd5
Use box tree characters to make DisplayLists easier to scan when
printing them out.
This is what the output looked like before:
```
#### start printing display list.
"####" Stacking context at Rect(800px×608px at (0px,0px)) with overflow Rect(800px×608px at (0px,0px)):
#### SolidColor(0,0,0,0). Rect(800px×608px at (0px,0px))
#### SolidColor(0,0,0,0). Rect(784px×0px at (8px,0px))
#### SolidColor(0,0.5019608,0,1). Rect(100px×100px at (0px,0px))
#### Child layers list length: 1
"########" Stacking context at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
######## SolidColor(1,0,0,1). Rect(100px×100px at (0px,0px))
######## Child layers list length: 1
"############" Stacking context at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
```
This is what it looks like after this patch:
```
┌ DisplayList
│ ├─ Layered StackingContext at Rect(800px×608px at (0px,0px)) with overflow Rect(800px×608px at (0px,0px)):
│ │ ├─ Block Backgrounds and Borders
│ │ │ ├─ SolidColor rgba(0, 0, 0, 0) @ Rect(800px×608px at (0px,0px)) (7f926f46f1f0)
│ │ │ └─ SolidColor rgba(0, 0, 0, 0) @ Rect(784px×0px at (8px,0px)) (7f926f46f2e0)
│ │ ├─ Layered StackingContext at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
│ │ │ ├─ Backgrounds and Borders
│ │ │ │ └─ SolidColor rgba(1, 0, 0, 1) @ Rect(100px×100px at (0px,0px)) (7f926f46f310)
│ │ │ ├─ Layered StackingContext at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
│ │ ├─ Layered StackingContext at Rect(100px×100px at (0px,0px)) with overflow Rect(100px×100px at (0px,0px)):
│ │ │ ├─ Backgrounds and Borders
│ │ │ │ └─ SolidColor rgba(0, 0.5019608, 0, 1) @ Rect(100px×100px at (0px,0px)) (7f926f46f3a0)
```
Source-Repo: https://github.com/servo/servo
Source-Revision: 4e9a888f1ac58866833418ee5e8253358918b741
Previously, StackingContexts might have a PaintLayer. We switch the
ownership, for several reasons:
* We want PaintLayers to potentially contain something other
than a StackingContext soon.
* We want to delay the creation of PaintLayers until the last
minute, so that we can synthesize new layers for sandwiched
content.
This commit also implements the second goal. Instead of creating
PaintLayers during layout itself, wait until we are sorting and
layerizing a completed DisplayList.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e0b010117889550effa3ad793e7ee8f9b692b40
Elided almost all the lifetimes and removed needless returns. Mostly done by sed + manual fixes.
r? @nox
Source-Repo: https://github.com/servo/servo
Source-Revision: c2c2646d37614ece5869af861993c3d619f6e003
Expands on the work by @wilmoz and cleans up the existing errors. Closes#7180. Closes#7111.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74825f9fde8e222f4ba9bb24b2c2a3864c73e5f
