Display scrolls up without user instruction

[Former user]

Originally reported on Google Code with ID 519

I've been meaning to report this for years.  Quite frequently in Linux, SC randomly
scrolls upwards when I'm least expecting or wanting it to.

It often happens when I'm entering new calculations.  All of a sudden, SC skips up
into the backscroll and I can no longer see the most recent answers.

This is a major annoyance if I'm depending on these answers for input.  It means I
have to move my hand over to the mouse just to scroll down again.

It's like I've rolled my mouse wheel one notch upwards, but actually the mouse isn't
even hovering over the SC window whenever this happens.

Reported by Xavion.0 on 2014-08-02 09:21:04

[Former user]

I am well aware of this bug for a very long time but never had the time and energy to
track it down. Hope me or someone else can fix it for 0.12.

Reported by helder.pereira.correia on 2014-08-03 17:43:20 - Status changed: Accepted - Labels added: Type-Defect, Milestone-0.12, Component-UI, Usability

[Former user]

I think I found the issue. Consider these steps:
0/ Enter some expressions so that the results window contains some lines.
1/ Click on one of the results.
2/ Click in the expression bar.
3/ Enter multiple expressions.
4/ After a moment, when you start typing a new expression, the result window scrolls
up as you start to type, and scrolls back to the bottom when you hit the "return" key
in the expression bar (with a valid expression).

The problem comes from MainWindow::clearTextEditSelection() which clears the selection
from the results (aka "display") widget. It is called when the expression bar gets
the focus or on new inputs in it. Clearing the selection from the display widget does
not move the cursor from where it was (that is, where you click in step 1), and it
triggers some signals/events which result in a call to QPlainTextEdit::ensureCursorVisible(),
which makes sure the current position of the cursor is visible (scrolling the view
if needed).

As QPlainTextEdit::ensureCursorVisible() is not virtual, so we can't bypass it. However,
avoiding touching the cursor if it doesn't hold a selection in MainWindow::clearTextEditSelection()
seems to do the trick. Such a trivial patch is attached.

Reported by [e-mail] on 2014-08-04 00:50:14

[Former user]

Yes, I think you've correctly diagnosed the problem.  Thanks very much for taking such
a close look at it so promptly.

You mentioned something about a patch, but I don't think it was attached to your message.
 Perhaps you can have another go at attaching it.

Reported by Xavion.0 on 2014-08-04 08:13:38

[Former user]

I attached the patch, but failed the captcha, and had to post the message again. I guess
this has removed the patch.

Anyway, it's should be attached now :)

Reported by [e-mail] on 2014-08-05 20:34:55

<hr> * Attachment: issue519_scrollBug.patch

[Former user]

Thanks for reattaching the patch.  I've tested it quickly and the problem seems to have
been solved.  Please merge the patch into the v0.12 codebase.  Thanks again for your
swift and resolute support.

Reported by Xavion.0 on 2014-08-05 21:24:10

[Former user]

Fixed in revision 66ffcf8. Thanks, Tey!

Reported by helder.pereira.correia on 2014-08-06 11:38:57 - Status changed: Fixed

[Former user]

Issue 521 has been merged into this issue.

Reported by [e-mail] on 2014-08-16 11:17:31

[Former user]

Issue 551 has been merged into this issue.

Reported by helder.pereira.correia on 2015-02-14 16:40:31

[Helder Correia]

This problem still occurs some times.

[Helder Correia]

This actually seems to be fixed. Can you confirm, @Teyut ?

[Tey']

Well, you're the one who re-opened the issue, so you tell me :) But from my side, I was unable to reproduce the issue after the patch was merged.

IIRC other changes from someone else have been merged/requested about this issue as well, but I've been unable to find them in the commit log.