New issue
Advanced search Search tips

Issue 825253 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 762709
Owner:
Closed: Mar 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Resize handle not responsive when Textarea is disabled and scrollbar is rendered.

Reported by hafe...@gmail.com, Mar 23 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36

Steps to reproduce the problem:
1. Enter text in a (default-styled) textarea and disable it.
2. Decrease the disabled textarea's height (via the resize handle) so the vertical scrollbars appear.
3. Mouseup off the handle and try to resize the textarea again via the resize handle. It is not possible.

What is the expected behavior?
Disabled textareas with scrollbars should be able to be resized by their bottom-right resize handle.

What went wrong?
Instead of the expected behavior, I cannot resize it once it is resized to a height that causes the scrollbars to render.

Did this work before? N/A 

Chrome version: 65.0.3325.162  Channel: n/a
OS Version: 10.0
Flash Version: 

Additionally, the entire right side of the textarea (scrollbars and resize handle) no longer accepts right-click as a valid action.

I have created a very simple testbed here: https://jsfiddle.net/haferje/zgf695vh/3/
 

Comment 1 by hafe...@gmail.com, Mar 23 2018

Sorry, this should have been filed under "component:Blink>Forms>Textarea".

Comment 2 by ajha@chromium.org, Mar 26 2018

Components: -UI Blink>Forms>Textarea
Labels: Needs-Triage-M65

Comment 3 by fotoku...@gmail.com, Mar 27 2018

I can confirm that behaviour on Linux (Mint) with Chrome 65.0.3325.181
Labels: Triaged-ET
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on chrome reported version 65.0.3325.162, but the same is not seen on latest chrome version 67.0.3381.0 using Windows-10. Hence working on Reverse Bisect, will update the Bisect information and behaviour of the other OS later. Hence marking it as Untriaged.

Thanks!
Components: Blink>Scroll
Labels: -Type-Bug -Pri-2 ReleaseBlock-Stable M-65 Target-65 FoundIn-65 hasbisect OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: dtapu...@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on reported version 65.0.3325.162 and the same is not seen on latest canary & Beta 67.0.3381.0 & 66.0.3359.45 using Windows 10, Mac 10.12.6 & Ubuntu 14.04, as the issue is seen in branch builds hence providing change log from omahaproxy
Note: Issue is also seen on latest stable 65.0.3325.181 

Reverse Bisect Info:
================
Last Bad build: 66.0.3359.18
First Good build: 66.0.3359.19

Change Log: https://chromium.googlesource.com/chromium/src/+log/66.0.3359.18..66.0.3359.19?pretty=fuller&n=10000
Commit: https://chromium.googlesource.com/chromium/src/+/ce2bae2aa8e3fd9a84ac0b8feee1bb67db3b7b5a

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

@Dave Tapuska: Please confirm the issue and help in re-assigning if it is not related to your change, please help in merging it to M-65 if applicable
Adding ReleaseBlock-Stable as it seems recent break, feel free to remove it if not applicable.

Thanks!
Mergedinto: 762709
Status: Duplicate (was: Assigned)
65 isn't taking merges of this fashion and it is fixed in 66. So there is nothing to be done. Marking as duplicate.

Sign in to add a comment