Constellation blocks on SetId by sending a Port through the compositor channel and waits for a response. If the compositor is in the process of shutting down, it will not look in the queue again. The compositor requires the constellation to be shut down first, so it sends a message to shut down and blocks until the constellation finishes, deadlocking.
Only very short lived executions would've been likely to see this deadlock.
_It is technically still possible to trigger a SetId message between when the compositor finishes running and when the constellation shuts down, but the window for exposure is greatly reduced. I've only seen it with "-o" so far._
Constellation blocks on SetId by sending a Port through the compositor
channel and waits for a response. If the compositor is in the process of
shutting down, it will not look in the queue again. The compositor
requires the constellation to be shut down first, so it sends a message
to shut down and blocks until the constellation finishes, deadlocking.
Only very short lived executions would've been likely to see this deadlock.
Moving another window on top of servo window, or switching screen would result in a blank window until the app was resized. This was due to a missing glfw callback.
Fixes#941.
This will allow us to stop going to the DOM in order to handle iframe
sizing. Instead we can just store the pipeline and frame IDs of iframes
inside the flow tree itself.
r? @kmcallister
This will allow us to stop going to the DOM in order to handle iframe
sizing. Instead we can just store the pipeline and frame IDs of iframes
inside the flow tree itself.
Fixes#222.
Implements 'text-align' inheritance for inline elements. The text alignment code has been changed a couple of times since the ticket was originally opened and was improved to inherit the text-align property from from an ancestor element. This addressed the issue, so long as no inline elements had a text-align property defined. Both Firefox and Chromium ignore any text-align properties attached to inline elements, but none of the specs are explicit about ignoring the property or inheriting only from non-inline elements:
http://www.w3.org/TR/CSS2/visuren.html#inline-formattinghttp://www.w3.org/TR/CSS2/text.html#propdef-text-align
This is my first stab at writing any code that touches the DOM node tree. Based on a few observations, I made the assumption that the `self.base.node` of a InlineFlow always corresponds to a BlockFlow-based node, no matter how deep inline DOM elements are nested; there was no obvious way to traverse Flow-traited objects directly and I'm not sure if it's possible to get from a FlowData struct back to a non-child {Block,Inline}Flow (probably intentionally).
I could've kept traversing the node tree directly, checking against each node style to ensure it didn't have an inline display property, but I could not create a scenario where the `base.node` was ever an inline. It also feels like a code smell to be walking up the tree at all, especially for stylesheet properties. Feels like it should eventually be handled in style::properties directly as being conditional inherited?
Fix this warning:
```
servo/src/components/gfx/platform/macos/font_list.rs:6:4: 6:42 warning: unused import, #[warn(unused_imports)] on by default
servo/src/components/gfx/platform/macos/font_list.rs:6 use font_context::FontContextHandleMethods;
```
This fixes the computation of restyle damage on `color-change-text.html`, which can be seen with `RUST_LOG=servo::layout::layout_task`.
However we can't prune the layout traversals yet, because we don't reuse `Flow` objects between reflows, so we have no old values to fall back to.
I think this used to work because `FlowContexts` (as they were called then) were stored in a DOM node's `LayoutData` and reused. But it's possible that it never really worked, and my testing when I landed the restyle damage code was insufficient (I didn't understand the layout code nearly as well back then).
r? @pcwalton
We don't reuse Flow objects between reflows, so we have no old values to fall
back to.
I think this used to work because FlowContexts (as they were called then) were
stored in a DOM node's LayoutData and reused. But it's possible that it never
really worked, and my testing when I landed the restyle damage code was
insufficient (I didn't understand the layout code nearly as well back then).
Instead we do selector matching again, then diff the style structs to set the
"restyle damage" bits which are used to prune reflow traversals.
Also don't force a reflow when timers finish, because individual DOM methods
should already take care of that.
flushing text clumps. Fixes this page:
http://en.wikipedia.org/wiki/Yellow_River
This is not the most efficient thing to do; a FIXME has been added
noting what is most correct.
r? @jdm
flushing text clumps. Fixes this page:
http://en.wikipedia.org/wiki/Yellow_River
This is not the most efficient thing to do; a FIXME has been added
noting what is most correct.
