56602 - (TextareaDrag) [FIX] Drag-scrolling to perform selection in a <textarea> causes whole page to scroll

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect, P3)

Description

[David Hyatt]

Get a textarea with a lot of content.  Start from the top and drag downwards
to select the text.  Keep dragging downwards.  Instead of the textarea
scrolling its contents, the entire page will scroll its contents instead!

Comment 1

[David Hyatt]

Observed on Win32.

Comment 2

[rubydoo123]

assigning to Kin, he knows exactly what the issue is, will have it fixed in no
time, but we are certain pdt would not allow this in for rtm, moving to future

Comment 3

[kinmoz]

I just need to do one extra check to see if the enclosing view scrolled at all
before scrolling the parent scrolled views.

Comment 4

[David Hyatt]

I will a= it if we want to try.

Comment 5

[rubydoo123]

*** Bug 58754 has been marked as a duplicate of this bug. ***

Comment 6

[rubydoo123]

*** Bug 62430 has been marked as a duplicate of this bug. ***

Comment 7

[Blake Ross]

kin, can we get that patch now?

Comment 8

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Noticed this on 1.0.0rc1 on MacOS X (2002041712).  The parent scroll seems to
occur only when the mouse goes beyond the bounds of the parent window.

Comment 9

[Ryan Pavlik]

I found that when in a textarea with more text than the area (so scroll bars
appear/enable), and selecting up, not only does the whole window scroll, the
particular window locks.  It does not update it's cursor when in the document
area (so it shows the two-arrow cursor) and accepts no clicks in the document
area.  Menus and toolbar buttons are still fully funcitonal.  A right-click in
the document area UNFREEZES the window!  Other windows in the same process are
unaffected, and processor usage for the mozilla process is also unaffected. 
Using the task manager to close the offending window leaves the other windows
undisturbed (though windows tries to close the process due to a false "not
responding").

Observed: Writing a bugzilla comment!
Reproducible: Very predictably: display locks every time.
System:
Athlon 500mHz
448 mb memory
Windows 2000 sp2 srp1
Mozilla build 2002071008

Comment 10

[Wesha]

*** Bug 163203 has been marked as a duplicate of this bug. ***

Comment 11

[Ere Maijala (slow)]

So this one's been open almost 2 years now. I start to realize what "will have
it fixed in no time" in comment 2 means..

Comment 12

[Alon Altman]

Get a textarea with a lot of content.  Start from the top 

------- Additional Comment #1 From David Hyatt 2000-10-13 23:46 -------

Observed on Win32.and drag downwards
to select the text.  Keep dragging downwards.  Instead of the textarea
scrolling its contents, the entire page will scroll its contents instead!



------- Additional Comment #2 From [e-mail] 2000-10-17 11:00 -------

assigning to Kin, he knows exactly what the issue is, will have it fixed in no
time, but we are certain pdt would not allow this in for rtm, moving to future


------- Additional Comment #3 From [e-mail] 2000-10-17 11:03 -------

I just need to do one extra check to see if the enclosing view scrolled at all
before scrolling the parent scrolled views.


------- Additional Comment #4 From David Hyatt 2000-10-17 11:16 -------

I will a= it if we want to try.


------- Additional Comment #5 From [e-mail] 2000-11-02 14:52 -------

*** Bug 58754 has been marked as a duplicate of this bug. ***


------- Additional Comment #6 From [e-mail] 2000-12-10 18:51 -------

*** Bug 62430 has been marked as a duplicate of this bug. ***


------- Additional Comment #7 From Blake Ross 2000-12-10 19:03 -------

kin, can we get that patch now?


------- Additional Comment #8 From Bill McGonigle 2002-04-24 12:27 -------

Noticed this on 1.0.0rc1 on MacOS X (2002041712).  The parent scroll seems to
occur only when the mouse goes beyond the bounds of the parent window.


------- Additional Comment #9 From Ryan Pavlik 2002-07-15 20:32 -------

I found that when in a textarea with more text than the area (so scroll bars
appear/enable), and selecting up, not only does the whole window scroll, the
particular window locks.  It does not update it's cursor when in the document
area (so it shows the two-arrow cursor) and accepts no clicks in the document
area.  Menus and toolbar buttons are still fully funcitonal.  A right-click in
the document area UNFREEZES the window!  Other windows in the same process are
unaffected, and processor usage for the mozilla process is also unaffected. 
Using the task manager to close the offending window leaves the other windows
undisturbed (though windows tries to close the process due to a false "not
responding").

Observed: Writing a bugzilla comment!
Reproducible: Very predictably: display locks every time.
System:
Athlon 500mHz
448 mb memory
Windows 2000 sp2 srp1
Mozilla build 2002071008



------- Additional Comment #10 From Wesha [H1B looking for job in Chicago]
2002-08-17 07:50 -------

*** Bug 163203 has been marked as a duplicate of this bug. ***


------- Additional Comment #11 From Ere Maijala 2002-08-17 07:56 -------

So this one's been open almost 2 years now. I start to realize what "will have
it fixed in no time" in comment 2 means..

Bug List: (38 of 203) First Last Prev Next   Show list      Query page     
Enter new bug
This is Bugzilla: the Mozilla bug system. For more information about what
Bugzilla is and what it can do, see mozilla.org's bug pages.
Actions: New | Query | bug # | Reports

Comment 13

[Place Holder]

I had this happen (on Windows XP Mozilla 1.2) and it appeared to "hang" the
window. I had to try selecting other windows, minimizing and restoring the
window and different key input events before I could recover enough to scroll
the text area back into view and get Mozilla to behave as you would expect it
again (otherwise I had a weird mode where I couldn't use the window and had the
wrong mouse cursor pointer, etc.)  Ironically this happened while I was trying
to make a Bugzilla update such as this one I am making now and I wanted copy and
move some text around before the commit.

Comment 14

[James Darpinian]

This bug is much worse than it sounds in the description for several reasons. 
Once you have dragged down to start the autoscrolling, it continues to
autoscroll down on its own until it reaches the bottom of the page.  After the
page scrolls it locks in a very strange way.  You can't click on links, use the
scrollbar, use the mousewheel, or drag-select any text.  You can right-click,
which frees up the mousewheel but doesn't fix the scrollbar.  The only way to
really un-freeze the window is to use the keyboard to scroll back up to the text
edit, which is really non-obvious.  Someone running into this bug for the first
time might be convinced mozilla had crashed, close it, and lose the text they
had been composing in the text edit.

Comment 15

[Daniel Clemente]

Well, when it gets like this -you can't click on any links, you can't use the
whell, etc- pressing ESC cancels the dragging.

Comment 16

[mrpink]

After the parent page is scrolled, pressing page up or page down breaks you out
of the lock up without any real trouble. 

Comment 17

[Andreas Kunz]

*** Bug 200203 has been marked as a duplicate of this bug. ***

Comment 18

[Pascal Chevrel:pascalc]

*** Bug 82162 has been marked as a duplicate of this bug. ***

Comment 19

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 20

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 21

[Mats Palmgren (inactive)]

The problem is more general than <textarea> really.  Drag-select-scrolling
should only scroll the view(s) to make visible what is currently being added
to the selection, then it should stop.  The correct behaviour can be seen in
IE6/WinXP for example. Taking bug since I have a patch that implements this.

Comment 22

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Restricts scrolling to only make the view visible according to comment 21.
As far as I can see this is the exact same behaviour that IE6 has, if you want
to try out the testcases with that UA first.
I have changed the 4th parameter of ScrollPointIntoView() to have a different
meaning than before, from "aScrollParentViews" which meant scroll parent views
unrestricted (this was always PR_TRUE), to "aRestrictedScrolling" which means
scroll restricted when PR_TRUE and the old unrestricted scrolling when
PR_FALSE, I hope that is OK.

Comment 23

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1 (diff -uw)

This is probably easier to read...

Comment 24

[Mats Palmgren (inactive)]

*** Bug 189069 has been marked as a duplicate of this bug. ***

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Mats, can you make your diffs with -p?

The function GetRestrictedScrollingPoint needs a big comment explaining exactly
what it computes.

'twould be nice if you can do that and resubmit the patch ... thanks

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 154207 [details] [diff] [review]
Patch rev. 1

minusing to get this off my queue until the updated patch is available

Comment 27

[Prognathous]

Mats, can you please ask for reviews for your new patch?

Thanks,

Prog.

Comment 28

[Mats Palmgren (inactive)]

From bug 27315 comment 29:

Similar results are encountered with the multiple select, with an added twist:
- if multiple select is partially visible in the currently displayed area of
the window, scrolling down with the mouse left click and held will select all
visible values, but will not scroll the entire window so that the bottom of the
select input field is visible.
- writing text in a textarea that is partially visible does trigger a scroll so
that the bottom of the textarea becomes visible as the cursor  goes down.
(same is valid for going up and sideways but only for input type text and
textarea)

Comment 29

[Daniel Clemente]

*** Bug 192422 has been marked as a duplicate of this bug. ***

Comment 30

[Daniel Clemente]

Also happens with IFRAMEs (bug 192422, has testcase), so this is a more general
issue, as said comment 21

Comment 31

[RNicoletto]

Am I wrong or there's a patch waiting for review since August 2004?

Comment 32

[Boris Zbarsky [:bzbarsky]]

The patch in question was marked review- on August 9, 2004.

Comment 33

[Mats Palmgren (inactive)]

I think this got fixed in a different bug some years ago...