User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:184.108.40.206) Gecko/20080201 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) See bug 418885 for a complete history of this issue. That bug addresses known runtime compatibility issues with running Firefox 3 for Linux (or really any Unix) with GTK versions lower than 2.10. In order to make Firefox 3 *compile* with GTK versions lower than 2.10, the following issues must be addressed: 1) By far the biggest issue is bug 193001. That patch introduces a strict dependence on a printing dialog window that was added in GTK+ 2.10. Option 1: make compilation work by omitting printing support when compiling with GTK+ < 2.10. Option 2: make compilation work by choosing the old printer dialog at compile time if necessary (and thus re-introducing the old printer code). Option 3: make compilation work by always compiling both dialogs and choosing the appropriate one at runtime. (Meaning, if you compile with 2.10 that version will also print if executed with 2.8. Of course if you compile with 2.8 then the new dialog would not actually be in the code and thus the reverse wouldn't be true.) Either way, I think the hardest thing here would be reworking the autoconf scripts to detect the GTK version and only search for the "gtk+-unix-print-2.0" package if the version is greater than 2.10. Dealing with the actual printer dialog ifdefs (see the patch in bug 193001) should be fairly straightforward I think. 2) bug 412954 introduces a couple enums that are only defined in 2.10 and newer. These should be trivial to ifdef out. I have been compiling on a system with 2.8 and these are the only two compile-time issues that I have found so far. There may be other issues with using 2.8 that affect the runtime (apart from the window property issues addressed in bug 418885) but I am still testing so I don't know yet. Regarding printing, my vote would be for "option 3". "option 1" is barely worth doing, as supporting a crippled Firefox 3 is hardly in the best interests of the Firefox project. I think the objections to bringing back the old dialog code are being driven more by emotional response than by practicality. It's really not that big of a deal to have both dialogs lying around. There are some code maintenance and QA issues, perhaps, and eventually it should be phased out, but for Firefox 3 at least can anyone give a convincing *technical* reason not to do this? Reproducible: Always Steps to Reproduce: 1. 2. 3.
Another question is how low a version of GTK would actually work? I am more than happy to test with 2.8, but that is all I have access to so we would need more testers with older versions to determine the answer.
Version: unspecified → Trunk
I'm OK with option 3, but the technical reason not to do it is "code bloat".
this should be marked as wont fix, firefox 3 is out of support
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.