Skip to content

p#479 Make sure running app is the one handling urls#5703

Merged
akleshchev merged 2 commits intodevelopfrom
andreyk/viewer_p479
Apr 28, 2026
Merged

p#479 Make sure running app is the one handling urls#5703
akleshchev merged 2 commits intodevelopfrom
andreyk/viewer_p479

Conversation

@akleshchev
Copy link
Copy Markdown
Contributor

@akleshchev akleshchev commented Apr 23, 2026

Make sure running app is the one handling urls.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR aims to ensure the macOS viewer that’s being launched/running re-registers itself as the URL scheme handler (e.g., secondlife://) to avoid stale Launch Services handler caching pointing to another viewer.

Changes:

  • Override LLAppViewerMacOSX::initSLURLHandler() to re-register URL schemes on startup.
  • Add a macOS Objective-C++ helper (register_url_schemes) that calls Launch Services APIs to re-register the bundle and set default URL scheme handlers.
  • Expose the helper via llappviewermacosx-objc.h.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File Description
indra/newview/llappviewermacosx.h Adds initSLURLHandler() override declaration for macOS viewer.
indra/newview/llappviewermacosx.cpp Implements initSLURLHandler() and invokes URL scheme registration.
indra/newview/llappviewermacosx-objc.h Exposes register_url_schemes() to C++ side.
indra/newview/llappviewermacosx-objc.mm Implements Launch Services registration / default handler assignment.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread indra/newview/llappviewermacosx-objc.mm
Comment thread indra/newview/llappviewermacosx.cpp Outdated
@akleshchev akleshchev force-pushed the andreyk/viewer_p479 branch 4 times, most recently from 7b33385 to 6a11d08 Compare April 24, 2026 16:54
I'm not sure if viewer should actually be shutting down on this, but as
a minimum we should be updating or clearing marker files. If viewer
crashes because of a hibernation, it isn't our problem. Viewer isn't
built for that and we can't maintain 'heartbeats' in hibernation.
@akleshchev akleshchev force-pushed the andreyk/viewer_p479 branch from 318f5f9 to 1eb6050 Compare April 27, 2026 17:39
@akleshchev akleshchev marked this pull request as ready for review April 27, 2026 23:06
@akleshchev akleshchev linked an issue Apr 28, 2026 that may be closed by this pull request
@akleshchev akleshchev merged commit ae9f6a5 into develop Apr 28, 2026
16 checks passed
@akleshchev akleshchev deleted the andreyk/viewer_p479 branch April 28, 2026 19:39
@github-actions github-actions Bot locked and limited conversation to collaborators Apr 28, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Win] Shut viewer down on sleep or hybernation

4 participants