Open
Bug 270683
Opened 20 years ago
Updated 2 years ago
Unable to select text using mouse (no scrolling)
Categories
(Core :: DOM: Selection, defect)
Tracking
()
NEW
People
(Reporter: relf, Unassigned)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
1.82 KB,
text/html
|
Details | |
2.43 KB,
patch
|
bzbarsky
:
review-
bzbarsky
:
superreview-
|
Details | Diff | Splinter Review |
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
Comment 1•20 years ago
|
||
testcase |
selecting text does not cause scrolling with linux trunk 2004111806
Comment 2•20 years ago
|
||
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
Comment 3•20 years ago
|
||
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
Comment 4•20 years ago
|
||
So it's the position: absolute; style that's messing things up.
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)
![]() |
||
Comment 6•20 years ago
|
||
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
![]() |
||
Comment 8•20 years ago
|
||
So what normally triggers the scrolling? That is, why is the fact that the
frame is absolutely positioned relevant here?
Comment 9•20 years ago
|
||
*** Bug 271394 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 10•20 years ago
|
||
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...
![]() |
||
Comment 12•20 years ago
|
||
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?
![]() |
||
Comment 13•20 years ago
|
||
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....
Updated•15 years ago
|
QA Contact: selection
Assignee: roc → nobody
Comment 14•9 years ago
|
||
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
Comment 15•5 years ago
|
||
Andre can you reproduce this?
Comment 16•5 years ago
|
||
Opening https://bugzilla.mozilla.org/attachment.cgi?id=166415 in Firefox 70 on Fedora 31 using Wayland, I can reproduce the problem.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•