Finicky Does Not Retain 'Open in Background' Setting to Pass to Opening Browser

[hisaac]

It appears that when an URL is set to be opened in the background, that setting is not passed from Finicky to the opening browser.

I did a little digging in the code, and I wonder if it's because right now the browser's are being opened by Finicky using a shell command. (This is an assumption based on the getBrowserCommand() method in Browsers.swift. It looks like you're building a shell command in that method.)

I wonder if it might be better to use NSWorkspace's open(_:withApplicationAt:configuration:completionHandler:) method instead. It allows for you to specify the app to open the URL, and pass in an NSWorkspace.OpenConfiguration value, which has an activates property. Passing in a false value for activates should open the app in the background.

This is all assuming that Finicky is being opened in a similar way, and that it's possible to grab the activates property off of whatever is opening Finicky. I haven't investigated far enough to know if that's true or not.

[johnste]

I remember Finicky used to handle this condition. I suspect I accidently removed it when I refactored something. I think it shouldn't be that hard to reimplement without having to refactor the way Finicky launches applications.

[hisaac]

Excellent, yeah hopefully it's not too difficult.

[hisaac]

I just tested the changes in 008e968, but the issue persists for me. I'm trying to debug in Xcode to see if I can follow it. What method gets called when Finicky handles a URL? I set breakpoints in all of the methods in the AppDelegate, but none of them seem to get hit.

[johnste]

It's `handleGetURLEvent`. I added back a method similar to the way it was done before, whee finicky keeps track of it's activated or not and passes that information to the browser command code. I tested it with an RSS reader app called Vienna RSS. How are you experiencing the issue? What app wants to open the browser in the background and what browser are you trying to open? There is a bug in Chromium browsers #71 (last I checked) which causes it not to open in the background.

…

On Sat, May 9, 2020, 23:12 Isaac Halvorson ***@***.***> wrote: I just tested the changes in 008e968 <008e968>, but the issue persists for me. I'm trying to debug in Xcode to see if I can follow it. What method gets called when Finicky handles a URL? I set breakpoints in all of the methods in the AppDelegate, but none of them seem to get hit. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGYKI6XUH4VW7RWY2J4DCTRQXBL7ANCNFSM4M2L3SEQ> .

[johnste]

If there still are issues I can probably look into it tomorrow

[johnste]

If xcode doesn't break anywhere maybe a copy of finicky is already runnning?

[hisaac]

I'm using Reeder to open the links, with its "Open links in background" setting on. And the browser I'm using is Safari.

When I have the default browser set to Safari, it works as expected — the links are opened in Safari, but Safari is not activated and brought to the foreground. When I have the default browser set to Finicky, the links are opened in Safari, but Safari is activated and brought to the foreground.

I got the breakpoints in Xcode to work now now — not sure why it wasn't the first time. Where are you pulling the "open this URL in the background" info from? The NSAppleEventDescriptor that gets sent into the handleGetURLEvent function? I'm not familiar with how Apple Events work, so I'm not sure how to find if the "open in background" piece is getting passed successfully.

Also, here's my config file if that helps:

module.exports = {
	defaultBrowser: "Safari",
	handlers: [
		{
			// Open Spotify links in Spotify.app
			match: finicky.matchHostnames("open.spotify.com"),
			browser: "Spotify",
		},
		{
			// Open Apple Music links directly in Music.app
			match: finicky.matchHostnames([
				"music.apple.com",
				"geo.music.apple.com",
			]),
			browser: "Music",
		},
		{
			// Open Zoom links in the Zoom.app
			match: /zoom.us\/j\//,
			browser: "us.zoom.xos",
		},
	],
	rewrite: [
		{
			// Rewrite Apple Music links to use `itmss` as protocol
			match: finicky.matchHostnames([
				"music.apple.com",
				"geo.music.apple.com",
			]),
			url: ({ url }) => ({
				...url,
				protocol: "itmss"
			}),
		},
	],
};

[johnste]

Thanks for the detailed info. I'll try to reproduce the problem now.

Finicky keeps track of if it is activated or not with these methods in AppDelegate.swift:

    func applicationDidBecomeActive(_: Notification) {
        isInBackground = false
    }

    func applicationDidResignActive(_: Notification) {
        isInBackground = true
    }

It then uses isInBackground and passes it down to configLoader.determineOpeningApp which uses it's isActivated parameter to set the behavior of the BrowserOpts representing each browser to potentially launch.

// Config.swift
let browser = try BrowserOpts(name: browserName, appType: appType!, openInBackground: openInBackground ?? !isActivated) 

[johnste]

I believe I have an idea of what's happening. Finicky assumes it's active when it is first started, so if a url is opened in the background it would default to opening it in the foreground.

Do you still see the issue if you open and close the Finicky console window first?

There's no obvious solution for this I think, will have to look into handling Apple Events more.

[johnste]

Ok, after doing some searching I found another method of checking the current active state of the application, (just NSApplication.shared.isActive) and using it to determine if the browser is to be opened in the bg or not.

I just pushed b23487e which has my new attempt at a fix. It seems to work well when I try it. I'm using your config and Vienna.

[hisaac]

Nice, it works now! Thank you for the quick fix!