Skip to content
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

Add layout RPC query for getting an element's style #19881

Merged
merged 1 commit into from Jan 28, 2018

Conversation

@jonleighton
Copy link
Contributor

jonleighton commented Jan 27, 2018

This enables us to implement Element::has_css_layout_box() in a more
direct way, and also enables us to remove some of the existing more
specific queries.

Fixes #19811.

r? @emilio


This change is Reviewable

@highfive
Copy link

highfive commented Jan 27, 2018

Heads up! This PR modifies the following files:

  • @bholley: components/style/values/specified/box.rs, components/style/data.rs
  • @canaltinova: components/style/values/specified/box.rs, components/style/data.rs
  • @emilio: components/style/values/specified/box.rs, components/style/data.rs, components/layout/query.rs
  • @fitzgen: components/script/dom/node.rs, components/script/dom/element.rs, components/script/dom/window.rs, components/script/devtools.rs
  • @KiChjang: components/script/dom/node.rs, components/script/dom/element.rs, components/script/dom/window.rs, components/script/devtools.rs
  • @asajeffrey: components/script/dom/node.rs, components/script/dom/element.rs, components/script/dom/window.rs, components/script/devtools.rs
@highfive
Copy link

highfive commented Jan 27, 2018

warning Warning warning

  • These commits modify style, layout, and script code, but no tests are modified. Please consider adding a test!
@jonleighton jonleighton force-pushed the jonleighton:issue-19811 branch from c66eece to d4d17ba Jan 27, 2018
@jonleighton
Copy link
Contributor Author

jonleighton commented Jan 27, 2018

Would computed_style_query be a clearer name, or do you think style_query is already clear enough?


/// Returns true if the value is `None`
#[inline]
pub fn is_none(&self) -> bool {

This comment has been minimized.

Copy link
@jonleighton

jonleighton Jan 27, 2018

Author Contributor

Perhaps controversial to add this? I felt like it made the code read a bit nicer, and it avoided an extra use declaration for the Display type, but I don't mind much either way. I can see how adding these sorts of methods all the time could get out of hand. (Note that it also reduced the implementation of ElementStyles::is_display_none().)

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

Looks fine to me.

overflow_pair.x == overflow_x::computed_value::T::Visible
}
/// Computed value of overflow-x or overflow-y is "visible"
fn has_visible_overflow(&self) -> bool {

This comment has been minimized.

Copy link
@jonleighton

jonleighton Jan 27, 2018

Author Contributor

There's duplication between has_visible_overflow and has_hidden_overflow. Ideally I'd prefer to have a more generic fn has_some_overflow(&self, value: OverflowType) but that would need overflow-x and overflow-y to both use the same value type I think.

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

Yeah, that implies moving them outside of mako, which is not too bad now, but should definitely be a followup.

What about noting that this can be simplified after fixing #19183?

@emilio
emilio approved these changes Jan 28, 2018
Copy link
Member

emilio left a comment

Looks great! Just a few documentation requests (it's easy to know why it's sound when writing it, but we should probably make sure that someone reading it knows it too).

Thanks a lot for this, this query can be super useful for all sorts of stuff! (I'm pretty sure we can use this to simplify and make stuff faster in canvasrenderingcontext2d.rs, and script_thread.rs, which right now call directly GetComputedStyle).

Those should of course be filed separately.

Thanks a lot for doing this again! :)

}
}
}
pub struct StyleResponse(pub Option<Arc<ComputedValues>>);

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

Maybe document when this is none?


/// Returns true if the value is `None`
#[inline]
pub fn is_none(&self) -> bool {

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

Looks fine to me.

overflow_pair.x == overflow_x::computed_value::T::Visible
}
/// Computed value of overflow-x or overflow-y is "visible"
fn has_visible_overflow(&self) -> bool {

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

Yeah, that implies moving them outside of mako, which is not too bad now, but should definitely be a followup.

What about noting that this can be simplified after fixing #19183?

fn has_css_layout_box(&self) -> bool {
self.upcast::<Node>().bounding_content_box().is_some()
let style = self.upcast::<Node>().style();
style.map_or(false, |s| !s.get_box().clone_display().is_none())

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

Please document why it's accurate? (because we won't return styles for elements in display: none subtrees)

let overflow_pair = window.overflow_query(self.upcast::<Node>().to_trusted_node_address());
overflow_pair.y == overflow_y::computed_value::T::Hidden
/// Computed value of overflow-x or overflow-y is "hidden"
fn has_hidden_overflow(&self) -> bool {

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

nit: Maybe has_any_hidden_overflow? (and same for visible?)

That way makes clear whether the semantics are all or any.

@emilio
Copy link
Member

emilio commented Jan 28, 2018

Would computed_style_query be a clearer name, or do you think style_query is already clear enough?

Sorry I didn't read this before... Both look fine to me honestly :)

This enables us to implement Element::has_css_layout_box() in a more
direct way, and also enables us to remove some of the existing more
specific queries.

Fixes #19811.
@jonleighton
Copy link
Contributor Author

jonleighton commented Jan 28, 2018

Thanks, I've addressed your comments. Also filed #19885 for the follow-up stuff you mentioned.

@emilio
emilio approved these changes Jan 28, 2018
Copy link
Member

emilio left a comment

r=me, moving to Element can be a followup if you want, since callers right now are fine with it.

@@ -154,12 +154,13 @@ pub fn handle_get_layout(documents: &Documents,
}

fn determine_auto_margins(window: &Window, node: &Node) -> AutoMargins {
let margin = window.margin_style_query(node.to_trusted_node_address());
let style = window.style_query(node.to_trusted_node_address()).unwrap();

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

I just noticed this... This unwrap may not be safe, I don't think anything guarantees that the element is not in a display: none subtree... Though it was a pre-existing bug, and I don't know where this code runs.

@@ -619,6 +620,10 @@ impl Node {
window_from_node(self).client_rect_query(self.to_trusted_node_address())
}

pub fn style(&self) -> Option<Arc<ComputedValues>> {

This comment has been minimized.

Copy link
@emilio

emilio Jan 28, 2018

Member

This should probably move to Element, since this getting called on, e.g., a text-node, will panic the layout thread.

Maybe worth doing before it lands, maybe fine as a followup? A doc comment here would be nice too :)

@emilio
Copy link
Member

emilio commented Jan 28, 2018

@bors-servo r+

Will file a followup for the documentation and moving it to Element :)

@bors-servo
Copy link
Contributor

bors-servo commented Jan 28, 2018

📌 Commit fe583fc has been approved by emilio

@bors-servo
Copy link
Contributor

bors-servo commented Jan 28, 2018

Testing commit fe583fc with merge 2a46067...

bors-servo added a commit that referenced this pull request Jan 28, 2018
Add layout RPC query for getting an element's style

This enables us to implement Element::has_css_layout_box() in a more
direct way, and also enables us to remove some of the existing more
specific queries.

Fixes #19811.

r? @emilio

<!-- 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/19881)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Jan 28, 2018

@bors-servo bors-servo merged commit fe583fc into servo:master Jan 28, 2018
3 checks passed
3 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@jonleighton
Copy link
Contributor Author

jonleighton commented Jan 28, 2018

I just noticed this... This unwrap may not be safe, I don't think anything guarantees that the element is not in a display: none subtree... Though it was a pre-existing bug, and I don't know where this code runs.

Good point. I filed #19887.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.