Cursor changes position when scrolling in Scrivenings mode

[TomGoodell]

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.

[haep]

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.

[biblioman]

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.

[tiho_d]

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.

[biblioman]

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. )

[haep]

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. ,

[Virescent]

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.

[biblioman]

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.

[Virescent]

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:


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.

[biblioman]

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. )

[devinganger]

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.

[biblioman]

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.

[aeternali]

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.

[EMPisek]

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.

[biblioman]

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 )).