|
|
Chromium Code Reviews
DescriptionHandle anonymous layout objects correctly in SnapCoordinator
This is done by not assume that |node()| is always available.
BUG=637423
Committed: https://crrev.com/4add15dab9bc86608da3158f25a57582e1f86dd0
Cr-Commit-Position: refs/heads/master@{#431881}
Patch Set 1 #Patch Set 2 : rebase #Messages
Total messages: 29 (18 generated)
The CQ bit was checked by majidvp@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by majidvp@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Handle anonymous layout objects correctly in SnapCoordinator Do not assume that |node()| is always available. BUG=637423 ========== to ========== Handle anonymous layout objects correctly in SnapCoordinator This is done by not assume that |node()| is always available. BUG=637423 ==========
majidvp@chromium.org changed reviewers: + skobes@chromium.org
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Should this have a test?
On 2016/09/16 01:11:16, skobes wrote: > Should this have a test? I had a hard time coming up with a good test. I don't know a good way to create, access and modify the style of an anonymous layout object to inject a snap point to trigger this. Any pointers? The original fuzz test case was achieving this indirectly via video.webkitRequestFullScreen() which somehow creates an anonymous layout object that inherits some of its parent's style but I don't think that is appropriate to use here. I have manually confirmed that the fix addresses the fuzz finding and I am not sure if it is even worth spending more time on creating a test case for the more general case.
ok, lgtm
The CQ bit was checked by majidvp@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Failed to apply patch for
third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp:
While running git apply --index -3 -p1;
error: patch failed:
third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp:33
Falling back to three-way merge...
Applied patch to
'third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp' with
conflicts.
U third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
Patch: third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
Index: third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
diff --git a/third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
b/third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
index
f3412809610faa1962b4e1e599f733fc2e7f24c0..478cbb7ea41968d6faaf8c8848e0091945b0f283
100644
--- a/third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
+++ b/third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
@@ -33,14 +33,14 @@ static LayoutBox* findSnapContainer(const LayoutBox&
snapArea)
// According to the new spec
https://drafts.csswg.org/css-scroll-snap/#snap-model
// "Snap positions must only affect the nearest ancestor (on the element’s
// containing block chain) scroll container".
- Element* viewportDefiningElement =
snapArea.node()->document().viewportDefiningElement();
+ Element* viewportDefiningElement =
snapArea.document().viewportDefiningElement();
LayoutBox* box = snapArea.containingBlock();
while (box && !box->hasOverflowClip() && !box->isLayoutView() &&
box->node() != viewportDefiningElement)
box = box->containingBlock();
// If we reach to viewportDefiningElement then we dispatch to viewport
- if (box->node() == viewportDefiningElement)
- return snapArea.node()->document().layoutView();
+ if (box && box->node() == viewportDefiningElement)
+ return snapArea.document().layoutView();
return box;
}
The CQ bit was checked by majidvp@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from skobes@chromium.org Link to the patchset: https://codereview.chromium.org/2332383002/#ps20001 (title: "rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
The CQ bit was checked by majidvp@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Failed to apply patch for
third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp:
While running git apply --index -p1;
error: patch failed:
third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp:30
error: third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp:
patch does not apply
Patch: third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
Index: third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
diff --git a/third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
b/third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
index
7eb7f145dc8471019a597414e47fe64e844328db..ad27eae93f1cd9aa888c8602c6fb324511d27984
100644
--- a/third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
+++ b/third_party/WebKit/Source/core/page/scrolling/SnapCoordinator.cpp
@@ -30,15 +30,15 @@ static LayoutBox* findSnapContainer(const LayoutBox&
snapArea) {
// "Snap positions must only affect the nearest ancestor (on the element’s
// containing block chain) scroll container".
Element* viewportDefiningElement =
- snapArea.node()->document().viewportDefiningElement();
+ snapArea.document().viewportDefiningElement();
LayoutBox* box = snapArea.containingBlock();
while (box && !box->hasOverflowClip() && !box->isLayoutView() &&
box->node() != viewportDefiningElement)
box = box->containingBlock();
// If we reach to viewportDefiningElement then we dispatch to viewport
- if (box->node() == viewportDefiningElement)
- return snapArea.node()->document().layoutView();
+ if (box && box->node() == viewportDefiningElement)
+ return snapArea.document().layoutView();
return box;
}
Message was sent while issue was closed.
Description was changed from ========== Handle anonymous layout objects correctly in SnapCoordinator This is done by not assume that |node()| is always available. BUG=637423 ========== to ========== Handle anonymous layout objects correctly in SnapCoordinator This is done by not assume that |node()| is always available. BUG=637423 Committed: https://crrev.com/4add15dab9bc86608da3158f25a57582e1f86dd0 Cr-Commit-Position: refs/heads/master@{#431881} ==========
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/4add15dab9bc86608da3158f25a57582e1f86dd0 Cr-Commit-Position: refs/heads/master@{#431881} |
