1600379 - user-select:none inside overflow:auto prevents scrolling with arrow keys

Status: NEW

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[felix.dietze]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

Place a large <div> with user-select:none inside a small div with overflow:auto and try to scroll the inner div with arrow keys.

jsfiddle: https://jsfiddle.net/h91eduj2/2/

<div style="height: 200px; overflow:auto; border: 1px solid black">
  <div style="height: 800px; user-select: none;">
    <p>Click here, then scroll with arrow keys.</p>
    <p>It works in Chrome, but not in Firefox.</p>
    <p>Firefox: If you disable <b>user-select:none</b> via inspector, scroll with arrow keys and then reenable it again, it works correctly: Text is not selectable but still scrollable ith arrow keys.</p>
  </div>
</div>

Actual results:

It does not scroll.

Expected results:

It should scroll like without user-select:none.

Comment 1

[Cameron McCormack (:heycam)]

Masayuki, what do you think the correct behavior is here? It seems like Chrome is tracking some additional focus state or something?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, interesting case. I think that the <div> element should be scrollable with keyboard because user-selection does not limit whether elements can have focus or not.

I think that even if user-selection is none, nsFrame needs to keep handling selection here to call nsFrameSelection::HandleClick(). Then, nsFrameSelection::TakeFocus() should only store clicked position with nsRange instance to track any DOM mutation. Then, nsFrameSelection should have a method to return scroll target of key navigation, if the nsRange is nullptr, use GetPrimaryFrameForFocusNode() like now. Otherwise, use the container of the nsRange. Finally, nsFrameSelection needs to clear the nsRange if when Selection is changed actually.

Ccing somebody who may have another idea.

Comment 4

[Daniel Holbert [:dholbert]]

Note: duplicate bug 1674145 has a case where this caused an issue on a real site. It's got some additional testcases to demonstrate our behavior-difference (vs. Chromium/WebKit) here, too; see e.g. attachment 9243762 [details] and bug 1674145 comment 13 (which has instructions/notes on attachment 9243774 [details]).