New window scroll forces large jumps

With today’s ROM update (21/4) I find that scrolling the content of a window or the window itself is not possible in small steps. As example, scrolling text in Messenger Pro jumps a minimum of ten text lines. The scroll wheel config panel doesn’t seem to change behaviour. Reverting to the 19-Ap- 20 ROM scrolling is normal. This is with a Logitech wireless mouse and BB -xM.

The scroll wheel config panel doesn’t seem to change behaviour.

It seems variable. NetSurf and PipeDream windows scroll in big fixed lumps whatever the setting but the TaskManager’s Tasks window does obey the configured setting. Oddly, however, Messenger Pro here scrolls one line at a time, irrespective of the setting.

Titanium in this case.

With today’s ROM update (21/4) I find that scrolling the content of a window or the window itself is not possible in small steps

For every window/program, or just some of them? Today’s OMAP3 ROM appears to be working correctly here. But there is certainly more work I need to do to try and make sure scrolling behaviour is consistent/sensible.

Part of the problem is that there are three different ways of scrolling windows (“open window” wimp messages, “scroll” wimp messages, and “extended scroll” wimp messages), and there’s not much consistency with how programs react to them.

• The “extended scroll” requests were created specifically for scroll wheels, but ROL don’t appear to have given any guidelines for how far windows should scroll in response to them. e.g. NetSurf scrolls by half the window height, while PipeDream spreadsheets scroll 5 rows. But since this mode is theoretically the correct way of telling apps about scroll wheel movement, WindowScroll will prioritise using it over the other methods.
• Regular “scroll” requests are what the Wimp uses when you click the scroll arrows that surround the scroll bar (if the window supports the message). Generally this gets interpreted as “scroll one line of text”, but ultimately it’s down to the app to decide how far to scroll (the PRM even says so), so there are likely to be some exceptions. WindowScroll will only use this if the “Line multiple” option is enabled in Configure.
• Open window requests are the fallback mode. In some ways they’re the best (WindowScroll can specific exactly how far to scroll), but that doesn’t stop some software from ignoring the info and doing something completely different (e.g. Edit, which tries to scroll one line at a time)

Currently it’s only the “open window” requests which will be affected by the scroll speed setting in Configure – you should be able to see this with well-behaved windows like the task manager. Hopefully I can find ways to scale some of the other requests as well (it’s a bit tricky because the window position doesn’t update straight away – so the code will have to wait until the app’s processed the request in order to read back the new scroll offsets)

Oddly, however, Messenger Pro here scrolls one line at a time, irrespective of the setting.

Which versions of Messenger Pro are you both on? Possibly different versions react to the different scroll requests differently.

Ok I have tried todays ROM and HardDisc image updates on my Iyonix using the softload version and both Netsurf and MessengerPro seem to work ok on scrolling.

I can alter the scroll speed in Configure>Mouse and it makes a difference.

I have the Scroll Wheel setting set to “Window under the pointer” in the Configure>Mouse setting screen.

This is with Netsurf 3.8 (Dev#4315) and Messenger Pro 8.04

On my ARMX6 I have put the latest ROOL disc components on and the Scroll Wheel support section of the Configure>Mouse is greyed out as it must check the OS/HAL version to see if it is supported as I would expect.

Hope that helps in finding the issue.

Update

both Netsurf and MessengerPro seem to work ok

So went back and rechecked and remembered that HID is loaded on the Iyonix so disabled that and tested again and MessengerPro is still OK , v 8.04, but Netsurf 3.8 (dev#4315) does jump in chunks no matter what the setting.

Sorry for any confusion.

Oddly, however, Messenger Pro here scrolls one line at a time, irrespective of the setting.

Which versions of Messenger Pro are you both on? Possibly different versions react to the different scroll requests differently.

I am on Messenger Pro 7.08, which is six years old.

P.S. PlingStore’s main window no longer scrolls at all now, it did previously.

Error block: 80000001 Internal error: abort on instruction fetch at &00000000
R0 = 00000000
R1 = 206cae94
R2 = 00000000
R3 = 206cb110
R4 = 01c01832
R5 = 00000000
R6 = 00008000
R7 = 00000113
R8 = 0000000a
R9 = 00000000
R10 = fa207eec
R11 = 30000324
R12 = 206cabb4
R13 = 206cafb8
R14 = 20000110
R15 = 00000004
CPSR = 60000110
R13_usr = 206cafb8
R14_usr = 20000110
R13_svc = fa208000
R14_svc = fc339b44
SPSR_svc = 20000110
R13_irq = fa102000
R14_irq = 60000113
SPSR_irq = 60000113
R13_abt = fa301fa8
R14_abt = 00000004
SPSR_abt = 60000110
R13_und = fa402000
R14_und = fc165474
SPSR_und = 60000113
OSMem16: 2 = fa100000, 00002000, 00002000
OSMem16: 3 = fa200000, 00008000, 00008000
OSMem16: 4 = fa300000, 00002000, 00002000
OSMem16: 5 = fa400000, 00002000, 00002000
Memory: fa100000 - fa102000
Memory: fa200000 - fa208000
Memory: fa300000 - fa302000
Memory: fa400000 - fa402000
Memory: ffff0108 - ffff010c
OSRSI6: 69 = ffff0108

R15 = 00000004 is system workspace
R14_usr = 20000110 = Module area +110

USR stack:
206cafb8 : 206cabe8 : | R3
206cafbc : 01c01832 : | R4
206cafc0 : 00000000 : | R5
206cafc4 : fc33a0fc : | R14: fc33a0fc (ASM call to fc33a130)
         :          : | fc33a0fc = TaskWindow +255c
         :          : | = SetWimpKeyStates +c
         :          : | fc33a130 = TaskWindow +2590
         :          : | = SetKeyStates +0
206cafc8 : 206cb110 : - R3
206cafcc : fc338a94 : | R14: fc338a94 (ASM call to fc33a0f0)
         :          : | fc338a94 = TaskWindow +ef4
         :          : | = GetParentTask +58
         :          : | fc33a0f0 = TaskWindow +2550
         :          : | = SetWimpKeyStates +0
206cafd0 : 20000113 : - R1
206cafd4 : 206cb084 : | R2
206cafd8 : 24515188 : | R3
206cafdc : fc339074 : | R14: fc339074 (ASM call to fc338a3c)
         :          : | fc339074 = TaskWindow +14d4
         :          : | = notcontrol +4
         :          : | fc338a3c = TaskWindow +e9c
         :          : | = GetParentTask +0
206cafe0 : 20000113 :
206cafe4 : 206cb084 :
206cafe8 : 24515188 :
206cafec : 00000044 :
206caff0 : 00000000 :
206caff4 : 00008000 :
206caff8 : 00000113 : - R0
206caffc : 0000000a : | R1
206cb000 : 00000000 : | R2
206cb004 : fa207eec : | R3
206cb008 : 30000324 : | R4
206cb00c : 206cabb4 : | R5
206cb010 : fc33a0fc : | R14: fc33a0fc (ASM call to fc33a130)
         :          : | fc33a0fc = TaskWindow +255c
         :          : | = SetWimpKeyStates +c
         :          : | fc33a130 = TaskWindow +2590
         :          : | = SetKeyStates +0
206cb014 : 00d9dad9 :
206cb018 : 00d9dad9 :
206cb01c : 00dadbda :
206cb020 : 00d9d9d9 :
206cb024 : 00dadada :
206cb028 : 00dbdbdb :
206cb02c : 00dbdbdb :
206cb030 : 00dbdbdb :
206cb034 : 00dbdbdb :
206cb038 : 00dbdbdb :
206cb03c : 00dbdbdb :
206cb040 : 00dbdbdb :
206cb044 : 00dbdbdb :
206cb048 : 00dbdbdb :
206cb04c : 00dbdbdb :
206cb050 : 00dbdbdb :
206cb054 : 00dbdbdb :
206cb058 : 00dbdbdb :
206cb05c : 7ca039cc :
206cb060 : 206cae94 :
206cb064 : 20000110 :
206cb068 : 00000000 :
206cb06c : 206cabe8 :
206cb070 : 00000016 :                                            - R0
206cb074 : fc339668 : - Return to fc339668?                      | R1
         :          : | = TaskWindow +1ac8                       | 
         :          : | = MyByteV +228                           | 
206cb078 : 2005a1b4 :                                            | R2
206cb07c : 206cabe8 :                                            | R3
206cb080 : fc338b7c : - Return to fc338b7c?                      | R4
         :          : | = TaskWindow +fdc                        | 
         :          : | = Code_ExitHandler +0                    | 
206cb084 : 00000000 :                                            | R5
206cb088 : fc33a0fc :                                            | R14: fc33a0fc (ASM call to fc33a130)
         :          :                                            | fc33a0fc = TaskWindow +255c
         :          :                                            | = SetWimpKeyStates +c
         :          :                                            | fc33a130 = TaskWindow +2590
         :          :                                            | = SetKeyStates +0
206cb08c : fc337c98 : - R3
206cb090 : fc338ec0 : | R14: fc338ec0 (ASM call to fc33a0f0)
         :          : | fc338ec0 = TaskWindow +1320
         :          : | = print_esc +1f4
         :          : | fc33a0f0 = TaskWindow +2550
         :          : | = SetWimpKeyStates +0
206cb094 : 01ced1d0 :
206cb098 : 64789882 :
206cb09c : ff3f7551 :
206cb0a0 : ff3e734e :
206cb0a4 : fc3d714d :
206cb0a8 : ff3e734e :
206cb0ac : ff3e734e :
206cb0b0 : ff3e734e :
206cb0b4 : fc3d714e :
206cb0b8 : ff3f7652 :
206cb0bc : 597d9c86 :
206cb0c0 : 00dbdbdb :
206cb0c4 : 00dbdbdb :
206cb0c8 : 00dadada :
206cb0cc : 00dbdbdb :
206cb0d0 : 00dbdbdb :
206cb0d4 : 00dbdbdb :
206cb0d8 : 00000000 :
206cb0dc : 00000000 :
206cb0e0 : 00000000 :
206cb0e4 : 00000000 :
206cb0e8 : 00000000 :
206cb0ec : 00000000 :
206cb0f0 : fa208000 :
206cb0f4 : 00000000 :
206cb0f8 : 0000000a :
206cb0fc : 00000000 :
206cb100 : 2005a1b4 :
206cb104 : 00000000 :
206cb108 : 00dbdbdb :
206cb10c : 00dbdbdb :
206cb110 : 00000000 :
206cb114 : 00000001 :
206cb118 : 7c8039c0 :
206cb11c : 00000000 :
206cb120 : 000039c0 :
206cb124 : ffff0ff8 :
206cb128 : 00dbdbdb :
206cb12c : 00dbdbdb :
206cb130 : 00dbdbdb :
206cb134 : 706d6957 :
206cb138 : 746f6c53 :
206cb13c : 00db0020 :
206cb140 : 00dbdbdb :
206cb144 : 00dbdbdb :
206cb148 : 00dbdbdb :
206cb14c : 00dbdbdb :
206cb150 : 00dbdbdb :
206cb154 : 00dbdbdb :
206cb158 : 00dbdbdb :
206cb15c : 00dbdbdb :
206cb160 : 00dbdbdb :
206cb164 : 00dadada :
206cb168 : 00dbdbdb :
206cb16c : 04c6cbc8 :
206cb170 : 90638c6f :
206cb174 : ff417953 :
206cb178 : f840724f :
206cb17c : ff3e734e :
206cb180 : ff3e734e :
206cb184 : ff3e734e :
206cb188 : ff3e734e :
206cb18c : ff407753 :
206cb190 : 6f72957d :
206cb194 : 02c9cfcb :
206cb198 : 00dbdbdb :
206cb19c : 00d9d9d9 :
206cb1a0 : 00dbdbdb :
206cb1a4 : 00dbdbdb :
206cb1a8 : 00dbdbdb :
206cb1ac : 00dbdbdb :
206cb1b0 : 00dbdbdb :
206cb1b4 : 00dbdbdb :
206cb1b8 : 00dbdbdb :
206cb1bc : 00dbdbdb :
206cb1c0 : 00dbdbdb :
206cb1c4 : 00dbdbdb :
206cb1c8 : 00dbdbdb :
206cb1cc : 00dbdbdb :
206cb1d0 : 00dadada :
206cb1d4 : 00dbdbdb :
206cb1d8 : 00dbdbdb :
206cb1dc : 1aa7b7ac :
206cb1e0 : db467956 :
206cb1e4 : ff3f7753 :
206cb1e8 : fa3a744f :
206cb1ec : ff3e734e :
206cb1f0 : ff3e734e :
206cb1f4 : ff3e734e :
206cb1f8 : ff3d724e :
206cb1fc : ff3f7551 :
206cb200 : b2568264 :
206cb204 : 04c5ccc7 :
206cb208 : 00dbdbdb :
206cb20c : 00dbdbdb :
206cb210 : 00d7d8d8 :
206cb214 : 6b71967e :
206cb218 : ff3e734e :
206cb21c : ff3e734e :
206cb220 : fc3d714d :
206cb224 : ff3e734e :
206cb228 : ff3e734e :
206cb22c : ff3e734e :
206cb230 : ff3e734e :
206cb234 : fc3d6f4e :
206cb238 : fa78b98a :
206cb23c : ff77bb8c :
206cb240 : ff77bb8c :
206cb244 : ff77bb8c :
206cb248 : ff77bb8c :
206cb24c : ff77bb8c :
206cb250 : ff77bb8c :
206cb254 : ff77bb8c :
206cb258 : ff77bb8c :
206cb25c : ff77bb8c :
206cb260 : ff77bb8c :
206cb264 : ff77bb8c :
206cb268 : ff77bb8c :
206cb26c : ff77bb8c :
206cb270 : fc74bb8c :
206cb274 : ff79be8f :
206cb278 : ec78bc8e :
206cb27c : 3aaacab4 :
206cb280 : 00dbdbdb :
206cb284 : 00dbdbdb :
206cb288 : 00dadbda :
206cb28c : 00dbdbdb :
206cb290 : 00dbdbdb :
206cb294 : 00dadbda :
206cb298 : 00dbdbdb :
206cb29c : 01d3d8d5 :
206cb2a0 : 579ec7ab :
206cb2a4 : fc79bf91 :
206cb2a8 : fc77bd8e :
206cb2ac : fc74bb8e :
206cb2b0 : ff77bb8c :
206cb2b4 : ff77bb8c :
206cb2b8 : ff77bb8c :
206cb2bc : ff77bb8c :
206cb2c0 : ff77bb8c :
206cb2c4 : ff77bb8c :
206cb2c8 : ff77bb8c :
206cb2cc : ff77bb8c :
206cb2d0 : ff77bb8c :
206cb2d4 : ff77bb8c :
206cb2d8 : ff77bb8c :
206cb2dc : ff77bb8c :
206cb2e0 : ff77bb8c :
206cb2e4 : fc75bc8e :
206cb2e8 : fc73bb8c :
206cb2ec : ff7cc392 :
206cb2f0 : a58ac19c :
206cb2f4 : 0ac5d3c9 :
206cb2f8 : 00dbdbdb :
206cb2fc : 00dadbdb :
206cb300 : 00dbdbdb :
206cb304 : 00dbdbdb :
206cb308 : 00dbdbdb :
206cb30c : 00dbdbdb :
206cb310 : 00dbdbdb :
206cb314 : 00dbdbdb :
206cb318 : 00dbdbdb :
206cb31c : 00dbdbdb :
206cb320 : 00dbdbdb :
206cb324 : 00dbdbdb :
206cb328 : 00dbdbdb :
206cb32c : 00dbdbdb :
206cb330 : 00dbdbdb :
206cb334 : 00dbdbdb :
206cb338 : 00dbdbdb :
206cb33c : 00dbdbdb :
206cb340 : 00dbdbdb :
206cb344 : 00dbdbdb :
206cb348 : 00dbdbdb :
206cb34c : 00dbdbdb :
206cb350 : 00dbdbdb :
206cb354 : 00dbdbdb :
206cb358 : 00dbdbdb :
206cb35c : 00dbdbdb :
206cb360 : 00dadbdb :
206cb364 : 00dbdbdb :
206cb368 : 0ec1d1c7 :
206cb36c : ad86be99 :
206cb370 : ff7bc292 :
206cb374 : fa78b98a :
206cb378 : ff77bb8c :
206cb37c : ff77bb8c :
206cb380 : ff77bb8c :
206cb384 : ff77bb8c :
206cb388 : ff77bb8c :
206cb38c : ff77bb8c :
206cb390 : ff77bb8c :
206cb394 : ff77bb8c :
206cb398 : ff77bb8c :
206cb39c : ff77bb8c :
206cb3a0 : ff77bb8c :
206cb3a4 : fc75bb8e :
206cb3a8 : ff77bb8c :
206cb3ac : ff7cc393 :
206cb3b0 : 2db0ccb9 :
206cb3b4 : 00dbdbdb :

End of dump

Tried a few apps to see what happens. Messenger Pro (v 8.04), NetSurf, Store, Ovation Pro 2.78c, Private Eye show the same problem. Edit seems more random, scrolling different distances each time. Often scrolling up jumps to the beginning of a document, from mid way through a long one.

Draw is closer to what I would expect, jumping smaller increments, but in none of the apps including this is there anywhere near resembling what could be described as a smooth scroll. Scroll speed adjustment seems totally ineffectual. Window sliders reflect the window content.

Tried a few apps to see what happens. Messenger Pro (v 8.04), NetSurf, Store, Ovation Pro 2.78c, Private Eye show the same problem.

I’m not sure what’s going on there – I don’t have copies of MPro or OvPro to test with, but for me NetSurf, Store, and Private Eye all exhibit completely different behaviour to each other.

• NetSurf will scroll by half the window height
• Store doesn’t scroll at all (it advertises support for the extended scroll requests, but seems to be ignoring them?)
• Private Eye will either scroll “one line” at a time (“line multiple” enabled) or an amount controlled by Configure’s scroll speed setting (“line multiple” disabled)

Edit seems more random, scrolling different distances each time. Often scrolling up jumps to the beginning of a document, from mid way through a long one.

That one I can reproduce; investigating it is on my todo list.

but in none of the apps including this is there anywhere near resembling what could be described as a smooth scroll. Scroll speed adjustment seems totally ineffectual.

Smooth scrolling isn’t implemented yet. But the “scroll speed” setting should definitely affect Draw (and most other apps that don’t use extended scroll requests, if “line multiple” is disabled).

To help diagnose problems, I’ve uploaded a debug build of WindowScroll here which will log some key info to Reporter each time it tries to act on some wheel movement:

• “New scroll pos” reports the “absolute” position of the mouse wheel(s) as reported by OS_Pointer 2
• “Scroll target” reports the window & icon handle of the thing that’s going to be scrolled
• “Scroll by” reports how many scroll “ticks” are going to be applied, and how (extended scroll request, normal scroll request (“line multiple”), or OpenWindow request). Normally the numbers should be small (e.g. 1 or 2) – if they’re much bigger than that then it suggests the problem might be that USBDriver isn’t dealing with the mouse very well

Also note that:

• The module will be using default settings when loaded, so you might want to go into the mouse setup plugin and click the Set button to re-apply any custom settings
• The scroll speed setting currently only affects the OpenWindow scroll method (and the “Scroll by” numbers are the values before the speed multiplier is applied)

If people who are experiencing weird things could try that debug build of WindowScroll and report back on anything suspicious in Reporter’s logs then that would be great.

NetSurf will scroll by half the window height

Might not be deliberate. See the strange comment for RO5 in here:

http://git.netsurf-browser.org/netsurf.git/tree/frontends/riscos/window.c#n1725

I didn’t write that code, so I’m not sure of the details, I just remember reading it.

I didn’t write that code,

and the person that did weite it seems to have forgotten to initial it so you can ask them what they had found thus ensuring any detective work is repeated. My sympathies.

I didn’t write that code, so I’m not sure of the details, I just remember reading it.

Yes, when USBDriver was handling scrolling directly it was doing it by sending 5 Scroll messages at a time:

https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/USB/USBDriver/-/blob/USBDriver-1_29/build/c/usbmouse#L741

However in Netsurf, the code for handling the “scroll by half window height” are the default cases in these sets of switch statements (which will only be hit if the bottom two bits of the scroll amount are zero, representing an extended scroll request, which up until now RISC OS 5 wouldn’t have been using):

http://git.netsurf-browser.org/netsurf.git/tree/frontends/riscos/window.c#n1122

Late to rejoin the party having done exciting things like navigate a supermarket without map or compass.

Fought with Reporter being unfamiliar with it and ended up making individual files for each aplication to avoid details falling off the end. What should I do with them?

Store changed it’s behaviour today, the catalogues not scrolling at all as David P found above. Reporter shows changes when the window scroll is attempted though nothing moves.

Fought with Reporter being unfamiliar with it and ended up making individual files for each aplication to avoid details falling off the end. What should I do with them?

You can email to me if you want.

http://www.phlamethrower.co.uk/contact.php

If you have any problems with Reporter feel free to contact me – see Help file

S’ok, thanks. Just not used it before and trying to be quick.

Got the logs, thanks.

To summarise:

• The problem you’re having is that it’s not possible to scroll in small steps
• MPro, OvPro, NetSurf and Private Eye all suffer from this problem
• Zap suffers from the problem too?
• Store did suffer from it, until today when it stopped scrolling completely (consistent with other people’s experiences, although the timing is still confusing)

NetSurf is a known issue, so I’ll ignore that.

Looking at the logs you gave me, MPro, OvPro and Zap are all being scrolled using OpenWindow requests, so as long as you don’t enable the “Line multiple” option the scroll distance/speed should be controllable via the slider in the mouse setup plugin. And the frequency of the events in the logs suggests that the mouse is generating scroll events at a normal rate. Testing Zap & Private Eye locally also shows that OpenWindow requests are being used (and the slider does correctly control the motion).

The *WimpScroll command with no arguments will print out the current settings being used by the module – so does the reported “speed” value change when you adjust the slider in Configure? (and click the “set” button)

Yes, Zap also scrolls multiple lines. Your summary is correct. I haven’t touched the Line multiple option so it’s unset. Though Reporter was showing a response to the scroll speed adjustments I made there wasn’t any visible difference.

It’s 2.04am and Zebedee has arrived.

Tomorrow’s ROM update should be interesting to try. One extra query… On the configuration panel the ‘Line Multiple’ option is selectable from anywhere in line with the button rather than just on the button. Is that intentional?

Tomorrow’s ROM update should be interesting to try.

And I’m still interested in knowing whether Configure is applying settings correctly for you (i.e. whether the speed value reported by ‘*WimpScroll’ changes)

On the configuration panel the ‘Line Multiple’ option is selectable from anywhere in line with the button rather than just on the button. Is that intentional?

It’s just a standard toolbox gadget, so I assume it’s intentional that it responds to clicks on the label part.

However I did make the label extra wide (to avoid any internationalisation issues), so it is probably accepting input from a larger area than users would expect.

Also note that tomorrow’s ROM won’t change the behaviour of Edit much – after taking a look at it last night, I know roughly what needs doing, but it could do with a bit of discussion to decide on the best solution.

Additionally, encouraged to retry the options in anticipation of the update I now find ‘Scroll speed’ now works for most of the applications I tried before. Just the known ones such as NetSurf iffy now. It’s bloody voodoo (the things that you do).

Can’t even get Edit to fault now. Had upped to 28-Apr-20 ROM but that shouldn’t have changed anything?

Had a quick play. The known issues of Edit, Netsurf and Store are as was. PipeDream window contents make big jumps and don’t respond to the scroll speed config though the sliders do – as with Netsurf. I don’t know if that’s abnormal – I haven’t used it for years and just tried the sample files.

Don’t know if the info’s useful but Zap, La Bella, MPro, FireWorks, OvnPro, Schema2, PDF, OpenVector, StrongEd, StrongHelp and Private Eye all behaved.

But it could do with a bit of discussion to decide on the best solution

Modify Edit? :)

Edit has the weirdest scrolling scheme the scrollbars seem to change size depending on the visible char count and not line count. Might be easier to not scroll Edit windows if exceptions can be made but unfortunately I think it’s a feature of the Text library in RiscOSLib which means it may be a problem elsewhere – like SrcEdit.