Right click menu in firefox 104 is missing about copy-as-markdown

[yorkxin]

@azzamsa Thanks. I think it's related to the fact that this extension is using synced storage for settings. I tested it on Chrome, but didn't test it on Firefox, as I expect API compatibilities.

Since there is no much settings that are worth syncing in this extension yet, I'll consider switch to local storage.

[lucascosti]

Thanks for the fix, @yorkxin! I've also tried v2.6.2rc1 in Firefox 104.0.1 on macOS 12.5.1, and the context menu entry has persisted through multiple Firefox restarts 🎉

[yorkxin]

@azzamsa @lucascosti I've uploaded version 2.6.3 to Firefox Add-On. You should be able to upgrade to that version in a short time. Please remove the rc1 version before installing store-released version.

Thanks for your help! I'm glad that Copy as Markdown is helping your life :)

[lucascosti]

I seem to be having the same problem on Firefox 104 on macOS 12.5.1.

[yorkxin]

Hi all, I am not able to reproduce the issue on my machine (Firefox 104.0.1 (64-bit), macOS 12.5.1).

Could you go to the following page (Add-on debug UI) and see if there is any error?

about:debugging#/runtime/this-firefox

Thanks!

[azzamsa]

I managed to install fresh Fedora today. the right click menu is exists after fresh Firefox install. But after enabling Firefox sync which in turn install all my previous extension, the right menu is disappeared again. I have tried to disable all extension the restart Firefox, but no luck.

I don't see any error in about:debugging#/runtime/this-firefox. Even in the copy-as-markdown console.

[yorkxin]

So I enabled Firefox sync on my computer. I can reproduce the issue that the context menu is not being displayed, but can also confirm that other features are working fine, such as browser action menu (an md icon on the toolbar), and the sync storage.

The context menu is installed here. There used to have some incompatibilities with chrome.runtime.onInstalled callback, due to the fact that Firefox and Chrome used to support so-called "event page" differently. It's difficult to imagine that this incompatibility also exists when Firefox sync is enabled.

Some past examples:

• Chrome ("industry leader" of MV3 implementation) suggests creating context menu in chrome.runtime.onInstalled callback
  • ... which only makes sense in non-persist background pages
• Firefox (currently MV2, with MV3 in beta) suggests running context menu installation on the top scope
  • ... but at the same time recommending background pages to be implemented as event page (for future MV3 upgrade), and use browser.runtime.onInstalled callback to create menus
  • ... now it seems that Firefox sync breaks this assumption that browser.runtime.onInstalled will be executed properly
• Safari developers is facing the same problem too: https://developer.apple.com/forums/thread/667056

I'll look into this issue and find a viable solution.

[yorkxin]

Update: it turns out whether Firefox Sync is enabled or not is irrelative. When Firefox restarts, the context menu disappears.

[yorkxin]

Upstream bugs:

• 1567467 - Persist contextMenus.create across restarts
• 1558336 - Allowing extension to run in PB via doorhanger closes post-install page and breaks extension

[azzamsa]

Upstream bugs:

* [1567467 - Persist contextMenus.create across restarts](https://bugzilla.mozilla.org/show_bug.cgi?id=1567467)

* [1558336 - Allowing extension to run in PB via doorhanger closes post-install page and breaks extension](https://bugzilla.mozilla.org/show_bug.cgi?id=1558336)

Wow. 3 years without a fix.

But, I have leechblock and uBlock extension. Both use the right click context menu. I think we can mimic their implementation.

[yorkxin]

@azzamsa thanks for actively following this thread.

I checked uBlock's source code. It looks like uBlock implemented its own context menu lifecycle manager. Indeed uBlock's context menu depends on the pages's URL and the actual DOM element. It doesn't seem to use runtime.onInstalled() to create menus; instead they are created on tab load(?).

In the case of Copy as Markdown, it's pretty much using the built-in API to decide which item to appear or not. Given that Firefox Manifest V3 (MV3) is about to be released in a short future (Early 2023?), I prefer not to introduce too much inconsistencies with Chrome.

That said I tried to introduce some workarounds in the Firefox version. I can share the XPI file so that you can test if you wish.

[yorkxin]

For reference, leechblock also implemented its own context menu lifecycle manager. Menus are "refreshed" (cleaned and re-created) every time the preferences are loaded https://github.com/proginosko/LeechBlockNG/blob/v1.5.1/background.js#L84

[azzamsa]

It the "workaround" took time to implement. I don't rush to have it soon. I can use the menu bar for time being. Even though I haev to reach more far distance each day. Because I am using this extension a lot :)

Take your time.
Thank you so much for this extension. It helps me a lot in my day to day journalling.

[yorkxin]

@azzamsa Hi, could you try this pre-build version to see if the problem still exists?

https://github.com/yorkxin/copy-as-markdown/releases/tag/v2.6.2rc1

It's weekend so please take your time to test it. I'll be away from keyboard from now until Monday UTC+9 so please don't rush.

Again, thank you so much for helping me find the bug!

[azzamsa]

Worked like a charm.
I will report if there any regression.

[yorkxin]

@azzamsa @lucascosti thank you both for confirming it's fixed. In that case i'll release the new version to Firefox Add-On website.