Issue 762708  has been merged into this issue.

Repro: 61 Stable on macOS
Not repro: 63 canary on Windows and macOS

So, it seems this was already fixed.

Normal and reverse bisect would be helpful.

Able to reproduce the issue on windows 7 , mac os 10.12.6 and ubuntu 14.04 using chrome M61 #61.0.3163.79 and M63 #63.0.3207.0.

This is a regression issue broken in M61.

Using the per-revision bisect providing the bisect results,
Good build: 61.0.3141.0(Revision: 482153).
Bad build: 61.0.3142.0  (Revision: 482491).

You are probably looking for a change made after 482440 (known good), but no later than 482441 (first known bad).

CHANGELOG 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/d654734a905602faa2dd33b7a60f06fd80efcdfb..a348403ddc19ee7bb93c38e6dda500c54d12e9d6

From the CL above, assigning the issue to the concern owner 

@Chris Harrelson - 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.

Reviewed-on: https://chromium-review.googlesource.com/547366

Thanks!

Making the PaintLayer self-painting causes hit testing to stop working for the
resizer. Trying now to see why.

The issue is that disabled form controls eat mouse events, and the code
to check whether the event should be targeted at the resizer happens after giving
the form control a chance to handle the event.

There is an runtime feature (in development?) that will change the eating
behavior:
--enable-blink-features=SendMouseEventsDisabledFormControls
Turning on this feature fixes the bug ( issue 762709 ).

An alternative solution to the bug is to offer the event to the resizer before
the form control.

The exact use-case in this bug regressed because I changed scrollable PaintLayers to
always be self-painting, rather than only due to other factors such as positioning
or compositing, which was the prior behavior.

Dave, sending to you as author of the flag above.

I think use counter on sending mouse events to disabled form controls in that we can probably ship it ok. I'll pull together an intent to ship for it. 

I don't know if we need spec text around it since our behavior wasn't specified anywhere. But the intent to ship will target chrome 63.

 Issue 769309  has been merged into this issue.

 Issue 771658  has been merged into this issue.

dtapuska@
Is there any update? Is the target version still M63?

This is fixed when experimental web platform features are enabled. We are working at adding metrics to determine if we can send all mouse events to disabled form controls. Unfortunately this was blocked based on interoperability concerns.

If this is serious we could investigate trying to fix it without the sending mouse events to disabled form controls but it isn't clear that it is. 

we have a customer with this issue:
case# 13924488
enabling flags or changing the shortcut is not an option for them (security issues)
could you please find a solution ?

> If this is serious [...] but it isn't clear that it is

It isn't clear that this is serious?? How can rendering a UI element unusable not be serious?

 Issue 789166  has been merged into this issue.

dtapuska@,
sorry to bother you, is the target version still M63 ?

dtapuska@, customer is asking for update, can you please provide?

Sorry I don't have an update. Sorry the progress is slow on this. The cause of the regression was done to explicitly certain issues. And in order to fix the resizing issue we need to ship a new feature to the web platform which there has been some uncertainty about.

Hi all, do we have any updates on this? Thanks!

Hi dtapuska@, thank you for your update in #17. Do we have any ETA for a fix/new feature?   

We added new metrics in 65 to hopefully be able to gather data as to whether we can ship the feature.. https://chromium-review.googlesource.com/c/chromium/src/+/847424

Hi all, do we have any updates? Thanks!

Hi all, 
the customer of case# 13924488 (big customer in Japan) is asking for updates on this bug, do we have some information I can share with the customer ?
what is the target version for this fix ?

Unfortunately the metrics are relatively high. We need to come up with an alternate plan here to ship the feature. I'll look at whether we can fix this bug separately and decouple it from shipping the feature that fixes it in experimental mode. Hopefully some time in m67.

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

commit 9e011ceac6b9848100fd845c6f9590bd768d85f5
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Tue Mar 06 23:17:12 2018

Fix resizing on disabled form controls.

Events would get marked as consumed when on top of the resize controller.
Deal with that situation so that we allow the resize to occur on
disabled form controls.

BUG= 762709 

Change-Id: I17f8ae25541f9e4665d4a4bbcfef9e719f12f454
Reviewed-on: https://chromium-review.googlesource.com/951911
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541234}
[modify] https://crrev.com/9e011ceac6b9848100fd845c6f9590bd768d85f5/third_party/WebKit/Source/core/input/EventHandler.cpp

Verified the fix on Mac 10.13.1, Windows-10 and Ubuntu 14.04 using Chrome version #67.0.3364.0 as per the comment #0.
Attaching screen cast for reference.
Observed that the Textarea can be resized with scroll bars.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue on reported chrome version.

Thanks...!!

Deleted: 762709 CL Verification.mp4 1.7 MB

	762709 CL Verification.mp4 1.7 MB View Download

Your change meets the bar and is auto-approved for M66. Please go ahead and merge the CL to branch 3359 manually. Please contact 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

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

commit ce2bae2aa8e3fd9a84ac0b8feee1bb67db3b7b5a
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Thu Mar 08 14:56:35 2018

Fix resizing on disabled form controls.

Events would get marked as consumed when on top of the resize controller.
Deal with that situation so that we allow the resize to occur on
disabled form controls.

BUG= 762709 
TBR=dtapuska@chromium.org

(cherry picked from commit 9e011ceac6b9848100fd845c6f9590bd768d85f5)

Change-Id: I17f8ae25541f9e4665d4a4bbcfef9e719f12f454
Reviewed-on: https://chromium-review.googlesource.com/951911
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#541234}
Reviewed-on: https://chromium-review.googlesource.com/955742
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#94}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/ce2bae2aa8e3fd9a84ac0b8feee1bb67db3b7b5a/third_party/WebKit/Source/core/input/EventHandler.cpp

marcore@ This should be fixed in canary and has been merged into M66. Please have the customer verify that it addresses their issue by testing the canary channel. 

M66 stable release is ~Apr 17th

Verified the fix on Mac 10.13.1, Windows-10 and Ubuntu 14.04 using Chrome version #66.0.3359.22 as per the comment #0.
Attaching screen cast for reference.
Observed that the Textarea can be resized with scroll bars.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue on reported chrome version.

Thanks...!!

Deleted: 762709 CL Verif.mp4 970 KB

	762709 CL Verif.mp4 970 KB View Download

 Issue 825253  has been merged into this issue.