!has_custom_scrollbar &&I added this in order to fix some c++ tests. Does it look correct?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
!has_custom_scrollbar &&I added this in order to fix some c++ tests. Does it look correct?
I'm afraid if we have an overlay scrollbar in one orientation and a custom scrollbar in another orientation we may still get a small resizer area (thin in the overlay orientation). How about `all_scrollbars_are_custom` instead of `has_custom_scrollbar`?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
!has_custom_scrollbar &&Xianzhu WangI added this in order to fix some c++ tests. Does it look correct?
I'm afraid if we have an overlay scrollbar in one orientation and a custom scrollbar in another orientation we may still get a small resizer area (thin in the overlay orientation). How about `all_scrollbars_are_custom` instead of `has_custom_scrollbar`?
thanks, i renamed the variable. does the logic otherwise look ok?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
!has_custom_scrollbar &&Xianzhu WangI added this in order to fix some c++ tests. Does it look correct?
Joey ArharI'm afraid if we have an overlay scrollbar in one orientation and a custom scrollbar in another orientation we may still get a small resizer area (thin in the overlay orientation). How about `all_scrollbars_are_custom` instead of `has_custom_scrollbar`?
thanks, i renamed the variable. does the logic otherwise look ok?
I meant the variable could be changed to reflect whether all scrollbars are custom, not just a rename, thus we'll use fixed size in the mixed custom/overlay scrollbars scenario.
However, now I'm inclined to the previous patchset than that idea. In the mixed scrollbar scenario, at least the author can control the size of the resizer in one direction, and the resizer won't interfere with the custom scrollbar.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
!has_custom_scrollbar &&Xianzhu WangI added this in order to fix some c++ tests. Does it look correct?
Joey ArharI'm afraid if we have an overlay scrollbar in one orientation and a custom scrollbar in another orientation we may still get a small resizer area (thin in the overlay orientation). How about `all_scrollbars_are_custom` instead of `has_custom_scrollbar`?
Xianzhu Wangthanks, i renamed the variable. does the logic otherwise look ok?
I meant the variable could be changed to reflect whether all scrollbars are custom, not just a rename, thus we'll use fixed size in the mixed custom/overlay scrollbars scenario.
However, now I'm inclined to the previous patchset than that idea. In the mixed scrollbar scenario, at least the author can control the size of the resizer in one direction, and the resizer won't interfere with the custom scrollbar.
I just tried to create a test case with mixed custom and overlay scrollbars to see how it looks with this CL, but it wasn't successful. It seems that we require both scrollbars to be custom or none, so the situation of my concern in my previous comment doesn't seem to exist. LGTM with the original name `has_custom_scrollbar` because it reflects the logic (though the new name also reflects the reality).
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
GetLayoutBox()->CanResize() && !has_custom_scrollbar &&I just added this to fix overlay-scrollbars.html - we shouldn't use a fixed size if there is not actually a resizer. This was affecting the scrollbars of scrollable areas that aren't resizable.
!has_custom_scrollbar &&Xianzhu WangI added this in order to fix some c++ tests. Does it look correct?
Joey ArharI'm afraid if we have an overlay scrollbar in one orientation and a custom scrollbar in another orientation we may still get a small resizer area (thin in the overlay orientation). How about `all_scrollbars_are_custom` instead of `has_custom_scrollbar`?
Xianzhu Wangthanks, i renamed the variable. does the logic otherwise look ok?
I meant the variable could be changed to reflect whether all scrollbars are custom, not just a rename, thus we'll use fixed size in the mixed custom/overlay scrollbars scenario.
However, now I'm inclined to the previous patchset than that idea. In the mixed scrollbar scenario, at least the author can control the size of the resizer in one direction, and the resizer won't interfere with the custom scrollbar.
Thanks, I put the name back to the previous one and rewrote the comment. How does it look?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
GetLayoutBox()->CanResize() && !has_custom_scrollbar &&I just added this to fix overlay-scrollbars.html - we shouldn't use a fixed size if there is not actually a resizer. This was affecting the scrollbars of scrollable areas that aren't resizable.
Acknowledged
!has_custom_scrollbar &&Xianzhu WangI added this in order to fix some c++ tests. Does it look correct?
Joey ArharI'm afraid if we have an overlay scrollbar in one orientation and a custom scrollbar in another orientation we may still get a small resizer area (thin in the overlay orientation). How about `all_scrollbars_are_custom` instead of `has_custom_scrollbar`?
Xianzhu Wangthanks, i renamed the variable. does the logic otherwise look ok?
Joey ArharI meant the variable could be changed to reflect whether all scrollbars are custom, not just a rename, thus we'll use fixed size in the mixed custom/overlay scrollbars scenario.
However, now I'm inclined to the previous patchset than that idea. In the mixed scrollbar scenario, at least the author can control the size of the resizer in one direction, and the resizer won't interfere with the custom scrollbar.
Thanks, I put the name back to the previous one and rewrote the comment. How does it look?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |