1683865 - [meta] replace <xul:image> usage in Thunderbird

Status: RESOLVED FIXED

(Thunderbird :: General, task)

Description

[Magnus Melin [:mkmelin]]

This bug tracks removal of xul:image usage.

mail: https://searchfox.org/comm-central/search?q=%3Cimage&path=mail&case=false&regexp=false ~140 cases

calendar: https://searchfox.org/comm-central/search?q=%3Cimage&path=calendar&case=false&regexp=false 29 hits

See bug 1584641 for removal of -moz-image-region, and bug 1403231 comment 2, which is quite intertwined with this bug, and should also be covered here.

Comment 1

[Magnus Melin [:mkmelin]]

It seems best not to invent a new element for images since there is already img.

There's a mix of easy and harder cases to take care of here. I think we could do the fairly easy ones first, than think about the hard ones later.

The easy ones is where the image has the same url all the time for all themes across the platforms. Seems this can generally be converted to <html:img src=... />. Cases like .person-icon, #userIcon, #attachmentIcon, the stuff in emailWizard.xhtml.

Note that <html:img> can't use content: url();

I didn't check the -moz-image-region parts, but they should each be attackable.

Comment 2

[Magnus Melin [:mkmelin]]

Attachment: Bug 1683865 - convert <xul:image> usage to <html:img> in image_editContactPanel.inc.xhtml. r=aleca

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/11efbeb3d116
convert <xul:image> usage to <html:img> in image_editContactPanel.inc.xhtml. r=aleca

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in event edit dialog. r=darktrojan

Comment 5

[alta88]

Has any consideration been given as to whether css background-image on an html element (could be img, or div etc.) is more advantageous than using the src attribute and thus needing <html:img> specifically?

Comment 6

[Magnus Melin [:mkmelin]]

Yes, see bug 1584641, and we will likely have to do that at least for certain situations (different image per theme at least). But, in general <img> is the semantically correct solution so other than a slightly higher cost for the one-time move over, it seems preferable.

Comment 7

[Richard Marti (:Paenglab)]

You could also use in CSS the background-image and padding with the half values of the width and height. Like

#link-image-top {
 background-image: url(chrome://calendar/skin/shared/link-image-top.svg);
 padding: 3.5px 4.5px;
}

Comment 8

[Henry Wilkes (they/them) [:henry-x]]

(In reply to alta88 from comment #5)

Has any consideration been given as to whether css background-image on an html element (could be img, or div etc.) is more advantageous than using the src attribute and thus needing <html:img> specifically?

The main difference of the background-image approach is that the source can remain specified in css. This can also be done with css content, but I think for background-image you would have to specify some dimensions in order for the element to not collapse. I would prefer content on a div, since background-image should probably be a background to something else.

Saying that, when making some edits for this bug, I have seen background-image being used for icons. I think it was to create a cropping effect that changes with a change in attributes, but this can be done with css object-fit and object-position (maybe it wasn't an option at the time?).

However, I still prefer using html:img with a set src because it is the obvious html element to use for images. This requires more work when the source is meant to change with different attribute values (which is simpler with css selectors) but I think its worth it.

Comment 9

[Richard Marti (:Paenglab)]

It's the same with background-image and content. You have to set the dimensions and this is the easiest with the padding trick.

Comment 10

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Richard Marti (:Paenglab) from comment #9)

It's the same with background-image and content. You have to set the dimensions and this is the easiest with the padding trick.

ok, I wasn't sure about content.

I don't understand why padding would be better than width and height, especially since it obscures what you actually want. Is it so it also works on display: inline elements?

Comment 11

[Richard Marti (:Paenglab)]

I had some issues when I used width/height. When it works for you then it's okay to use it.

Comment 12

[alta88]

There are 2 issues:

1. <img> may seem like it should be used, because it's called img; that doesn't mean it's technically better just 'feels better', and this seems to be the reason it's being supported here. There should be a stronger reason. Some stronger reasons don't apply to the use case here: internal chrome pages, not web pages. The sentiment in Bug 1584641 doesn't seem pro img but pro css content.
2. The larger objection is to using the src attribute. This is definitely more work, maintenance wise. Loading a file as src allows the parser to call an element's onerror for bad images. This is not free, and certainly not a necessary feature for internal pages. Most importantly though, a src image cannot be overridden in css.

Comment 13

[Magnus Melin [:mkmelin]]

There's not necessarily one single right answer that covers all cases. For cases where it's not purely for design, e.g. it's an image you can/should click, <img> is needed for accessibility purposes. Cases where things wouldn't work correctly if the image is missing or couldn't load.
It's quite conceivable we'd load the pages also through other means than internal chrome some time in the future, and there could then be some possibility an image didn't load due to networking errors or similar.

<img src> can be overridden in css if desired - see http://www.audenaerde.org/csstricks.html#imagereplacecss

Comment 14

[alta88]

(In reply to Magnus Melin [:mkmelin] from comment #13)

There's not necessarily one single right answer that covers all cases. For cases where it's not purely for design,

But that will be the case for the very large majority of conversions. It is the case for both the patch checked in and the patch queued up. Using src for the editContactPanel panel star is the least correct and efficient way to do it. Tb should follow Emilio's suggestion in Bug 1584641 for content else use background-image.

Cases where things wouldn't work correctly if the image is missing or couldn't load.
It's quite conceivable we'd load the pages also through other means than internal chrome some time in the future, and there could then be some possibility an image didn't load due to networking errors or similar.

There is no legitimate scenario for missing image to be true for internal pages and I don't see how remote loading is conceivable at all; no one would propose such a thing for a desktop app. Some hypothetical thunderbird on the web scenario is not relevant here, and even then would be delivered via a font library with unicode private area definitions using content, like the tag button on this page.

<img src> can be overridden in css if desired - see http://www.audenaerde.org/csstricks.html#imagereplacecss

Sure, that is what's called a paper-over masking hack, not an override.

Comment 15

[Henry Wilkes (they/them) [:henry-x]]

(In reply to alta88 from comment #12)

2. The larger objection is to using the src attribute. This is definitely more work, maintenance wise. Loading a file as src allows the parser to call an element's onerror for bad images. This is not free, and certainly not a necessary feature for internal pages. Most importantly though, a src image cannot be overridden in css.

Is the idea that you think the image for an icon should be treated as styling, and therefore remain in css as much as possible? Similar to how button and selector icons are specified in css with list-style-image?

Also, do you have an example in mind for where you would want to override in css?

Side note

It would be nice if there was a general policy on what element to use in different circumstances. For example, using some examples I've come across in calendar:

1. Elements with no image, but used for their css decorations. E.g. the calendar colors. If it doesn't have some accessibility role, probably want an empty div.
2. Clickable images. E.g. the lock chain icon when setting event times. Probably want an img with alt describing the action. src would need to be set since css content doesn't work on img.
3. Images that convey information. E.g. the calendar alarm and private icons that act as flags. Probably want an img with an appropriate alt.
4. Images that complement an action. E.g. the timezone map (both the map itself, and the highlight overlay). Probably want an img with alt="" so that it can be ignored by accessibility.
5. Images that only decorate. E.g. the L linkers that sit above and below the lock chain icon when setting event times. This could either be an empty div with set css content or an img with alt="".
6. Images that 'spoof' a button icon, next to some text. E.g. the arrow next to 'Today Pane' in the status bar. Same as above, could either be an empty div or an img with alt="".
7. Images that have their source set in javascript. E.g. the file-type icons for attachments. This is easiest with setting src on an img, but you could technically have a div and set divElement.style.content = "url()" in javascript. But even then, you wouldn't be able to override in css (unless you used important!?).

At the moment, accessibility in calendar is probably very poor in general, so I'm not sure how much difference alt text would make. But it would be good to work in that direction. (Good news: this discussion has made me think about this more, so I will be adding alt to my changes). Please let me know if I've got something wrong regarding using alt for accessibility in thunderbird.

@alta88 Maybe it would help to talk about specific cases, as in the above. Are you advocating for using an empty div with css content for some of these cases?

Comment 16

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in calendar alarm dialog. r=darktrojan

Comment 17

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in email event invitation bar. r=darktrojan

Comment 18

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage for event priority bars. r=darktrojan

Now only use a single html:img for showing the priority status.
The svg was split into three separate images.

Comment 19

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in today pane. r=darktrojan

The 'image' element in <stack><image id="mini-day-image"/><hbox/></stack> was only used for its CSS background, but this can be applied to the 'hbox' directly, so the 'stack' and 'image' were removed and the 'id' was placed in the 'hbox'.

Also changed the drag 'xul:image' element to a 'html:img'.

Comment 20

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in event item classification and category. r=darktrojan

Comment 21

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in event item. r=darktrojan

Also removed unused associated attributes: 'allday', 'progress', 'itemType' and 'todoType'.

Depends on D110060

Comment 22

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in calendar agenda summary. r=darktrojan

Depends on D110267

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/bbfbd335b145
Replace xul:image usage in event edit dialog. r=darktrojan
https://hg.mozilla.org/comm-central/rev/73ae14c4f53d
Replace xul:image usage in calendar alarm dialog. r=darktrojan
https://hg.mozilla.org/comm-central/rev/366832b3cd41
Replace xul:image usage in email event invitation bar. r=darktrojan
https://hg.mozilla.org/comm-central/rev/68e5144c9b49
Replace xul:image usage for event priority bars. r=darktrojan
https://hg.mozilla.org/comm-central/rev/96a872a4ac6f
Replace xul:image usage in today pane. r=darktrojan
https://hg.mozilla.org/comm-central/rev/c56017612648
Replace xul:image usage in event item classification and category. r=darktrojan

Comment 24

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in calendar summary. r=darktrojan

Comment 25

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in attendance dialog. r=darktrojan

Comment 26

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in network calendar creation. r=darktrojan

Comment 27

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in event timezone dialog. r=darktrojan

Comment 28

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in event attachments. r=darktrojan

Comment 29

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in setting event reminders. r=darktrojan

Comment 30

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in calendar manager. r=darktrojan

Comment 31

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in attendee dialog. r=darktrojan

The 'status-icon' class was completely removed since it was unused.

Comment 32

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in event gripbars. r=darktrojan

Also replaced the 'set parentorient' with a watch on the 'parentorient' and 'whichside' attributes. The former method was not working: the 'parentorient' property was always being set to "" in 'connectedCallback' because the 'parentorient' attribute had not yet been set.

Comment 33

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in statusbar today pane. r=darktrojan

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d4afbf8aaef6
Replace xul:image usage in event item. r=darktrojan
https://hg.mozilla.org/comm-central/rev/e9863d2e6541
Replace xul:image usage in calendar agenda summary. r=darktrojan
https://hg.mozilla.org/comm-central/rev/052f22f50429
Replace xul:image usage in calendar summary. r=darktrojan
https://hg.mozilla.org/comm-central/rev/e5f34a08a2d5
Replace xul:image usage in attendance dialog. r=darktrojan
https://hg.mozilla.org/comm-central/rev/8cbb622a3cd7
Replace xul:image usage in network calendar creation. r=darktrojan
https://hg.mozilla.org/comm-central/rev/2e851450f0db
Replace xul:image usage in event timezone dialog. r=darktrojan
https://hg.mozilla.org/comm-central/rev/fdeeaa5b4cd2
Replace xul:image usage in event attachments. r=darktrojan
https://hg.mozilla.org/comm-central/rev/3a15062552f2
Replace xul:image usage in setting event reminders. r=darktrojan
https://hg.mozilla.org/comm-central/rev/c3d7a5ec0fd5
Replace xul:image usage in calendar manager. r=darktrojan
https://hg.mozilla.org/comm-central/rev/1037586298d6
Replace xul:image usage in attendee dialog. r=darktrojan
https://hg.mozilla.org/comm-central/rev/b69844efd68a
Replace xul:image usage in event gripbars. r=darktrojan
https://hg.mozilla.org/comm-central/rev/a21c8adc678f
Replace xul:image usage in statusbar today pane. r=darktrojan

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4779e6740711
Backed out changeset 3a15062552f2 for test failures in at least calendar/test/unit/test_alarmutils.js

Comment 36

[Alessandro Castellani [:aleca]]

Attachment: Screenshot from 2021-04-15 11-24-49.png

One of the patches seemed to have regressed the indicator-private-browsing.svg icon used in the calendar sidebar list.
The "lock" icon appears when a calendar is marked as read-only.

Comment 37

[Alessandro Castellani [:aleca]]

Just to clarify, the icon is still there but the image is empty when the calendar is not read-only.
So the CSS should be updated to hide the image, I think.

Comment 38

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Make calendar-readstatus invisible when it has no src. r=aleca

Otherwise the image will be visible with a black outline.

Comment 39

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Alessandro Castellani [:aleca] from comment #37)

Just to clarify, the icon is still there but the image is empty when the calendar is not read-only.
So the CSS should be updated to hide the image, I think.

Yup, it should be invisible. I added a patch.

Weirdly I tested this specific case visually before and missed it. I know for some of the other changesets where the src attribute is removed I set them to be display: none when I didn't want them to take up space, but I'll double check the other cases.

Comment 40

[Henry Wilkes (they/them) [:henry-x]]

Just checked the other patches, all other cases of no src attribute would be error cases (so the black square would be an appropriate indicator) or are hidden by the parent.

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/67263bb1748d
Make calendar-readstatus invisible when it has no src. r=aleca

Comment 42

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage for chat user, protocol and status icons. r=freaktechnik

Also, as part of this:

• Reduced styling repetitions, and some coding repetitions.
• Dropped some stylesheets because they were no longer needed or the few rules could be merged.
• Moved logic related to chat-conversation-info into internal methods.
• Removed some old styling hacks that were used to show the user name and status in chat-tooltip, chat-conversation-info and imAccounts, and replaced them with a grid.

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/61591773c2d0
Replace xul:image usage in setting event reminders. r=darktrojan

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9c30d915b033
Replace xul:image usage for chat user, protocol and status icons. r=freaktechnik

Comment 45

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in OTR fingerprint dialog. r=freaktechnik

Comment 46

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in chat roles. r=freaktechnik

Comment 47

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in chat groups. r=freaktechnik

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/32100bb1fe5f
Replace xul:image usage in OTR fingerprint dialog. r=freaktechnik
https://hg.mozilla.org/comm-central/rev/d2b3fe4417d6
Replace xul:image usage in chat roles. r=freaktechnik
https://hg.mozilla.org/comm-central/rev/6b9339177659
Replace xul:image usage in chat groups. r=freaktechnik

Comment 49

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Fix setting an error icon for calendar cloud attachment failure. r=darktrojan

Comment 50

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/885b6b740086
Fix setting an error icon for calendar cloud attachment failure. r=darktrojan

Comment 51

[Henry Wilkes (they/them) [:henry-x]]

There are a few places that use the loading.png icon to indicate waiting (normally for the network). Each of these can be changed to

<img src="chrome://global/skin/icons/loading.png"
     srcset="chrome://global/skin/icons/[e-mail] 2x"
     alt="" />

However, since this would be fairly common, I thought it might make sense to create a custom HTML element <loading-img/>, which just sets these attributes by default.

But I have two questions:

1. Is creating a custom element to only set some common attributes over the top? Is there a lighter method to get the same result?
2. Which directory is a good place for such custom elements that are used across TB?

Comment 52

[Alessandro Castellani [:aleca]]

Sorry to interject here, but we should slowly getting rid of the loading PNG and switch to the SVG version.
The PNG forces us to have a 2x variation for HiDPI monitors, and we can't control it to properly adapt it for dark theme variations.

We currently use the new SVG with a CSS based animation in a couple of areas.
https://searchfox.org/comm-central/rev/571b1a21fbcb0e57b10a931a4c599a6fb0cb7292/mail/themes/shared/mail/tabmail.css#214-238
https://searchfox.org/comm-central/rev/571b1a21fbcb0e57b10a931a4c599a6fb0cb7292/mail/themes/shared/mail/message-bar.css#147-171

Not sure if this is out of scope for this bug, but I just wanted to put it out there to avoid for Henry to do double work.

Comment 53

[Magnus Melin [:mkmelin]]

(In reply to Henry Wilkes [:henry] from comment #51)

1. Is creating a custom element to only set some common attributes over the top? Is there a lighter method to get the same result?

CE is probably how to do it. But I would say it's not worth doing if the functionality is minimal, like for the images. CEs are very expensive compared to normal elements, and if things ever change, global search/replace is very easy/fast to do, so not something to worry too much about.

2. Which directory is a good place for such custom elements that are used across TB?

They would be with the other mail/ widgets. Geoff is currently moving those to a separate folder.

Like :aleca says, we want to use svgs going forwards, but e.g. your 2x case is easily fixable by a global search/replace at that point.

Comment 54

[Henry Wilkes (they/them) [:henry-x]]

Thanks for the info. And its useful to know that we'll be switching to svgs.

I'll stick with the basic method rather than use custom elements.

Comment 55

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in email address headers. r=mkmelin

Also allowed the chat status icon to show a wider range of statuses.

Comment 56

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b296c12d6577
Replace xul:image usage in email address headers. r=mkmelin

Comment 57

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Remove the data-l10n-id when setting alt text through both fluent and inline. r=mkmelin

In cases where we (un)set the alt text through a mixture of l10n.setAttributes, setAttribute("alt",) and removeAttribute("alt"), we make sure to remove the data-l10n-id attribute in the last two cases.

This cleans up the element's attributes (which is useful for debugging inspection) but is also needed in some cases. For example, if we perform the following sequence:

1. l10n.setAttributes(image, "same-fluent-id-to-set-alt")
2. image.setAttribute("alt", "")
3. l10n.setAttributes(image, "same-fluent-id-to-set-alt")

The alt attribute is not restored by the last call because the data-l10n-id attribute is unchanged. We need to remove the data-l10n-id attribute after step 2 so that the localization can detect the change in id and restore the alt text.

Comment 58

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in message encryption header. r=mkmelin

Comment 59

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e449dd990478
Remove the data-l10n-id when setting alt text through both fluent and inline. r=mkmelin

Comment 60

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in treecol-image. r=mkmelin

Comment 61

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/5803f56195b0
Replace xul:image usage in treecol-image. r=mkmelin

Comment 62

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in menulist-editable. r=mkmelin

Removed the unused icon part.

Comment 63

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in attachment list. r=mkmelin

Dropped the 32 image size since the icon is only ever displayed as 16px by 16px.

Comment 64

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in address pills. r=mkmelin

Comment 65

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Convert the addresses field close button from a xul:label into a xul:button. r=mkmelin

The button was constructed as a xul label, but its event behaviour and role were set to mimic that of a button. So a button is more semantically correct and brings the desired behaviour automatically.

Comment 66

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in toolbar activity indicator. r=mkmelin

Comment 67

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ab0cf15447b2
Replace xul:image usage in menulist-editable. r=mkmelin

Comment 68

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3dc8a1620918
Replace xul:image usage in attachment list. r=mkmelin
https://hg.mozilla.org/comm-central/rev/0a4c15818b12
Replace xul:image usage in address pills. r=mkmelin
https://hg.mozilla.org/comm-central/rev/760cf06249e1
Convert the addresses field close button from a xul:label into a xul:button. r=mkmelin
https://hg.mozilla.org/comm-central/rev/87d37b027784
Replace xul:image usage in toolbar activity indicator. r=mkmelin

Comment 69

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Remove title from chat-conversation-info status icon. r=freaktechnik

All the textual information in the icon tooltip is already available in the status box adjacent to it.

Comment 70

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Remove alt text that duplicates the title. r=mkmelin

Current specifications (see "Accessible Name and Description Computation" in HTML Accessibility API Mappings 1.0) state that if there is an alt attribute for an img it is used as the Accessible Name, otherwise the title attribute is used as the Accessible Name. See also Bug 1700174.

For existing situations where the title describes an icon for visual pointer users, and we also want this to be the Accessible Name, to avoid duplicating information, we should simply not include the alt attribute.

Note that these situations should still be avoided because a visual keyboard user would not have access to the title text.

Comment 71

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/1c0c6a085c8f
Remove alt text that duplicates the title. r=mkmelin

Comment 72

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/668a02c0a6db
Remove title from chat-conversation-info status icon. r=freaktechnik

Comment 73

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in tab drop indicator. r=mkmelin

Comment 74

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/16972bd72bf2
Replace xul:image usage in message encryption header. r=mkmelin
https://hg.mozilla.org/comm-central/rev/4a6f152a44d9
Replace xul:image usage in tab drop indicator. r=mkmelin

Comment 75

[Geoff Lankow (:darktrojan)]

(In reply to Henry Wilkes [:henry] from comment #40)

Just checked the other patches, all other cases of no src attribute would be error cases (so the black square would be an appropriate indicator) or are hidden by the parent.

<img class="reminder-icon" value="NONE" alt="" />

I think we should just hide this case, it's not an error and not having an icon is appropriate. (Code in calendar/base/content/dialogs/calendar-event-dialog-reminder.js.)

Comment 76

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Geoff Lankow (:darktrojan) from comment #75)

(In reply to Henry Wilkes [:henry] from comment #40)

Just checked the other patches, all other cases of no src attribute would be error cases (so the black square would be an appropriate indicator) or are hidden by the parent.

<img class="reminder-icon" value="NONE" alt="" />

I think we should just hide this case, it's not an error and not having an icon is appropriate. (Code in calendar/base/content/dialogs/calendar-event-dialog-reminder.js.)

I didn't realise other values were allowed. What does value="NONE" mean in the reminder dialog?

Looking through now, it seems "AUDIO" is checked in CalAlarm.jsm. I also remember removing a test that used "MOBILE".

Where do these other values come from since the selector in the reminder dialog only has "EMAIL" and "DISPLAY" (https://searchfox.org/comm-central/rev/b972d9ae1bd20536044be70c5bf3670e70b40720/calendar/base/content/dialogs/calendar-event-dialog-reminder.xhtml#124). Is there a limited set of values somewhere?

Would it make sense to have icons for these other cases? Currently in the reminder dialog, for "DISPLAY", it shows

<alert-icon> | 15 minutes before the event starts

or in the accessibility tree

Show an Alert | 15 minutes minutes before the event starts

But without an icon, it would just be

15 minutes before the event starts

without any idication of what the alert type is, or what the text refers to. So maybe we should have icons for each case, or at least use a fallback icon (like a question mark with alt text Unknown Alert).

In the case of event boxes where we only have an icon on its own (https://searchfox.org/comm-central/rev/b972d9ae1bd20536044be70c5bf3670e70b40720/calendar/base/modules/utils/calAlarmUtils.jsm#140), would you rather use a fallback icon? Otherwise, we might as well not create and add the <img> at all.

Comment 77

[Magnus Melin [:mkmelin]]

https://icalendar.org/iCalendar-RFC-5545/3-8-6-1-action.html - it's not a fully limited set. But the ones we don't support MUST be ignored.

Comment 78

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Magnus Melin [:mkmelin] from comment #77)

https://icalendar.org/iCalendar-RFC-5545/3-8-6-1-action.html - it's not a fully limited set. But the ones we don't support MUST be ignored.

Does that mean in setupListItem (https://searchfox.org/comm-central/rev/b972d9ae1bd20536044be70c5bf3670e70b40720/calendar/base/content/dialogs/calendar-event-dialog-reminder.js#210) we should not create the list item if it is neither "DISPLAY" nor "EMAIL"?

Comment 79

[Magnus Melin [:mkmelin]]

Well, and AUDIO. But otherwise correct.

Comment 80

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Magnus Melin [:mkmelin] from comment #79)

Well, and AUDIO. But otherwise correct.

OK, I'll make the changes. We also would need an "AUDIO" icon then, or at least include some additional text, otherwise we still have this problem from comment #76:

without an icon, it would just be

15 minutes before the event starts

without any idication of what the alert type is, or what the text refers to.

Comment 81

[Richard Marti (:Paenglab)]

(In reply to Henry Wilkes [:henry] from comment #80)

(In reply to Magnus Melin [:mkmelin] from comment #79)

Well, and AUDIO. But otherwise correct.

OK, I'll make the changes. We also would need an "AUDIO" icon then, or at least include some additional text, otherwise we still have this problem from comment #76:

There is one at "chrome://global/skin/media/audio.svg".

Comment 82

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Do not show reminder icons for unsupported reminder actions. r=darktrojan

DISPLAY and EMAIL actions already had icons, and added icon support for the AUDIO action. All other actions should be ignored by the UI until they are supported.

Comment 83

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in content pane security icon. r=mkmelin

Comment 84

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in message attachment. r=mkmelin

Comment 85

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in openpgp notification icons. r=mkmelin

Comment 86

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in openpgp settings. r=mkmelin

Comment 87

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in openpgp key generation/import. r=mkmelin

Comment 88

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4a72aca99202
Do not show reminder icons for unsupported reminder actions. r=darktrojan
https://hg.mozilla.org/comm-central/rev/46839b999e58
Replace xul:image usage in content pane security icon. r=mkmelin
https://hg.mozilla.org/comm-central/rev/4785f8e16605
Replace xul:image usage in message attachment. r=mkmelin
https://hg.mozilla.org/comm-central/rev/7b9edcbe3bf7
Replace xul:image usage in openpgp notification icons. r=mkmelin
https://hg.mozilla.org/comm-central/rev/2d19637d6b1f
Replace xul:image usage in openpgp settings. r=mkmelin

Comment 89

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/cd9a0fda9cf8
followup to fix Fluent linting. rs=fluent-lint DONTBUILD

Comment 90

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/aa4a4b2932ac
Replace xul:image usage in openpgp key generation/import. r=mkmelin

Comment 91

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in sanitation dialog. r=mkmelin

Comment 92

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d392076e308e
Replace xul:image usage in sanitation dialog. r=mkmelin

Comment 93

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Clean out activity manager. r=aleca

The activity manager richlistitems were simplified to use html elements instead of xul. Common CSS between platforms was merged into a shared file.

The unused activity buttons (undo, pause, resume, restart, cancel and recover) were dropped.

Comment 94

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in cloud provider selection dialog. r=aleca

Comment 95

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace "add recipient field" xul elements with html buttons. r=aleca

Also changed the representation of the extra buttons from a xul:panel to an in-place set of buttons that are shown/hidden to reflect the semantics: neither a dialog nor a selection menu, but an overflow for the set of buttons.

Also fixed the arrow key navigation in this area, so that it is possible to smoothly navigate between the main set of buttons, and the overflow set.

Comment 96

[Alessandro Castellani [:aleca]]

(In reply to Henry Wilkes [:henry] from comment #95)

Created attachment 9231185 [details]
Bug 1683865 - Replace "add recipient field" xul elements with html buttons. r=aleca

I'm not sure this patch should be in this bug as it does way more than only replacing the xul:image.
I think it's better to track this in a dedicated bug.

Comment 97

[Phabricator Automation]

Comment on attachment 9231185 [details]
Bug 1683865 - Replace "add recipient field" xul elements with html buttons. r=aleca

Revision D119897 was moved to bug 1721352. Setting attachment 9231185 [details] to obsolete.

Comment 98

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Changed status bar to HTML. r=mkmelin

Also supported tab shifting to the status-bar through F6.

Comment 99

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in about:downloads. r=mkmelin

Also updated the content policy to allow moz-icon image sources.

Also combined the behaviour for img elements whose src values are allowed to be invalid into ImgUtils.jsm.

Comment 100

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Make the popup browser url headers look like the content tab header. r=mkmelin

Comment 101

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in preferences application icons. r=mkmelin

Comment 102

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in message-bar-icon. r=mkmelin

Comment 103

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in preferences category panel. r=mkmelin

Comment 104

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4f5b4ed62455
Replace xul:image usage in preferences category panel. r=mkmelin
https://hg.mozilla.org/comm-central/rev/2f83b271cc3b
Replace xul:image usage in about:downloads. r=mkmelin

Comment 105

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/18c1f76631f6
Replace xul:image usage in cloud provider selection dialog. r=aleca
https://hg.mozilla.org/comm-central/rev/991627ce316e
Changed status bar to HTML. r=mkmelin
https://hg.mozilla.org/comm-central/rev/b23d8206a1e9
Make the popup browser url headers look like the content tab header. r=mkmelin
https://hg.mozilla.org/comm-central/rev/5a1b41edf4fd
Replace xul:image usage in preferences application icons. r=mkmelin
https://hg.mozilla.org/comm-central/rev/3dfb738fa834
Replace xul:image usage in message-bar-icon. r=mkmelin

Comment 106

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace junkMailInfo dialog with a link to the junk support page. r=mkmelin

Comment 107

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Drop the empty no-results-image. r=mkmelin

Comment 108

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in telemetry preferences. r=mkmelin

Also, previously the image was missing because the info-icon-telemetry image (taken from mozilla-central) had no corresponding CSS in scope.

Comment 109

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in newmailalert. r=mkmelin

Comment 110

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in create CardDAV dialog. r=mkmelin

Comment 111

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b4705b6adee8
followup to b23d8206a1e9 - fix linting. rs=eslint DONTBUILD

Comment 112

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in mail storage converter dialog. r=mkmelin

Comment 113

[Phabricator Automation]

Comment on attachment 9235628 [details]
Bug 1683865 - Replace junkMailInfo dialog with a link to the junk support page. r=mkmelin

Revision D122258 was moved to bug 1725220. Setting attachment 9235628 [details] to obsolete.

Comment 114

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4383c12604c0
Drop the empty no-results-image. r=mkmelin
https://hg.mozilla.org/comm-central/rev/05eeba0d2703
Replace xul:image usage in telemetry preferences. r=mkmelin
https://hg.mozilla.org/comm-central/rev/886ae0b97414
Replace xul:image usage in newmailalert. r=mkmelin
https://hg.mozilla.org/comm-central/rev/d1210f26e9cb
Replace xul:image usage in create CardDAV dialog. r=mkmelin

Comment 115

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/107b3a18ff53
follow-up - Fix broken tests. rs=bustage-fix DONTBUILD

Comment 116

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Remove unused xul:image elements in gloda autocomplete richlistitems. r=mkmelin

The images were always empty (no src or list-style-image) and took up no space.

Comment 117

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in search boxes. r=mkmelin

Comment 118

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in chat badge button. r=mkmelin

Comment 119

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/6fabadfb4f73
Clean out activity manager. r=aleca
https://hg.mozilla.org/comm-central/rev/f6d936ae7135
Replace xul:image usage in mail storage converter dialog. r=mkmelin
https://hg.mozilla.org/comm-central/rev/7aeafac65b60
Remove unused xul:image elements in gloda autocomplete richlistitems. r=mkmelin
https://hg.mozilla.org/comm-central/rev/daa47b19e997
Replace xul:image usage in search boxes. r=mkmelin

Comment 120

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/f96c863c78cf
Replace xul:image usage in chat badge button. r=mkmelin

Comment 121

[Magnus Melin [:mkmelin]]

(In reply to Pulsebot from comment #119)

https://hg.mozilla.org/comm-central/rev/daa47b19e997
Replace xul:image usage in search boxes. r=mkmelin

The quick filter search box used to get a "clear" icon on the right after you type something. That's not appearing anymore.

Comment 122

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Magnus Melin [:mkmelin] from comment #121)

The quick filter search box used to get a "clear" icon on the right after you type something. That's not appearing anymore.

That search box is controlled by mozilla-central search-textbox. The regression is caused by https://hg.mozilla.org/mozilla-central/rev/64cf5966f871

Comment 123

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage for updates. r=mkmelin

Comment 124

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/c1c11744674a
Replace xul:image usage for updates. r=mkmelin

Comment 125

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Adjust the icon-button class to plain-button. r=mkmelin

The original definition that zeroed the padding, margin and border-radius ended up being overwritten in most use cases.

Comment 126

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in tab close icon. r=mkmelin

Also got rid of some unnecessarily precise ... > .tab-stack > ... parts of CSS selectors.

Depends on D123432

Comment 127

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7f8909debcf4
Adjust the icon-button class to plain-button. r=mkmelin
https://hg.mozilla.org/comm-central/rev/c6695c5b5708
Replace xul:image usage in tab close icon. r=mkmelin

Comment 128

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Replace xul:image usage in tab (fav)icon. r=mkmelin

Comment 129

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3fef60eeb2d0
Replace xul:image usage in tab (fav)icon. r=mkmelin

Comment 130

[Henry Wilkes (they/them) [:henry-x]]

Status update

Here are the known remaining locations within comm-central that still contain a xul:image, and why they won't be changed yet.

• mailnews/compose/content/askSendFormat.xhtml displays a platform dependant message/question/warning icon - This dialog should be removed with Bug 1727493.
• mail/extensions/openpgp/content/ui/enigmailMsgBox.xhtml displays a platform dependant message/question/warning/error icon - This dialog should be removed with Bug 1716759.
• mail/base/content/messenger.xhtml uses #addons-notification-icon and #app-update-notification-icon - The code for this is a bit messy and controlled by ExtensionsUI.jsm and GlobalPopupNotifications.jsm, but these are both based on ExtensionsUI.jsm and PopupNotifications.jsm from mozilla-central. We can wait and see how this is handled there.
• mail/base/content/profileDowngrade.xhtml uses an info icon - Based on mozilla-central file of the same name.
• mail/components/addrbook/content/abMailListDialog.xhtml, abEditListDialog.xhtml, abCard.inc.xhtml, addressbook.xhtml - Old address book is being replaced with Bug 1705276.
• extensionControlled.js close icon is a xul:image - This section was introduced in Bug 1711274 and is ported from mozilla-central, but seems to be broken anyway because we are missing fluent entries and the icon sources. See Bug 1728323.
• mail/components/customizableui/content/customizeMode.inc.xhtml panel-arrow icon (which I think is empty anyway) - Based on mozilla-central.

Note that xul:images still exist in other places in thunderbird, but only from code in mozilla-central, such as the icons used in xul menus and buttons.

Comment 131

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Follow up to 32100bb1fe5f that fixes the fingerWarning icon. r=freaktechnik

Added an alt attribute. Also removed the tooltiptext attribute which is incorrect for html elements; whilst it could have been replaced with the title attribute, the text is already shown below the input, so there is no need to duplicate it.

Comment 132

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1683865 - Add alt attribute that was missing in rev e5f34a08a2d5. r=darktrojan

Comment 133

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/013d34bdb558
Follow up to 32100bb1fe5f that fixes the fingerWarning icon. r=freaktechnik
https://hg.mozilla.org/comm-central/rev/5cb8f8479f80
Add alt attribute that was missing in rev e5f34a08a2d5. r=darktrojan

Comment 134

[Elizabeth Mitchell]

Context Update

There are two different tags in the code base:

<image - Searchfox results
<xul:image - Searchfox results

Edit: Shared the above information for context and as a follow-up to comment #0. comment #135 provides further context.

Comment 135

[Alessandro Castellani [:aleca]]

(In reply to Elizabeth Mitchell from comment #134)

There are two different tags in the code base:

<image - Searchfox results
<xul:image - Searchfox results

Yes, they're basically the same. The xul prefix is used when the context of the parent element is pure HTML.

Comment 136

[Elizabeth Mitchell]

Attachment: Bug 1683865 - Replace app notifications icons. r=aleca

Comment 137

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/afd690ad68cf
Replace app notifications icons. r=aleca

Comment 138

[Richard Marti (:Paenglab)]

(In reply to Pulsebot from comment #137)

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/afd690ad68cf
Replace app notifications icons. r=aleca

Can the list-style-images https://searchfox.org/comm-central/rev/1749f88c7a80c1a2b5bafc95111a82736175cb18/mail/themes/shared/mail/messenger.css#822 and https://searchfox.org/comm-central/rev/1749f88c7a80c1a2b5bafc95111a82736175cb18/mail/themes/shared/mail/messenger.css#861 be removed?

Comment 139

[Alessandro Castellani [:aleca]]

Oh yes, it seems we can remove those attributes.
I guess we could also remove the addons-icon class entirely form that element since it's not used.

Comment 140

[Elizabeth Mitchell]

I will remove those attributes. Thank you! Will look into removing the addons-icon class as well.

Comment 141

[Elizabeth Mitchell]

Attachment: Bug 1683865 - Remove unused CSS from app notification icons. r=aleca

• Remove .addons-icon class
• Remove list-style-image attribute from .app-update-icon class
• Refactor is needed as a result of changes in:
  https://hg.mozilla.org/comm-central/rev/afd690ad68cf

Comment 142

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/34a26d8261e0
Remove unused CSS from app notification icons. r=aleca

Comment 143

[Elizabeth Mitchell]

Status Update

Remaining instances:

<image
<xul:image

As of today, there are 8 combined remaining instances in the code.

Comment 144

[Magnus Melin [:mkmelin]]

For the case in enigmailMsgBox.xhtml, that whole file and its consumers should be ripped out and replaced with standard prompts.

Comment 145

[Elizabeth Mitchell]

Attachment: Bug 1683865 - Replace person icon in address book list dialogs. r=aleca

• Refactor icon to use img instead of xul:image
• Replace icon in new list dialog and edit list dialog

Comment 146

[Elizabeth Mitchell]

(In reply to Magnus Melin [:mkmelin] from comment #144)

For the case in enigmailMsgBox.xhtml, that whole file and its consumers should be ripped out and replaced with standard prompts.

Thanks for sharing this information. I found more information about enigmailMsgBox.xhtml in comment #130 and Bug 1716759. I'll touch base with Alessandro Castellani [:aleca] about this.

Comment 147

[Alessandro Castellani [:aleca]]

(In reply to Magnus Melin [:mkmelin] from comment #144)

For the case in enigmailMsgBox.xhtml, that whole file and its consumers should be ripped out and replaced with standard prompts.

Yup, we will tackle this in bug 1716759, so we can close this metabug once the other images are replaced.

Comment 148

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/feb4c44c3f24
Replace person icon in address book list dialogs. r=aleca

Comment 149

[Elizabeth Mitchell]

Attachment: Bug 1683865 - Replace icon in profile downgrade dialog. r=aleca

• Replace xul:image icon with html:img icon
• Previous icon was not loading in the dialog

Comment 150

[Elizabeth Mitchell]

Attachment: Bug 1683865 - Update icon in common dialog. r=aleca

• Replace xul:image with img icon

Comment 151

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9416876e8afe
Replace icon in profile downgrade dialog. r=aleca

Comment 152

[Alessandro Castellani [:aleca]]

From this work, you can also ignore the images in customizeMode.inc.xhtml, since we're rebuilding the customization mode for the toolbar from scratch in pure HTML, we will soon delete all those files, so no need to update them.

So the last piece of work needed to close this are the 2 images in panelUI.inc.xhtml.

Comment 153

[Elizabeth Mitchell]

Okay. Thanks for the update.

Comment 154

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ccb7ec2faf62
Update icon in common dialog. r=aleca

Comment 155

[Elizabeth Mitchell]

Attachment: Bug 1683865 - Replace icons in panelUI. r=aleca

Comment 156

[Alessandro Castellani [:aleca]]

I think we can finally close this meta bug after this last patch lands.
We can tackle the enigmail dialog in its dedicated bug.

Comment 157

[Elizabeth Mitchell]

The enigmail dialog will be handled outside of this [meta] bug.

Comment 158

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/806a5fdd8543
Replace icons in panelUI. r=aleca