Closed Bug 956461 Opened 11 years ago Closed 7 years ago

context menuitems have no id in the dom.

Categories

(Add-on SDK Graveyard :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: t1m3f0x, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131205075310 Steps to reproduce: Use DOM Inspector to view the menuitem of a context menu entry created by an add on that uses the sdk. Actual results: menuitem has no id. Expected results: menuitem should have an id, (needed for compatibly with Menu Editor)
Don't you dare mark this WONTFIX, Menu Editor is an essential add on. as things are I have to use Stylish to control my context menu. I HAD TO WRITE @namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul); @-moz-document url-prefix('chrome://') { #menu_newPrivateWindow, .show-only-for-keyboard, #context-openlinkincurrent, #tm-linkWithhistory, #tm-openAllLinks, #tm-openinverselink, #context-openlinkprivate, #context-bookmarklink, #context-sharelink, #context-marklinkMenu, #context-shareimage, #context-sendimage, #context-setDesktopBackground, #context-viewimageinfo, #context-viewimagedesc, #context-sharevideo, #context-back, #context-forward, #context-reload, #tm-autoreload_menu, #context-stop, #tm-content-miscSep, #tm-content-closetab, #tm-duplicateTabContext, #tm-duplicateinWinContext, #tm-detachTabContext, #tm-mergeWindows, #tm-content-freezeTab, #tm-content-protectTab, #tm-content-lockTab, #tm-tabsList, #tm-content-undoCloseSep, #tm-content-undoCloseTab, #tm-content-undoCloseList, #context-sep-stop, #context-bookmarkpage, #context-savepage, #context-sharepage, #context-markpageMenu, #context-sep-viewbgimage, #context-viewbgimage, #contentAreaContextMenu #img2tab, menuseparator[insertbefore="context-undo"], #tm-content-textSep, #context-openTextLink-copy, #context-keywordfield, #context-openTextLink-current, #context-openTextLink-tab, #context-openTextLink-window, #USMContextMenuItem, #USMContextMenuItemSeperator, #context-shareselect, #frame-sep, #frame, #context-viewpartialsource-selection, #context-viewpartialsource-mathml, #context-sep-viewsource, #context-page-translator, #context-viewsource, #context-viewinfo, #context-sep-bidi, #context-bidi-text-direction-toggle, #context-bidi-page-direction-toggle, #abppa-contextmenu, #fxrContextMenuFoxReplace, #nosquint-menu-settings, #tiletabs-contentmenu-separator, #tiletabs-contentsubmenu, #tiletabs-contentmenu-tile, #tiletabs-contentmenu-tilenew, #tiletabs-contentmenu-tiledup, #tiletabs-contentmenu-tilelink, #tiletabs-contentmenu-assign, #tiletabs-contentmenu-untile, #tiletabs-contentmenu-expand, #tiletabs-contentmenu-show, #AddToUpdateScan, #quicknote-contexttab, #quicknote-contexttablink {display: none!important;} } JUST TO USE SCROLL HERE!
I'd happily take a patch here
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
I think this is covered with the context-menu version 2, is this correct Irakli?
Flags: needinfo?(rFobic)
Summary: Menuitems have no id in the dom. → context menuitems have no id in the dom.
No we don't generate id's for menuitems but that should be easy & we'll take patches.
Flags: needinfo?(rFobic)
Whiteboard: [good first bug]
>No we don't generate id's for menuitems but that should be easy & we'll take patches. When it will be fixed ? Any ETA ?
(In reply to infoplus007 from comment #5) > >No we don't generate id's for menuitems but that should be easy & we'll take patches. > > > When it will be fixed ? Any ETA ? It will never be fixed unless someone volunteers to write a patch to do this.
Patch converted from github PR 2044 (https://github.com/mozilla/addon-sdk/pull/2044) with author metadata preserved.
Attaching a patch to add a new small test case to check its behaviour on valid and deprecated iterators.
(In reply to Luca Greco from comment #8) > Created attachment 8704290 [details] [diff] [review] > 0002-Bug-1098617-addon-sdk-array-fromIterator-test-case.patch > > Attaching a patch to add a new small test case to check its behaviour on > valid and deprecated iterators. ouch, wrong tab :-( This patch does not belong to this issue
Attachment #8703653 - Attachment is obsolete: true
Attachment #8704290 - Attachment is obsolete: true
I am constantly getting requests for this, and I don't think it is fair to have add-on developers be blackmailed into submitting the patches ourselves when it is time-consuming setting up the dev. environment, and this would be so trivial to fix for someone who already had the SDK dev. environment working. I already did my part in submitting https://github.com/mozilla/addon-sdk/pull/2044 Would someone with CVS set up please just add a darn id attribute here?? Punishing Firefox users to get back at volunteer add-on devs and failing to add something extremely simple and reasonable to the API (which is not our responsibility) is, imo, a very counter-productive attitude to take. Would someone please just fix this?
Because of the difficulty finding mentors and the expected life span of the SDK, we are removing [good first bug] from remaining SDK bugs.
Whiteboard: [good first bug]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: