New issue
Advanced search Search tips

Issue 902697 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

CSS: (ghost) resize handle gets stuck

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Steps to reproduce the problem:
1. got to https://design-system.service.gov.uk/components/button/
2. resize browser window
3. observe stuck resize handle position

What is the expected behavior?
resize handle moves

What went wrong?
resize:both css property attached to the iframe

Did this work before? N/A 

Chrome version: 70.0.3538.77  Channel: stable
OS Version: OS X 10.13.6
Flash Version:
 
resizeHandle.gif
1.7 MB View Download
looking through Browserstack, it wasn't an issue in 68, started in 69
Labels: Needs-Triage-M70
Cc: viswa.karala@chromium.org
Labels: Triaged-ET
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on chrome reported version# 70.0.3538.77 and on latest chrome# 72.0.3604.0 using Mac 10.12.6 with sample URL(https://design-system.service.gov.uk/components/button/) provided in comment# 0. As this issue is not seen on M-60 builds, will update the bisect info and other OS behavior soon. Marking this issue as Untriaged and adding Needs-Bisect label to it.

Thanks!
Labels: Needs-Bisect
Labels: -Type-Bug -Pri-2 -Needs-Bisect hasbisect-per-revision Target-70 Target-71 Target-72 RegressedIn-69 M-72 FoundIn-71 FoundIn-70 FoundIn-72 OS-Linux OS-Windows Pri-1 Type-Bug-Regression
Owner: wangxianzhu@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on reported chrome version 70.00.3538.77 and on latest chrome# 72.0.3604.0 using Windows-10, Mac 10.12.6 & Ubuntu 14.04 hence providing Bisect Info

Bisect Info:
================
Good build: 69.0.3475.0 
Bad build: 69.0.3476.0

You are probably looking for a change made after 571250 (known good), but no later than 571251 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/35bea100681d5c1268ec075ba83f715163107cb1..f0498e2265442349ed2b837c09631fb3b9eb237c
Change-Id: I08e3a1f8883584b3a30c4dfa498489df64be012c
Reviewed-on: https://chromium-review.googlesource.com/1117712

@Xianzhu Wang: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!
Components: -UI Blink>Paint>Invalidation
This happens when a composited iframe with resizer resizes (textarea is not affected):
<style>
iframe, textarea {
  display: block;
  width: 200px; 
  height: 200px;
  resize: both; 
  will-change: transform; 
}
</style>
<iframe id="iframe"></iframe>
<textarea id="textarea"></textarea>
<script>
setTimeout(function() {
  iframe.style.width = '400px';
  textarea.style.width = '400px';
}, 500);
</script>

Project Member

Comment 9 by bugdroid1@chromium.org, Nov 10

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/61fc2540a70544c6368823d45a5d7a94235c1024

commit 61fc2540a70544c6368823d45a5d7a94235c1024
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Sat Nov 10 03:14:11 2018

[PE] Don't paint composited resizer twice

The bug was exposed by removal of cache generation mechanism of paint
controller. Before that, objects painted onto different paint
controllers were always implicitly invalidated in one of the paint
controllers due to cache generation mismatch. The bug exposed because we
don't invalidate resizer in the main graphics layer on container resize
if the resizer is composited.

We should not paint composited resizer on the main graphics layer.

Bug:  902697 
Change-Id: Ia6eefe687d79a4a787528c3ccb391c57f649a911
Reviewed-on: https://chromium-review.googlesource.com/c/1329803
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607094}
[add] https://crrev.com/61fc2540a70544c6368823d45a5d7a94235c1024/third_party/WebKit/LayoutTests/paint/invalidation/compositing/composited-iframe-resizer-expected.html
[add] https://crrev.com/61fc2540a70544c6368823d45a5d7a94235c1024/third_party/WebKit/LayoutTests/paint/invalidation/compositing/composited-iframe-resizer.html
[modify] https://crrev.com/61fc2540a70544c6368823d45a5d7a94235c1024/third_party/blink/renderer/core/paint/replaced_painter.cc

Status: Fixed (was: Assigned)
hi there, is there a release date?
Labels: M-71 Merge-Request-71
Status: Assigned (was: Fixed)
M-72 stable release may be too late (https://www.chromestatus.com/features/schedule). Requesting merge into M-71.
cool, thanks
Project Member

Comment 14 by sheriffbot@chromium.org, Nov 11

Labels: -Merge-Request-71 Hotlist-Merge-Review Merge-Review-71
This bug requires manual review: M71 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-71 Merge-Rejected-71

Per comment #6, this is regressed in M69 and M71 is very close to stable promotion. Lets target fix for M72. Pls let me know if there is any concern here. Thank you.
surely regressions should be prioritised?
Status: Fixed (was: Assigned)
Sorry for the regression and only fixing it in M-72.

If feasible, you can workaround the issue by removing '[-webkit-]transform: translate3d(0, 0, 0) from the iframe.
ok, thanks.
will evaluate impact

Sign in to add a comment