Bugzilla

(In reply to Kershaw Chang [:kershaw] from comment #17)
> I can also reproduce this by simply ticking the checkbox in the prompt.
> 
> The result of  `isCurrentAppOSDefaultForProtocol("ftp")` is false and the mismatch is:
> 
> ```
> selfURL
> file:///Users/changkershaw/work/gecko/objdir/dist/NightlyDebug.app/
> ```
> ```
> handlerBundleURL
> file:///Applications/Firefox.app/
> ```

OK, so what's happening here is that you don't use the profile manager by default and so Firefox starts up with the new URI, and hands the URI back to nightly-debug? If you make nightly-debug the default for ftp URIs, the problem doesn't happen?

We explicitly decided not to deal with that case in bug 1496380 (cf.  https://phabricator.services.mozilla.com/D48742#inline-300614 ). The understanding there seems to be that Firefox.app shouldn't be delegating to NightlyDebug.app if they're not using the same profile. If that's still happening, that feels like it should be a separate bug to this one, ideally with more details - as the real issue there would be profile selection.

> Note that I can make  `isCurrentAppOSDefaultForProtocol("ftp")` return true by using swiftdefaultapps to change ftphandler to `NightlyDebug.app`, but the prompt still shows and ask me if I want to use `NightlyDebug` to open the `ftp` link. I think we should always ask users to choose an external app, not to choose between external app and `NightlyDebug`.

You can file a separate bug about improving this flow, but it's not straightforward and probably not a priority for now. IIRC we only have infra to get the system default from the OS -- not "all the apps that told the OS they can handle these URIs". So we list the OS default, plus items that the user has manually added as helper apps. So in terms of straightforward fixes, we could hide an item referring to the current app, so that only the "choose an app" row shows up. That still doesn't sound great, it feels like really we should be telling the user in some way "hey, you configured your OS to open `whatever:` links with Firefox but we don't know how to open those links". Anyway, fodder for a separate bug.


Anyway, it sounds like we've established that this is basically a result of bug 1599713. If someone has the knowledge of linux default checks to address that, that'd be great - it basically boils down to an implementation of

(In reply to Kershaw Chang [:kershaw] from comment #17)
> I can also reproduce this by simply ticking the checkbox in the prompt.
> 
> The result of  `isCurrentAppOSDefaultForProtocol("ftp")` is false and the mismatch is:
> 
> ```
> selfURL
> file:///Users/changkershaw/work/gecko/objdir/dist/NightlyDebug.app/
> ```
> ```
> handlerBundleURL
> file:///Applications/Firefox.app/
> ```

OK, so what's happening here is that you don't use the profile manager by default and so Firefox starts up with the new URI, and hands the URI back to nightly-debug? If you make nightly-debug the default for ftp URIs, the problem doesn't happen?

We explicitly decided not to deal with that case in bug 1496380 (cf.  https://phabricator.services.mozilla.com/D48742#inline-300614 ). The understanding there seems to be that Firefox.app shouldn't be delegating to NightlyDebug.app if they're not using the same profile. If that's still happening, that feels like it should be a separate bug to this one, ideally with more details - as the real issue there would be profile selection.

> Note that I can make  `isCurrentAppOSDefaultForProtocol("ftp")` return true by using swiftdefaultapps to change ftphandler to `NightlyDebug.app`, but the prompt still shows and ask me if I want to use `NightlyDebug` to open the `ftp` link. I think we should always ask users to choose an external app, not to choose between external app and `NightlyDebug`.

You can file a separate bug about improving this flow, but it's not straightforward and probably not a priority for now. IIRC we only have infra to get the system default from the OS -- not "all the apps that told the OS they can handle these URIs". So we list the OS default, plus items that the user has manually added as helper apps. So in terms of straightforward fixes, we could hide an item referring to the current app, so that only the "choose an app" row shows up. That still doesn't sound great, it feels like really we should be telling the user in some way "hey, you configured your OS to open `whatever:` links with Firefox but we don't know how to open those links". Anyway, fodder for a separate bug.


Anyway, it sounds like we've established that this is basically a result of bug 1599713. If someone has the knowledge of linux default checks to address that, that'd be great - it basically boils down to an OS-specific implementation of the ` isCurrentAppOSDefaultForProtocol` XPCOM method.