IncognitoClone — Open browser frontmost tabs in private windows

[vitor]

Invoke ic to open the current tab in your frontmost browser in a new incognito (Chromium-based browsers) or private (Webkit-based browsers) window. Actioning with ⌃↵ will also close the tab in your current window. ⌥↵ opens the tab in a new clean temporary browser profile window, and ⌘↵ does the same while closing the tab in the current window.

Webkit-based browsers do not support multiple profiles, so that feature is not available to them.

In addition, Webkit-based browsers do not support opening new private windows programatically, so to do it we can either fake a keyboard shortcut or click the menu options. Faking keyboard shortcuts can break in more situations, so this Workflow uses the latter technique. If your system is not in English, change the webkit_menu_path Workflow Environment Variable to the menu words in your language (they must be exact).

 
Download | Source

Edited May 8, 2020 by vitor

[vitor]

Update.

 

Added options to open a new Chrome instance, with an empty profile. See the options on the original post.

[vitor]

Update.

 

Includes instructions and a version (Alfred 3 features).

[vitor]

Update.

 

It now uses OneUpdater, so this should be the last time you need to manually update.

[vitor]

Updated to use the most recent version of OneUpdater (released today).

[vitor]

Update.

New icon and slight code improvements.

To update, download the latest version (same URL) or wait a few days (15 or less) and it’ll prompt you to on next usage, since it uses OneUpdater.
 

[vitor]

Major Updates.

Rewrote the Workflow in JXA. It now supports not only Chrome, but other Chromium-based browsers as well (Vivaldi, Brave, …). It also supports Webkit-based browsers, but only for opening private windows, not for new profiles (if you want that feature to be possible, you’ll have to ask Apple).

 

For opening private windows in Webkit browsers, a bit of GUI automation is necessary. I tend to avoid those, but this should be fairly reliable since it achieves its goal by going through the app menus, not by faking a keyboard shortcut (which could be changed by the user). Let’s see if it works well in practice.

To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.
 

[deanishe]

5 hours ago, vitor said:

this should be fairly reliable since it achieves its goal by going through the app menus

 

Simulating keypresses is more reliable, imo, because Safari's menus will not necessarily be in English.

[vitor]

9 hours ago, deanishe said:

Simulating keypresses is more reliable, imo, because Safari's menus will not necessarily be in English.

 

I absolutely forgot about that detail. You’re right. But relying on a changeable keyboard shortcut is something I’d really like to avoid. I’ll either remove the ability for Webkit browsers or provide a way to submit the correct menu wordings via a Workflow Environment Variable.

[vitor]

Update.

Allow for non-english menu items in Webkit-based browsers.

To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

[deanishe]

2 hours ago, vitor said:

provide a way to submit the correct menu wordings via a Workflow Environment Variable

 

Good call. You could probably have also built the workflow so the keyboard shortcut is dispatched via Alfred's Dispatch Key Combo, where the user could also change it. But I think I like your way better.

 

I put this feature in my Safari and Firefox workflows, and it was really easy to implement in the Firefox one because it's part of the native extension window/tab-creation API. It's super fast and extremely reliable. Of course, that doesn't change the fact that the whole thing was a massive PITA due to having to write an extension in the first place…

[vitor]

2 hours ago, deanishe said:

Of course, that doesn't change the fact that the whole thing was a massive PITA due to having to write an extension in the first place…

 

Which just reminded me I ended up never answering on the Firefox Assistant thread! I didn’t have the chance at the time and saved the email as a reminder, but then that does require one to remember to check old emails as new ones pile up.

 

Email clients should have an option to sort from oldest to newest. That way you wouldn’t forget them—they’d inconvenience you until dealt with.

[deanishe]

3 minutes ago, vitor said:

Email clients should have an option to sort from oldest to newest.

 

Yours can't??? MailMate ftw.

 

But more importantly, what did you want to say about the Firefox workflow? It's very much a prototype at this point. Useful feedback and suggestions are definitely wanted.

[vitor]

2 minutes ago, deanishe said:

Yours can't??? MailMate ftw.

 

I remember first seeing MailMate years ago. It looked impressive in what it could do, but its looks and price (I don’t remember if at the time I had ever paid for software, but even if I had I surely had never paid that much) made me shy away from it. I should take a look at it again, though, as there’s currently no email client that satisfies me

 

What do you use on iOS?

 

10 minutes ago, deanishe said:

But more importantly, what did you want to say about the Firefox workflow? It's very much a prototype at this point. Useful feedback and suggestions are definitely wanted.

 

Nothing useful yet, as I haven’t had the chance to explore it in detail. But it looks great so far—I took the demo for a spin first, and the idea to pass the variables to the Call External Trigger so that it can be called back is ingenious, I really liked that one.

Though it’s with that one that I realised Call External doesn’t show an error if it calls a Workflow the user doesn’t have installed, and that would be useful. As of now it’s a silent failure.

However, when calling an External Trigger via AppleScript it does produce an error if it can’t find it. So a way around the limitation would be to have an External Trigger in Firefox Assistant connected to nothing (the identifier could be something like exist). That way one could tell application id "com.runningwithcrayons.Alfred" to run trigger "exist" in workflow "net.deanishe.alfred.firefox-assistant" beforehand, and if it failed show an error to the user: “Hey, you need to install Firefox Assistant first: <link>”.

Alternatively, we could make a feature request to either (or both): show an error in the debugger if External Trigger tries to call a Workflow that isn’t installed; have a way to check via AppleScript for a Workflow, without having to resort to the trick above (i.e. without the developer having to specifically add the feature).

[deanishe]

12 hours ago, vitor said:

What do you use on iOS?

 

Triage for quickly deleting unimportant mails and Mail.app. I've tried most iOS email clients, and they're just not very good, imo. I do most email on the Mac, anyway, because it has a real keyboard and MailMate.

 

It's definitely worth the money, imo. I've been using it for years and there's never been a paid upgrade. Also, the developer Benni is amazing. When I had a problem, he spent all day emailing with me and making me special builds.

 

12 hours ago, vitor said:

However, when calling an External Trigger via AppleScript it does produce an error if it can’t find it. So a way around the limitation would be to have an External Trigger in Firefox Assistant connected to nothing (the identifier could be something like exist).

 

Good idea. I'll add that.