Issue metadata
Sign in to add a comment
|
CSS drop-shadow seems to interfer with transform: rotate
Reported by
dauml...@gmail.com,
Dec 21 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Steps to reproduce the problem: 1. open https://weblogo.terrapinlogo.com 2. Click "Take me to Logo!" 3. Enter the following commands at the bottom: PPROP 0 "SHADOW 5 PPROP 0 "GLOW TRUE FD 50 RT 1 What is the expected behavior? The drop shadow remains underneath the rotated image, and the image is not clipped What went wrong? The image is partially clipped, but only when rotated Did this work before? N/A Does this work in other browsers? Yes Chrome version: 63.0.3239.84 Channel: stable OS Version: 10.0 Flash Version: The image vanishes entirely if you enter this command to show another image: TELL 1 ST It reappears if you hide the other image again with HT The clipping border is a fixed area. The attached screenshot has a vertical size of 1080. You can drag the bottom border of the "Graphics" panal up and dow to watch the clip effect. The parent DIV has an absolute position with negative offsets, and the image has again an absolute position. Works fine on Edge and Firefox, latest builds as of today (12/20/17). The problem also seems to appear on Mac OS High Sierra according to a customer. Tested on an Asus Chromebook: with 60.0.3112.114, no clipping, all was well; with 62.0.3202.97, clipping, but as a sudden disappearance when shrinking the Graphics panel vertically.
,
Dec 21 2017
,
Dec 28 2017
This works in head and 64. Fails in 63. I suspect it would be too risky to merge a fix to 63. We probably should add this case to the test suite.
,
Dec 28 2017
,
Dec 29 2017
daumling@ Thanks for the issue. Able to reproduce this issue on Windows 10 and Mac OS 10.12,6 on the latest Stable 63.0.3239.108. Issue is not reproducible on the latest Canary 65.0.3307.0 and Beta 64.0.3282.39. Issue is also not observed on Ubuntu 14.04. Reverse Bisect Information: ========================== Good Build: 64.0.3280.0 Bad Build : 64.0.3279.0 As the issue is fixed on the latest Canary, executing the per-revision script with reverse bisect and below is the changelog URL. Changelog URL: --------------- https://chromium.googlesource.com/chromium/src/+log/b4c579cc9e9c123839a0674bda83b4a91276c905..04f4824dd3e9ff81d39072d83daecee65a4b9781 From the above Changelog URL, suspecting the below change for this issue. Reviewed-on: https://chromium-review.googlesource.com/794019 skia-deps-roller@ Can you please check if this issue is related to your change, else help us in assigning to the right owner. Adding ReleaseBlock-Stable as it is a recent regression. Please feel free to remove the same if it is not applicable. Thanks...
,
Jan 2 2018
,
Jan 2 2018
Based on offline chat Stephen we can live with this issue on M63, Since we are pretty close to M64 stable launch and the bug is fixed or doesn't reproducible on M64 and above Chrome versions there isn't any action required. Please correct me if I am wrong.
,
Jan 2 2018
Re comment 8: yes that is correct. Removing releaseblock-stable. What remains now is to add the testcase.
,
Jan 19 2018
Ping - Mike, this is still marked as a P1. Could you verify which patch fixed the issue and that it's well tested?
,
Jan 19 2018
This is the first time I've seen this bug. Do we think it's caused by 2017-11-28 mtklein remove clip-bounds query overrides from SkColorSpaceXformCanvas ?
,
Jan 19 2018
Oh, do we think that CL _fixed_ some issue? That's much more likely. Those clip-bounds query overrides were a bad, bug-prone idea. That CL was designed to be very, very easy to backport if necessary.
,
Jan 19 2018
The bisect strongly indicates that, but needs confirmation.
,
Jan 19 2018
To clarify: the bisect shows that your CL likely fixed the testcase in comment 5.
,
Jan 24 2018
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dauml...@gmail.com
, Dec 21 2017