New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose Quirks Mode information in the layout data and code #14430
Expose Quirks Mode information in the layout data and code #14430
Conversation
Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @asajeffrey (or someone else) soon. |
Heads up! This PR modifies the following files:
|
@@ -938,6 +939,9 @@ pub struct BaseFlow { | |||
pub stacking_context_id: StackingContextId, | |||
|
|||
pub scroll_root_id: ScrollRootId, | |||
|
|||
// Mode for the current document. | |||
pub quirks_mode: QuirksMode, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussed with @SimonSapin, we were not sure whether integrating this into FlowFlags would be a good idea.
const IS_QUIRKS_MODE = 0b0000_0100, | ||
/// Which quirks mode we're in: 0 is quirks, 1 is limited quirks | ||
const QUIRKS_MODE = 0b0000_1000, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here I decided to integrate it in the bitflags, because I thought fragments are everywhere and I didn't want to use more memory when not needed.
@@ -442,7 +442,8 @@ fn render_text(layout_context: &LayoutContext, | |||
style.clone(), | |||
style, | |||
RestyleDamage::rebuild_and_reflow(), | |||
info)); | |||
info, | |||
None)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
quirksmode information is actually useless here
@@ -1727,6 +1731,7 @@ pub struct InlineFragmentNodeInfo { | |||
pub selected_style: Arc<ServoComputedValues>, | |||
pub pseudo: PseudoElementType<()>, | |||
pub flags: InlineFragmentNodeFlags, | |||
pub quirks_mode: QuirksMode, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same question here, not sure whether this could go into flags above.
pub fn from_node_and_style<N: ThreadSafeLayoutNode>(node: &N, | ||
style: Arc<ServoComputedValues>, | ||
specific: SpecificFragmentInfo) | ||
-> Fragment { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created this to simplify some of the existing code, but it's not really necessary for this patch. Tell me if you'd prefer that I revert the changes around this constructor.
If you decide that we should keep it, maybe new
could call it too and cut some code.
let writing_mode = style.writing_mode; | ||
|
||
let mut restyle_damage = node.restyle_damage(); | ||
restyle_damage.remove(RECONSTRUCT_FLOW); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I read prperly, this single line is usually what is different where I changed the calls from from_opaque_node_...
to this constructor. I don't know what the consequences are. Maybe it's better because more factorized ? :)
Isn't the Quirks mode a document-level thing? If so, shouldn't it go into |
Yes it is at the document-level; I'll check why I didn't go with this solution. Note we don't consume more memory if we use the existing bitflags :) |
Yes, but we'd use two flags that would be more helpful for other stuff :) |
Yep, I'll look closer :) |
So I looked closer and now I remember why I did it this way. Ultimately we need the information in the flow objects (like InlineFlow or BlockFlow) for most of layout-related issues (I especially looked #11704 so far but I expect other issues to have the same requirements). At first I only added the information in BaseFlow and modified the constructors for InlineFlow and BlockFlow (we don't even need to change LayoutContext for this as we can directly access the data in the document). InlineFlow was quite easy, but I saw that BlockFlow's constructors were used a lot with a fragment as argument. That's when I thought that having this information in a Fragment could be useful as well after all. Now I understand how LayoutContext works: we create it once for every thread (with some shared data) and we pass it over as parameter to every call. Do you think it would be a better architecture ? |
On Thu, Dec 01, 2016 at 07:10:18AM -0800, Julien Wajsberg wrote:
Now I understand how LayoutContext works: we create it once for every
thread (with some shared data) and we pass it over as parameter to
every call. Do you think it would be a better architecture ?
Yes, I think so, makes sense to put in SharedLayoutContext anything that
is thread-independent and valid for the whole layout pass.
|
cc66b22
to
3fe7d5b
Compare
@emilio I just pushed 2 new commits to revert part of my previous changes and add the information in the shared layout context. Can you tell me what you think ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly nits, the rest looks sane to me :)
Also, please squash together the commits.
@@ -908,6 +913,13 @@ impl<'ln> ThreadSafeLayoutNode for ServoThreadSafeLayoutNode<'ln> { | |||
self.get_jsmanaged().downcast::<Element>().unwrap().get_colspan() | |||
} | |||
} | |||
|
|||
#[inline] | |||
fn quirks_mode(&self) -> QuirksMode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This is not needed anymore, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think you're right. If we ever need it later, we can just add it at that time.
@@ -515,6 +521,7 @@ impl LayoutThread { | |||
error_reporter: self.error_reporter.clone(), | |||
local_context_creation_data: Mutex::new(local_style_context_creation_data), | |||
timer: self.timer.clone(), | |||
quirks_mode: self.quirks_mode.unwrap_or(QuirksMode::NoQuirks), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should be able to unwrap
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking only at this file, I wasn't sure quirks_mode
would be always already populated when eg repaint
or tick_animations
or others would be called. I think it's not a big deal to have a default value here, what do you think ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd be wrong to lay out a quirks mode document in no-quirks mode, then laying it out in quirks mode, overall taking into account incremental reflows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But just unwrapping would panic the thread in the same case; is it wishable ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we do. I don't think we can layout anything without a document anyway. Indeed the sanest stuff would be making build_shared_layout_context
taking the document directly, and don't store the quirks mode in the script thread at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Er.., in the layout thread, I mean
@@ -228,6 +230,9 @@ pub struct LayoutThread { | |||
// Number of layout threads. This is copied from `util::opts`, but we'd | |||
// rather limit the dependency on that module here. | |||
layout_threads: usize, | |||
|
|||
/// Which quirks mode are we rendering the document in ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: No space before ?
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my french typography ;)
58247ae
to
ab73ef6
Compare
I fixed your comments except the last one, I squashed the commits. I'm not sure of what gives the test issue on Travis. I reproduce also locally, but not on master, so it should be something in this patch. But I don't know how to get more information. |
ab73ef6
to
dc1943a
Compare
@@ -30,6 +30,7 @@ euclid = "0.10.1" | |||
fnv = "1.0" | |||
heapsize = "0.3.0" | |||
heapsize_derive = {version = "0.1", optional = true} | |||
html5ever = {version = "0.10.2", features = ["heap_size", "unstable"]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a fairly large dependency to add to Stylo, just to use a small enum. And it is also what causes build-geckolib
to fail because that uses an older (stable channel) Rust compiler that doesn’t know about new-style procedural macros.
Instead I recommend duplicating the definition of the QuirksMode
enum into components/style/context.rs
. For consistency, the rest of Servo should be changed to use that enum instead of html5ever::tree_builder::QuirksMode
. Namely, these files:
components/script/dom/node.rs
components/script/dom/document.rs
components/script/dom/bindings/trace.rs
components/script/dom/servoparser/html.rs
The latter has a set_quirks_mode
method that takes a html5ever::tree_builder::QuirksMode
and will need to do the conversion to style::context::QuirksMode
.
7f8d2b6
to
f26e0bf
Compare
☔ The latest upstream changes (presumably #14436) made this pull request unmergeable. Please resolve the merge conflicts. |
🔒 Merge conflict |
d1f20de
to
6873527
Compare
6873527
to
2265cfb
Compare
☔ The latest upstream changes (presumably #14610) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors-servo: delegate+ |
✌️ @julienw can now approve this pull request |
2265cfb
to
d024787
Compare
Just realized how I should add r=emilio :) but afk right now so this will wait a few more hours. |
@bors-servo r=emilio |
📌 Commit d024787 has been approved by |
Expose Quirks Mode information in the layout data and code <!-- Please describe your changes on the following line: --> This patch exposes the Quirks (NoQuirks/LimitedQuirks/Quirks) state to the layout subsystem. --- <!-- 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). Prelimary work for issue #11704. <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because _____ (Waiting for guidance of where/which tests I could do here) <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14430) <!-- Reviewable:end -->
☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css, mac-rel-wpt1, mac-rel-wpt2, windows-dev |
thanks @KiChjang ! |
Thank you for the patch @julienw! :) |
This patch exposes the Quirks (NoQuirks/LimitedQuirks/Quirks) state to the layout subsystem.
./mach build -d
does not report any errors./mach test-tidy
does not report any errorsPrelimary work for issue Implement line-height quirks #11704.
(Waiting for guidance of where/which tests I could do here)
This change is