Scroll Into View not right for blank paragraphs

1

I have made use of the scroll-margin css property to get my PM editor to scroll the bottom or top so that the paragraph being edited is not at the very very edge (top or bottom) of the editor div. For the most part it is awesome, keeping the caret in a sensible position as typing happens.

However, when I add a new paragraph (hitting the enter key to split a paragraph in the middle or at the end of a paragraph), the cursor does not immediately scroll onto the screen properly until I depress another key (any key, even an arrow key). I am calling tr.scrollIntoView() in my main plugin’s appendTransaction routine to trigger the scroll if neded, but I am wondering if the DOM addition of the new paragraph is maybe not yet created (as opposed to adding characters inside an existing paragraph) and thus is not getting actual DOM bounds for scrolling.

What is the best strategy for getting the scroll to work when the Enter key is adding a brand new (usually empty) paragraph, in the middle or end of the document?

2

This works by default (see demo editors on the website), so the first question would be what did you change to break it.

3

I have a fixed position header (with a menu) and a fixed position footer (with zoom icons and some doc info) at the bottom, both overlaying the multi-page editor div, which might the root of my baseline problem. The caret might sometimes technically on-screen yet is underneath the footer, which was the rationale for the scroll-margin setting (I set it to 75px so users are never typing too close to the bottom of the window). Works great except for adding a new empty paragraph.

Note that previously I had the scroll bar on the editor div, where the header and footer were separate block divs above and below it, and the scrolling into view worked just like the demos at the site - but moving the scroller to the content div of the site (a cleaner look IMO), where the header and footer are overlaid as fixed divs on top of the editor, is where the issues arise. Clearly some special code is needed for fixed overlays in relation to the DOM scrollIntoView as the browser may not think the cursor is offscreen when it is hidden under the fixed overlay (top or bottom).