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.
modules/main/templates/_textarea.inc.php has two links pointing to URLs under issues.thebuggenie.com without preceding http:// protocol, resulting in non-working links.
$ grep 'href="issues' core/modules/main/templates/_textarea.inc.php
'MarkdownFormatting')); ?>
'MarkdownFormatting')); ?>
- Open a text area, for example to report a new issue
- Have Markdown as Selected syntax
- Have the ”See more formatting tips in MarkdownFormatting” tip appear (I don’t know the exact steps to trigger this)
4. Try to open the MarkdownFormatting link
In Wily, adding the PPA and running `apt update` results in a ”W: Failed to fetch … 404 Not Found”: apparently there are no Wily builds in the PPAs. FWIW, I have been using dailies from the ”vivid” repository and they seem to work fine under Wily.
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.
With more testing I found that the context menu position depends (perhaps solely) on whether my mouse pointer is on the left side or the right side of the horizontal half of the rightmost monitor: if you imagine a vertical line dividing the rightmost monitor’s display area into two equal-sized halves, right-clicking anywhere on the left side of that line brings up the menu on the correct display, whereas right-clicking anywhere on the right side brings it up on the wrong display.
(That is why I first made the mistake of thinking links weren’t affected: the ones I tried first just happened to be on the left side.)
Unfortunately I don’t have a third display to verify that I’m really seeing a different manifestation of the same bug as Nathaniel, of one that depends on the monitor count.