Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PowerPoint: Report link destination #17435

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

CyrilleB79
Copy link
Collaborator

Link to issue number:

None

Summary of the issue:

When in PowerPoint, NVDA+K does not work to report a link.

Description of user facing changes

  • In PowerPoint slides (edition mode), pressing NVDA+K will now report the link destination. This works in text areas as well as on shapes / charts / images that are links.
  • Also 2 small fixes:
    • Restored the Copy and Close buttons of the browseable message of NVDA+K that were removed by mistake in Report destination of link in Word / Outlook legacy #17292
    • In Windows UI, e.g. settings, pressing NVDA+K on a link does not report anymore that there is no link; it rather reports that the destination cannot be reported.

Description of development approach

  • Use PowerPoint object model
  • Changed the global strategy to retrieve a link: first try from text infos; if not supported, try from the focused object.

Testing strategy:

  • Tested PowerPoint link reporting in text area, on shapes and images
  • Re-tested link reporting in browsers (Chrome, FF and ui.browseableMessage), in Word / Outlook with/without UIA (text and images), in Excel.

Known issues with pull request:

  • NVDA+K doesn't still work in the slideshow; by the way, the presence of links is not reported either in slideshow.
  • There are other situations where link is not reported by NVDA+K on the web or elsewhere (WordPad, Adobe Reader) but this PR does not degrade any experience.

Code Review Checklist:

  • Documentation:
    • Change log entry
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • API is compatible with existing add-ons.
  • Security precautions taken.

@coderabbitai summary

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • PASS: License check.
  • PASS: Unit tests.
  • FAIL: Lint check. See test results and lint artifacts for more information.
  • PASS: System tests (tags: installer NVDA).
  • Build (for testing PR): https://ci.appveyor.com/api/buildjobs/pq3nek8hq450qkur/artifacts/output/l10nUtil.exe nvda_snapshot_pr17435-34625,af181091.exe
  • CI timing (mins):
    INIT 0.0,
    INSTALL_START 1.4,
    INSTALL_END 1.2,
    BUILD_START 0.0,
    BUILD_END 30.5,
    TESTSETUP_START 0.0,
    TESTSETUP_END 0.4,
    TEST_START 0.0,
    TEST_END 19.0,
    FINISH_END 0.1

See test results for failed build of commit af181091bf

@seanbudd seanbudd added the conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review. label Nov 26, 2024
@CyrilleB79 CyrilleB79 marked this pull request as ready for review November 26, 2024 10:38
@CyrilleB79 CyrilleB79 requested a review from a team as a code owner November 26, 2024 10:38
@CyrilleB79 CyrilleB79 marked this pull request as draft November 26, 2024 20:25
@CyrilleB79
Copy link
Collaborator Author

For reviewers (@SaschaCowley or @seanbudd ):

OK finally, I'll mark this as ready.

My initial intention was to rework the code to avoid reporting "Not a link" on links in applications where retrieving the destination of a link is not implemented (e.g. Adobe Reader). But I am unable to create a function to detect if the caret is on a link. Since it was a bonus in this PR,I won't keep it blocked on this point.

Also, I'd like to move the class definition for _LinkData class elsewhere than in textInfos.__init__.py since it does not apply anymore only to text infos. But I do not know where to move it. Any suggestion?

@CyrilleB79 CyrilleB79 marked this pull request as ready for review November 27, 2024 21:59
@seanbudd
Copy link
Member

seanbudd commented Dec 2, 2024

@CyrilleB79 my suggestion from _LinkData is utils.urlUtils

@CyrilleB79
Copy link
Collaborator Author

@CyrilleB79 my suggestion from _LinkData is utils.urlUtils

OK thanks. Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants