Closed Bug 52458 Opened 24 years ago Closed 23 years ago

Thinkpad Scrollpoint Mouse Button does not scroll Warpzilla window

Categories

(SeaMonkey :: General, defect, P3)

x86
OS/2
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: barrymarshall, Assigned: mkaply)

Details

Attachments

(6 files)

Tested with Warpzilla nightly build 0912 on WSeB base with Scitech DD on TP770X with base Trackpoint drivers. 1) Start Warpzilla 2) View www.mozilla.org @ 1024 * 768 * 24bpp 3) Hold TP Window scroll button down (blue button at bottom) 4) Move trackpoint. Window does not scroll up and down, even when focus is explicitly set inside window by manual click.
dupe of 20618, which has some dupes that deal with laptop mice *** This bug has been marked as a duplicate of 20618 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
While I agree that this is the same general problem, the specific problem cited is for the Win32 platform only. People involved in working on that fix will more-than-likely implement a Win32 specific fix, nor will they have an OS/2 machine to test on. I'll leave it for Mike to talk about how different the mouse handling functions and calls are under OS/2 vs Win32, but I suspect it will be rather platform-specific in nature.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Per Mike Kaply's request, I've attached a SPY log of scrolling around inside the System Editor while looking at CONFIG.SYS. I scrolled with the Trackpoint button once up and down and then left to right. Hopefully this make some sense...
This is going to be an OS/2 only problem and I do see it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm working on this one
Assignee: mkaply → jkobal
Whiteboard: CMVC32745
SCREENED. VERIFIED AS VALID.
Fix checked in. Note we could only make this work in the vertical direction. We will need to open a second XP bug against Mozilla for the fact that the mouse wheel scrolling support was only designed for vertical. In addition to trackpoint scrolling, there are mice that have two wheels - one horz, one vert.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
This is in 1027, right? If so, I still can't scroll the window. When I try, I get a quick beep, and nothing happens.
Re-open. Something's not quite right.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Re-confirmed not working under 1114.
Still broken under 1121.
Unfortunately, we don't have a TP770 available to test this. Barry, can you please run PMSPY and see what messages are generated to the queue of the browser window when you do the scroll operation?
Here's the approach I took with the SPY file. 1) Loaded Mozilla and got to a webpage. 2) Loaded SPY and selected Mouse events 3) Clicked back to Mozilla 4) Clicked a couple of times in dead space to make sure focus was explicitly set in the browser window. 5) Activated Trackpoint scrolling button to try to scroll the browser window. Got my usual beep and nothing happened. 6) Loaded a new webpage from My Bookmarks 7) Had to stop the load because it wasn't completing, but scroll bar existed. 8) Tried scrolling the window with the scroll bar manually. This worked no problem. 9) Tried scrolling window with Trackpoint. Usual beep and no dice. 10) Brought up task list, but Spy doesn't register itself in it. 11) Minimized Mozilla and closed SPY. Hopefully the data is good. Let me know what else you need.
Thanks, Barry. I need you to add the scrolling messages (WM_VSCROLL and WM_HSCROLL) to the PMSPY output. Currently, the output you got doesn't show any messages from the scrolling.
Okay, I'll see if I can figure out how to do that. I haven't used SPY before this problem. There's an option "Trace All Windows". Even though it would be tons of data, would that be useful to set?
No, do not set "Trace All Windows". Just set the spy on the queue for the browser window, and filter in the desired messages.
Okay, this is weird. I opened up both an E session and a Mozilla session with Spy still visible. I moved my mouse around and did some operations in both windows to confirm that I was tracing both windows. When I was scrolling around in E, I did see the WM_VSCROLL and WM_HSCROLL messages being generated and sent to E, so I know I can generate them either by the Trackpoint or by clicking the scroll arrows on the side of the screen. When I tried to scroll around Mozilla, neither message gets generated. Dumb user who once took a PM programming course and hasn't looked at Mozilla's design question follows: Could these be due to the use of XP GUI code instead of native OS/2 widgets? Could OS/2 not really recognise the fact that these XP scrollbar's up and down arrow windows are getting setup and are the same function as the OS/2 equivalent? If it doesn't recognise what these windows are for, then it maybe thinks that the Mozilla window is not really scrollable because it's just one big window? I've just tried using the Scrollpoint on the Launchpad/Toolbar (another non-standard PM program) and it exibits the same behaviour. I'll attach the trace I've created so you can see what's going on.
Actually, it's not that weird. I'm trying to ascertain what the scrollpoint driver is doing, figuring that it is either sending the scroll messages to the wrong place, or not sending them at all. The beep you are getting is indicating that someone is signalling an error condition, but I can't tell what that error is. I'm still trying to trace down a TP770 to test this myself, but was hoping that you could shed some light on it with PMSPY. Yes, the fact that Mozilla uses custom scrollbars (not PM) is causing the problem, but I still don't know how the scrollpoint driver KNOWS that there isn't a real scrollbar on the window. The "up and down arrows" are just bitmaps drawn on the window; they aren't really buttons, and all of the handling is internal to Mozilla, so there is no way for OS/2 to "recognize" them. Even though OS/2 can't tell that the window is scrollable, it should still send along the scroll notifications; and I'd still like to know HOW it is trying to tell whether the window is scrollable, so I can put in code to fake it out. The code we put in under this bug already will do the scrolling if the WM_VSCROLL is received (which wouldn't have worked before). The only other thing I can think of for you to try is having PMSPY look at ALL messages going to the browser when you use the scrollpoint, and see if any of those are messages that could be querying information from the window to see if it supports scrolling. In the meantime, I'll keep trying to get a TP770 to test on at this end.
In Warpcenter's KillFeatureEnabled listing (Alt-Click the task list) there's a program running called MULTIPT.EXE (Trackpoint Features), which I assume is some sort of snoop program for the Trackpoint feature. Are there any tools I can use to find out what messages this thing is snoopoing on?
Netscape/2 4.61 also doesn't get the WM_VSCROLL messages either, so that's doing something right... Attached will be a trace show E (PID: 66) and Netscape Navigator (PID: 61) scrolling around. NS/2 is showing http://www.restoration-team.co.uk/, which can be crushed up to have several scrollable frames. I set the "Trace All Frames" option, so maybe that will give some more interesting information.
Hold on a sec.... the scrolling doesn't work with Netscape 4.61 either? That's strange; if you click in a scrollable frame (to put focus in the frame) and use the scrollpoint, does that work? I was able to borrow a TP770 for the day and learned a few things: (1) No messages are being sent to determine the existence of a scrollbar. (2) If I put a dummy scrollbar in the Mozilla webpage view, scrolling WORKS! (3) The XP scrollbars are not separates windows, so there's no way for our platform-specific code to know that any Mozilla window has a scrollbar. Conclusion: This is not going to be easy to fix. We could try to put an invisible native scrollbar on every window that has an XP scrollbar, but there's no way to determine which windows that would be.
Keywords: helpwanted
Sorry, I wasn't being clear enough. The scrolling DOES work with NS/2 4.61 and with multiple frames in the browser, but you don't get the WM_VSCROLL & WM_HSCROLL messages (as you can see in the trace).
The beep is all I get when using scroll button on Thinkpad A21M as well. Works on NS 4.61. Andy Willis
Assigning back to Mike, since I'm no longer on the Mozilla project.
Assignee: jkobal → mkaply
Status: REOPENED → NEW
Attached patch Hack for problem (deleted) — Splinter Review
I've added a preference, os2.trackpoint, that when set to true causes all Mozilla child windows to be created with invisible scroll bars so that thinkpad scrolling works. YUCK
Comment on attachment 89982 [details] [diff] [review] Hack for problem r=pedemont sr=blizzard (platform specific code)
Attachment #89982 - Flags: superreview+
Attachment #89982 - Flags: review+
Fix checked in. Requesting driver approval
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Keywords: helpwantedmozilla1.0.1
Resolution: --- → FIXED
Whiteboard: CMVC32745
Attachment #89982 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
I can't verify this anymore, since I'm now on a T21 without the hard drive space for OS/2. My only remaining OS/2 machine is my old Aptiva M70. Can someone else do the honours?
fixed on branch
Looks like dbradley (as sheriff) backed this out of the branch because it doesn't compile on the branch, due to the lack of an mIsScrollbar variable.
Attached patch Diff for branch (deleted) — Splinter Review
Had to add mIsScrollbar to the branch for this to work.
*** Bug 143982 has been marked as a duplicate of this bug. ***
Landed again. Should be OK this time.
Marking verified. We have had a lot of testing on this.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: