Keyboard paging computation error while paging up
See original GitHub issueReplicate
- Run the following JavaFX application, which uses RichTextFX:
import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.ScrollPane; import javafx.stage.Stage; import org.fxmisc.flowless.VirtualizedScrollPane; import org.fxmisc.richtext.StyleClassedTextArea; public class Pagination extends Application { public static void main( final String[] args ) { launch( args ); } @Override public void start( final Stage stage ) { final var editor = new StyleClassedTextArea( false ); final var scrollbars = new VirtualizedScrollPane<>( editor ); scrollbars.setVbarPolicy( ScrollPane.ScrollBarPolicy.ALWAYS ); editor.setWrapText( true ); stage.setScene( new Scene(scrollbars) ); stage.show(); } }
- Copy multiple text paragraphs (e.g., https://www.lipsum.com/feed/html).
- Paste the text 5 times (to ensure the scrollbar extends).
- Do not resize the window (you can, but it’ll mean more steps; if you did, start over):
- Press
Ctrl+Home
to navigate to the top of the document. - Press
Ctrl+End
to navigate to the bottom of the document. - Press and hold
Page Up
to navigate upwards.
Expected Results
The view port navigates back one page for as long as the key is held, or the top is reached.
Actual Results
The computation for the new caret position goes awry in a variety of ways, depending on how much text is pasted and the view port size, resulting in one of the following behaviours:
- Nothing happens.
- View port scrolls up several times, but eventually stops, as though running into an asymptote.
- View port scrolls up a few times, then scrolls to the same page within an infinite loop.
Bonus “Bug”
Possibly considered a feature request, most word processors allow the page up key to move the cursor to the top of the document. If there is insufficient room for a complete page before reaching the top of the document (i.e., paragraph 1, care position 1), RichTextFX prevents further paging up. This is atypical behaviour, but not really a bug because it is likely performing to specification. The specification is inconsistent with most other editors. (Compare with the page up/page down behaviour of the text area for writing issues on GitHub, for example.)
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (2 by maintainers)
Top GitHub Comments
@DaveJarvis thanks for reporting. I submitted a PR in Flowless that hopefully resolves this.
I’ve had look and was able to replicate the problem, but I haven’t determined what causes it. Will have a look next week and see if I can find out why …