Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd support for scrollbars per Scroll Frame #2015
Conversation
|
There are two reftest failures I'm looking into related to the root scroll frame scrollbar being offset a bit.
|
|
So I decided to keep the RendererOptions |
| @@ -458,6 +458,7 @@ impl FrameBuilder { | |||
| &viewport_rect, | |||
| content_size, | |||
| ScrollSensitivity::ScriptAndInputEvents, | |||
| false, | |||
This comment has been minimized.
This comment has been minimized.
nc4rrillo
Nov 8, 2017
Author
Contributor
Previously I set this to true, but it caused reftest failures, I'm wondering if its because of some special handling of the root scroll frame.
This comment has been minimized.
This comment has been minimized.
mrobinson
Nov 14, 2017
Member
Yes. Root scroll frame scrollbars are handled automatically by the ENABLE_SCROLLBARS option. We don't want this turned on in Gecko anyhow.
| @@ -128,6 +129,23 @@ impl<'a> FlattenContext<'a> { | |||
| ); | |||
| } | |||
|
|
|||
| // Draw scrollars for other scroll frames | |||
| for (clip_id, clip_node) in &self.clip_scroll_tree.nodes { | |||
This comment has been minimized.
This comment has been minimized.
nc4rrillo
Nov 8, 2017
Author
Contributor
I'm thinking in flatten_root I should filter the clip scroll nodes by the current PipelineId, else we'll run into trouble with a nested Iframe?
This comment has been minimized.
This comment has been minimized.
mrobinson
Nov 14, 2017
Member
Hrm. It seems like it would be a lot easier just to add the item when processing the scroll frame item during flattening. Otherwise I think that stacked scroll frames will have all their scrollbars on the top of the scene.
|
|
|
Apologies for not getting to this - will look at it on Monday if no-one else gets to it before me. |
|
@nc4rrillo Sorry! I hadn't seen this PR when I made my recent scrollbar change. It looks like the two PRs are compatible, even though there is now a merge conflict. |
|
@mrobinson No worries. I'll rebase my changes and update this PR. |
1c5254f
to
2ca7b1f
|
So there is still an issue that's visible in the scrolling example, where if you scroll the outer scroll frame, the inner scrollbar isn't clipped by its parents bounds. |
2ca7b1f
to
b8e55e5
b8e55e5
to
2fb4303
|
Okay I fixed that issue, I think this is ready for review. |
|
r? @mrobinson |
|
|
|
Really sorry for the delay in reviewing this PR! I have added some suggestions below, but this is looking pretty good. This PR also needs to be rebased in order to remove the two extra commits that got lumped along with it. |
| @@ -1162,6 +1162,7 @@ impl DisplayListBuilder { | |||
| complex_clips: I, | |||
| image_mask: Option<ImageMask>, | |||
| scroll_sensitivity: ScrollSensitivity, | |||
| enable_scrollbars: bool | |||
This comment has been minimized.
This comment has been minimized.
mrobinson
Nov 14, 2017
Member
I think it would be better to use an enum for this argument. Just judging by the changes to the examples, it's already a little hard to tell what this argument does. I suggest something like
enum IframeScrollbars {
Enabled,
Disabled,
}
| @@ -128,6 +129,23 @@ impl<'a> FlattenContext<'a> { | |||
| ); | |||
| } | |||
|
|
|||
| // Draw scrollars for other scroll frames | |||
| for (clip_id, clip_node) in &self.clip_scroll_tree.nodes { | |||
This comment has been minimized.
This comment has been minimized.
mrobinson
Nov 14, 2017
Member
Hrm. It seems like it would be a lot easier just to add the item when processing the scroll frame item during flattening. Otherwise I think that stacked scroll frames will have all their scrollbars on the top of the scene.
| @@ -500,6 +502,7 @@ impl FrameBuilder { | |||
| frame_rect, | |||
| content_size, | |||
| scroll_sensitivity, | |||
| enable_scrollbars | |||
This comment has been minimized.
This comment has been minimized.
mrobinson
Nov 14, 2017
Member
I'm not sure we need to pass this value to the ClipScrollNode. I think you can just add the scrollbar here as a child of the parent ClipScrollNode. You might need to do some special calculation to ensure that the scrollbar stays within the rectangle of the parent node.
| @@ -458,6 +458,7 @@ impl FrameBuilder { | |||
| &viewport_rect, | |||
| content_size, | |||
| ScrollSensitivity::ScriptAndInputEvents, | |||
| false, | |||
This comment has been minimized.
This comment has been minimized.
mrobinson
Nov 14, 2017
Member
Yes. Root scroll frame scrollbars are handled automatically by the ENABLE_SCROLLBARS option. We don't want this turned on in Gecko anyhow.
|
@mrobinson I've tried to move creating the scrollbars to Here's a screen shot with debug alpha primitives turned on to demonstrate: |
|
I believe this is because One of the reasons why doing it in |
|
Okay so my proposed fix is to do the following:
This takes care of most cases, I add a final check to My thinking is that this works around the there not being a specific |
| @@ -612,6 +594,9 @@ impl<'a> FlattenContext<'a> { | |||
| .clip_rect() | |||
| .translate(&reference_frame_relative_offset); | |||
| let content_rect = item.rect().translate(&reference_frame_relative_offset); | |||
|
|
|||
| let enable_scrollbars = IframeScrollbars::Enabled == info.enable_scrollbars; | |||
This comment has been minimized.
This comment has been minimized.
nc4rrillo
Nov 14, 2017
Author
Contributor
I turned the enum into a bool here, but I could just as easily thread it all the way down into FrameBuilder if need be.
| @@ -129,6 +129,9 @@ pub struct FrameBuilder { | |||
| /// parent new scroll nodes. | |||
| reference_frame_stack: Vec<ClipId>, | |||
|
|
|||
| parent_scroll_frame_id: Option<ClipId>, | |||
| pending_scroll_frame_stack: Vec<(ClipId, ClipId, LayerRect)>, | |||
|
|
|||
This comment has been minimized.
This comment has been minimized.
nc4rrillo
Nov 14, 2017
Author
Contributor
I doubt think this needs to be a Vec, I don't think there will be more than one pending scroll frame that hasn't drawn scrollbars at a time.
|
I pushed a commit to address your review and implement the proposed change I outlined above. |
|
CI failures are because I need to update wrench |
671be1d
to
f21e969
|
Looks like this needs a rebase, sorry! |
f21e969
to
74e1209
9dfc841
to
e9944a7
e9944a7
to
c48cfcb
|
Rebased and bumped crate versions for wr, wr api, and wrench |
|
r? @mrobinson |
|
@nc4rrillo Sorry for not giving this as much attention as I should have. I have been rolling this around the back of my head for the past week or so. The approach you take, which is to wait until the display list flattening sees another Instead of doing this now and then having to redo it in the future, I think the right approach here is to let the client control adding scrollbars completely. To me, the most obvious way to do this is to expose a scrollbar display item. This display item would, for the moment, be a rectangle with a height, width, and color. WebRender would be responsible for moving that item around in the ScrolFrame's parent just like for existing scrollbars. Again, sorry for the delay and perhaps leading you down a dead end here. |
|
No worries. I like your approach much more. I’m going to close this and work on that. |


nc4rrillo commentedNov 8, 2017
•
edited
Hi,
This PR adds support for specifying scrollbars being enabled per Scroll Frame by adding an additional bool to
define_scroll_frame.This is a (albeit tiny) breaking API change, so I've bumped the WR API version. I hope I did that right :).
I also updated the scrolling sample to show off the new functionality.
This change is