Closed
Bug 1407227
Opened 8 years ago
Closed 8 years ago
contextMenu items are not added/updated when context menu is already open
Categories
(WebExtensions :: Untriaged, defect, P5)
WebExtensions
Untriaged
Tracking
(firefox57 wontfix)
RESOLVED
WORKSFORME
| Tracking | Status | |
|---|---|---|
| firefox57 | --- | wontfix |
People
(Reporter: Fallen, Unassigned)
References
Details
STR:
1) Use an async function to update the enabled state of a context menu (or alternatively create/remove the context menu item)
2) Context-click on an element on a page
Result:
* The context menu is opened, the enabled state is not updated
Expected:
* The context menu is opened, initially showing the former enabled state
* As soon as the async message comes in, the enabled state of the context menu item should be updated.
Other info:
I'm doing it this way because the context menus api only allows to detect very specific elements, e.g. links. My use case is a context menu on a submit button, where I want to show a context. The only way I see is to do the detection in a content script, then send the message to the background script.
For my specific case, I can workaround once bug 1215376 or bug 1325814 is fixed, but I think this is a bug not a feature. If the item is disabled, it should reflect that even for open context menus.
Updated•8 years ago
|
Severity: normal → enhancement
status-firefox57:
--- → wontfix
Priority: -- → P5
Whiteboard: [design-decision-needed]
Comment 1•8 years ago
|
||
Hi Philipp, this has been added to the agenda for the WebExtensions APIs triage on March 13, 2018. Would you be able to join us? :)
Here’s a quick overview of what to expect at the triage:
* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details
Relevant Links:
* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1b4r8z964_Est_mbSYUx9jtRt-HTtXgu-EAzM_3yr7ww/edit
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
Comment 3•8 years ago
|
||
Sorry, Philipp -- since this bug is a dupe, we're taking it off the design-decision agenda.
Comment 4•8 years ago
|
||
Philipp, I apologize again! I had misread this bug as the one duped. :/
This bug has been added to the agenda for the April 3 WebExtensions APIs triage. Hope you'll be able to join us!
Agenda: https://docs.google.com/document/d/1H1ZEWf7dmyyu7NZZL90TkbyaUTjbdIK3TUEtO_vff34/edit#
Maybe this can be fixed by using menus.refresh [1]?
[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/menus/refresh
Or maybe you need this bug [1]?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1341804
| Reporter | ||
Comment 7•8 years ago
|
||
Results from the API triage, I will retest this with onBeforeShow from bug 1215376, and if that does what I need then we can likely close this bug WONTFIX.
Flags: needinfo?(philipp)
| Reporter | ||
Comment 8•8 years ago
|
||
I think the current APIs are sufficient and it seems the bug I was originally experiencing is fixed. Thank you for your time!
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(philipp)
Resolution: --- → WORKSFORME
Updated•8 years ago
|
Whiteboard: [design-decision-needed]
Updated•8 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•