1037792 - Cannot scroll by dragging the scrollbar thumb after doing Ctrl+A (Select All)

Status: NEW

(Firefox :: PDF Viewer, defect, P3)

Description

[kenkon]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

1. Open any PDF (e.g. http://rsb.info.nih.gov/ij/docs/pdfs/examples.pdf)
2. Right-click and choose "Select All" or do Ctrl+A
3. Try dragging the vertical (or horizontal) scroll bar's thumb.


Actual results:

1. The document is opened.
2. Everything is selected including text that is not part of the PDF document but is part of the viewer.
3. The thumb does not move. The page does not scroll. The mouse pointer icon changes to an interdiction sign (black circle with diagonal line). An image preview of the page follows the mouse pointer until the left mouse button is released.


Expected results:

The page should scroll by dragging the thumb. All other scrolling methods work.

Comment 1

[Petruta Horea [:phorea], Desktop QA]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

Reproduced using latest Nightly 20140727030204.

Comment 2

[Yury Delendik (:yury)]

Also reported at https://github.com/mozilla/pdf.js/issues/3220 and https://github.com/mozilla/pdf.js/issues/1995, and blocked by bug 734180 and bug 739396

Comment 3

[Patrick Wigmore]

I can reproduce the bug in Firefox 68 on Windows and Linux, but it is also possible to get the same behaviour of the scrollbar by being a bit imprecise with the mouse click at the start of an attempt to click-and-drag of the scrollbar. Click on the grey background of pdf.js, and drag from there onto the scrollbar. It seems this causes something in the pdf.js UI to become invisibly selected, putting the software into the state where the bug occurs. I find that selecting some text in the PDF or clicking anywhere on the page to clear the problematic invisible selection restores normal scrolling behaviour.

In the buggy state, the scrollbar scrolls a small distance before abruptly halting the scroll, at which point the mouse cursor changes. On Windows, the cursor changes to a "not-allowed" cursor, as described in the original bug report. On Linux, the behaviour is identical except it changes to a "grabbing" mouse cursor. This matches the cursors used by Firefox on these platforms when dragging selected text over an item that the selected text cannot be dropped onto.

Comment 4

[Andrei Purice]

Reproduced on latest Nightly build 71.0a1 (2019-09-12) on Windows 7 x64.

Comment 5

[Augusto Pace]

Hi,

I was able to reproduce this issue on Windows 10 with Firefox version 75.0a1 (2020-03-03) (64-bit). Marking that flag as affected.

Comment 6

[Patrick Wigmore]

I played around with Developer Tools to see what I could learn about this bug.
I discovered a few things:

1. Thumbnails in the sidebar do not have style user-select: none, and get
   selected (even when hidden).
2. It seems as though elements with display: none can be user-selected even if
   they have user-select: none. For example, the buttons on the sidebar
   toolbar, and the items in the Tools drop-down menu ("Go to First Page" "Go to
   Last Page", "Rotate Clockwise", etc.) Not sure if display: none is the
   only/exclusive trigger here.
3. It is possible to select the text in the 'page number' and 'find text' inputs
   that exist in the DOM, and this can get included in Ctrl+A and accidental
   selections.
4. Even if I use Firefox Developer Tools to delete all of the GUI controls from
   the DOM, leaving only outerContainer, mainContainer, viewerContainer and its
   contents, and then delete the annotation layers and canvas layers from each
   PDF page, leaving only the textLayers, the bug is still evident.

Taking a sledgehammer-to-crack-a-nut approach, I tried using Firefox Developer
Tools to add CSS rules:

#outerContainer {
    user-select: none;
}

and

.textLayer {
    user-select: text;
}

to disallow selection on more or less everything except class textLayer.

This seems to cause fairly usable behaviour, though obviously it's just a quick
experiment with no formal testing and may have unintended consequences.

I am inexperienced, so for me this raises more questions than it answers:
How is user-select supposed to work? Is there a good reason why pdf.js
currently applies user-select only or mainly to leaf nodes in the DOM tree
rather than in broad strokes to the whole tree? Is it good/bad practice to apply
user-select in broad strokes to whole trees of elements, with subtree
exceptions?

Hopefully this is useful information for someone who knows better what to do
with it.

Comment 7

[Florencia Di Ciocco, NI to vbalducci]

Hi, this is still present in 82.0a1 (2020-09-12) (64-bit).