Issue metadata
Sign in to add a comment
|
Borders acting strangely since 63
Reported by
bran...@promotionsonly.com.au,
Dec 12 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. Drag the image 2. The bottom border of the image is missing but if you navigate to the bottom of http://getskeleton.com/examples/landing/ and drag the exact same images at a different size the right border disappears 3. Additionally, the right border on the element disappears when the flex container is changed from row to column. What is the expected behavior? Borders should all be visible I guess. These 2 examples are just one of many (atleast 7-10) I've noticed since my first day on 63. What went wrong? Borders being cut off when they shouldn't be. Did this work before? Yes 62 Does this work in other browsers? Yes Chrome version: 63.0.3239.84 Channel: stable OS Version: 10.0 Flash Version: I've been seeing weird behaviour with all different types of/unrelated borders since 63 so my main question is what changed? p.s i think it's silly to have the Does this feature work correctly in other browsers tip about using browserstack because not everyone has the same budget as google
,
Dec 12 2017
,
Dec 12 2017
The drag image is being filtered to reduce its size, and that is filtering out part of the border. We changed the filtering behavior to always use faster filters for resize of drag images, which is almost certainly the reason why the image is losing it's apparent border when dragged. You might be seeing border width changes because we changed the snapping and sizing behavior of sub-pixel borders. But that was older than M-63. I could not reproduce step 3 above, with the change from row to column. That did not change my layout of the page. Can you provide video showing the problem to be sure we're trying to reproduce correctly?
,
Dec 26 2017
The NextAction date has arrived: 2017-12-26
,
Jan 2 2018
Closing due to lack of feedback and plausible explanation of the change.
,
Mar 8 2018
It's fine to bother us. There have been lots of DragImage changes in the last few releases, so they could be causing this issue. Where can we try to reproduce the behavior? Site? Platform?
,
Mar 8 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 8 2018
SheriffBot, what are you doing?
,
Mar 26 2018
The NextAction date has arrived: 2018-03-26
,
Mar 26 2018
Closing again due to no response to comment #7, looking for site and platform information for comment #6. Provide reproduction info and we'll reopen (again).
,
Mar 27 2018
Apologies but this has since been fixed in the last Chrome update, I believe it was during patch 180 to 181, don't know how I missed the two email notifications...
,
Mar 27 2018
No problem at all. The bug triage process is working as intended. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by gov...@chromium.org
, Dec 12 2017Labels: M-63 Needs-Triage-M63