@davesteele Yup, installs without a hitch now. Much appreciated!

Was there a regression or is gtk-update-icon-cache now a hard dependency? I’m getting this in Ubuntu 16.04 (when using the PPA).

The following packages have unmet dependencies:
 gnome-gmail : Depends: gtk-update-icon-cache but it is not installable

Steps to reproduce:
Select to download a file uploaded to a channel.

What happens:
A browser window/tab opens with a Slack redirect URL pointing to the file, and asks me to log in to Slack.

What I expect to happen:
I’d prefer it if Scudcloud just directly prompted me with the file saving dialogue, without having to log in to Slack again in the browser.

Other info:
I’m using version 1.22-2 from the PPA on Ubuntu 14.04. I have 2FV set up for the Slack team in question in case it matters.

Thanks @VicDeo, that indeed fixes it.

I’d argue that the comment above the setting in the sample makes this less than apparent — at least I would have been unlikely to have dared to set it to false on my own, and it still seems to me that in making this change I lose ”a crucial security check” for .htaccess. But that’s perhaps subject for another bug.

The README documents wontDeepEqual() as similar to willDeepEqual() but expecting a rejected promise. But a wontDeepEqual() function is not actually defined in the plugin code.

Upgraded to 8.2 today and the issue persists.

Just tested it and I can confirm that it works. Thanks a lot! I’ll post a review on AMO right after this.

All right, thanks for looking into this — whatever the outcome.

I’m using Firefox 41.0 (in Ubuntu 14.04). Steps to reproduce:

1. Go to Firefox privacy settings, set ”Remember history” (allow FF to restart if needed)
2. Install jump to anchor
3. Verify it works (context menu has ”Jump to anchor”)
4. Go to Firefox privacy settings, set ”Never remember history” and allow FF to restart
5. Open context menu

What happens:
”Jump to anchor” is missing from the context menu.

I’m in a UTF-8 environment and a lot of my directories’ names have characters above ASCII in them. For many of those it’d be natural to assign bookmark names that also have characters beyond ASCII. For example, my ”Desktop” directory is localized as ~/Työpöytä, and I’d like to name that bookmark ”työpöytä”.

jani@saegusa:Työpöytä$ s työpöytä
bookmark name is not valid

This fails because bashmarks validates names using the regexp /[^A-Za-z0-9_]/. It’s simple enough to patch to account for the 6 additional characters in my Scandinavian locale, but bashmarks also derives an environment variable name from the bookmark name, and apparently Bash does not support UTF-8 for those:

jani@saegusa:~$ LC_MESSAGES=C export DIR_työpöytä=$HOME/Työpöytä/
bash: export: `DIR_työpöytä=/home/jani/Työpöytä/': not a valid identifier

There may be other obstacles as well, those are just the two I could find at a glance.

Obviously I can work around this by not using UTF-8 in bookmark names, but it needlessly increases the mental effort required to recall the names and also the chances of name collisions.