Closed Bug 1280347 Opened 9 years ago Closed 7 years ago

Add ability to provide custom HTML elements working as alias of existing Firefox UI items, especially tabs

Categories

(WebExtensions :: General, enhancement, P2)

Product:
WebExtensions
Component:
General
Type:
enhancement

Tracking

(firefox64 fixed)

Status:
VERIFIED FIXED
Milestone:
mozilla64
Iteration:
64.2 - Sep 28
Tracking Flags:
Tracking Status
firefox64 --- fixed

People

(Reporter: yuki, Assigned: robwu)

References

(Blocks 2 open bugs)

Details

(Keywords: dev-doc-complete, Whiteboard: [design-decision-deferred] triaged)

Attachments

(5 files)

Bug 1280347 - Support changing context type to tab and bookmark
46 bytes, text/x-phabricator-request
mixedpuppy
: review+
Details | Review
Bug 1280347 - Add tests for overriding context type of extension menus
46 bytes, text/x-phabricator-request
mixedpuppy
: review+
Details | Review
Bug 1280347 - Normalize local ExtensionErrors
46 bytes, text/x-phabricator-request
mixedpuppy
: review+
Details | Review
Bug 1280347 - Require a permission for the API
46 bytes, text/x-phabricator-request
mixedpuppy
: review+
Details | Review
Bug 1280347 - Remove <all_urls> requirement for the "tab" context
46 bytes, text/x-phabricator-request
mixedpuppy
: review+
Details | Review
This is an expanded idea from https://bugzilla.mozilla.org/show_bug.cgi?id=1270786#c1 Firefox should treat HTML elements with something special attribute as an alias of existing Firefox UI element. For example, if the name of the attribute is "data-moz-ui-alias", an addon can provide a custom HTML page like as: ~~~ <!DOCTYPE html> <ul> <li><a href="#" data-moz-ui-alias="xxxxxx(id of the first tab)">Tab1</a></li> <li><a href="#" data-moz-ui-alias="yyyyyy(id of the second tab)">Tab2</a></li> </ul> ~~~ The HTML page will be loaded inside an embedded iframe dynamically generated by the addon, or the sidebar. Then the user can access full features of Firefox tabs via the custom UI elements - left click to select, middle click to close, or right-click to open the context menu. (Of course, if the event is canceled by the addon, those default behaviors won't triggered and the addon can override them.) This can introduce UI spoofing problem, so this feature should be allowed only with special permission like "uiAlias". Then the user can know what is the addon actually does, before he install the addon. The basic motivation of this proposal is: porting Tree Style Tab ( https://addons.mozilla.org/firefox/addon/tree-style-tab/ ), Tab Center (in Test Pilot), and something addons provides custom appearance for tabs, to WebExtensions. Because those addon actually just change the appearance of existing UI element of Firefox itself, they can work with other existing tab-related addons (like Clolourful Tabs, Auto Unload Tab, and others), even if they don't know TST or Tab Center. They other addons thought just as: I'm working with regular Firefox tabs. Thus TST and Tab Center can provide compatibility to other tab addons. On the other hand, if such a thing is not allowed and each TST like addon must provide full features of tabs to provide custom tab bar in the sidebar, then the custom tab bar won't work with other existing tab related addons designed to working with Firefox's tabs. And the author of the custom tab bar addon will get much more requests from users, like: "please add the feature like Colourful Tabs", "please include Auto Unload Tab feature into your addon", and so on, and the addon will become bloated. Instead, Firefox should lead each addon author to design his addon small, simple, and purpose-oriented. This proposal is just an idea to do that, I think there is something more better proposal.
Summary: Add ability to provide custom HTML elements working an alias of existing Firefox UI items, especially tabs → Add ability to provide custom HTML elements working as alias of existing Firefox UI items, especially tabs
On this idea, a tab-related addon always registers its listener like `chrome.tabs.onUserAction(function(...) { ... })` to provide its custom feature like `reload the tab on double click`. And, when the user clicks on the alias element (like `<span data-moz-ui-alias="...">label</span>`, a JSON message like `{"target":"tab-x","button":0,"modifiers":...}` will be delivered to listeners. On another situation, an addon like TST registers its listener like `chrome.tabs.onColorChange(function(...) { ... })`. When another addon like Colourful Tabs applies custom appearance to the tab via an API like `chrome.tabs.setColor(...)`, then it is notified to both Firefox itself and the listener registered by addons. If TST-like addon is designed to support known messages, it will work with Colourful Tabs like addon via WebExtensions's standard APIs implicitly, without any special message. (On the other hand, even if both TST and Colourful Tabs provide their own custom messages, they cannot collaborate with each other until they are updated for each other.)
> On another situation, an addon like TST registers its listener like `chrome.tabs.onColorChange(function(...) { ... })`. When another addon like Colourful Tabs applies custom appearance to the tab via an API like `chrome.tabs.setColor(...)`, then it is notified to both Firefox itself and the listener registered by addons. If TST-like addon is designed to support known messages, it will work with Colourful Tabs like addon via WebExtensions's standard APIs implicitly, without any special message. (On the other hand, even if both TST and Colourful Tabs provide their own custom messages, they cannot collaborate with each other until they are updated for each other.) Sorry I missed the point. It can be done without the special attribute proposed at this bug... I had to figure out more better example.
> On another situation, an addon like TST registers its listener like `chrome.tabs.onColorChange(function(...) { ... })`. When another addon like Colourful Tabs applies custom appearance to the tab via an API like `chrome.tabs.setColor(...)`, then it is notified to both Firefox itself and the listener registered by addons. If TST-like addon is designed to support known messages, it will work with Colourful Tabs like addon via WebExtensions's standard APIs implicitly, without any special message. (On the other hand, even if both TST and Colourful Tabs provide their own custom messages, they cannot collaborate with each other until they are updated for each other.) Sorry I missed the point. It can be done without the special attribute proposed at this bug... I had to figure out more better example.
Whiteboard: [design-decision-needed]
Whiteboard: [design-decision-needed] → [design-decision-needed] triaged
Blocks: webext-more-ui
Thanks. I need this also for Vertical Tabs Reloaded.
Crazy idea but if context menu things were to change would role="tab" be something that could be used here: https://www.w3.org/TR/wai-aria/roles#tab My use case is basically to transform the context menu of <a href="">sss</a> to be more meaningful, everything else I'm not really bothered about. Instead of "Open Link in New Tab" it would have the usual Tab context menu, the developer could potentially manage those events? The alternative might be clear the context menu completely and let the developer completely reimplement it.
Hi all, this has been added to the agenda for the May 23 WebExtension APIs triage meeting. If you are able to attend, please let me know. We would love to have you join us. Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Details_.26_How_to_Join Agenda: https://docs.google.com/document/d/1-j08Zo4sbwAuRZndNNtdIRlDM8TblddDA-PAeRgYMWU/edit#
OK, I'll join to the IRC channel while the meeting. (In reply to Jonathan Kingston [:jkt] from comment #5) > Crazy idea but if context menu things were to change would role="tab" be > something that could be used here: https://www.w3.org/TR/wai-aria/roles#tab Oh, I forgot the "role". However I think a new role for this purpose should be introduced like "moz-tab", because the generic "tab" role will appear for different purpose, like: <ul> <li role="tab"><a href="#">Group 1</a> <ul> <li role="moz-tab"><a href="#">Tab 1</a></li> <li role="moz-tab"><a href="#">Tab 2</a></li> </ul> </li> <li role="tab"><a href="#">Group 2</a> <ul> <li role="moz-tab"><a href="#">Tab 3</a></li> </ul> </li> </ul>
Flags: needinfo?(amckay)
Jonathan, could you let us know where to find the context menu bug when it is filed?
Flags: needinfo?(jkt)
Bug 1367160 is the alternative discussed here on clearing the context menu.
Flags: needinfo?(jkt)
We made up a new status "deferred" to recognise the fact that some day, something might happen here to allow this to happen. It's not going to happen by Firefox 57 or some time scale around that due to all the other things that need to be done. Doing something like this was a goal of some of the people working on this project, so it might make sense to revisit at some point in the future, perhaps once 57 is out the door.
Flags: needinfo?(amckay)
Whiteboard: [design-decision-needed] triaged → [design-decision-deferred] triaged
Priority: -- → P5
> It's not going to happen by Firefox 57 or some time scale around that due to all the other things that need to be done. What about postponing WebExtension-only to >57?
The release of Firefox 57 with WebExtensions as the only add-on API has been planned for years and would be near impossible to delay at this point. The desire to get more functionality into the product prior to the 57 release is completely understandable, but as is often the case, the bucket of desires is simply larger than the bucket of resources. We are working hard to prioritize the WebExtensions roadmap in order to bring additional and enhanced APIs to future releases as quickly as we can.
Another bug 1396031 seems including effective API proposal for things I mostly worried about.
Product: Toolkit → WebExtensions
status-firefox50: affected → ---
(In reply to YUKI "Piro" Hiroshi from comment #0) > ~~~ > <!DOCTYPE html> > <ul> > <li><a href="#" data-moz-ui-alias="xxxxxx(id of the first > tab)">Tab1</a></li> > <li><a href="#" data-moz-ui-alias="yyyyyy(id of the second > tab)">Tab2</a></li> > </ul> > ~~~ I would personally prefer if Firefox provided `<firefox-*>` elements as built‑in Custom Elements to extensions which request them (using `browser_style` or something). Maybe even use that to improve the current class‑based panel components¹. ¹ https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/user_interface/Browser_styles#Firefox_Panel_Components
Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958
Component: Untriaged → General
See Also: → 1396031
I'm not literally going to support HTML attributes, but I do intend on adding a new API that can be called from the "contextmenu" DOM event to set a custom context (bookmark or tab, initially). The main goal of this new API is to allow extensions to hide all default menu items in favor of their own (bug 1367160), and to support automatic inclusion of tab/bookmark-specific menu items from other extensions. Including Firefox's default menu items is out of scope, because the default menu labels don't always make sense. For example, the "Close Tabs to the Right" menu item makes no sense in a vertical tabs-type extension. If there are menu items that cannot be replicated with the extension APIs, then we can decide on a case-by-case basis for how this should be supported.
Assignee: nobody → rob
Blocks: 1466876
Severity: normal → enhancement
Status: NEW → ASSIGNED
Depends on: 1367160
Priority: P5 → P2
(In reply to Rob Wu [:robwu] from comment #17) > Including Firefox's default menu items is out of scope, because the default > menu labels don't always make sense. For example, the "Close Tabs to the > Right" menu item makes no sense in a vertical tabs-type extension. > If there are menu items that cannot be replicated with the extension APIs, > then we can decide on a case-by-case basis for how this should be supported. Does this mean that addons like "Tree Style Tab" or sometihng other "custom tab manager" addon need to provide Firefox compatible context menu menu items by self? Then those items will appear under the parent menu item to group all menu items added by the addon like following: + [Share SNS] (provided by one of other addon loaded before my addon, automatically imported) | + Share by Twitter | ... + Copy tab title (provided by one of other addon loaded before my addon, automatically imported) + [Tree Style Tab] (provided by my addon, automatically grouped by Firefox) | + Reload Tab (imitates Firefox's one) | + Mute Tab (imitates Firefox's one) | + ------ | + Pin Tab (imitates Firefox's one) | + Duplicate Tab (imitates Firefox's one) | + Reopen in Container (imitates Firefox's one) | | + Personal (built from browser.contextualIdentities) | | + Work (built from browser.contextualIdentities) | | + Banking (built from browser.contextualIdentities) | | + Shopping (built from browser.contextualIdentities) | + Move to New Window (imitates Firefox's one) | ... | + Close Tab (imitates Firefox's one) | + ------ | + Reload this Tree | + Close this Tree | ... + Unload Tab (provided by one of other addon loaded after my addon, automatically imported) Or, what the sketch you imagined is like following?: + Reload Tab (provided by my addon, imitates Firefox's one) + Mute Tab (provided by my addon, imitates Firefox's one) + ------ + Pin Tab (provided by my addon, imitates Firefox's one) + Duplicate Tab (provided by my addon, imitates Firefox's one) + Reopen in Container (provided by my addon, imitates Firefox's one) | + Personal (provided by my addon, built from browser.contextualIdentities) | + Work (provided by my addon, built from browser.contextualIdentities) | + Banking (provided by my addon, built from browser.contextualIdentities) | + Shopping (provided by my addon, built from browser.contextualIdentities) + Move to New Window (provided by my addon, imitates Firefox's one) ... + Close Tab (provided by my addon, imitates Firefox's one) + [Tree commands] (provided by my addon, grouped by my addon) | + Reload this Tree | + Close this Tree | ... + [Share SNS] (provided by one of other addons, automatically imported) | + Share by Twitter | ... + Copy tab title (provided by one of other addons, automatically imported) + Unload Tab (provided by one of other addons, automatically imported) The first sketch looks too bad for user experience. Imitated menu items should be placed top level of the menu. The second sketch looks better, and my addon Tree Style Tab currently does things like this. However, it looks hard to provide imitated "Reopen in Container" menu items via browser.menus.create(), because they need to have colored SVG icons and browser.contexualIdentities provides only uncolored SVG images. In other words, to imitate these menu items I need to generate colored SVG dynamically - it looks too hard. Thus, I hope that default context menu items provided by Firefox itself should be imported to the menu *optionally*. "Close Tabs to the *Right*" is actually odd for vertical tab managed addons, but the sidebar area still can provide custom horizontal tab manager. For such addons, simply imported default context menu items will be useful enough.
(In reply to YUKI "Piro" Hiroshi from comment #18) > (In reply to Rob Wu [:robwu] from comment #17) > > Including Firefox's default menu items is out of scope, because the default > > menu labels don't always make sense. For example, the "Close Tabs to the > > Right" menu item makes no sense in a vertical tabs-type extension. > > If there are menu items that cannot be replicated with the extension APIs, > > then we can decide on a case-by-case basis for how this should be supported. > > Does this mean that addons like "Tree Style Tab" or sometihng other "custom > tab manager" addon need to provide Firefox compatible context menu menu > items by self? Itself. The tab manager extension itself will have full control over all menu items in menu items in their content (e.g. sidebar). There may be one additional menu item that explains to the user how they can open the default menu. The current one-extension-menu-item-per-menu limit will not be enforced for an extension's own menu on their own document. > Or, what the sketch you imagined is like following?: > > + Reload Tab (provided by my addon, imitates Firefox's one) > + Mute Tab (provided by my addon, imitates Firefox's one) > + ------ > + Pin Tab (provided by my addon, imitates Firefox's one) > + Duplicate Tab (provided by my addon, imitates Firefox's one) > + Reopen in Container (provided by my addon, imitates Firefox's one) > | + Personal (provided by my addon, built from browser.contextualIdentities) > | + Work (provided by my addon, built from browser.contextualIdentities) > | + Banking (provided by my addon, built from browser.contextualIdentities) > | + Shopping (provided by my addon, built from browser.contextualIdentities) > + Move to New Window (provided by my addon, imitates Firefox's one) > ... > + Close Tab (provided by my addon, imitates Firefox's one) > + [Tree commands] (provided by my addon, grouped by my addon) > | + Reload this Tree > | + Close this Tree > | ... > + [Share SNS] (provided by one of other addons, automatically imported) > | + Share by Twitter > | ... > + Copy tab title (provided by one of other addons, automatically imported) > + Unload Tab (provided by one of other addons, automatically imported) Yes, something like that. > The second sketch looks better, and my addon Tree Style Tab currently does > things like this. However, it looks hard to provide imitated "Reopen in > Container" menu items via browser.menus.create(), because they need to have > colored SVG icons and browser.contexualIdentities provides only uncolored > SVG images. In other words, to imitate these menu items I need to generate > colored SVG dynamically - it looks too hard. Quite doable actually: https://github.com/Rob--W/bookmark-container-tab/commit/afd4aa5165d91b69841df2899ff615795417a0ad > Thus, I hope that default context menu items provided by Firefox itself > should be imported to the menu *optionally*. "Close Tabs to the *Right*" is > actually odd for vertical tab managed addons, but the sidebar area still can > provide custom horizontal tab manager. For such addons, simply imported > default context menu items will be useful enough. The current proposal is meant to offer 100% control over the menus, with automatic inclusion of menu items from other extensions. Built-in menu items are currently out of scope, because that is not something that cannot be replicated with extension APIs.
(In reply to Rob Wu [:robwu] from comment #19) > (In reply to YUKI "Piro" Hiroshi from comment #18) > > The second sketch looks better, and my addon Tree Style Tab currently does > > things like this. However, it looks hard to provide imitated "Reopen in > > Container" menu items via browser.menus.create(), because they need to have > > colored SVG icons and browser.contexualIdentities provides only uncolored > > SVG images. In other words, to imitate these menu items I need to generate > > colored SVG dynamically - it looks too hard. > > Quite doable actually: > https://github.com/Rob--W/bookmark-container-tab/commit/ > afd4aa5165d91b69841df2899ff615795417a0ad Or, you can do what I did and use the built‑in icons available from `iconUrl`¹ and set `fill`² to `colorCode`¹ using `‑moz‑context‑properties`², like what I did in my Application Menu³ extension. ¹ https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/contextualIdentities/ContextualIdentity ² https://developer.mozilla.org/docs/Web/CSS/-moz-context-properties ³ https://github.com/ExE-Boss/app-menu/commit/a515c9ae6eb2e1057a2e6eb8ac82ad1d746a93ec#diff-77e13090b1fc910b9afc5df8efb92cc1
(In reply to ExE Boss from comment #20) > Or, you can do what I did and use the built‑in icons available from > `iconUrl`¹ and set `fill`² to `colorCode`¹ using `‑moz‑context‑properties`², > like what I did in my Application Menu³ extension. Thank you for the idea! But "‑moz‑context‑properties" requires "svg.context-properties.content.enabled"="true" (it is "false" by default), so it looks not suitable for released addon for consumers. Anyway, my largest concern was about impossibility to place imitated menu items on the top level. Except required hard work to follow up changes of context menu commands day by day (and localization for each language - Firefox supports 99 languages!) , there are less worryings. Imitating of the "Send Tab to Device" menu (and its subcommands) requires new WebExtensions to access data of Firefox Sync. It maybe depends on the bug 1308059 (and more).
Iteration: --- → 64.2 (Sep 28)
This allows extensions to include tab/bookmark menu items from other extensions. Built-in menu items from the browser are *not* added. Depends on D6623
Normalize errors thrown by extension API implementations in content processes to ensure that extension code can read the error message if the error is an instance of ExtensionUtils.ExtensionError. This code path is triggered in browser_ext_menus_replace.js and browser_ext_menus_replace_menu_permissions.js. Depends on D6625
Note: the current implementation discards the full original context when the tab/bookmark context is spoofed. I would preferably have offered a key to match on the extension document URL (e.g. via documentUrlPatterns), but unfortunately that field is already used to match the selected document in the "tab" context. I will allow extensions to match the sidebar only via viewTypes, from bug 1416839. I will update one of the patches to include the viewType (e.g. sidebar/tab) when either bug lands.
See Also: → 1416839
Comment on attachment 9011397 [details] Bug 1280347 - Normalize local ExtensionErrors Shane Caraveo (:mixedpuppy) has approved the revision.
Attachment #9011397 - Flags: review+
Attachment #9011395 - Attachment description: Bug 1280347 - Support spoofing tab and bookmark menu contexts → Bug 1280347 - Support changing context type to tab and bookmark
Attachment #9011396 - Attachment description: Bug 1280347 - Add tests for extension menu context spoofing → Bug 1280347 - Add tests for overriding context type of extension menus
The new permission is added to make it easier to audit the usage of the API. It is an optional permission, in case we ever decide to introduce a permission warning for it.
The current API requires the following permissions to replace the menu in your extension: - "menus" = no warning - "menus.overrideContext" = no warning (maybe? The patch is subject to review) Additionally, to include context menus (from other extensions, for context "tab"), the following permissions are required: - "tabs" = "Access browser tabs" warning - "<all_urls>" = "Access your data for all websites" warning The rationale for these permissions is explained here: https://phabricator.services.mozilla.com/D6624#inline-26015 The main risk is that an extension with minimal permissions is able to access the content of any tab when the user clicks on the menu item (because any tabId can be chosen, and bug 1446956 allows extensions access to the "clicked" tab). Ideally the <all_urls> permission should not be needed. I think that a reasonable balance between potential access and permission warning is the following modification: - Don't require <all_urls> - Allow activeTab for other extension menu items. - Don't grant activeTab to the extension where the menu is triggered. This means that in order to access the content of any tab without any host permissions, the following user interaction is needed: - User must install two extensions: - Extension A: * Permission warnings: "Access browser tabs" * Uses this new API to override the menu. - Extension B: * Permission warnings: None * Adds a menu item to menu (from extension A). - User must open a context menu in the extension page (sidebar or tab) of extension A. (or extension popup, but that requires another click so it is even less likely) - User must click on the context menu item from extension B. The number of required user interactions reduces the likelihood that a malicious extension developer would unknowingly get access to any website data. Perhaps we can add a permission warning to the new "menus.overrideContext" permission to make the user even more aware that the extension is capable of spoofing/overriding menus in their own extension page.
I would either go with tabs + menus.overrideContext or tabs + all_urls, but not all three. I think this is a good point at which to get a 3rd opinion from mconca.
Flags: needinfo?(mconca)
Comment on attachment 9011395 [details] Bug 1280347 - Support changing context type to tab and bookmark Shane Caraveo (:mixedpuppy) has approved the revision.
Attachment #9011395 - Flags: review+
Comment on attachment 9011396 [details] Bug 1280347 - Add tests for overriding context type of extension menus Shane Caraveo (:mixedpuppy) has approved the revision.
Attachment #9011396 - Flags: review+
Comment on attachment 9011771 [details] Bug 1280347 - Require a permission for the API Shane Caraveo (:mixedpuppy) has approved the revision.
Attachment #9011771 - Flags: review+
(In reply to Shane Caraveo (:mixedpuppy) from comment #29) > I would either go with tabs + menus.overrideContext or tabs + all_urls, but > not all three. I think this is a good point at which to get a 3rd opinion > from mconca. At this point we have tabs + <all_urls>. I would prefer to avoid <all_urls> if possible. Tab managers such as Tree Style Tabs have fared well without any host permissions so far, and requiring them to demand access to "all websites" just for the convenience of automatically including other extension menus seems to be a bit too unreasonable. After writing out the reasoning in comment 28 for "menus.overrideContext" + "tabs", I think that I should go ahead and drop <all_urls> in favor of the approach from comment 28 . An open question is still: Do we want a permission warning for this new "menus.overrideContext" permission?
I agree that this API should require "tabs" + "menus.overrideContext" and not require <all_urls>. We can proceed without a permission warning for the new permission. r+
Flags: needinfo?(mconca)
Comment on attachment 9011923 [details] Bug 1280347 - Remove <all_urls> requirement for the "tab" context Shane Caraveo (:mixedpuppy) has approved the revision.
Attachment #9011923 - Flags: review+
Pushed by rob@robwu.nl: https://hg.mozilla.org/integration/autoland/rev/c642d1ca80ea Support changing context type to tab and bookmark r=mixedpuppy https://hg.mozilla.org/integration/autoland/rev/a8662c5976db Add tests for overriding context type of extension menus r=mixedpuppy https://hg.mozilla.org/integration/autoland/rev/c466b0ee17a1 Normalize local ExtensionErrors r=mixedpuppy https://hg.mozilla.org/integration/autoland/rev/4320e29b5a3a Require a permission for the API r=mixedpuppy https://hg.mozilla.org/integration/autoland/rev/9212b6a6155a Remove <all_urls> requirement for the "tab" context r=mixedpuppy
Depends on: 1494957
Flags: qe-verify-
I really tried this new feature and I successfully get expected result. Thanks a lot for the big effort! I've written a blog article and I hope it helps addon developers until official API document is updated. https://piro.sakura.ne.jp/latest/blosxom/mozilla/xul/2018-10-14_override-context-on-fx64.htm#topic2018-10-14_override-context-on-fx64
Status: RESOLVED → VERIFIED
See Also: → 1498896
Depends on: 1498896
Note to docs team: I added a note to the Fx64 rel notes covering this: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/64#Changes_for_add-on_developers But I'm really not sure I got this right. When you come to properly document this, check it and update as needed. Thanks!
@Chris The description of this feature is incorrect. Please take a look at the "Even More Context Menu Improvements" section at https://blog.mozilla.org/addons/2018/11/08/extensions-in-firefox-64/ and update the MDN article if you can.
The section in the blog post has an anchor, in case you want to directly link to it: https://blog.mozilla.org/addons/2018/11/08/extensions-in-firefox-64/#cm
(In reply to Rob Wu [:robwu] from comment #41) > @Chris > The description of this feature is incorrect. > Please take a look at the "Even More Context Menu Improvements" section at > https://blog.mozilla.org/addons/2018/11/08/extensions-in-firefox-64/ and > update the MDN article if you can. OK, thanks for the feedback. I've had a go at updating the release note. We'll aim to have the feature documented properly before the 64 release.
This has been shipped but still not documented on MDN. Any plan to work on this?
(In reply to ariasuni from comment #44) > This has been shipped but still not documented on MDN. Any plan to work on > this? It's tagged dev-doc-needed which means it's in the queue for our documentation editors. :) Irene, do you have an ETA for when this documentation will be updated?
Flags: needinfo?(ismith)

(In reply to Caitlin Neiman [:caitmuenster] from comment #45)

(In reply to ariasuni from comment #44)

This has been shipped but still not documented on MDN. Any plan to work on
this?

It's tagged dev-doc-needed which means it's in the queue for our
documentation editors. :)

Irene, do you have an ETA for when this documentation will be updated?

Yes, this is one of my current tasks. It will be documented this week.

Flags: needinfo?(ismith)
Keywords: dev-doc-needed → dev-doc-complete

This is covered in the menu changes I made for menus.overrideContext

That article is missing the sidebar, a browser-compat-table entry (should mention Firefox 64 compat) and quite short. Could you expand the article? There is more existing information/text that you can use, see:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/64#Changes_for_add-on_developers
https://blog.mozilla.org/addons/2018/11/08/extensions-in-firefox-64/#cm

Flags: needinfo?(ismith)

Sorry, I wrote this reply but didn't hit "Save Changes"...

(In reply to Rob Wu [:robwu] from comment #48)

That article is missing the sidebar, a browser-compat-table entry (should mention Firefox 64 compat) and quite short. Could you expand the article? There is more existing information/text that you can use, see:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/64#Changes_for_add-on_developers
https://blog.mozilla.org/addons/2018/11/08/extensions-in-firefox-64/#cm

Thank you, I will add this update to my list. I have already fixed the sidebar.
Irene

Flags: needinfo?(ismith)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: