Closed Bug 62431 Opened 24 years ago Closed 19 years ago

Mousewheel should only scroll scrollable textareas

Categories

(Core :: XUL, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

Attachments

(3 files)

The mousewheel should only scroll a textarea if it has scrollbars. It currently tries to scroll it even when it doesn't, which means nothing happens if the cursor happens to be over, say, an empty textarea.
QA Contact: jrgm → janc
This should only be happening if the text area has focus, I would think...
Accepting, although I don't see this one as really high priority.
Status: NEW → ASSIGNED
OS: Windows ME → All
Hardware: PC → All
Target Milestone: --- → mozilla1.0
This applies to single-line text fields, too. Many times a day I curse at mozilla in bugzilla pages because I type something, then try to wheel-scroll, then realize that I have to click outside the text field first. It would SO enhance usability if this was fixed ... can I help?
Summary: Mousewheel should only scroll textarea if it has scrollbars → Mousewheel should only scroll text control if it has scrollbars
See also bug 27771, on the same problem as it relates to page up/down. Bryner suggests that nsGfxTextControlFrame2::GetScrollableView should return the parent if the text conrol is not scrollable, which sounds very sensible, and I'm going to play with that and see if it fixes the problem (with luck, it'll fix both bugs).
I have a fix for the input field part. I'm not yet sure how to determine if the textarea overflows.
Assignee: bryner → blakeross
Status: ASSIGNED → NEW
Summary: Mousewheel should only scroll text control if it has scrollbars → Mousewheel should only scroll scrollable textareas
Just realized that ::GetClosestScrollableView needs to be returning an NS_IMETHOD for correctness (per its prototype). fixed. by the way, this doesn't fix the pgup/dn bug. GetScrollableView is never reached, probably because editor is bailing somewhere beforehand.
Status: NEW → ASSIGNED
errr, NS_IMETHODIMP.
r=bryner
Priority: P3 → P1
Target Milestone: mozilla1.0 → mozilla0.9.1
not my area, best guess reassigning to jrgm
QA Contact: janc → jrgm
*** Bug 80014 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
See also bug 42313, Unable to scroll with mousewheel over objects contained in IFRAMEs.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work. If anyone disagrees with the new target, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Priority: P1 → --
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0.1
removing Mozilla1.01 target
Target Milestone: mozilla1.0.1 → ---
*** Bug 140074 has been marked as a duplicate of this bug. ***
ok it works now
This caused bug 209807
*** Bug 185121 has been marked as a duplicate of this bug. ***
WF in current trunk build, shouldn't this be resolved WFM?
WFM too Please reopen if you can reproduce with a trunk build
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: