Are there any plans to implement animated .PNG, aka .MNG (Multiple-PNG) images? At www.cdrom.com/pub/mng you can find technical details describing this new image format. There is a movement underway to completely replace .GIF images with .PNG images on the web(because of a licensing fee that is asked for .GIF supporting software) but that will only happen if the .PNG format will also support animation.

Reassigning to PNG component owner, Greg.

Is MNG a finalised standard yet?

MNG is a frozen proto-standard; it will not be officially standardized until there are at least a couple of complete implementations available--one often discovers subtle little problems in a spec only by writing the code and testing the thing. Currently there's a fairly complete MNG encoder/decoder available as a Windows-only binary, but I don't think it's an optimizing encoder. There's also full MNG-LC encode/decode support in ImageMagick (i.e., Open Source), which is sufficient to allow fully lossless conversion of animated GIFs with the sole exception of the kind that use the one (very rare) disposal method. The only commercial app with any support is Paint Shop Pro (or Animation Shop, now that it's sort of a separate product), but it hasn't been updated to the current spec and writes an out-of-date MHDR chunk. As for implementing MNG in Mozilla, yes, that's definitely been in the back of my mind as the next obvious step after PNG is working correctly, and I've tried to keep that in mind as I've rewritten bits of the PNG code. But I personally don't have the cycles to do it, and I haven't seen much action on the MNG list, either. That is, there are only three guys on the list who have done *any* real MNG coding (I don't count my own extensions to pngcheck since it's really only a meta-info dumper), and only two of them have released anything. Interested folks really should think about chipping in, perhaps starting with some extensions to libpng to make it more MNG-friendly. (A separate libmng probably isn't necessary or desirable. Feel free to steal from ImageMagick.) Greg P.S. I'm changing the status to ASSIGNED to avoid getting auto-spammed, but don't expect any progress from me for at least 6 months, probably longer. (If a resolution of LATER is preferable, Eli can go ahead and change it to that.)

You have the option of reassigning to nobody@mozilla.org. Adding [HELP WANTED].

Per e-mail from Greg, he has relinquished PNG component ownership; thus, reassigning assigned bugs to ImageLib owner.

Reassigning to nobody@mozilla.org, for anyone who'd like to implement this to pick up.

Assigning all open "nobody@mozilla.org" bugs to "leger@netscape.com" to weed thru.

Moving back to nobody@mozilla.org. This is where the helpwanted will be assigned until someone picks them up.

*** Bug 37986 has been marked as a duplicate of this bug. ***

*** Bug 37986 has been marked as a duplicate of this bug. ***

info from 37986: MNG would be a tremendous addition to Mozilla as it would offer all the features of GIFS with no patent issues. In addition it would allow for true color animated images compressed as a JPEGs. You can find more information at... http://artpacks.acid.org/pub/mng/

Are you volunteering to write the mng component? Great! -P

actually not, I was just adding comments from a dupe. I have no idea where to even start ;)

Updating URL, removing "helpwanted", and taking bug.

tor rocks!

tor is my hero. isn't it done yet? seriously though, this feature is an IE5 killer. Throw a few spiffy MNGs up on popular, anti-microsoft sites, and all their viewers will soon be using the amazing, stupendous, MNG-capable mozilla.

It is done - I'm working on getting it checked in and helping to solve the bugs that prevent full integration (see the dependencies for this bug).

tor: On which platforms have you tested the code? If someone would volunteer to test on wintel and/or mac (and maybe linux if you tested on solaris) would be a huge help. -pn

Personally tested on solaris/sparc and linux/ia32. I have written diffs for the win32 build system, but don't have a system available to attempt a build. Haven't figured out the mac build system enough to attempt to make the necessary changes there. My thought was to get this code checked in behind a --enable-mng configure flag for unix (plus perhaps the win32 changes), then work on getting the other platforms running.

uh. changing the configure files won't affect win or mac either way. We can just not modify the win/mac make scripts to pull in mng. And we don't want to modify the mime sniffer. Really. Not until we know why necko is being stupid about understanding the mime type. Or why the loader isn't finding the decoder component. -P

pnunn, as part of the MNG landing I would like to checkin the attached patch for if.cpp to add mng/jng to sniffout_mimetype(). This allows mozilla to handle MNG/JNG files from servers that don't attach the appropriate mimetype. This patch also reindents the ART chunk to match the rest of the code and includes the gross hack to let the MNG decoder handle two mimetypes (by pretending JNG files are video/x-mng). Along with the unix build system changes I've made the necessary changes to config/config.mak and modules/libimg/makefile.win that should allow mng-capable builds on win32 by setting MOZ_MNG=1. The build system changes have been reviewed by cls.

I don't want the mime sniffer changes checked in. We have to respect what a web server sends. Assuming that we know better what mime type is sent is arrogant and ultimately confusing. If the component loader is not finding the mng decoder, we need to find out what's wrong. Not paste over the problem with 'fixit' code. If you need to test how the component loader is working, reference the mng test file by way of an html page, with an <img> tag. This will assure you the data is routed to the image lib. The mime sniffer is there to override setting that may occur on certain classes of browser images. But if the data stream doesn't match anything in the mime sniffer's list, the component should be loaded with the mime type sent from necko. This is the part that is broken. There should be a way to add a mime mapping with file extension in necko. I'm adding Jud and Gagan to this list so they are aware of the issue. -P

If you say that we should believe what the server tells us, why is the mime sniffer there at all? Currently if I rename a gif file to foo.png, mozilla will ignore the image/png mimetype and feed the stream to the gif decoder. Mozilla should trust that the mimetype and attempt to decode it with the png decoder.

The mime sniffer is there for some of the basic image mime types that are commonly used as part of the browser and browser chrome. It minimizes some of the more common place user error screw ups. But for the browser to be able to have a mechanism to drop in new image format decoder components, we have to trust that some users somewhere have a clue and can create a new mime type mapping. If we police all the data streams, then we should test all data streams in necko just in case they _might be_ image data. And the browser would be so slow it would be unusable. I see these as the basic issues: 1. Where should the user add the mime type mapping to necko? 2. Is the component loading correctly? Is the correct mime type passed through to imglib? Why can't the component be loaded? If we have the answers to these issues and it makes sense to add in a _temporary_ mng signature to the imglib mime sniffer until we can get the correct structures in place in necko, I'd be ok with checking it in. But I don't want to do it, until we have a clear view of what is wrong and how to fix it. -P

ps. I can see cls oking the X config system changes, but can he really test the win changes? I had the impression he is an unix only guy. -P

Since the mng/mngcom subdirectory makefile.win are untested, I'll leave off the win32 build system changes in my checkin and attach them here for the adventurous.

Code checked in along with unix build system changes to add a --enable-mng option. Here are the current limitations (which will drop away as dependent bugs are resolved): MNG files, limited to roughly 256Kb, must be specified inline (i.e. <img src="foo.mng">). For people on win32, hopefully all that's needed is applying the following patch, setting MOZ_MNG=1, and making in modules/libimg. More realistically you'll probably need to tweak modules/libimng/mng{com}/makefile.win. Please try it out and report any successes or patches needed. We could use some help from a MacOS person to get it building there. Index: modules/libimg/makefile.win =================================================================== RCS file: /cvsroot/mozilla/modules/libimg/makefile.win,v retrieving revision 3.6 diff -u -r3.6 makefile.win --- makefile.win 1999/11/06 03:31:07 3.6 +++ makefile.win 2000/06/12 23:40:43 @@ -20,6 +20,10 @@ DEPTH=..\.. -DIRS = public src public_com png pngcom jpgcom gifcom +DIRS = public src public_com png pngcom jpgcom gifcom \ +!if defined(MOZ_MNG) + mng mngcom \ +!endif + $(NULL) !include $(DEPTH)\config\rules.mak

tor: This is Great! I can't wait to play with this... -P

[#whatever pnunn said!]

Most of the thanks should go to Gerard Juyn (gerard@libmng.com), who wrote the excellent libmng and graciously made modifications to the library to ease integration with mozilla.

tor: I'm going to a meeting today to find out who needs to work on user specified mime mapping (like helper apps, but with components.). I will be doing some tests to see where the mime type is 1)not getting set 2)if set, where it is lost. fyi -P

To get libmng to build on Windows, I indeed had to tweak makefile.win.

Copy/paste/modify error on my part - patch checked in. Thanks!

The MNG decoder was turned on by default today on all platforms, and is now in the nightly builds. Give it a try and if you find any bugs other than the current dependencies of this bug please file a bug against me. Thanks.

Gamma correction dosn't seem to work on Windows. Added dependency on bug 44866

Insofar as (1) basic MNG support is enabled on all platforms, (2) basic MNG support works on all platforms (well, Linux and Win32, at least), and (3) MNG gamma correction works (tested with Win32 build 2000072008), this bug should not block 8415--everything necessary for chrome support is in place, as far as I can tell. The only MNG features on Gerard's test suites (http://www.libmng.com/MNGsuite/ and http://www.libmng.com/JNGsuite/) that do NOT work, as far as I can tell, are color correction--either via chromaticity chunks or ICC profiles--and JNG. But neither is a blocker for chrome. Greg

MNG is still not working in chrome. I have finished a new skin for bug 8415, and the MNGs I attempted to use did not work. They are included in the skin for use as a test case. Just modify communicatior/skins/brand.css to test the throbber.

As I said in 8415, MNGs not working in chrome is most likely due to bug 41333.

tor - is there an issue with MNG on Mac still (this is implied by an earlier comment)? If so, does it need fixing by RTM? Gerv

I don't know of any mac-specific problems other than the gamma correction, which affects mac more than other platforms.

*** Bug 66963 has been marked as a duplicate of this bug. ***

MNG support does not appear to work in Build 20010430 Win98. Is anyone else experiencing this problem?

libpr0n (the new image library) does not have a MNG decoder. I have half of such a decoder in my tree - works fine, but leaks all images. I'm planning on getting back to it before 0.9.1.

> libpr0n Ha ha very funny. Now please change it. Political enemies of the organizations that supported libpng/libmng in the first place could have a field day with it. Glenn

Image library name discussion --> bug 66984

randeg: libpr0n is the name of the entire new image library, not just the PNG/MNG part. Besides, it's also called imglib2 (IIRC) if you want to be politically correct. Not sure what you mean by "political enemies of the organizations that supported libpng/libmng". It's an image rendering library, not welfare reform.

> Not sure what you mean by "political enemies of the organizations that > supported libpng/libmng". It's an image rendering library, not welfare reform. enemies: Radio talk show hosts and the like. organizations: Government laboratories support: Tangible support, e.g., web/ftp hosting

The progress of MNG is disgusting (it's literally moving backwards). Adding helpwanted, regression, and *strongly* suggesting for nsbeta1. Many sites out there still credit Netscape 6/Mozilla with having MNG support from the days when it actually *did*. Currently Mozilla doesn't support any animated image format except Unisys' patented GIF89a format.

removing nsbeta1, netscape only

doronr: By your keyword change I am assuming Netscape has fixed MNG for Netscape 6.1. Is this true?

No. He's removing the keywords because they are no longer relevant. tor has MNG in hand; he's waiting for help with building it on Mac and Windows, AIUI. Patience :-) Gerv

Gerv: Please explain to me how nsbeta1 is no longer relevant.

AIUI, nsbeta1 was NS 6.1 PR 1, which has happened. Gerv

My apologies; I was wrong. nsbeta1 is not specific to any release, and no-one except Netscape employees should be removing Netscape keywords. Gerv

IIRC no one removes the nsbeta1 keyword. it is replaced with nsbeta1- if Netscape doesn't feel it is necessary. However, the next nsbeta1 is going to be a while in coming, but at least it'll be there for PDT. :-) "Bugs which have been rejected for consideration in the next Netscape release will have the nsbeta1 keyword replaced with the nsbeta1- keyword." --Keyword Description

Yes, and only @netscape.com should be setting nsbeta1(+|-).

I think until MNG works again, we need to put up a release note that MNG *will not work* with affected versions. This is particularly important since some sites still say that Mozilla supports MNG.

I've seen that there is a directory modules/libpr0n/decoders/mng in the Mozilla Tree - how can I enable the MNG Decoder? Is it working on Win32? If not, what needs to be done?

Should run fine on windows, though personally I haven't tested the new decoder on that platform. To build it cd to modules/libpr0n/decoders/mng and do a make -f makefile.win . Any problems encountered should be reported in bug 66976.

Zach is supposed to be producing the Mac project files for MNG, but he tells me he's too swamped to sort it out. Is this the only thing blocking turning MNG on? Can someone else produce these files? Gerv

I just asked on irc.mozilla.org if anybody would like to create the Mac Project Files for the MNG Decoder, and peterv said he would do it if he had time; I should remind him in a day or two. Couldn't the MNG Decoder turned on on the other platforms while Mac Project Files are missing?

The REQUIRES Line in the Makefile is completely wrong, the following will work. I haven't checked makefile.win, but I assume that it needs the same changes. Index: Makefile.in =================================================================== RCS file: /cvsroot/mozilla/modules/libpr0n/decoders/mng/Makefile.in,v retrieving revision 1.4 diff -u -r1.4 Makefile.in --- Makefile.in 2001/09/18 13:38:03 1.4 +++ Makefile.in 2001/10/01 13:37:11 @@ -32,6 +32,12 @@ REQUIRES = $(MNG_REQUIRES) \ $(JPEG_REQUIRES) \ $(ZLIB_REQUIRES) \ + xpcom \ + necko \ + gfx \ + gfx2 \ + imglib2 \ + timer \ $(NULL) CPPSRCS = nsMNGDecoder.cpp nsMNGFactory.cpp imgContainerMNG.cpp

gerv: mac project files, getting r/sr on the mng decoder, and the minor build tweaks to turn on mng by default are all that's left.

tor: are you chasing r and sr on the decoder at the moment? Gerv

gerv: no - I was waiting until it was built and tested on all tier-1 platforms before trying for a review. A four month old review (when the decoder was ready) would be considered stale.

Should this bug still depend on 41333, now that MNG is on the trunk? Glenn

Probably not. Gerv

Right, but it does need to be fixed. The number of tables that needed to be modified to add a new image mimetype is insane. If Christian hadn't done the hard work of finding all of them for ICO I probably wouldn't have bothered with a full integration of MNG. Since MNG is now turned on everywhere and chromacity correction is somewhat low profile, I'm closing this bug. If you find MNG support bugs, please file them in bugzilla against me.

Verified MNG's working on win XP build 2002032803, linux build 2002040211 and Mac OS X build 2002040203

There is a move afoot to remove MNG/JNG support (See bug #195280), therefore this bug should be reopened. A vote for this bug should be considered a vote against 195280. Glenn

Help still wanted (libmng maintenance/support within imagelib), regression threatened (bug #195280). Not sure if reopening will work, but trying anyway...

I'll work within libmng to explore ways to reduce its footprint. Glenn

Now that bug #195280 has been "FIXED", please change this bug's title from "retain support for MNG ..." to "restore support for MNG ...". Glenn

Reassigning since the bug is currently assiged to the person who CAUSED this bug.

This is just tor's patch for bug 195280 (attachment 117320 [details] [diff] [review]) reversed. It only affects the build system.

This bug has 30 CCs and 39 votes. 50 of either will make this bug block bug 163993.

Give up Mozilla is doomed - at least if they go on removing good an interesting features like this.

Tim: I'd be interested in seeing an alternate patch that puts MNG/JNG support in the extensions instead of back in libimg2.

Removing MNG saved what, 300kb on my 40+ GB drive? Whoop-de-doo!

Re: comment 81, I'd love to, but build config changes are out of my ballpark ("my" patch was just running tor's patch through a reversing program).

Here is a zip containing the old files in a new location (extensions/mng). I fixed the depth in Makefile.in, which is the only change at all in any of the files. --- modules/libpr0n/decoders/mng/Makefile.in 2003-01-30 00:53:12.000000000 -0500 +++ extensions/mng/Makefile.in 2003-06-04 10:53:52.000000000 -0400 @@ -17,7 +17,7 @@ # Contributor(s): # Tim Rowley <tor@cs.brown.edu> -DEPTH = ../../../.. +DEPTH = ../.. topsrcdir = @top_srcdir@ srcdir = @srcdir@ VPATH = @srcdir@ I don't know what changes would need to be made to other parts of the build system (probably the extensions/Makefile.in file and maybe the configure.in file).

An XPI for MNG support is available at http://stud4.tuwien.ac.at/~e0225227/. Versions for Linux and windows can be found there. other operating systems may follow.

Tim wrote: > Created an attachment (id=124907) > Relocate old MNG decoder files > Here is a zip containing the old files in a new location > (extensions/mng). Moving MNG support to extensions/mng/ may not be a good solution since much of the stuff in extensions/ is not part of the default build and/or will be explicitly turned-off by some vendors if there is a way to do so (bug 133534 is one example how things can go really worse... ;-( ).

Is there an existing architecture to make image decoders pluggable and/or in-/excludeable at build time? If not, we should put one in place right now, as we apparently have the need for that.

kairo: we have both. at compile time, there's --enable-image-decoders (iirc); and at a later time, you can just drop in a component (well almost, but it works quite good).

mozilla/extensions exists so that vendors/embedors/distributors/whoever can disable things that they don't need, which is exactly the case for MNG as well as many other things in mozilla (including .bmp and .ico). Why would Crocodile Clips need to include the code for MNG decoding in their software for teaching math? Or why should ACME-Handhelds need to include a xprint in their handheld browser? The answer is obviously that they don't. If someone doesn't want to ship with a certain part of the browser we should not force them to. That will only cause distributors to choose other browsers. So the fix for this bug is to find someone who is willing to own MNG (which it looks like Glenn is), and then place it in mozilla/extensions

So why do we have to move it to extensions and not use --enable-image-decoders for enabling/disabling? I think it would keep a clearer structure. Anyway, it's good to see MNG support being at least optional, if not enabled by default, again.

i just stumbled about this occasionally... but i'd like to see the return, too. especially since merging MNG into libimg2 and removing redundant code (PNG) would be more than acceptable in my opinion. there's nothing more beatiful than 8bit transparency. and as said in bug 195280 gerald would volunteer to maintain this. but well. should we carry this discussion over to mozillazine? maybe this way more people would get to know about this. and help to solve the issue.

> Moving MNG support to extensions/mng/ may not be a good solution Leaving it where it was is of course a better solution, but the module owner doesn't want it there and has already removed it. Putting it in extensions/ is a stopgap measure. >So the fix for this bug is to find someone who is willing to own MNG >(which it looks like Glenn is), and then place it in mozilla/extensions Yes I am willing, although I don't seem to be empowered to mark the bug ASSIGNED. I will need to rely on those who are "empowered" to help out. Glenn

If you want the permissions to modify/confirm a bug you just need to shoot an e-mail to <gerv@mozilla.org>.

I don't think this bug should depend on bug 44866. That's color-correction stuff that's far from being implemented anywhere in Moz AFAIK.

Will help where I can, but I've no experience with graphics.

Just so these XPIs are as available as bugzilla is, here is a zip of the web page and XPIs mentioned in comment 85. This is split into four files since the max size is 300K. You only need the one for your platform.

Please let's stop crippling away important Mozilla features to make it more like Internet Explorer. Mozilla was meant to be much more than a simple browser. Mozilla paved the way for the best support of PNG graphics in the industry. It will pave the way for JNG and MNG as well. I've juste added my vote here. 151st one. Keep up the good work, gang. - Jacques

Since Glenn is taking care of moving the MNG support to extensions/mng/, why not restore the old imgmng module until the Glenn's MNG extension is finished? I am trying to understand why you want to remove the former native MNG support, but I cannot understand why it must be removed *now*, and cripple some of the upcoming Mozilla releases! Cosmin

I've just placed a comparison of the Firebird Throbber.mng from before the MNG removal, an optimized version of it, and the GIF version that was recently provided to the Firebird crew, in bug #125280 comment #100 along with a copy of the optimized MNG throbber. I used Greg Roelofs' "pngquant" and some of my own tools to reduce the filesize from 24kbytes to under 4kbytes without any effect on its appearance. The GIF is over 8kbytes. Judge for yourself how it looks against the black background. I suppose it could be optimized too but I don't have anything that writes compressed GIFs.

The throbber demo is in bug #195280 comment 100. Sorry about the typo. Note that the comparison is in static PNG format, not MNG, for the benefit of those who are using a MNG-hobbled browser.

I dont want a browser without MNG support. I DONT WANT GIF/flash copyright images/animations!!!!!! I think that MNG can find a manteiner if reeintroduced.

I concur with some other posts above, adding that the *final candidate* stage is not when this kinds of surgery should take place! That's quite ridiculous.

I concur with some other posts above, adding that the *final candidate* stage is not when this kinds of surgery should take place! That's quite ridiculous.

It's only been removed on the trunk not the branch

Support for MNG should most definitely be restored to Mozilla. Firstly it is the only way a web site using open standards can implement animation. Secondly, with the native implementation (rather than plugin) provided by Mozilla one can insert an animation as easily as inserting an image, which avoids all the embed/object pain when trying to support XHTML. Thirdly, a big vote of thanks to the MNG/PNG team, who have made a big contribution to the future interoperability of the web. Oh - and fourthly - I'll have to find another reference browser as I use quite a few mings on my site...

As many, many people here, I'm all for restoring the MNG plugin. Even after reading the developers' reasons, I fail to understand why they removed something that was usable. Here's my vote.

Please put it back into the build. As someone stated before. NO PATENT ISSUES with this format.

People, don't add useless comments like 'ooooh, this has to get back in', that will NOT help. Just vote for the bug, help with development, make a strong case with reasons why MNG should be included again. It's a lot better to post nothing than to post something like 'you NEED to add this again' :\ Just vote and then either wait or help. And please read the Bugzilla docs :D

I believe this bug now has more votes than any other bug ever. At 402 votes, it's passed the PGP RFE. And it got most of them in about 9 days. FWIW, I'm developing a bioinformatics tool that was to use MNG for genome mutation visualization. Things like that aren't ever going to show up on an image search because they're generated dynamically. Does drivers have an official stance on this issue?

The same question has been nagging me but I've been hesitant to ask it: at what point are the votes important?

Have a look at http://www.mozillazine.org/talkback.html?article=2702&message=21 for Asa Dotzler's take on votes vs action. To summarize, votes aren't taken into account at all in and of themselves, if Netscape decide to work on any RFE, they will typically work on the ones with more votes first. Votes on groups of bugs along the lines of 'implement this feature'/'don't implement this feature' (such as this one and its friend) typically aren't worth the paper they're printed on.

Lewis: All of your statements are valid and _do_ apply to a bug where there is some work to be done. However, this is not such a bug. This is a simple management decision. There is no work involved in 'fixing' this bug. I realize that there is no method by which people may vote against this bug but perhaps the sheer quantity of attention to this bug prompts further exploration, yes? And if indeed our votes "aren't worth the paper they're printed on", you just insulted 400 voters. So which is it? Should I keep my vote here more move it to a bug "worth something"? Perhaps a poll at mozillazine would provide a more representative sample of the Mozilla user base's opinion?

Sure you can vote against this bug. To do so, vote for bug #195280.

Amusingly, bug 195280 has *lost* votes. I believe it had 2. Now 1. Could be because it was "fixed" I suppose.

Jason: these are not my opinions, but a summary of those found at http://www.mozillazine.org/talkback.html?article=2702&message=21 . I suggest you go and read the whole posting, especially the third paragraph ("Even if you just look at Bugzilla account holders as a representative sample of end-users (I dispute this heavily but for the sake of argument we can discuss it) then you've still got less than 1/2 of 1% of Bugzilla users voting for a particular feature or bugfix").

> There is no work involved in 'fixing' this bug. This is untrue. There is a lot of work, in particular, someone has to own the MNG code, fixing bugs as they are found, maintaining the code in the face of a changing Gecko, and working on MNG's significant memory and disk footprint. (I believe there is a volunteer at the moment, I'm just pointing out that this is still a lot of work.)

Yes, this bug has currently the largest number of votes in Bugzilla: http://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=200&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&remaction=run&namedcmd=QAWanted%20for%20last%2010%20days&field0-0-0=noop&type0-0-0=noop&value0-0-0=&order=bugs.votes,bugs.bug_id

I had a discussion with pavlov about this yesterday. He doesn't care about votes AT ALL: "<stuartk> heikki: if i see like 250k votes, that might be signifigant" (he got flamed a lot for that, even by other developers, as those numbers are idiotic and can never be reached) It's still more interesting to discuss the arguments against MNG: 1) filesize - this got reduced by around 50%, maybe more. 2) GIF and Flash cover this - flash is closed source, about GIF we only need to see the new throbber on a dark background, how good this is covered. 3) little used - there is only few use for animated images at all, as you also see only few ani-GIFs. As MNG isn't supported in MSIE for now, 2% of all animaged images would mean it's more successfull, than Mozilla is ;). Also we have comments, that it IS used. 4) W3C - just see comment #3 here.

>> There is no work involved in 'fixing' this bug. >This is untrue. There is a lot of work, in particular, someone has to own the >MNG code Fixing this bug simply requires reversing the patch which removed the support - that is not a lot of work. Whether it's a good idea to have un-owned code in the tree (or even in the build) is another question, but AIUI, there's quite a bit of it around. and even if there is a maintainer, that's only part of the reason it was removed - another reason was that there is virtually no usage of MNG on the web. > Yes, this bug has currently the largest number of votes in Bugzilla > [huge query string] that, in itself, doesn't change anything. PGP (now pushed down to second place) has had several hundred votes for a couple of years, and nobody is doing anything about that. and if you must post query URLs, there's a bookmarklet which shortens them to something reasonable at http://www.squarefree.com/bookmarklets/mozilla.html

>PGP (now pushed down to second place) has had several hundred votes >for a couple of years, and nobody is doing anything about that. The difference is that MNG *was* supported in Mozilla since DEC-2001 and then was suddenly removed.

Well, now that we know that votes on this bug are completely disregarded (per comment #121), I'm moving my vote from here to bug #204520 which is where the work on getting MNG's footprint reduced is occuring. And Mr. Developer: in the future, please don't tell us to shut up and "just vote" for something when -- in fact -- you don't care. You just wasted a whole lot of our time and insulted us, to boot.

Look. People working on the Mozilla codebase can only act this way because the rest of the Bugzilla community allows it. If people staged some sort of strike and refused to do anything on Bugzilla (like confirm bugs, verify, develop testcases, etc.) that might have some sort of effect. If they don't listen to the votes, then force'em to.

> If they don't listen to the votes, then force'em to. from Bugzilla Etiquette (http://bugzilla.mozilla.org/page.cgi?id=etiquette.html): No obligation. "Open Source" is not the same as "the developers must do my bidding." The only person who has any obligation to fix the bugs you want fixed is you. Never act as if you expect someone to fix a bug by a particular date or release. This is merely obnoxious, and is likely to get the bug ignored.

but you can't force anybody to help an app, which moves into the wrong direction. And this happenes here, if the community (!= all users!) are totally ignored.

There are many people who work on the Mozilla Project in a capacity other than as coder. We do all kinds of things to free the coders' time up to do coding. If we are going to do that work so that they can code, they could at least have some deference to that instead of sending us a collective "bite me". I don't think it bad ettiquette to say, "if you don't do the work we want, we aren't going to do your grunt work anymore."

**** people off is never a good strategy. You can catch more flies with honey than vinegar. Let this bug simmer for a while. Posting "me too" comments (kind of like this one :-) only spam everyone who has voted for this bug and fill up mailboxes making more people apt to unvote/unCC themselves. And remember, at the end of the day, it's just a web browser, and it's just a file format.

I think the reality is that tough decisions do have to be made and in this instance, one has already been made. The comment that votes are irrelevant was probably not communicated in the most diplomatic way.... for the most part I'm sure it is true, otherwise in cases such as this we'd always wind up having to bow to demands. It is a tough decision. I think the point being made was that decisions are made and votes won't change that. The votes are merely to aid the order in which bugs are fixed. All that said, I don't think it hurts for people to vote if they really believe in something such as this. But no one should expect that 1000, or 10,000 votes or whatever means the decision will be reversed. But if you believe in this and you vote for it then in reality is must have a slight effect on future decisions. And thats democrasy (even if I can't spell it!). Myself, I would like to see this feature in place - it does seem like a Good Thing(TM), but the people making the final decisions know this. They are aware. They do understand. They do care. Unless I can commit the time to doing the development myself, then I can't really complain; people do what they can to aid the common cause. If anyone is sooo upset about this decision, then be proactive in trying to reverse it - don't start wars!! Peace and love everyone! Have a great weekend. ;)

I am working with the imglib maintainers on defining a set of criteria that they want to be met in order to get MNG back in. As soon as they are agreed, I'll let everyone know what they are. In the mean time, please continue to vote for this bug if you so wish. Gerv

Thanks Gerv, it's really good to see someone @mozilla.org taking care of getting this discussion in a good shape. Please cqare to take a look that the creteria can really be met, so we don't get "you must have 250k votes" or something like that. Again, thanks for steppoing up and trying to get that discussion and work back to some use again. <thought mode="crazy">My theory grows to be that pavlov wants MNG to be broadly supported and well-supported, so he tries to make tons of people upset about the topic, so that they all do really care of what's happening in the future and start using MNG for almost everything, as soon as it's supported again</thought>

Just an additional argument for keeping it: I read on German IT newschannels that there is an ongoing patent issue with the JPEG format. Not very definitive yet, but maybe the future will bring us bad news. So having an additional open format at hand could be a big advantage, even if it is not widely spread yet. Maybe that could also be a reason to begin to ACTIVELY spread it now.

For the love of god people, this isn't a forum! Shows of moral support, "that's great," personal attacks, and "me too" posts have no place here. As this is a codebase steering issue, and not an actual bug (intended functionality, or lack thereof is not a bug) the arguments for and against bringing back MNG may have been warented, but only when the arguments made were contruvite and helpful. I don't think it's really impossible to argue for MNG to be reimplemented without breaking the rules in the Bugzilla Etiquette. That means no pointless comments, no trying to FORCE the developers to do what you want, and NO personal attacks. The nastiness out of some parties is really just getting inappropriate for a software development bug tracker. I believe "Hey, something's being done? I think that's great" is also not appropriate. That being said, I want MNG back in the codebase, but if the developers can't agree to do it, there's only three things you can do. You can find another browser, create a set of patches against the trunk which re-adds the functionality, and release your own binaries, or if there really are enough people disatisfied with how this was handled with coding skill and time to maintain such a massive project, as is open source tradition, you can always fork the codebase. I hope it doesn't come to that last option, but it's always a possibility, and in someways, it could also be interesting, assuming enough developers could be found to maintain both Mozilla and the forked project. Anyway, useless comments down to a minimum, please? Not everyone likes waking up to 15 e-mails in their mailbox. Oh, and before anyone else posts something to the last post which I just got in my e-mail, I'm not really sure what JPEG has to do with MNG. JPEG is a lossy static image format, and MNG is an animation format for PNG, which is loss-less. The two are about as unrelated in usage as possible for raster image formats capiable of 24-bit colour. True JPEG can be hacked to do animation in Mozilla, but I haven't really seen it used outside of streaming webcam software, which uses a Java App for IE, in years, because IE, and many other JPEG renderers do not support animated JPEGs.

<offtopic>I'm sorry for this spam upfront, but if I don't say it on here, somebody will. Notice this bug includes JNG which is the JPEG Network Graphics format, which is basically JPEG-in-MNG. So before adding more spam to everybody's mailbox complaining about complaining, get the simple facts straight. Though I do agree that that post did in fact have nothing to do with this bug (if JPEGs are in trouble, then so is JNG, another issue altogether).</offtopic> Thanks for responding, Gerv; glad to know actual progress is being made. NOBODY ELSE NEEDS TO COMMENT HERE UNTIL GERV GETS BACK TO US.

Setting blocking1.4- as MNG suppport has not been removed from the 1.4 branch and thus will be in 1.4 final.

The MNG decoder is 300k? Oh lord please tell me it isn't 300k! I mean I only have a 70gig drive here people, you all act like this is the 21st century or something, sheesh. And talk about that memory footprint, I need to conserve my 512megs of RAM to make sure AIM runs smoothly and none of that 300k bloat taking up all my RAM. *rolls eyes*

Since bugzilla isn't letting me vote without comment, I'm just stating that I'm voting to change resolution to FIXED to support the MNG/PNG format. Good luck to all involved in getting it reinstated into the Moz trunk.

See bug 209439 - "Need ability to find 3rd-party extensions through .xpi". Perhaps if this were available as a toolkit-level addon, it wouldn't need to be distributed with Mozilla and could be downloaded into the GRE on demand. Of course, this means nothing for the XPFE version of Mozilla as long as we carry it. Tux: The size is not an issue for hard drive space, but for download time.

>Perhaps if this were available as a toolkit-level addon, hm? What do you mean with toolkit-level addon? > it wouldn't need to be >distributed with Mozilla and could be downloaded into the GRE on demand. currently, you can't install extensions into the GRE, and it looks like that's as intented, as written in another bug. > Of >course, this means nothing for the XPFE version of Mozilla as long as we carry it. ? the xpfe version of mozilla does not currently include the mng decoder however, my xpi should work for all versions of gecko.

> currently, you can't install extensions into the GRE, and it looks like that's > as intented, as written in another bug. biesi: see bug 209439 (which really needs a better description)... I am working on a mechanism that will allow "GRE extensions"... there is a whole dependency tree to accomplish before this become reality, but it will happen. > Of >course, this means nothing for the XPFE version of Mozilla as long as we carry The XPFE mozilla uses the GRE just like Phoenix does...

Nice. Perfect. Just when I started to use MNG. Thanks a lot guys. Is there a way to get that xpi working in Mozilla Firebird?

It seems likely that when MNG is restored to the trunk, it will be in a degraded form that doesn't handle 16-bit samples or Delta-PNG datastreams. If so, is there a way to use an XPI to regain full MNG capability? Note that it would be possible to regain full MNG capability by building with the system libmng instead of the embedded one, but I think only a small minority of users will want to do that or even be capable of it.

Why only degraded lib? How much size does it save?

It's a tradeoff of size versus removal of features. The specific amount saved is platform-dependent. For specifics, after Gerv gets back to us, see bug #204520. But rest assured that Gerard and I are making pretty good progress.

The XPI should work just fine in Firebird; though I haven't tested it. does it not work?

It is claimed in mozillazine "Fb" forum, near the end of the thread on MNG/JNG removal, that it does not work with Firebird.

In my personal opinion, it is a good idea to drop the 16-bit support since only 8 bits are rendered anyway, but it is not a good idea to drop Delta-PNG. Notwithstanding the portability of MNG files, Delta-PNG is one of the key features of MNG, that can make a big difference in compression, compared to GIF. I also wish to make a suggestion: since efforts are concentrating towards reducing the libmng footprint, isn't it possible to redirect some of these efforts towards replacing the entire libpng with libmng, for PNG rendering? I understood that libpng is older and more reliable -- which means that more efforts should be concentrated around more libmng testing. What else would be required? I am not asking people to do extra things (which may look bad, considering that I am not doing anything myself); I am only suggesting to spend the efforts in a different direction.

I'll answer comment #148 in bug #204520. Please continue the thread over there.

as for using libmng for png images, see bug 48893

------- Additional Comment #131 From Gervase Markham 2003-06-13 09:22 ------- I am working with the imglib maintainers on defining a set of criteria that they want to be met in order to get MNG back in. As soon as they are agreed, I'll let everyone know what they are. It has been two-and-a-half weeks and I've heard nothing on the maintainers' (most of whom have e-mails ending in @netscape.com) demands for reinstating the MNG format. However we have many contributors that could become MNG maintainers and very good progress has already been made in reducing the file size. I believe there is an effort underfoot to remove MNG without valid reason.

I have, as yet, had no reply from one of the imglib maintainers who needs to sign off on the criteria under discussion. Gerv

well, what about this guy: http://www.cs.waikato.ac.nz/~singlis/ kinda cute, imo. what do you think about the software. He mentioned scanners, i am overly fond of scanners; so maybe i am too biased.

Which maintainer isn't replying? I find it ironic that part of the reason MNG was removed by the imglib staff is because of the lack of an active maintainer, when... well, you know.

ImageLib maintainers, according to http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser Owner: jdunn@netscape.com; QA contact: tpreston@netscape.com ImageLib has maintainers. The MNG part didn't.

I've checked a "slimmer libmng" in to libmng's CVS. For details see bug #204520 comment #56. Hopefully this will provide sufficient information to the powers-that-be to help them decide how much reduction is required.

Damian, skewer: the maintainer in question is Stuart Parmenter (pavlov), not one of those you name. Gerv

I just looked over the recent developments here, and here is a summary. Please correct me if I'm wrong. * This bug has over 500 votes. It is by /far/ the most voted-on bug in Bugzilla, ever. * Glenn has been waiting on comment 21 in bug 204520 for a month and a half with no response outside of a outrageous request from IRC. That is to say, nobody has formally set a target size for libmng despite requests. * The original complainer and the person who checked in this bug to the trunk (tor@acm.org), who I suppose is the proper authority regarding comment 21, has not commented in any of these bugs since early June AFAICT. I would therefore believe that the original complaint is dead, and the want for MNG support is very high, so there is no reason why libmng-1.0.6 should not be checked into the trunk immediately when it is released. Looking forward to the day when bug 195280 is marked WONTFIX.

Gerv: I wonder if pavlov will (wants to) stay a module owner in the now-different situation (employer)... Additionally, I believe we should have some better organization of module owner issues - but I'll take that to npm.seamonkey

> Gerv: I wonder if pavlov will (wants to) stay a module owner in the > now-different situation (employer)... That's something you'll have to ask him. :-) Gerv

Don't think I'm going anywhere. Remember, I was working on Mozilla well before I started at Netscape ;)

And would you have the time and be so kind to answer some of the questions that have been asked, regarding the validity of reasons behind removing MNG support, and what would be required to re-instate it? Eg. are 518 registered bugzilla voters an indication of more wide-spread use than assumed? What reasonable size-reduction would be required to consider it a useful addition to Mozilla rather than a bloat?

I'm still here, too. I was working on Mosaic-2.4.1 (see changelog) before Netscape had been heard of by the general populace, and before PNG/MNG were invented. Current situation with MNG reduction, on a particular platform (FreeBSD/gcc-3.2.1) is about 179k: 62k removal of redundant and unused functions in libmng, 50k removal of unused functions in libpng, 17k removal of 16-bit sample support in libmng, and about 50k merging libmng and libimg2 to avoid storing two copies of the jpeg library, as demonstrated by tor. IMHO that is enough. How about putting MNG back on the trunk now? Additional 7k could be obtained by removing Delta-PNG support but I don't recommend that, and about 13k by removing JNG support but I don't recomend that either.

And as usual, we get no response... Stuart, is it just me and Glenn, or are you this plain rude to everyone with a fleeting interest in PNG/MNG/JNG? It's not like we're asking you to solve the mysteries of the universe or something...

"Stuart Parmenter" pavlov@pavlov.net was the strongest supporter of removing MNG without justification. I don't think his opinion is valid in this issue.

FYI: If pavlov could provide some definite requirements for his supporting MNG's return, and the full imagelib crew agrees with those requirements, I would be more inclined to respect his opinion on this matter. But he personally backed and approved the removal of MNG without a single word about why, and now that he's the only person who needs to say anything, he's filibustering the whole operation and still has provided NO REASON why he would want MNG removed. This is an insult to thousands of Mozilla users and a direct insult to 520 Bugzilla users who are voting for this bug. Things need to change here.

What's this, Bugzilla invasion of the trolls? Gerard, ever thought that maybe Stuart doesn't spend his time 24/7 in front of the computer, trying to solve what *you* think is an important issue? Skewer: Find a new place to troll. Thanks!

trusted2mozilla.org@slater.ch please take your bugspam elsewhere, thanks

Mark: Umm... since you weren't paying attention, Stuart has neglected to give a response for over a month now. It doesn't require being on a computer 24/7 to say something in that time. Also, he responded to the inquiry as to whether he would continue to be the module owner just the other day, without saying one thing about requirements for reimplentation of MNG. So the impatience is quite justified.

skewer: pavlov is the imglib module owner (last time I looked), so his opinion is very much valid. Mark: gerard (with Greg) is one of the people who has been working hard on MNG over the past few weeks, so his frustration is perfectly understandable. Can we calm down a bit here, please? Gerv

For those who have misinterpreted my statement "IMHO that is enough", that means in my humble opinion it is enough to warrant checking MNG back into the trunk, not that I intend to quit working on it. I am committed to continuing to reduce the size of libimg/libmng unless I find out for sure that it is a fruitless exercise.

skewer: pavlov is the imglib module owner (last time I looked), so his opinion is very much valid. Gerv: And Bush is the U.S. President. That doesn't mean he knows what he's doing or belongs there. What argument is there not to remove GIF because of the Unisys patent issues or because there is a viable alternative available (PNG, MNG)? In fact, why not remove XML, how often is it you run into a webpage that uses XML?

Skewer: Let's see how did you put it . . oh yea "please take your political- spam somewhere else please, thanks."

skewer: Your political commentary was completely off-base. However in light of the work done and improvements made of late, it does seem like someone very much doesn't want to concede that they might have made a mistake when deciding to remove libmng indefinitely.

I lost my patience for a moment and I apologize. Even if it's pretty obvious why. I certainly didn't want to star a flamewar, so let's all stay civilized and work towards a solution. Ranting doesn't work! And Mark, I *don't* think it's important, in fact, I couldn't give a hoots **** at the moment whether MNG comes back or not. There are a lot more interesting things happening in my life right now. But don't read that to mean that I'm not interested. libmng has been my pet project for 4 years and will remain so for some time to come, and I'll work with anyone that *works* with me!!! Just to recap for those that do not want to go through the entire backlog. Here's the status on the original reasoning behind the removal: > * mng decoder module is roughly the same size as all the other > image decoders and libpr0n logic combined. > Linux sizes: > 261796 libimglib2.so > 241492 libimgmng.so > MS-Windows sizes: > 155024 imglib2.dll > 170336 imgmng.dll From bug 204520 comment 60: MOZILLA_1_4_BRANCH libmng: 189K tip libmng-devel/mozlibmngconf.h: 112K That's a 77K (40%) size-reduction in the bare decoder. Looks to me like Glenn has already done an incredible job towards reducing the size. Also 50K were saved from the libpng implementation, another 50K could be saved by removing the duplicate JPEG code. Also the optimized MNG throbbers for Firebird are a fair bit smaller than their GIF-makeovers (bug 195280 comment 100). And we still have more ideas on how to decrease the size of libmng further. But neither of us is going to spend a lot of time working in the dark. If pav can be se kind to answer our question on what size-reduction is required, at least we'll know what we're working against. And I mean a real number, not some off the top of the head figure akin to impossibility. A valiant module-owner wouldn't hesitate to answer such simple mathematics. I don't mind if there are more personal reasons behind keeping MNG out of the tree, but at least come out and say so. I've been down such paths myself a couple of times, but believe me, the ostrich-way really doesn't pay off. > * mozilla integration is rather rough, partly due to a necko bug > (possibly fixed by darin's recent async changes) and partly > due to the lack of active, interested maintainers. There is still no active maintainer. The most obvious person at this point (Glenn) has been turned down. The fact remains that the new maintainer wouldn't actually need much knowledge of the MNG library itself, since he/she will have Glenn and me for the full 200% behind him/her to solve any issues relating to the MNG decoder. Maintenance would therefor be more of an administrative task then real grunt-work. If we would have had a bit of co-operation from the module-owner, I would have spent a lot more effort in squashing the currently outstanding bugs against MNG. > * animated gifs and flash (and possibly svg in the future) cover > much of the feature set of mng. jng is a bit more interesting, > but not in ways that most people will care about. > > * the formats are not w3c recommended. As many people have stated this isn't much of an argument. Have a look at bug 195280 comment 100 and see if MNG isn't a tat superior to animated-GIF. And AFAIK themes can't use flash. Other arguments against this point are that MNG is an open standard, not proprietary or flee-ridden with patents, it's a lot more sophisticated than simple 8-bit paletted image-streams, can achieve better compression than GIF, and can be run transparently against the background. You can only achieve that with Flash if you design the whole page in Flash, which makes it rather impossible to maintain. > * the formats are little used in the wild. 500+ registered bugzilla voters think not. The Firebird crew and many other theme-authors didn't think so. And what kind of thorough investigation has been done to support this point? MNG usage is growing thanks to Mozilla! Let's keep it that way. You've got a great product. And as many people stated before, Mozilla is an open-source platform that gives new emerging technologies a foothold to gain the status they deserve. *Mozilla* makes the difference, not IE!!! Gerard

I don't think anyone caught my point, they were too busy accusing me of trolling or spamming, so I'll put it simply: The reason this bug, bug 18574, is not currently FIXED, is because <pavlov@netscape.com> (anyone wonder why I prefer to refer to THAT e-mail?) and only pavlov is not providing the criteria which would allow MNG to be checked back in. Since he is the imglib owner he has the authority to stop MNG from being included in Mozilla for absolutely no reason at all. That's exactly what is happening--no reason at all is being given for its current exclusion from Mozilla. The size has been reduced more than it needed to be (the additional size of a typical Flash or GIF animation compared to an optimized MNG is more than the difference in the code made by removing the libmng library). Lack of widespread usage might be a valid reason to remove something like this from IE, but this is Mozilla, and there are plenty of little-used standards that are being included because they're good, not because they're popular; for example, CSS3. W3C recommendation isn't a valid reason, because bug 3744 is based on the "GNKSA" guidelines some kid made up. Just about any reason for stopping MNG can also by stymied by the fact that we even include MARQUEE support in Mozilla. Overall this MNG removal thing is something that never should have happened. Am I right?

This is a question based on my understanding of the processes put in place by the mozilla organization, and as such, may be based entirely on a misunderstanding. But as I understood it, all module owners are answerable to drivers, and if a particular module owner is not doing an adequate job, the drivers can investigate the issue and come up with a solution including anything from "allow this bug to be checked in, regardless of what the owner says" up to and including revoking the person's ownership position. To be clear: I am NOT suggesting that pavlov should be removed from imglib ownership. However, I *do* think that he has failed to carry out his duty as module ownership in this case: that duty would certainly include providing a timely response to an entirely reasonable question like this. As such, doesn't the normal mozilla process say that the appropriate action now would be to contact drivers? Gerv, as the person who's taken the lead on bringing this to a diplomatic solution, what's your take on the current situation? Do you feel that the delay in getting a response is still reasonable? If so, how much longer until it becomes unreasonable, and am I right about the correct action to take in that case? (I'm not trying to propose an ultimatum or anything like that, but *some* kind of limit to how long this bug is going to sit in limbo would be appreciated by everyone involved, I think)

> Gerv, as the person who's taken the lead on bringing this to a diplomatic > solution, what's your take on the current situation? Your understanding of mozilla.org process is correct. It is up to individuals to decide when and if to escalate a particular issue to drivers, and if they are the most appropriate person to escalate that issue. Those who are considering this course of action may do well to contact Gerard or Greg, as they are the people currently hacking on MNG. Gerv

Gerv, It's Glenn and me, but mostly Glenn doing the hacking. Greg's our punchball in the back. We'll be getting in touch with drivers some time this week. Just deciding who's doing the writing...

Sorry, guys - all your names begin with G, and I get confused :-) Gerv

> there are plenty of little-used standards that are being included because > they're good, not because they're popular; for example, CSS3 HMMMPPPFFFF.....

I know, this bug gets spammed out to over half a thousand people now, but I just wanted to link to this little project: http://sgs1.brinkster.net/gserver/ I got it off of this MNG site: http://www.doc.cs.univ-paris8.fr/mirrors/mng/mngaped.html What I find interesting about something like this is it is a quick easy browser-based alternative to VNC (yes, there are VNC Java Applets, but nonetheless). I recommended it to my boss, who has been looking for something like this. If he starts using it, I imagine he'll be either looking to install Netscape/Mozilla on remote computers, or the IE MNG plugin. Even more then a website, a browser based application they depend on is something people might go out of their way to install Mozilla for. Especially if they were used to using it for this reason on their home/work computers. Of course, if MNG becomes a plugin, then people would probably just use the IE plugin. No difference, after all. Similar reasoning applies to intranets. Indifferently supported web standards often get a toe-hold there as well. Just one more reason along with MNG in the classroom (Mozilla as default install on a college network is another source of evangelism), and MNG throbbers, as well as the amazing difference between a 20k translucent JNG and the 200k PNG that would be needed for same effect. Ok. My one and only bug post on the subject :)

pavlov: I wanted to watch my favorite pr0n clip with current Mozilla, but I failed to see it. I'm confused now, as as http://libpr0n.com/faq.html says it should support it's MNG format. Either your webpage is wrong, or Mozilla doesn't qualify for a good pr0n browser, as animated goatpr0n comes best in MNG format.

Pavlov had nothing to do with that web site. See bug#66984 comment#6.

I tried to install the mng extension from the firebird extension website and it didn't work (I verified this by trying the bugzilla testcase on the top of this site http://bugzilla.mozilla.org/attachment.cgi?id=124879&action=view ). The installation failed with 0.6.1 official (=final) build and the latest nightlies {current one is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030731 Mozilla Firebird/0.6.1}. having restarted the first time after the extension installation, firebird gave me an error : "the application couldn't be started because mozz.dll couldn't be found". firebird started anyway and after the next restart the error msg was gone, but mng animations didn't display. so there isn't native mng support anymore nor a working extension. see: http://forums.mozillazine.org/viewtopic.php?p=133923#133923

I hate to reply with this many cc's, but leaving the previous comment without a response helps nothing. bernd, the extension in question has issues on Firebird Windows, but works on Seamonkey Windows and both products under Linux (apparently), at least based on that and other threads. mozz.dll does not exist under Firebird, so the extension isn't really compatible. Maybe the extension author should update it, who knows whether he's interested still. If MNG is that important in the short term, use Mozilla Navigator with the extension or use Linux.

I opened bug #214737 for discussion of the MNG XPI problem.

Updating dependancy tree, removing duplicates and putting bugs they are duplicated to.

I'd wanted to nominate this bug as a blocker for version 1.5, just because I can't think of a normal (non-alpha, non-beta) version of Mozilla without MNG support. But because this is not possible (yet) I'd nominate this as an 1.5beta blocker. One of the main reasons of the removal of the support was the size of the decoder, in the other comments of this bug is alreday stated that there can be more size/footprint winnings when converting the (animated) GIF's in the chrome to MNG. So if we are concerned about the reduction of the size we should do that (too). BTW: There is no need in blocking 1.4.x, because the branch for 1.4 was cut before MNG support was removed from Mozilla.

Maybe the person who removed the "blocking1.5b" flag could leave a comment to explain why they did so?

Only drivers should set blocking+ flags. If you wish to nominate a bug for blocking status, set the blocking? flag.

I'll take the leap here and set that.

Re: comment #186 and comment #187; the MNG extension is working now with Firebird. See http://quicktools.mozdev.org/mngsupport/ which is based on the attachment #125114 [details], above, plus mozz.dll and some Windows registration settings.

Asa, could you please explain why you removed blocking1.5b for this bug when it is the most voted-on bug in all Bugzilla and can be easily fixed?

referring to #193: sorry glenn, this new xpi didn't fix my problem either. steps I did: 1) installed the "complete MNG Support for FireBird (mng-windows-fb.xpi) extension package" 2) restarted firebird 3) tried testcases -> all testcases failed 4) checked "extensions" in "options" -> no extension was installed 5) executed mng.reg manually as instructed on the site you mentioned 6) made sure mozz.dll was in the firebird folder 7) installed "MNG Decoder for Windows (92 KB Download)" from http://stud4.tuwien.ac.at/~e0225227/ (the "original Extension page") 8) tried testcases -> all testcases failed Conclusion: still no mng firebird support on windows. tried with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030808 Mozilla Firebird/0.6.1+

Please continue discussion of XPI in MozillaZine->Firebird forum: http://forums.mozillazine.org/viewtopic.php?p=145184#145184

Since I know Asa doesn't get bugmail for most/all changes: #194, look at the link in comment 114 as to why votes don't always equal action. And just to clarify for those who tried adding the blocking flag: The requirements have been laid out in bug 204520, and those are what is needed for MNG to be added and this bug fixed. Until those goals are met or modified, drivers have made it clear that this will not be added back to the trunk. As a result, requests to block any release will be denied since drivers already decided it could be removed until the goals are met.

Re: #194: "Asa, could you please explain why you removed blocking1.5b for this bug when it is the most voted-on bug in all Bugzilla and can be easily fixed?" Several reason: This bug is not _ready_ to be fixed as as set of specs is still beign drawn up by module owners and drivers. This bug in now way is a sudden regression, or otherwise urgent in the scope of the 1.5b release and does not even rise to the level of rendering sites incorrectly. Also, did you not see this? Status Whiteboard: DO NOT COMMENT UNTIL DRIVERS GET BACK TO US REGARDING STATUS (COMMENT #131). IF YOU HAVE TECHNICAL ISSUES, SEE BUG 204520 OR FILE A NEW BUG It's pretty clear this bug is not close to being resolved yet.

referring to #195: a complete dump of my former profile let me install the xpi. thanks for all those messing with the mng and the mng-xpi creation. :)

I have received word from drivers. They invite MNG support to be put back in the image library as a configurable option that is turned off in default mozilla.org-produced builds (Seamonkey, Firebird, Thunderbird). They are interested in having only MNG-VLC supported as a configurable that does not entail all the footprint of full MNG, and would support such a subset being turned on in mozilla.org-produced builds and made part of the "typical" GRE configuration that Mozilla.org brands and promotes (aside: we see the need for "minimal", "typical", and "all" GREs, with "typical" being widely deployed on desktop machines).

(drivers invite MNG support to be put back in the image library as a configurable option that is turned off in default) And we all know that that will be useless. While telling users to use Mozilla for certain content might be feasable, telling them to choose special configuration options clearly is not. Also all current users of Mozilla will have to mess around and it won't work out of the box. People will forget it when upgrading. This quote from Glenn in bug #208607 shows IMO how ridicoulous and frustrating the whole situation already is: "My patch for reducing libpng another 5-10k in addition to 50k already saved by me to make room for MNG support has been lingering in bug #208607 for a couple weeks without any response. I have also reduced my own copy of the jpeg library significantly, too, but why bother?" IMO this all is not about memory footprint, but only about pride, power and control. Which is all very sad.

I don't wish to lay blame or attack anyone - I'd just like a clarification of the state of affairs without loads of Moz. Dev. TLAs: Is it now true that the main reason for not [re]including MNG as default is it's footprint? I seem to recall reading above that more footprint is /saved/ by converting the default chrome's animated GIFs to MNGs that is taklen up by it's inclusion in the library - an overall footprint /decrease/ by including it. Am I right? Also, I'm not quite sure I understand the mechanism by which MNG will/will not be present in a moz under the seeming current plan. Will it need a special build, or will it 'be there' in the default build but not downloaded by default unless some installer tickbox is set? If it's not 'there', what happens if a MNG is found whilst browsing - will there be an automated 'plugin dialogue' offering to make it work, or will it just not display?

to Neil Bird -> let me explain the mechanism: not being built by default, will not be supported, you will have to find somewhere a Mozilla build with support enabled

So, essentially, the current status quo is preserved. Is anyone surprised?

Drivers supports the reinclusion of MNG-VLC in mozilla.org builds, via it being "on" for "typical" GRE Builds. What this means is, the full MNG spec will not be compiled by default (but will be available as an option), but they MNG-VLC *will* be compiled by default, *and* available for install in all but the "Minimal" GRE configuration. Before anyone accuses drivers of maintaining the status quo, read above. In essence drivers have approved the reinsertion of a signifigant portion of MNG into the tree.

Is that a tentative "yippee" then? What's "VLC"?