Remove XBM support from Mozilla

RESOLVED FIXED in mozilla1.9.2a1

Status

()

RESOLVED FIXED
10 years ago
3 years ago

People

(Reporter: bholley, Assigned: bholley)

Tracking

(Depends on: 1 bug)

Trunk
mozilla1.9.2a1
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

10 years ago
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.
(Assignee)

Updated

10 years ago
Blocks: 304521
Blocks: 202274

Comment 1

9 years ago
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>
(Assignee)

Comment 2

9 years ago
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

9 years ago
> 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

9 years ago
We support urlencoded but nobody would use it when they can use base64.
(Assignee)

Comment 5

9 years ago
we might want the for the branch - asking for blocking 1.9.2
Flags: blocking1.9.2?
(Assignee)

Comment 6

9 years ago
Created attachment 391043 [details] [diff] [review]
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.
(Assignee)

Comment 7

9 years ago
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.
Attachment #391043 - Flags: superreview?(vladimir)
Attachment #391043 - Flags: review?(joe)

Comment 8

9 years ago
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.
(Assignee)

Comment 9

9 years ago
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?
(Assignee)

Comment 10

9 years ago
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

9 years ago
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

9 years ago
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 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.
Attachment #391043 - Flags: review?(joe) → review+
Comment on attachment 391043 [details] [diff] [review]
patch v1

Do we need to get rid of it from nsExternalHelperAppService?
(Assignee)

Comment 15

9 years ago
Created attachment 391140 [details] [diff] [review]
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"
Attachment #391140 - Flags: superreview?(vladimir)
(Assignee)

Updated

9 years ago
Attachment #391043 - Flags: superreview?(vladimir)
(Assignee)

Comment 16

9 years ago
Created attachment 391150 [details] [diff] [review]
patch v3

addressed vlads comments. re-flagging for sr
Attachment #391140 - Attachment is obsolete: true
Attachment #391140 - Flags: superreview?(vladimir)
(Assignee)

Comment 17

9 years ago
Comment on attachment 391150 [details] [diff] [review]
patch v3

(and re-pushing to try)
Attachment #391150 - Flags: superreview?(vladimir)
Attachment #391150 - Flags: superreview?(vladimir) → superreview+
http://hg.mozilla.org/mozilla-central/rev/e3c9ab74bbdd
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Assignee)

Comment 19

9 years ago
removing blocking nomination - this made it
Flags: blocking1.9.2?
(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 :-(

Updated

9 years ago
Depends on: 528755
Depends on: 529883

Comment 21

9 years ago
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/
Target Milestone: --- → mozilla1.9.2a1

Comment 22

4 years ago
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

3 years ago
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
You need to log in before you can comment on or make changes to this bug.