Cursor changes position when scrolling in Scrivenings mode

To
TomGoodell
Posts: 140
Joined: Tue Nov 13, 2012 3:13 pm
Platform: Windows

Sun Sep 29, 2019 5:01 pm Post

Beta 2.9.0.24 - when I am in Scrivenings mode and scroll through the documents in the editor, the cursor automatically moves to whatever document is currently in view. I often scroll up and down through Scrivenings and then just press the arrow key to get back to where I was working, but that no longer works - the cursor now shows up in whatever document is displayed on the screen. If I scroll back to view the document where I was working, the cursor is back in the right place in that document. But that means I have to carefully scroll back to that document, rather than getting there just by pressing the arrow key.

I'm not sure if this is a bug or intended, but it seems to me to reduce functionality. If I want to edit in the document I've scrolled to, I'm going to click in that document at the point I want to edit, so having the cursor go there automatically doesn't help.

User avatar
haep
Posts: 30
Joined: Tue Oct 17, 2017 4:29 am
Platform: Win + iOS

Sun Sep 29, 2019 5:09 pm Post

TomGoodell wrote:Beta 2.9.0.24 - when I am in Scrivenings mode and scroll through the documents in the editor, the cursor automatically moves to whatever document is currently in view.....


I can confirm this strange behaviour.
Windows 10 home 2004
Intel(R) Core i7-7500U CPU 2.7GHz 2.9 GHz 8.00GB RAM
SSD 500GB
15" 1920x1080 at 125% zoom
23" 1920x1080 at 100% zoom
32" 1360x768 at 100% zoom

IPhone 8 Plus IOS 13.5.1
IPad Pro 12.9” third gen. IOS 13.5.1

bi
biblioman
Posts: 109
Joined: Sat May 26, 2018 11:08 pm
Platform: Windows

Sun Sep 29, 2019 6:27 pm Post

Can confirm, seems like a piece of bug still in.

P.S. Just to notice—while scrolling, as top edge of another document reach the top edge of the screen, the document becomes current in the Binder.

User avatar
tiho_d
Posts: 1495
Joined: Tue Sep 13, 2011 1:14 pm
Platform: Linux + Windows

Sun Sep 29, 2019 7:32 pm Post

This is by design, and funny enough the old behavior was also reported as a bug and the current behavior was requested. :-) The current behavior is also the MAC and Scrivener v1 behavior.

bi
biblioman
Posts: 109
Joined: Sat May 26, 2018 11:08 pm
Platform: Windows

Sun Sep 29, 2019 8:03 pm Post

tiho_d wrote:This is by design, [...] The current behavior is also the MAC and Scrivener v1 behavior.


So far as all is OK with cursor behavior in a single document, the matter is hardly worth further discussion. Even though some switcher (i.e. option) for this behavior could possibly be a great decision—say, in v.3.6 or 4.1. )

User avatar
haep
Posts: 30
Joined: Tue Oct 17, 2017 4:29 am
Platform: Win + iOS

Mon Sep 30, 2019 1:24 am Post

tiho_d wrote:This is by design, and funny enough the old behavior was also reported as a bug and the current behavior was requested. :-) The current behavior is also the MAC and Scrivener v1 behavior.

Long time ago since the last time I use V1. :wink:,
Windows 10 home 2004
Intel(R) Core i7-7500U CPU 2.7GHz 2.9 GHz 8.00GB RAM
SSD 500GB
15" 1920x1080 at 125% zoom
23" 1920x1080 at 100% zoom
32" 1360x768 at 100% zoom

IPhone 8 Plus IOS 13.5.1
IPad Pro 12.9” third gen. IOS 13.5.1

Vi
Virescent
Posts: 5
Joined: Sun Oct 06, 2019 12:52 am
Platform: Windows

Sun Oct 06, 2019 1:14 am Post

tiho_d wrote:This is by design, and funny enough the old behavior was also reported as a bug and the current behavior was requested. :-) The current behavior is also the MAC and Scrivener v1 behavior.


I find the "correct" behaviour baffling since the focus is jumping all over the place based solely on scrolling without much visible indication of where the cursor is now located (no other software that I know of does that). I use to scroll a lot and find it useful for the cursor to stay put in one place, since the page will scroll back to that place as soon as you start typing again.

The "correct" behaviour is also very annoying when working near the split between two files, because Scrivener always wants to move the cursor to the file visible at the top of the window at the slightest scroll.

I couldn't believe this was behaviour in v1, but it is so. I got so used to the "buggy" way of v3 betas I guess. To me, it just makes sense that the cursor position doesn't change unless you click somewhere or move it using keyboard keys.

I understand that now there would be people entrenched on both sides adoring both behaviours, and the only real solution is to provide a toggle mode option (as biblioman suggested) to switch between "correct" and "buggy" behaviours.

bi
biblioman
Posts: 109
Joined: Sat May 26, 2018 11:08 pm
Platform: Windows

Sun Oct 06, 2019 10:32 am Post

Virescent wrote:
tiho_d wrote:This is by design, and funny enough the old behavior was also reported as a bug and the current behavior was requested. :-) The current behavior is also the MAC and Scrivener v1 behavior.


I find the "correct" behaviour baffling since the focus is jumping all over the place based solely on scrolling without much visible indication of where the cursor is now located (no other software that I know of does that). I use to scroll a lot and find it useful for the cursor to stay put in one place, since the page will scroll back to that place as soon as you start typing again.

The "correct" behaviour is also very annoying when working near the split between two files, because Scrivener always wants to move the cursor to the file visible at the top of the window at the slightest scroll.

I couldn't believe this was behaviour in v1, but it is so. I got so used to the "buggy" way of v3 betas I guess. To me, it just makes sense that the cursor position doesn't change unless you click somewhere or move it using keyboard keys.

I understand that now there would be people entrenched on both sides adoring both behaviours, and the only real solution is to provide a toggle mode option (as biblioman suggested) to switch between "correct" and "buggy" behaviours.


Frankly speaking, I am not sure such a problem could be solved by a switcher—just because it is about some fundamental principle, not an option. Even thoug I find the point you framed totally right: «the cursor position should not change unless you click somewhere or move it using keyboard keys». What is more, yes, it is this behaviour (cursor does not move with page scrolling) that seems common practice.

Vi
Virescent
Posts: 5
Joined: Sun Oct 06, 2019 12:52 am
Platform: Windows

Sun Oct 06, 2019 2:05 pm Post

biblioman wrote:Frankly speaking, I am not sure such a problem could be solved by a switcher—just because it is about some fundamental principle, not an option.

Why would you say it can't be solved by a mode? I don't think this is a difficult problem technically speaking. There was a bug altering the behaviour, so it doesn't seem to me that some fundamental change is required. Just bring up that bug back and make that behaviour optional.


To further the argument for the behaviour that keeps the cursor is place, I would like to cite the WCGA 3.2.1 Criterion (I know Scrivener is not a web-page, but accessibility guidelines are pretty universal):
On Focus: When any component receives focus, it does not initiate a change of context.

It's not an exact match to the current situation, but it boils down to "reducing the chance that a change of context will occur unexpectedly". And I think changing focus on a simple window scroll is unexpected.

Here, I type on one file, then scroll down a single line, and the cursor jumps into a different file altogether. If this is not unexpected, I don't know what is:
Image

Also, Microsoft has written extensive interaction guidelines for Windows applications and there is section on Mouse and Pointers and specifically on Mouse Wheel, and it says:
Don't change the input focus when using the mouse wheel.


So, to recap. I think the behaviour when the cursor position is changed when scrolling in Scrivenings mode is wrong on three accounts:
  1. This behaviour does not seem to be a common practice among text-editing or other software, and most users would be unfamiliar with it.
  2. This behaviour is arguably breaks accessibility guidelines by introducing unexpected focus changes without an explicit user intention to move the focus.
  3. This behaviour breaks Microsoft guidelines for Windows application on not changing input focus when using the mouse wheel.

The best outcome, as I see it, would be to return to the "buggy" behaviour for the Windows version of Scrivener when the cursor doesn't move on scrolling. If that is not entirely possible, since it would be a big change for the Scrivener user base who came to rely on this behaviour, a switch that toggles the behaviour between moving and not moving the cursor would be the second best solution.

bi
biblioman
Posts: 109
Joined: Sat May 26, 2018 11:08 pm
Platform: Windows

Sun Oct 06, 2019 4:09 pm Post

Virescent wrote:
biblioman wrote:Frankly speaking, I am not sure such a problem could be solved by a switcher—just because it is about some fundamental principle, not an option.

Why would you say it can't be solved by a mode? I don't think this is a difficult problem technically speaking. There was a bug altering the behaviour, so it doesn't seem to me that some fundamental change is required. Just bring up that bug back and make that behaviour optional.

[...]

So, to recap. I think the behaviour when the cursor position is changed when scrolling in Scrivenings mode is wrong on three accounts:
  1. This behaviour does not seem to be a common practice among text-editing or other software, and most users would be unfamiliar with it.
  2. This behaviour is arguably breaks accessibility guidelines by introducing unexpected focus changes without an explicit user intention to move the focus.
  3. This behaviour breaks Microsoft guidelines for Windows application on not changing input focus when using the mouse wheel.

The best outcome, as I see it, would be to return to the "buggy" behaviour for the Windows version of Scrivener when the cursor doesn't move on scrolling. If that is not entirely possible, since it would be a big change for the Scrivener user base who came to rely on this behaviour, a switch that toggles the behaviour between moving and not moving the cursor would be the second best solution.


Virescent, I just love your last reply—both the approach and, especially, arguments. If I were the delelopers, I would definitely follow you proposal. But as long as I am not, I can only express some doubts. Of course, I do not think getting back to the 'correct' behaviour is a fundamental technical problem. What I meant (and I would be happy to be wrong), there is hardly possible to have both versions available for the customers (i.e. to permit toggling between them in Options). If so, it is a fundamental choice point for the developers, bearing in mind not only the party of 'happy users', but the expected concordance with the OS version interface.

Again, from my point of view, the concordance with the vast majority of text editing apps for Windows (from text-editors and word-processors to big layout systems like InDesign) should be the highest priority in this case. But there are probably some other priorities that make the decision not so easy. An extra option (in Options )) could be great, but, as I said, I doubt this is optional. )

User avatar
devinganger
Posts: 2508
Joined: Sat Nov 06, 2010 1:55 pm
Platform: Mac, Win + iOS
Location: Monroe, WA 98272
Contact:

Mon Oct 07, 2019 12:58 am Post

The devs have already stated that the bug has been fixed so that its behavior matches the Mac behavior. THAT IS SPEC. The Windows version is not supposed to be adding differences in if not absolutely necessary.

If you want to argue that both versions should do it differently, Wish List is the right place to have the argument.
--
Devin L. Ganger
Not a L&L employee; opinions are those of my cat
Life has a way of moving you past wants and hopes -- Kevin Flynn

bi
biblioman
Posts: 109
Joined: Sat May 26, 2018 11:08 pm
Platform: Windows

Mon Oct 07, 2019 7:08 am Post

devinganger wrote:The devs have already stated that the bug has been fixed so that its behavior matches the Mac behavior. THAT IS SPEC. The Windows version is not supposed to be adding differences in if not absolutely necessary. If you want to argue that both versions should do it differently, Wish List is the right place to have the argument.


(1) I don't think anybody in this thread is in a position to argue with the devs, except the devs; (2) I do not think reasonable comments about buggy or seemingly buggy (in any case, not standard), behaviour are related to the wish list. Moreover, some further important details were added above after the devs' statement. And this is just a position of a few (or possibly more than a few) customers on the specific theme for the devs to hear—just what this section of the forum is intended for.

ae
aeternali
Posts: 10
Joined: Sat Apr 21, 2018 12:41 am
Platform: Windows

Thu Oct 17, 2019 3:13 am Post

This is unusable like this. I can't predict where the cursor will end up and I change things that I did not intend to change. The scrolling and focus seems to be flying all over the place and if this is not resolved I will have to discontinue using Scrivener.

EM
EMPisek
Posts: 167
Joined: Sat Jun 02, 2018 2:05 pm
Platform: Windows

Thu Oct 17, 2019 10:59 am Post

aeternali wrote:This is unusable like this. I can't predict where the cursor will end up and I change things that I did not intend to change. The scrolling and focus seems to be flying all over the place and if this is not resolved I will have to discontinue using Scrivener.


Then use the non beta.
:arrow: I'm not just a tester,.. I'm a user :!:

bi
biblioman
Posts: 109
Joined: Sat May 26, 2018 11:08 pm
Platform: Windows

Thu Oct 17, 2019 11:23 am Post

EMPisek wrote:
aeternali wrote:This is unusable like this. I can't predict where the cursor will end up and I change things that I did not intend to change. The scrolling and focus seems to be flying all over the place and if this is not resolved I will have to discontinue using Scrivener.


Then use the non beta.


EMPisek, I am afraid the point of this discussion is not a bug (which is to be eliminated in the relise), but rather a conceptual problem—see Virescent's posts above (and Tiho's official statement )).
Last edited by biblioman on Thu Oct 17, 2019 11:27 am, edited 1 time in total.