Navigator object vaidation before recognition in contentRecog

[ShubhamJain7]

Link to issue number:

fixes #11380

Summary of the issue:

contentRecog.recogUI.recognizeNavigatorObject currently has no mechanism for validating the navigator object before passing it to the recognizer for content recognition. This allows navigator objects that are known to produce bad or no results to be processed for content recognition and waste user time.

Description of how this pull request fixes the issue:

This pull request adds a validateNavigatorObject to contentRecog.ContentRecognizer that can then be overridden by users to define validation code for their application and also define what to do when validation fails. This function is then called in contentRecog.recogUI.recognizeNavigatorObject to ensure that the currently focused navigator object is valid before it is passed to the recognizer for content recognition.

Testing performed:

I overrode the validateNavigatorObject function when creating a class that derives from contentRecog.ContentRecognizer to ensure that the width and height of the navigator object are greater than a specific threshold. I then tested the code on navigator objects with dimensions both greater and lower than the specified threshold and got expected results. Which is, content recognition was performed for navigator objects that passed the validation test and not on navigator objects that failed the test.

Known issues with pull request:

None

[Adriani90]

@ShubhamJain7 could you please also add a note for change log? Something like:

• NVDA no longer presents incomplete or bad OCR results on certain navigator objects

[Adriani90]

Moreover, did you test this in pdf documents which contain pictures or scan images? Note that if you run an OCR on a pdf page after you switched to it, NVDA will recognize the whole page at once. But if you move on the page with arrow keys, NVDA will only recognize the navigator object.
Ideally this functionality should not be broken by this pull request.

[Adriani90]

Sometimes even bad results give enough detail for an user to understand what the object is about.
cc: @lukaszgo1 or @CyrilleB79 your ghoughts on this are also appreciated.

[lukaszgo1]

@Adriani90 I'm afraid you misunderstood what this PR implements. There is no change in functionality here - it just makes it easier to implement additional validation for developers but there is none implemented by default.

[ShubhamJain7]

@Adriani90, @lukaszgo1 is correct. This PR doesn't change existing functionality, it only adds a mechanism for users to validate a navigator object before it is used for content recognition. By default, it is treated as valid so any previous use of this code segment will not be affected.

[LeonarddeR]

This code assumes that we're recognising the navigator object. I don't think this should be true always. have you considered to make this more generic, e.g. validateObject?

[ShubhamJain7]

@LeonarddeR
Thanks for pointing that out! I'll update the method name.

[feerrenrut]

It probably is better that the validate method name is generic, but at the moment the object is the result of api.getNavigatorObject().

[feerrenrut]

Thanks @ShubhamJain7