Open Bug 270683 Opened 17 years ago Updated 2 years ago

Unable to select text using mouse (no scrolling)

Categories

(Core :: DOM: Selection, defect)

x86
Windows
defect
Not set
normal

Tracking

()

People

(Reporter: relf, Unassigned)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files)

Mozilla linux build 2004111506

To reproduce:
1. Open provided URL
2. Try to select the page content using mouse
3. It possible to select a part of the text within the browser window but no
text below since no scrolling happens
Attached file testcase
selecting text does not cause scrolling with linux trunk 2004111806
this regressed between linux trunk 2004071906 and 2004072005, apparently bug 53966
Assignee: selection → roc
Status: UNCONFIRMED → NEW
Depends on: 53966
Ever confirmed: true
Keywords: regression, testcase
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041119

I don´t see the regression on the URL, but I see it on the testcase.

wfm: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040716 

regressed: BuildID 2004072509
OS: Linux → All
So it's the position: absolute; style that's messing things up.
Attached patch fixSplinter Review
What's happening is that when the user moves the mouse out of the absolute
frame in this testcase, the mouse is not over anything selectable so selection
doesn't change.

This patch solves the bug by making absolutely positioned frames capture the
mouse to themselves. This means that you can no longer start a selection in an
absolute frame and then extend the selection with the mouse to some content
outside the absolute frame. But no-one will miss that, I guess.
Attachment #167057 - Flags: superreview?(bzbarsky)
Attachment #167057 - Flags: review?(bzbarsky)
Won't that patch regress bug 93188?  Given that google-cache's PDF-to-HTML
converter absolutely positions every single line, I do expect people to miss
selection working right with abs pos elements...
hmm.

well then, I'm not sure what to do here
So what normally triggers the scrolling?  That is, why is the fact that the
frame is absolutely positioned relevant here?
Blocks: 271394
No longer blocks: 271394
*** Bug 271394 has been marked as a duplicate of this bug. ***
Comment on attachment 167057 [details] [diff] [review]
fix

r- per comments, at least pending answer to my last question
Attachment #167057 - Flags: superreview?(bzbarsky)
Attachment #167057 - Flags: superreview-
Attachment #167057 - Flags: review?(bzbarsky)
Attachment #167057 - Flags: review-
Okay. What happens here is that when we select the text in the absolute frame
and we go out of the window, mouse capturing is set to the scrolled canvas
(good). The mouse events continue to be received. The view manager decides to
dispatch the events to the scrolled canvas' view because where the mouse is, all
other views have been clipped away by the scrollport view, so it falls back to
the original view to which the event was dispatched (probably bad).
GetFrameForPoint on the canvas frame doesn't check the absolute children so we
decide that the mouse is over nothing, and there's nothing scroll into view, so
we don't scroll.

Note that even if we changed things so that when the canvas is capturing, we
could target the absolute frame with the mouse move events, we'd still have a
problem when the user moves horizontally outside the absolute frame. You can see
this by selecting the absolute text without scrolling and moving your mouse up
and down to the right of the text --- selection won't change.

What happens for normal text is that the captured mouse event, below the window,
is still determined to be over some text or other frame, which gets selected and
the selection scrolsl into view.

I'm still not sure what to do here, especially given the problem in the second
paragraph...
So how does this work for "body { width: 50% }" if we move to the right out of
the body?   That should have the same issues, should it not?
So if I set the "html" to 50% width, if I try to mouse down to the right of the
<html> and drag no selection happens.  If the initial mousedown is within the
<html>, even if I drag to the right out of it things are ok....
Blocks: 279906
QA Contact: selection
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0

I have tested this issue on the latest Firefox release (46.0.1, Build ID: 20160502172042) and the latest Nightly (49.0a1, Build ID: 20160516030211) and I was able to reproduce it. I've opened the testcase from comment 1, selected a part of the content, and holding the mouse button down I've tried to select all the way down the bottom of the page and I was unable to scroll down beneath the browser window. However if you start selecting right from the top of the page, you are able to scroll down to the bottom of the page.

I tried with the provided url, and it is no longer reproducible. However I've visited an article on wikipedia.org and bbc.com and the issue is reproducible just like in the case of the testcase.

This is not reproducible on Mac OS 10.11 and Ubuntu 14.04.
OS: All → Windows

Andre can you reproduce this?

Opening https://bugzilla.mozilla.org/attachment.cgi?id=166415 in Firefox 70 on Fedora 31 using Wayland, I can reproduce the problem.

You need to log in before you can comment on or make changes to this bug.