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)
Add-on SDK Graveyard
General
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: t1m3f0x, Unassigned)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review |
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!
Comment 2•11 years ago
|
||
I'd happily take a patch here
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Comment 3•10 years ago
|
||
I think this is covered with the context-menu version 2, is this correct Irakli?
Blocks: sdk/context-menu
Flags: needinfo?(rFobic)
Updated•10 years ago
|
Summary: Menuitems have no id in the dom. → context menuitems have no id in the dom.
Comment 4•10 years ago
|
||
No we don't generate id's for menuitems but that should be easy & we'll take patches.
Flags: needinfo?(rFobic)
Updated•10 years ago
|
Whiteboard: [good first bug]
Comment 5•9 years ago
|
||
>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 ?
Comment 6•9 years ago
|
||
(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.
Comment 7•9 years ago
|
||
Patch converted from github PR 2044 (https://github.com/mozilla/addon-sdk/pull/2044) with author metadata preserved.
Comment 8•9 years ago
|
||
Attaching a patch to add a new small test case to check its behaviour on valid and deprecated iterators.
Comment 9•9 years ago
|
||
(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
Comment 10•9 years ago
|
||
Attachment #8703653 -
Attachment is obsolete: true
Attachment #8704290 -
Attachment is obsolete: true
Comment 11•9 years ago
|
||
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?
Comment 12•8 years ago
|
||
Because of the difficulty finding mentors and the expected life span of the SDK, we are removing [good first bug] from remaining SDK bugs.
Updated•8 years ago
|
Whiteboard: [good first bug]
Comment 13•7 years ago
|
||
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.
Description
•