New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 800425 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

Contenteditable element does not scroll horizontally with the mouse

Project Member Reported by einbinder@chromium.org, Jan 9 2018

Issue description

What steps will reproduce the problem?
(1) Go to https://jsfiddle.net/oobry4qy/2/
(2) Attempt to scroll the first text box horizontally with the mouse.

What is the expected result?
It should scroll the div horizontally

What happens instead?
The scroll position never changes

This works in Edge and WebKit. The desired behavior can be observed with the input element underneath. This bites us in DevTools where our text inputs with autocomplete are contenteditable divs.
 
Cc: einbinder@chromium.org sc00335...@techmahindra.com
 Issue 800038  has been merged into this issue.

Comment 2 by yosin@chromium.org, Jan 10 2018

Labels: -Type-Bug -Pri-2 Pri-3 Type-Feature
Status: Available (was: Untriaged)
Note: Chrome and Firefox behaves same.

There are two options to address this issue:

1. Change hit test to handle overflow:hidden + content editable as overflow: scroll
2. Expose ::scrollbar; needs to be standardized

Note: Blink uses ::scrollbar.

Inner editor of INPUT element is implemented with "overflow-x: scroll;" and
hidden scrollbar thumb[1]

[1] LayoutTextControlSingleLine::CreateInnerEditorStyle()
  scoped_refptr<ComputedStyle> no_scrollbar_style = ComputedStyle::Create();
  no_scrollbar_style->SetStyleType(kPseudoIdScrollbar);
  no_scrollbar_style->SetDisplay(EDisplay::kNone);
  text_block_style->AddCachedPseudoStyle(no_scrollbar_style);
  text_block_style->SetHasPseudoStyle(kPseudoIdScrollbar);

Comment 3 by yosin@chromium.org, Jan 10 2018

Third option is change LayoutBlock::StyldDidChange() to change style as
inner editor of INPUT element when overflow:hidden + user-modify != read-only.
Coming from https://bugs.chromium.org/p/chromium/issues/detail?id=800038  

If it's ok with the chromium/blink team, I'll still like to implement the fix once an approach is decided. 
Updated fiddle to https://jsfiddle.net/5u3a52zj/3/ to show there's also some discrepancy between text areas in the different browsers.

In Webkit: Every example in the fiddle scrolls.
Chrome/Firefox: content editable doesn't scroll but neither does a text area with overflow hidden. So it behaves similar to content editable.
Edge: See #1 (but not sure about text area)

I'm going to go do some digging and reading to see if there's clear guidance on how these feature should work in the spec/previous discussions/etc...

If the text area seems unrelated let me know. Trying to be helpful but I also don't want to distract from the actual issues - To me, they feel like they're behavior should be consistent too.


Project Member

Comment 6 by sheriffbot@chromium.org, Jan 14

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment