1351942 - list-style-image applied to context-openlinkintab appears black if not styled with !important

Status: RESOLVED WONTFIX

(Firefox :: Extension Compatibility, defect, P5)

Description

[hockeymikey]

Attachment: firefox_2017-03-29_21-57-48.png

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0.1 Waterfox/52.0.1
Build ID: 20170318221232

Steps to reproduce:

Apply list-style-image to #context-openlinkintab.  It has only applied to the "open link in new tab" menu item.  No other items seem to be effected.


Actual results:

The icon is a blacked out version of itself as seen in the picture.


Expected results:

A full colored icon like the others.  I tested this in Dev 54.0a2 and Waterfox 52.0.1.  Appeared sometime around 50.0

Comment 1

[Loic]

Could you tell which exact line your added in userChrome.css to reproduce the issue?

Comment 2

[hockeymikey]

Something like:

#context-openlinkintab {
list-style-image: url("chrome://menuiconsplus/skin/Silk.png");
}

You can switch the image source with identical results.  Tried across many profiles with all addons disable with no change.

Comment 3

[Loic]

I fail to add an image for each entry of the context menu, is there something I missing?

@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

#context-openlinkintab {
list-style-image: url("file:///C:/Users/Pictures/icon.ico");
}

Comment 4

[hockeymikey]

I can get the icon working just fine using userChrome.css with the following:

#context-openlinkintab {
	list-style-image: url("http://www.famfamfam.com/lab/icons/silk/icons/browser_internetexplorer.png")!important; 
	-moz-binding: url(chrome://global/content/bindings/menu.xml#menuitem-iconic) !important;
}	

The issue is when I add it any other way aka addons.  Using Stylish, MenuIcons Plus or Menu Wizard all produce a black icon when the css is applied through them.

Why would their application of the css be causing issues and only for the "open link in new tab" context menu item?  Other items are fine.

Comment 5

[Loic]

Ok, I'm able to reproduce the issue with add-on "Menu Icons Plus" when selecting the icon set "Fugue":
https://addons.mozilla.org/fr/firefox/addon/menu-icons-plus/

Comment 6

[Loic]

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f19157ac2e4800139a5b82896a7fa0b0846469d6&tochange=ab12ade757276792c6e077e27563ce3cc5a145c0

Jonathan Kingston — Bug 1278177 - Change container icons to a single sprite sheet and to be rendered by CSS r=jaws

Jonathan, could you check this issue, it affects styling context entries with icons, when using popular add-ons like Stylish or Menu Icons Plus.

Comment 7

[Jonathan Kingston [:jkt] he/him]

I'm not exactly sure why that would be firing, it looks to me like the following line in CSS is the issue:

.menuitem-iconic[data-usercontextid] > .menu-iconic-left > .menu-iconic-icon,

In my nightly I don't have ".menuitem-iconic" on this menu item, so unless the addon is adding that back in then it shouldn't be triggering.

I will test the addon however I don't think this is something we should be fixing if that is what they are doing.

Comment 8

[Jonathan Kingston [:jkt] he/him]

Yup so that addon adds the className to the menu item which wasn't expected in the code.
The fix might be something like:

.menuitem-iconic[data-usercontextid]::not([data-usercontextid=0])

However I still don't think we should be fixing our code for addons especially as this isn't impacting userland CSS.

Happy to hear if this is not the case though.

I have attached a P5 and good-first-bug until otherwise.

Thanks

Comment 9

[Loic]

Should we triage this issue in Extension Compatibility to reflect the fact add-on devs should fix the code of their add-on?

Comment 10

[Jonathan Kingston [:jkt] he/him]

Loic, I'm not sure on what we do for issues like this. Like we could change the code to be super specific to fix the issue I guess like making it all work off explicit classes for menu items related to containers.

Another fix in the addon would be to change the filter in the extension I think.

Comment 11

[Marcia Knous [:marcia]]

Adjusting status flags based on the fact that this is now fix optional for all branches - no need to track.

Comment 12

[Jorge Villalobos [:jorgev] (he/him)]

Mass-closing old Extension Compatibility bugs that relate to legacy add-ons or NPAPI plug-ins. If you think this bug is still valid, please reopen or comment.

Sorry for the bug spam, and happy Friday!