Closed Bug 140074 Opened 22 years ago Closed 21 years ago

scroll wheel is scrolling page, not textarea, when focussed on textarea

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED DUPLICATE of bug 62431

People

(Reporter: msgport, Assigned: bryner)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc1) Gecko/20020425
BuildID:    2002042506

The use of middle button to scroll the page fails when the caret input is focues
at a multi-line text input box (not single line input)

Reproducible: Always
Steps to Reproduce:
1. Get a page with multi line text input
2. type something in the box (and don't lose the focus)
3. scroll using the middle button

Actual Results:  fails to work

Expected Results:  Should also be able to scroll
Confirmed Win2000sp2 2002042406-1.0 branch.

Looks like the sort of thing someone would claim as a feature-not-a-bug. Though
then I'd expect the scroll wheel to move the caret back and forth through the
text (my phone, a Sony [Ericsson] CMD-J6, does this for entering SMS text
messages), though probably only on the basis of 'intuitive is what is expected'.

I would suggest 'User Interface Design' as the component.

I'm not sure this rates as 'major' ...
Sorry but I just wish to clarify. Maybe my words are not clear enough. Scroll
does not move the caret, but SCROLL the page. this works when the input text
field is single line.
What mouse are you using and what driver + version ? I can't test but
judging from bugzilla this should work.
Summary: Failure to use the middle scroll of mouse in multi line text input → scroll wheel is scrolling page, not textarea, when focussed on textarea
I am just using simple PS/2 mouse that runs without any drivers...

Just a simple general compatible mouse...
This Win2k box has three mice connected to it!

1. HP 5185-2485 optical mouse (Microsoft USB HID-compliant driver 5.0.2183.1)
2. Genius Netscroll+ ordinary mouse with ball (Microsoft PS/2 driver 5.0.2183.1)
3. Wacom graphics tablet (Microsoft USB HID-compliant driver 5.0.2183.1)

and this bug happens consistently with all three.

I really don't think it's weird stuff in the mouse driver ... or if it is, with
the generic MS mouse driver, it's something we'd pretty much have to work with/
around.
The reason I asked was because I couldn't find a duplicate, and this
is bound to be a dupe unless it's a very recent regression ...
It's not recent... I've seen this since I get my first copy of Mozilla abt 2
weeks ago. Just that I haven't use to the bugzilla system.
Hm, I agree with David, that this is a feature and not a bug.

Let us take _this_ page.

If I have the cursor in the "Keywords"-input-field, mouse-wheel will scroll the
page, and that is good, because there is no reason to scroll any other thing.

If the cursor is in the "Additional Comments"-input-field, the mouse wheel will
scroll the text in this input field, if the text has more lines than the input
field (scrollbar visible), and it will scroll nothing if the written text is
short enough (no scrollbar at the input-field visible). I think that is ok.

It could  be discussed, weather mozilla should be able to decide:
- short text, scroll page
- long text, scroll text
I agree now... so can it be realized? I think it is a good idea to have it more
user friendly... we have the direct mind that for sure, what scroll should do rite?
Reporter: 
is this still a problem with mozilla 1.1b ?
wfm with win2k build 20020724 and MS Intellimouse Explorer
WFM with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020722
This bug's component should really be "XP Toolkit/Widgets".

I think that IE works very well in this regard.  If the textarea has enough text
that it needs to scroll, then the mousewheel scrolls the textarea.   If the
textarea has a short text (no vertial scrollbar, or vertical scrollbar disabled)
the mousewheel scrolls the main window.

I haven't dug very far into the code, but the necessary change would be in
nsEventStateManager::GetNearestScrollingView()  Right now it merely checks the
view to see if it supports scrolling.  If I get a chance, I may be able to put a
patch together in the next week or so.
Status: UNCONFIRMED → NEW
Ever confirmed: true
XP toolkit
Assignee: Matti → jaggernaut
Component: Browser-General → XP Toolkit/Widgets
QA Contact: imajes-qa → jrgm
-> bryner
Assignee: jaggernaut → bryner
is this still happenning ?
May have been fixed with fix for bug 33732.
setting to minor, although it might be an enhancement.
Severity: major → minor
*** Bug 207144 has been marked as a duplicate of this bug. ***
This is a dupe of bug 62431

*** This bug has been marked as a duplicate of 62431 ***

*** This bug has been marked as a duplicate of 62431 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.