| Summary: | [WK2] Fixed/Sticky layers can get mispositioned when the layer tree commit change their position or size | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Benjamin Poulain <benjamin> | ||||
| Component: | New Bugs | Assignee: | Benjamin Poulain <benjamin> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | cmarcelo, commit-queue, jamesr, luiz, simon.fraser, tonikitoo | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Benjamin Poulain
2014-07-23 21:38:26 PDT
Created attachment 235404 [details]
Patch
First round. Comment on attachment 235404 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=235404&action=review > Source/WebCore/page/scrolling/ScrollingTree.h:134 > + void fixedOrStickyNodeRemoved() { --m_fixedOrStickyNodeCount; } Should assert that m_fixedOrStickyNodeCount isn't going to underflow. > Source/WebCore/page/scrolling/mac/ScrollingTreeFixedNode.mm:50 > + scrollingTree().fixedOrStickyNodeRemoved(); Not a huge fan of doing work like this in the destructor. I think it would be better to make more explicit didAddNode/didRemoveNode (which also enter the node in m_nodeMap), but maybe that's too risky at this point. Committed r171532: <http://trac.webkit.org/changeset/171532> |