Regression: Bookmark drop-down turns blank after clicking on the entries present in it.
Reported by
aiman.an...@etouch.net,
Mar 13 2018
|
|||||||
Issue descriptionChrome Version: 67.0.3368.0 (Official Build) Revision 0f36d3901569535a63173a1835f8dfbcf7b66d60-refs/heads/master@{#542340}(32/64-bit) OS: Win(7,8,8.1,10), Linux(14.04 LTS), Mac(10.12.6,10.13.1,10.13.4). Test URL: https://collegereadiness.collegeboard.org/pdf/sat-practice-test-1.pdf What steps will reproduce the problem? 1. Launch chrome, navigate to the above URL and click on bookmark icon in pdf toolbar. 2. Click on First Entry and observe. Actual: Bookmark drop-down turns blank after clicking on the entries present in it. Expected: Bookmark drop-down should not appear blank after clicking on entries. This is a regression issue, broken in M-67 series, Using the per-revision bisect providing the bisect results, Good Build:67.0.3366.0(Revision:541889) Bad Build:67.0.3367.0(Revision:542330) You are probably looking for a change made after 542040 (known good), but no later than 542041 (first known bad). CHANGE-LOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/bdb3104733f57f58963321f20e079bea4eab8cb4..06f244ec11ee17699c98c7c59bf4bba664eb14cb Suspect: https://chromium.googlesource.com/chromium/src/+/06f244ec11ee17699c98c7c59bf4bba664eb14cb trchen@:Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thank You!
,
Mar 13 2018
It is actually a overlap testing bug related to RLS. I made a minimal repro which triggered this bug even before my CL. (Though it's still a bit worrisome because my CL is expected to change nothing.) There is a space mismatch one this line: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/compositing/CompositingInputsUpdater.cpp?rcl=1f31a184a7f74cf3f1bbafc21487d5ccb9b5bb08&l=250 that caused clipped_absolute_bounding_box to become empty. RLS mode seems to cache clip rects differently from this optimization: https://chromium-review.googlesource.com/c/chromium/src/+/864560 This CL is a part of M65, but we only enabled RLS by default on M66. I think this usage pattern isn't uncommon, and we should bring a fix to M66 as well.
,
Mar 16 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d09d2073659030ed2d5ea3f3b8331583d46796c0 commit d09d2073659030ed2d5ea3f3b8331583d46796c0 Author: Tien-Ren Chen <trchen@chromium.org> Date: Fri Mar 16 01:06:26 2018 [Blink] Add fixed-pos counterscroll in PaintLayerClipper for RLS mode The caller of PaintLayerClipper expects the returned clip rect to be in the scrolled space of LayoutView, while the computed clip rect for a fixed-pos layer is in the unscrolled space prior to compensation. The fixed-pos compensation has been done for non-RLS mode, this CL adds the RLS counterpart. BUG= 821279 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I48a92d0614d97c745fe66b1265dce0613514ffc4 Reviewed-on: https://chromium-review.googlesource.com/961643 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Tien-Ren Chen <trchen@chromium.org> Cr-Commit-Position: refs/heads/master@{#543584} [modify] https://crrev.com/d09d2073659030ed2d5ea3f3b8331583d46796c0/third_party/WebKit/Source/core/paint/PaintLayerClipper.cpp [modify] https://crrev.com/d09d2073659030ed2d5ea3f3b8331583d46796c0/third_party/WebKit/Source/core/paint/PaintLayerClipperTest.cpp
,
Mar 19 2018
,
Mar 19 2018
This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 20 2018
Approving merge to M66. Branch:3359
,
Mar 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cee8973f56386ace74fa77b87e81224c04ca7b26 commit cee8973f56386ace74fa77b87e81224c04ca7b26 Author: Tien-Ren Chen <trchen@chromium.org> Date: Tue Mar 20 20:18:05 2018 [Blink] Add fixed-pos counterscroll in PaintLayerClipper for RLS mode The caller of PaintLayerClipper expects the returned clip rect to be in the scrolled space of LayoutView, while the computed clip rect for a fixed-pos layer is in the unscrolled space prior to compensation. The fixed-pos compensation has been done for non-RLS mode, this CL adds the RLS counterpart. BUG= 821279 TBR=trchen@chromium.org (cherry picked from commit d09d2073659030ed2d5ea3f3b8331583d46796c0) Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I48a92d0614d97c745fe66b1265dce0613514ffc4 Reviewed-on: https://chromium-review.googlesource.com/961643 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Tien-Ren Chen <trchen@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#543584} Reviewed-on: https://chromium-review.googlesource.com/971866 Reviewed-by: Tien-Ren Chen <trchen@chromium.org> Cr-Commit-Position: refs/branch-heads/3359@{#352} Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276} [modify] https://crrev.com/cee8973f56386ace74fa77b87e81224c04ca7b26/third_party/WebKit/Source/core/paint/PaintLayerClipper.cpp [modify] https://crrev.com/cee8973f56386ace74fa77b87e81224c04ca7b26/third_party/WebKit/Source/core/paint/PaintLayerClipperTest.cpp
,
Mar 20 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by nyerramilli@chromium.org
, Mar 13 2018