I'm not sure which of those options we should do. In this case, we need to come up with some other way to both clip the contents of the s but also allow for the scrollbar to be painted. We really do need to preserve this behavior. In this situation, we should simply always use the paddingBoxRect(), and never use the contentBoxRect. Notice how the "f" in the list box is clipped so that it does not intrude into the padding, and therefore does not look like the "f" outside the list box. This "spilling" is testable by making an.
#Mac for word version 15.71 Patch
The second patch you link to explicitly states "items should not spill into the padding box." I don't know the original reason why (because I'm not the author) but I would imagine it is there to preserve consistency between WebKit list boxes and existing platform controls. > + LayoutRect clipRect = hasOverlayScrollbars() ? paddingBoxRect() : contentBoxRect() > Source/WebCore/rendering/RenderListBox.cpp:736 > + No new tests as there is no machinery in place to test overlay scrollbars.ĭoes () not work? View in context: > Source/WebCore/ChangeLog:28 however, I am still checking the implications of such change.īasically, issue has started in (9 years ago!), when r19037 excluded "padding" from the RenderListBox::controlClipRect. If (verticalScrollbarIsOnLeft() & (!layer() || !layer()->verticalScrollbarIsOnLeft()))ĬlipRect.move(m_vBar->occupiedWidth(), 0) + // Clip to the padding box to at least give content the extra padding space, and not clip out overlay scrollbars if any. LayoutRect clipRect = contentBoxRect()
LayoutRect RenderListBox::controlClipRect(const LayoutPoint& additionalOffset) const +++ -730,7 +730,8 bool RenderListBox::nodeAtPoint(const HitTestRequest& request, HitTestResult& re
a/Source/WebCore/rendering/RenderListBox.cpp I figured that the the following change locally fixes the problem:ĭiff -git a/Source/WebCore/rendering/RenderListBox.cpp b/Source/WebCore/rendering/RenderListBox.cpp
0 kommentar(er)
