504822 - Remove XBM support from Mozilla

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Bobby Holley (:bholley)]

It doesn't seem like anyone uses XBMs on the web these days (microsoft dropped support for them in ie6), and we no longer use them anyone in the platform. Each additional image decoder makes it more time consuming to maintain imagelib, because changes have to be replicated. Thus, unless somebody has a reasoned opinion to the contrary, I'll remove XBM support in a week or two.

As a bonus, this should fix bug 304521, if it still exists.

Comment 1

[Philip Chee]

Oops. I have a test case using XBM in:
<https://bugzilla.mozilla.org/show_bug.cgi?id=386333#c6>

How do I rewrite it to not use XBM but still tests the criteria in:
<https://bugzilla.mozilla.org/show_bug.cgi?id=491310#c24>

Comment 2

[Bobby Holley (:bholley)]

Philip - So if I understand correctly, you're looking to test alternative data-url formats for images? It's true that XBM is currently the only ASCII image format we support (this certainly wouldn't be enough of a reason to keep support for it). Are there any alternative dataurl formats, or are base64 and ascii the only 2 options?

Comment 3

[Philip Chee]

> Are there any alternative dataurl formats, or are base64 and
> ascii the only 2 options?

No idea but Neil asked me to handle the above situation in that bug so once XBM goes away I need an alternative test case. On the other hand once XBM goes away I might not have to test for ASCII formats. Ping Neil?

Comment 4

[[e-mail]]

We support urlencoded but nobody would use it when they can use base64.

Comment 5

[Bobby Holley (:bholley)]

we might want the for the branch - asking for blocking 1.9.2

Comment 6

[Bobby Holley (:bholley)]

Attachment: patch v1

Attached a patch to remove XBM support. I just pushed to try. Once I confirm that it doesn't break anything, I'll flag for review.

Comment 7

[Bobby Holley (:bholley)]

Comment on attachment 391043 [details] [diff] [review]
patch v1

tryserver looks good. Flagging joe for review and vlad for sr.

Joe, vlad - beltzner wants this in for the alpha. Since I'm taking tomorrow and probably thursday off (party!) it would be really helpful if you could review this when you get in so I can land it today.

Comment 8

[Axel Hecht [:Pike]]

imageFilter=*.jpg; *.jpeg; *.gif; *.png; *.bmp; *.ico

sounds like something that doesn't need to be in l10n at all, AFAICT.

What happens if some localizer doesn't pick up this change? If we really need this change, we should flip the entity name, or rip it out of l10n. I guess I'd prefer the latter.

Comment 9

[Bobby Holley (:bholley)]

alex - I'm not too familiar with l10n stuff. do you have a clear grasp of what needs to happen to rip this out of l10n? If so, do you have time to do it?

Comment 10

[Bobby Holley (:bholley)]

Also, AFAICT the impact of a localizer not picking that up would be that somewhere an XBM file might be labeled and image (which is true), despite the fact that firefox can't display it. Probably not a big big deal IMO.

Comment 11

[Axel Hecht [:Pike]]

Sorry, I don't have cycles for that right now.

Not sure where to move the list to, someone from imglib should know. Really, as soon as you know where to put, ripping it out should be nothing more than removing the line and changing the callsites.

Not sure if a pref is good enough.

Comment 12

[(no longer active)]

Couldn't we just move those to a separate .properties file outside of the locale dir, and modify the call site to load the bundle from that new location?

Comment 13

[Joe Drew (not getting mail)]

Comment on attachment 391043 [details] [diff] [review]
patch v1

r+ as long as you inline the filepicker filter in nsBaseFilePicker and remove it from the .properties file.

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 391043 [details] [diff] [review]
patch v1

Do we need to get rid of it from nsExternalHelperAppService?

Comment 15

[Bobby Holley (:bholley)]

Attachment: patch v2

updated patch to address joe's review concerns. keeping joe's r+ and updating vlad's sr request to this. pushing to try again "just in case"

Comment 16

[Bobby Holley (:bholley)]

Attachment: patch v3

addressed vlads comments. re-flagging for sr

Comment 17

[Bobby Holley (:bholley)]

Comment on attachment 391150 [details] [diff] [review]
patch v3

(and re-pushing to try)

Comment 18

[Joe Drew (not getting mail)]

http://hg.mozilla.org/mozilla-central/rev/e3c9ab74bbdd

Comment 19

[Bobby Holley (:bholley)]

removing blocking nomination - this made it

Comment 20

[[e-mail]]

(In reply to comment #8)
> imageFilter=*.jpg; *.jpeg; *.gif; *.png; *.bmp; *.ico
> 
> sounds like something that doesn't need to be in l10n at all, AFAICT.
> 
> What happens if some localizer doesn't pick up this change? If we really need
> this change, we should flip the entity name, or rip it out of l10n. I guess I'd
> prefer the latter.
Unfortunately there were two consumers of this string :-(

Comment 21

[Scott Schiller]

For what it's worth, I was wondering why a (highly-experimental, not important) hack I was using had stopped working with 3.6b3.. ah well.

eg.
http://www.schillmania.com/temp/xbm-test.html (image/x-bitmap data: URI, etc.)
.. leading to dynamic URI generation via JS, and favicon "animation", here (Works in Firefox 3.5.x and Opera):
http://www.schillmania.com/projects/soundmanager2/demo/page-player/

"Defender of the favicon" still works, as it's image/png-based via canvas - I'll move to that as well.
http://www.p01.org/releases/DEFENDER_of_the_favicon/

Comment 22

[ajf]

I know this is unlikely to be undone all these years later, but I am upset this was removed. Some web content did still rely on XBM. An example of this is Wolf5K:

http://www.wolf5k.com/

Quite a few pages used XBM + <img src="javascript:..."> in order to draw images prior to the <canvas> element. Now, they're unusable in Firefox, Safari or Internet Explorer. This is really sad.

Comment 23

[John Duncan]

I agree with ajf. To make matters even worse, I [personally] can no longer leverage Mozilla's built in XBM support to display local/online XBM picon searches (which I have recently added into my updated MessageFaces extension for mailnews); I am constrained to simply relying on the GIFs from the picon database. I was also unaware that Mozilla could not decode X Pixmaps (I can neither open XBM or XPM picons in SeaMonkey 2.40 on OS X 10.11)

Removal seems like a sort of arbitrary decision (especially on the Mozilla platform which has historically been lauded for its wide-array of historical features in the power-user and end-user communities alike).

I'd argue that, since most people are spending a majority amount of their time on the web these days (and thus live inside of their web-browser), that their web-browser should support all of the features that the respective user-base deems important. And I think it could be possible to make the case that a percentage of active Mozilla users still care about these powerful (albeit old/arcane) open image formats.

Cited:
http://www.cs.indiana.edu/l/www/pub/faces/picons/
https://github.com/JohnDDuncanIII/MessageFaces