Redundant braille.BrailleHandler.update executions

[burmancomp]

About

There are following code lines in braille.BrailleHandler._handlePendingUpdate:

if scrollTo is not None: self.scrollToCursorOrSelection(scrollTo) if self.buffer is self.mainBuffer: self.update()

scrollToCursorOrSelection should execute scrollTo when region is type of TextInfoRegion. scrollTo in turn executes updateDisplay which executes braille.BrailleHandler.update.

Because region is type of TextInfoRegion and thus buffer should be mainBuffer, braille.BrailleHandler.update is executed twice.

There is similar case in braille.BrailleHandler._doNewObject function:

self.scrollToCursorOrSelection(region) if self.buffer is self.mainBuffer: self.update()

What is the harm? At least log file, when using debug level, contain redundant ""Braille window dots" lines.

Steps to reproduce:

Log level to debug and investigation of log when there is braille display in use (I have not looked at log when braille display is no display).

Actual behavior:

redundant log lines

Expected behavior:

no redundant log lines

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

running from source

NVDA version:

current main branch code

Windows version:

windows 10 22h2

Name and version of other software in use when reproducing the issue:

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

If NVDA add-ons are disabled, is your problem still occurring?

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

[burmancomp]

Fixing this might help to some extend as to issue #16356.

[seanbudd]

Re-opening as #16463 and #16501 are reverted

[burmancomp]

I somewhat feel that removing updateDisplay execution from scrollTo could resolve this type of double updates.

May I try pr with this approach?

[seanbudd]

I'd encourage getting some try build testing before marking it as ready for review, but please do attempt improvements if they are clear improvements

[burmancomp]

Maybe less log lines when debugging is major advantage of this.

I am sorry about testing. In this case I did not unfortunately take into account at least braille messages maybe because I have them disabled so I did not think them (maybe not at all) but it is not acceptable reason).