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.
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>
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?
> 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?
We support urlencoded but nobody would use it when they can use base64.
we might want the for the branch - asking for blocking 1.9.2
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 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.
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.
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?
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.
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.
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?
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"
addressed vlads comments. re-flagging for sr
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+
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
removing blocking nomination - this made it
(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 :-(
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/
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.