editor opening in top ⅓ of doc...

[kadso]

Shortly after updating to MacOS 15.3 I noticed Scrivener opening the editor window about ⅓ the way down the document.. Previously, when I clicked on a document in the binder, the editor would display the top of the document. This is with MacOs 10.15.3 + Scrivener 3.15 (12258).

I've also noticed—after lots of assessment—that the above misalignment is related to the inspector window. Specifically, after I click on a doc in the binder (resulting in the editor opening the document about ⅓ the way down and cutting off the top), I can get expected top line alignment by opening and closing the inspector. I do this via this keyboard combo: command + option + i.

I searched and couldn't find any postings, Is anyone else experiencing this?

[RobG]

Just updated my own Mac and am not seeing this issue. I've not seen any other reports so far either.

Is it confined to one project?

[kadso]

no. all projects
It is very irritating. I can set the window to display the first row of text. I then click off the article to a second article, and them click back to the first article. Rather than appearing where I left off (at the top, even with the cursor in the first row), the window opens down the page.

At this time, I can't determine a set percentage or amount it sets down.
This happens at many > 100% and 100% zoom. When I set zoom at <100 the entire text appears.

Thoughts?

[kadso]

I've done some more testing and found something interesting and repeatable. It has to do with the ruler showing for not showing. When it's not showing, the behavior is as expected: the editor window opens up to where the cursor was last positioned.

However, when the ruler is showing, and the cursor is positioned on the first line, the ruler is blocking the view of the first line.

A bit of clicking in and out of different document editor windows, with and without the ruler should demo what I'm experiencing.

I understand Scrivener uses Apple's text engine. Now that I think about it, I'm experiencing similar situations in other apps known to use the same text engine.

I can roll without the ruler showing 100% of the time. So it was more about a minor visual annoyance, than anything else.

Thanks for the interaction. It was quite helpful...

[SkyPilot]

I'm using the Windows beta (v36), but I experience what I thought was the same thing. Perhaps this is expected behavior, but it seems a little bit odd. It's probably the correct behavior, but when I'm coming back to either read the document, or scan for some particular passage, that's when I find it a bit offputting.

Recipe:
- open a document that is longer than the viewport of the editor window.
- place cursor anywhere down in the body of the document.
- click off of that document, and onto another
- return to the first document

Result: The first document will open in the editor with the cursor at the bottom most position of the viewport....positioned, it seems, for the next line of text to be typed in.

EDIT: On reflection, it seems that it has to be one or the other. If the document always opened at the topmost position, then those who are still writing that particular document would find it just as bothersome.

[xiamenese]

I'm using the Windows beta (v36), but I experience what I thought was the same thing. Perhaps this is expected behavior, but it seems a little bit odd. It's probably the correct behavior, but when I'm coming back to either read the document, or scan for some particular passage, that's when I find it a bit offputting.

Recipe:
- open a document that is longer than the viewport of the editor window.
- place cursor anywhere down in the body of the document.
- click off of that document, and onto another
- return to the first document

Result: The first document will open in the editor with the cursor at the bottom most position of the viewport....positioned, it seems, for the next line of text to be typed in.

Post this in the Windows Beta Testing forum if you haven't already. The Mac version is Mac-native while the Windows version is programmed in Qt. As such, I don't suppose they share much code, perhaps not any at all.



Mark

[SkyPilot]

I'm actually thinking that what I am seeing is really not a bug, and is very likely expected behavior.