[Bug]: sendURLToOtherInstance not working with other viewers

[dvask]

Environment

Alchemy Beta 7.1.9.2492 (64bit)

Description

After installing Alchemy on Windows, all SLURL links passed on from Windows to the viewer is opened in Alchemy. If another viewer is running (say LL Second Life viewer) then Alchemy will still be launched, despite another viewer already running.

While not strictly a bug, I do see this as a (hopefully) unintended consequence impacting the URL handoff functionality if another viewer (instance) is running.

Alchemy defines its window class as "Alchemy" but other viewers I have tested this issue with (LL's official viewer, Firestorm, Catznip, Cool VL) all define their window class as "Second Life".

I'm not a viewer developer, but if we look at the implementation of LLAppViewerWin32::sendURLToOtherInstance in llappviewerwin32.cpp, then it's clear that with the current implementation, it will never pass on URLs to any other viewer besides Alchemy due to the window class name:

//virtual
bool LLAppViewerWin32::sendURLToOtherInstance(const std::string& url)
{
    wchar_t window_class[256]; /* Flawfinder: ignore */   // Assume max length < 255 chars.
    mbstowcs(window_class, sWindowClass.c_str(), 255);
    window_class[255] = 0;
    // Use the class instead of the window name.
    HWND other_window = FindWindow(window_class, NULL);

    if (other_window != NULL)
    {
        LL_DEBUGS() << "Found other window with the name '" << getWindowTitle() << "'" << LL_ENDL;
        COPYDATASTRUCT cds;
        const S32 SLURL_MESSAGE_TYPE = 0;
        cds.dwData = SLURL_MESSAGE_TYPE;
        cds.cbData = url.length() + 1;
        cds.lpData = (void*)url.c_str();

        LRESULT msg_result = SendMessage(other_window, WM_COPYDATA, NULL, (LPARAM)&cds);
        LL_DEBUGS() << "SendMessage(WM_COPYDATA) to other window '"
                 << getWindowTitle() << "' returned " << msg_result << LL_ENDL;
        return true;
    }
    return false;
}

This issue of course also impacts Alchemy in the opposite direction - if a user installs Alchemy and then installs another viewer, then SLURLs will never be passed on to Alchemy as they are looking for a window with the class name "Second Life".   My suggested fix is to either change the window class name to "Second Life", or modify the implementation to specifically also look for windows with the "Second Life" class name.

Reproduction steps

1. Install another viewer, i.e. LL Official Viewer or Firestorm
2. Install the latest Alchemy beta
3. With Alchemy closed, open the other (non-Alchemy) viewer and pass along a secondlife:// url, for example the Welcome Hub, secondlife://WelcomeHub/130/86/25
4. Observe that Alchemy will now launch instead of handing off the URL to the already running viewer.

[DarlCat]

This is not a defect, and is identical in function to every other Linden codebase derived viewer. Please direct your attention to the Windows registry and the associated default apps settings which are responsible for associating URI schemas with their associated default applications.

The sendURLToOtherInstance code path is what enables a stub viewer process to detect an existing instance and pass the SLURL to that running instance before exiting.

Tradition dictates that the most recently installed viewer becomes default as this is Linden Lab's set standard. If you wish to use another viewer as your SLURL URI default then you will need to adjust that in your system settings, or re-run that viewer's installer.

[dvask]

This is not a defect, and is identical in function to every other Linden codebase derived viewer. Please direct your attention to the Windows registry and the associated default apps settings which are responsible for associating URI schemas with their associated default applications.

The sendURLToOtherInstance code path is what enables a stub viewer process to detect an existing instance and pass the SLURL to that running instance before exiting.

Tradition dictates that the most recently installed viewer becomes default as this is Linden Lab's set standard. If you wish to use another viewer as your SLURL URI default then you will need to adjust that in your system settings, or re-run that viewer's installer.

Traditions aside, a quick test shows that only two of the top third-party viewers (specifically Alchemy and Black Dragon) are not implementing "Second Life" as the window class.

But if that is your stance then that is fine, I will instead reroute my feedback to Linden Lab and the TPV meetings instead as I believe a change in this behavior would benefit anyone running multiple viewer installations.

[DarlCat]

Alchemy isn't Second Life, so it should not share its window class. Default SLURL URI mapping is left to the host operating system. The binary that is launched by the operating system for an associated schema is not a decision of the binary itself, it is a decision that the operating system makes based on its configuration.

[dvask]

Alchemy isn't Second Life, so it should not share its window class. Default SLURL URI mapping is left to the host operating system. The binary that is launched by the operating system for an associated schema is not a decision of the binary itself, it is a decision that the operating system makes based on its configuration.

I understand how the SLURL mapping works just fine, all I am saying is that the functionality to forward it to already running sessions is already there, and fully utilized by nearly every other third-party viewer.

It's your project and I just wanted to raise this as I believe making a change here would benefit anyone having more than one viewer installed.

Having to re-install another viewer anytime Alchemy is updated in order to be able to use other viewers together with Alchemy is not exactly very user friendly.

I did not have any ill intentions; I was simply looking to help improve the overall user experience and align better with what most other viewers are doing.

Thank you for taking the time to discuss this :)

[DarlCat]

It seems you do not fully understand how the SLURL mapping code functions. The unique window class for each viewer ensures that the URI handler instance spawned by the OS can send messages to the already running instance of itself.

This is critical to prevent confusion, as having the same window class for different viewers would cause SLURLs to open in the wrong viewer, ignoring the user's OS preferences.

For example, if all viewers followed your logic, having Alchemy set as the default but running the Second Life viewer would cause SLURLs to open in Second Life instead of Alchemy, disregarding user preferences.

Therefore, it's essential for each viewer to identify only its instances to honor the OS settings. Viewers with different names and directories should have distinct window classes to avoid intercepting messages and conflicting with the "allow multiple instances" limitation. Proper differentiation is crucial for respecting user preferences and maintaining functionality.

[dvask]

I'm not disagreeing with you in the sense that this is not how it is supposed to be used, just as a user is - from an installation standpoint - only supposed to have one preferred viewer.

While you may consider the outcome of sharing the window class undesirable, it is in fact what (from my testing) most other viewers, besides Alchemy and Black Dragon does, and evidently also something that a subset of the users are expecting based on some of the support questions I have seen.

Ultimately a user can rerun the installation from one of the other viewers after updating or installing Alchemy and get this behavior back, but at the cost of the other viewers only passing along the SLURL between them but will not pass it along to Alchemy.

I prefaced this message with me agreeing with you that this is not how it is supposed to be used, and despite other viewers using it this way, I also respect that you will not make that change for Alchemy. The path forward I believe will be for LL to implement a better way of handling SLURLs, especially in this age where some users switch between viewers.

In the meanwhile, I'm considering submitting a feature request to allow the user to opt-out of having "HKEY_LOCAL_MACHINE\Software\Classes\secondlife\shell\open\command" modified during installation - would you be opposed to a solution like that? I see that this already appears to be optional in the linux installer shell script.

[DarlCat]

That would be a welcome feature request, and a pull request would also be welcomed.