Closed Bug 29244 Opened 26 years ago Closed 25 years ago

wheel mouse issue over textarea

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla0.9

People

(Reporter: harm.verhagen+bugzilla, Assigned: bryner)

References

(
URL
)

Details

Overview Description: when looking at a page (for example http://bugzilla.mozilla.org/show_bug.cgi?id=29005) and you scroll whith the mouse wheel. the scrolling stops as the mousepointer comes over a textarea ( just below 'Additional Comments:' Steps to Reproduce: 1)open page http://bugzilla.mozilla.org/show_bug.cgi?id=29005 2)use wheelmouse to scroll down 3) Actual Results: page srolls and when mouse pointer is over textarea below 'Additional Comments' the scrolling stops. If you move mouse out of textarea you can continue scrolling. Expected Results: the page keeps scrolling even when mouse comes over a textarea. If you click inside a textarea then the mousewheel is used for scrolling inside the textarea. Reproducibility: every time Build Date & Platform Bug Found: Mozilla/5.0 (X11; N; Linux 2.2.14 i686; en-US) mozilla-i686-pc-linux-gnu.tar.gz 23 -feb 2000 Additional Builds and Platforms Tested On: mozilla-i686-M13.tar.gz -> same bug netscape-communicator-4.7-4 -> same bug Additional Information: I guess this 'feature' is in because you want to enable wheel scrolling inside a textarea when entering text. However scrolling over a html-page should not stop over a text area when you a re not editing text in that text area ( when you have not clicked inside the textarea )
Moving to more appropriate people.
Assignee: shuang → don
Component: User Interface: Design Feedback → XPApps
QA Contact: elig → janc
That's not a bug. NN 4.x makes it the same way (IE keeps scrolling). The point is when mouse is over a textarea and you are trying to scrollon it - scrolls the _textarea_ (in the area), not the whole page. And thats the best way it must function.
comments from h.verhagen@chello.nl I agree with you, that a wheel mouse should scroll inside a textarea. _but_ only if you are actually working in the textarea, editting , inserting etc. If you are not actually working in the textarea the page should scroll.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I argee with this.
*** Bug 34158 has been marked as a duplicate of this bug. ***
This problem is also a bit more widespread. Scrolling with the mouse (though that's currently not working at the moment) also stops over normal textboxes. This is entirely unnecessary as normal form input textboxes aren't multiline anyways. Thus, there'd be no need to scroll down (or anywhere) within them with the mouse wheel. Adding myself to cc list, changing platform and OS to All, this problem isn't confined to just Linux
OS: Linux → All
Hardware: PC → All
Thought: should it only scroll in a text area if the mouse has been clicked on something in that text area? That way you don't have to worry about it the text area is a multi-line or single-line its just what area is currently selected? I believe this is the way current navigator handles it, atleast in windows.
In M15 the behaviour seems te be changed to that a page scroll with the wheel mouse does not stop over a textbox. Note: it is also not possible to scroll inside a (multiline) textbox anymore. I think this behaviour is better than when i reported this bug. ( page scrolling stopped over any textbox, editting or not ) Although It is not the best way (to my humble opinion). If one is working in a textbox it should be possible to wheelscroll throuth the textbox.
hasn't this been FIXED for awhile now?
Reassigning as per Don
Assignee: don → bryner
This is an old bug, and has already been fixed. The issue of what exactly should get scrolled when the pointer is over a textbox is an open question. What it's currently doing is the same as what IE5 does.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Hmmm. While it *is* doing what IE does, it's not doing what Nav4.x does, and while Nav4.x. is not perfect, it is more versatile (usefull) than IE5. As I understand from the previous comments in this bug, the document should continue to scroll past a text box whether the mouse is over it or not unless the text box has focus (has been clicked in.) Is this correct? Since the issue is not resolved, I can't verify this as fixed (sorry.) reopening bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
We don't do what IE does at all (at least on win32). IE is infinitely smarter than us. Not only does it not stop scrolling the page if the mouse happens to pass over the textarea, but it doesn't even stop scrolling the page if the textarea has focus, unless there's enough content (text) in the textarea to make it scrollable (i.e. its vertical scrollbar is enabled). This, to me, seems like the best solution. We should also completely ignore single line textboxes (input type=text), since those can never be scrollable (right?) I'm not sure if we do that now, as I'm away from Mozilla for a little while.
Assignee: bryner → bryner
Status: REOPENED → NEW
When I tested it, IE would not scroll the text area for me, EVEN if I had it focused AND it had a scrollbar.
hmm..that's odd...you're right, I just tried it on a computer here and I got the same results. I could swear it works on my comp at home...
IE 5.5 WinMe behaves just as Blake says. tested on bugzilla bug 31233 on CC area.
Actually, that's my point regarding IE5. It doesn't stop scrolling even when the textarea has focus. You can't use your mousewheel to scroll through a textarea the way you can in Nav. And Mozilla is now emulating IE behavior: it forces you to use the scroll bar of the textarea and ignores the wonderful mousewheel that you've paid extra to have. :-) Personally, I hate the way IE works and much prefer having the textarea scroll *when it has focus.* Nav does it nearly right although having the focus automatically shift to the textarea when the mouse passes over it is annoying. Even so, I prefer it to having my mousewheel effectively disabled when the textarea has focus. I just discussed this with Gramps, and he recommends asking Ben. I'm adding Ben to the cc list.
Once more time... IE 5.5 on WinME scrolls the area with a wheel when the area has the focus!!! IE 5.5 works just right in this case.
In fairness, I tested this on IE5.0, not 5.5. But I should point out that whether the text field scrolls can be *mouse driver dependent*. Some drivers do their own locating of a native scrollbar before dispatching a message to the application. So, it's entirely possible that some of you are seeing the textfield scroll, and others not seeing it scroll. We can't possibly emulate the way each mouse driver interacts with native scrollbars, on gfx scrollbars. We're going to have to just pick a behavior and go with it.
Yes, bryner's right, this must be driver-dependent (which is why I see it at home but not here, and ezh sees the behavior I do but jan doesn't). I still believe that the behavior I originally described is the best: "Not only does it not stop scrolling the page if the mouse happens to pass over the textarea, but it doesn't even stop scrolling the page if the textarea has focus, unless there's enough content (text) in the textarea to make it scrollable (i.e. its vertical scrollbar is enabled). This, to me, seems like the best solution. We should also completely ignore single line textboxes (input type=text), since those can never be scrollable (right?)"
Yes, I agree with both of you on how it should work. I didn't think of the driver issue (doh!) which likely explains my seeing different behavior. For the record, I'm using Logitech v9.00 driver. Are you guys using MS mice? Ok, here are my dumb questions for today: Are driver behaviors brand specific or individual driver specific no matter what brand? And can we force the same behaviors from both brands in our product?
Well, it can be a combination of the driver, OS, and whether the driver has a "helper app" (usually in the system tray) that does location of native scrollbars. I've been using the behavior of my Logitech mouse on Win98 for reference here. We can't force driver behavior in our product. However, the good news is that once we've completely rid the product of native scrollbars (currently they are still used in select boxes, see bug 18895 marked Future), it won't matter because the driver will simply dispatch the mousewheel message to the app and let it decide what to do. The inconsistency comes when the driver tries to outsmart the app by preferring to find a native scrollbar to scroll - and only dispatching the mousewheel message to the app if it can't find one. This is also the cause of bug 33732. So, if we decide to make it so a focused text area should scroll using the wheel, I can implement that. Is that what we want to do?
I'm using MS Intellipoint driver 3.1a on WinME (on which it does not work properly). BTW. Many users do not install any additional mouse drivers, so we can make use of Mozilla little comfortable.
Status: NEW → ASSIGNED
->Future to get off NS6 radar.
Target Milestone: --- → Future
targetting mozilla 0.9 for all the mousewheel event targetting bugs
Target Milestone: Future → mozilla0.9
*** Bug 48565 has been marked as a duplicate of this bug. ***
As noted in bug 48565, the fact that textareas don't scroll with the wheel also causes mousewheel scrolling not to work in HTML Source mode in Composer.
a patch for this is attached to bug 57598
fixed checked in (we now scroll the textarea when it has focus).
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.