Closed Bug 418885 Opened 17 years ago Closed 11 years ago

Firefox 3 shouldn't require GTK+ 2.10

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: osmancan, Assigned: ventnor.bugzilla)

References

(
URL
)

Details

(Whiteboard: [not needed for 1.9])

Attachments

(1 file, 3 obsolete files)

Patch 3
13.56 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080208 Firefox/2.0 Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.0b4pre.en-US.linux-i686.tar.bz2 Firefox 3 requires GTK+ 2.10 or newer which a lot of distros don't use (for ex.Yellow Dog Linux, Xandros, VectorLinux SOHO, Puppy Linux 2.17, Debian, Long Term Support - LTS release of Ubuntu (6.06), Mepis Linux 6.5...) Reproducible: Always Actual Results: I see a error dialog which says: We're sorry, this application requires a version of the GTK+ library that is not installed on your computer. You have GTK+ 2.8. This application requires GTK+ 2.10 or newer. Please upgrade your GTK+ library if you wish to use this application. Expected Results: A browser!
Summary: Firefox 3 shouldn't require → Firefox 3 shouldn't require GTK+ 2.10
Firefox 3 should use GTK+ 1.0 Red Hat 5.1 and SUSE 5.3 don't have GTK+ 2.8
I've been meaning to submit a bug about this so I'm glad you already did. I am on Debian Etch and fully agree that limiting to GTK+ 2.10 will cut out a very large swath of Linux users. I don't know how low a version of GTK+ should be supported, but allowing 2.8 will certainly bring in a larger chunk of users. The comment above suggests that even 2.8 isn't low enough. Unfortunately I can only comment on 2.8 because that is the only version I have access to. As I see it there are actually two problems: - Firefox 3 will absolutely not compile on a machine without GTK+ 2.10, currently. - Firefox 3 pre-compiled *might* have runtime issues on a machine with GTK+ < 2.10, and it will definitely not support printing if it does run. I've been investigating the details of getting it to compile and run on Debian Etch (GTK+ 2.8), and here is what I have found: 1) By far the biggest issue is bug 193001. That patch introduces a strict dependence on printing APIs that were added in GTK+ 2.10. 2) Another patch that adds 2.10 dependence is bug 412954. This one is relatively minor and could easily be controlled with #ifdefs. 3) There are some 2.10-only window properties accessed in the file "gtk2drawing.c" that cause runtime "Gtk-WARNING" messages and cause some widget issues. These are also very easy to fix with #ifdefs. 4) Regarding the forced prevention of running with < 2.10, see bug 418126. Of course that patch could easily be removed (or the version requirement changed) if this bug is addressed. There may be other issues but those are the ones I have found so far. I have managed to compile a working version of the latest cvs (as of the timestamp of this comment) by unrolling 193001, 412954, and 418126 from the source and also addressing the window property issues described above in 3). I wouldn't mind submitting patches for 2), 3), and 4), but creating a --enable-gnome-printing (or whatever) configure option for 1) would require a bit of work that I don't think I'm qualified to do. I looked into it a bit, but I'm just not sure about the best and most "Firefox correct" way of doing something that major. Can this be taken up by the Firefox team?
We can probably allow runtime checks of the GTK version, but that means that even if we do allow you to run Firefox 3 you won't be able to print. The old Linux printing code was removed from the tree, and I would rather eat babies than allow the return to our old, horrible "click print and pray" system. I can then remove the discriminatory dialog, but we should not offer Firefox 3 as an automatic update to GTK 2.8 users because of the lost functionality.
(In reply to comment #2) > 2) Another patch that adds 2.10 dependence is bug 412954. This one is > relatively minor and could easily be controlled with #ifdefs. What happened in that patch? gtk_window_set_type_hint is mentioned in the 2.8 docs...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well I believe there is already a runtime check in the printing code that will prevent it from crashing, in nsDeviceContextSpecGTK::Init(). The problem is that it only helps in the situation of downloading a prebuilt Linux version onto a system with 2.8. But Linux prebuilds are often unlikely to work straight out of the box anyway, especially given all the other distro dependencies that are probably out of date if GTK is out of date. I know the whole linux prebuild thing was the source of some recent controversy, so we don't need to get into that, but long story short no one denies the fact that it is very often the case that Linux Firefox must be built on the exact (or at least similar) given system in order to be usable. So, for anyone hoping to compile on a system with < 2.10, they are currently out of luck. I agree that it would be ugly to support two divergent printing dialogs (for this I was thinking compile-time, not run-time option), but the Firefox team and community needs to strongly consider what it means to abandon GTK+ < 2.10. GTK+ 2.10 was *released* in July of 2006. That is less than two years ago, and that is just the release, not the point at which it started propagating into the majority of distributions. Perhaps what will happen is that there will simply be distribution-specific patches not in the main source that strip out the print dialog. If so, at least this bug will serve as a point of reference for anyone attempting to do that. Personally I'd still vote for bringing back the old code and adding a compile-time option to disable gnome printing dialogs, since I think it would get a significant amount of usage by builders. In bug 412954, the various "GDK_WINDOW_TYPE_HINT" enums are only available in 2.10. There is runtime dependence on them in gtk_window_set_type_hint (which you can see if you look at its source), so not only does it not compile w/ 2.8, these would need to be prevented at runtime even for a 2.10-compiled build running on 2.8.
(In reply to comment #5) > Well I believe there is already a runtime check in the printing code that will > prevent it from crashing, in nsDeviceContextSpecGTK::Init(). We found that there is an earlier entry point to printing code and that 2.8 will crash anyway. I should probably post a patch here to fix that. > The problem is > that it only helps in the situation of downloading a prebuilt Linux version > onto a system with 2.8. But Linux prebuilds are often unlikely to work straight > out of the box anyway, especially given all the other distro dependencies that > are probably out of date if GTK is out of date. I know the whole linux prebuild > thing was the source of some recent controversy, so we don't need to get into > that, but long story short no one denies the fact that it is very often the > case that Linux Firefox must be built on the exact (or at least similar) given > system in order to be usable. So, for anyone hoping to compile on a system with > < 2.10, they are currently out of luck. Unless there is a way to conditionally check for GTK versions in Makefiles, there isn't much we can do here. And I don't necessarily agree that Firefox must be built under the same conditions it is run; Firefox only really depends on core libraries that come with almost every base installation (with the possible exception of Cairo, but it is far too integrated to conditionally check for that now), at least in my experience. I never needed to manually install any extra libraries to run an official Firefox .tar.bz2 build. > I agree that it would be ugly to support two divergent printing dialogs (for > this I was thinking compile-time, not run-time option), but the Firefox team > and community needs to strongly consider what it means to abandon GTK+ < 2.10. > GTK+ 2.10 was *released* in July of 2006. That is less than two years ago, and > that is just the release, not the point at which it started propagating into > the majority of distributions. By the same token, we must also consider the case for those that do run up-to-date versions. For one they get a consistent interface with more features than our old dialog. One example that I can think of is that if you plug in a printer while the GTK print dialog is open, and the printer is detected and autoconfigured, its entry will be dynamically added to the printer list in the dialog. Our old internal dialog can only dream of such things. Of course, we may not need to totally abandon these users (I might make a patch to do this), but we still cannot let them stand in the way of such phenomenal progress. > Perhaps what will happen is that there will simply be distribution-specific > patches not in the main source that strip out the print dialog. If so, at least > this bug will serve as a point of reference for anyone attempting to do that. > Personally I'd still vote for bringing back the old code and adding a > compile-time option to disable gnome printing dialogs, since I think it would > get a significant amount of usage by builders. I personally think the wise choice for them would be to stick with Firefox 2. Then, when they release a new version of their distribution they should include an up-to-date GTK library, or at least one later than 2.10. Is 2.10 really a huge difference performance-and-size-wise to 2.8? They can bring back the old code if they like, but they will have to be totally responsible for it. There is no chance that code will be officially maintained by Mozilla upstream anymore (it was hardly touched when it was still in use!) > In bug 412954, the various "GDK_WINDOW_TYPE_HINT" enums are only available in > 2.10. There is runtime dependence on them in gtk_window_set_type_hint (which > you can see if you look at its source), so not only does it not compile w/ 2.8, > these would need to be prevented at runtime even for a 2.10-compiled build > running on 2.8. I see. I don't think I can really provide the ability to compile on < 2.10 without too much work and a lot of conditionals, but it doesn't seem too hard to make Firefox 3 functional on 2.8 again.
Latest version of GTK+ is 2.12.8. Distros with GTK+ 2.8 and older are outdated. Why anybody, who doesn't mind to use outdated distro, want to use latest web browser, which isn't released yet ?
If we are going to support 2.8, we'll need to figure out a workaround to add the gtk-select-all icon to the theme as well.
Speaking using my distro hat on, I think the requirements are pretty clear. For Red Hat Enterprise Linux (RHEL) 5, we happen to have all the requirements needed. For RHEL 4, however, we don't. That does not mean I can't ship Firefox 3 on RHEL4. I fully intend to ship Firefox 3 all the way back to RHEL 2.1 which _ships with GTK+ 1.2, and doesn't have GTK+ 2.x at all_. All it means is that I need to include a static copy of the required libraries with the browser. I am personally OK with that, and other distros do the same AFAICT to ship e.g. new Evolution on older products. I could complain and ask for GTK+ 1.2 support to be brought back, but seriously. If you are going to be using an older distro, you are going to need to understand that some newer software is going to need newer libraries. Either you deal with it yourself as a user, or your distro deals with it for you. But making Firefox support older versions is just plain pain because we get to use less cool features, plus where do you draw the line? I'm sure there are still a lot of Sarge users out there. Do we support that too? Bottom line really is that all distros have a process for including software which depends on software not in the distro yet. Generally, you package up the dependency first, and then package up the app. In this specific case, the dependency happens to be an new version of a library. It might make sense if someone volunteers a gtk210 package to debian or something that Firefox can depend on, or just a Firefox3 package with all of it's dependencies rolled in or something. Making Firefox work with every distro out there isn't mozilla.org's job, its our job as Linux distributors to make them work with our distros.
URL: http://wiki.mozilla.org/Linux/Runtime...
Whiteboard: WONTFIX?
Version: unspecified → Trunk
> By the same token, we must also consider the case for those that do run > up-to-date versions. For one they get a consistent interface with more features > than our old dialog. One example that I can think of is that if you plug in a > printer while the GTK print dialog is open, and the printer is detected and > autoconfigured, its entry will be dynamically added to the printer list in the > dialog. Our old internal dialog can only dream of such things. I hope I didn't give the impression that the new dialog isn't a great thing. It should absolutely be used when it is available. The issue I have with this whole 2.10 requirement is that, apart from the minor issues I mention which are easily fixed (I'll just go ahead and submit a patch for those things if I can get to it), the printing dialog is the only thing causing the requirement. (If it isn't, I would love to hear what else is. Like I said I am able to build and run (and print!) by unapplying that patch. I will continue to test and look for any other incompatibilities.) It would be one thing if we were talking about the rendering or font engine or something, or even the engine in charge of rendering the printable page, but we're talking about a printing *dialog*. I don't mean to dismiss the importance of progress in that realm, but is that really what should be the defining feature for abandoning a large number of users? And I'll repeat that I don't think this needs to be a runtime thing. I think it would be fine for printing to not be supported (vs. not allowing running the program at all) IF it weren't compiled to use the old dialog. Debian requires compiling with --disable-jemalloc anyway, as I think many other distros will since that feature requires a newish version of glibc, so forcing a recompile to get printing is a fair trade, in my opinion. > dependency happens to be an new version of a library. It might make sense if > someone volunteers a gtk210 package to debian or something that Firefox can > depend on, or just a Firefox3 package with all of it's dependencies rolled in > or something. This just seems like such a colossal waste of many peoples' time all over the world (and in most cases will probably just never happen due to the complexity of doing that) vs. a standardized compile-time flag that fixes the problem for everyone. Yes that old dialog may be a beast, but until January 20th 2008 it was the only one ever used in all versions of Linux Firefox and it got by just fine, so I think it's a bit extreme to suggest that it is completely unsalvageable.
(In reply to comment #9) > I fully intend to ship Firefox 3 all the way back to RHEL 2.1 which > _ships with GTK+ 1.2, and doesn't have GTK+ 2.x at all_. All it means is that > I need to include a static copy of the required libraries with the browser. I > am personally OK with that, and other distros do the same AFAICT to ship e.g. > new Evolution on older products. Then maybe Mozilla should put static copy of libraries into the tar.bz2 and as user I shouldn't have to deal with them myself. > > I could complain and ask for GTK+ 1.2 support to be brought back, but > seriously. If you are going to be using an older distro, you are going to need > to understand that some newer software is going to need newer libraries. > Either you deal with it yourself as a user, or your distro deals with it for > you. But making Firefox support older versions is just plain pain because we > get to use less cool features, plus where do you draw the line? I'm sure there > are still a lot of Sarge users out there. Do we support that too? > Firefox is not ordinary software. It is great browser, it is one of the most important programs of the users. Firefox 3 has a lot of cool features and only few of them require new GTK+. I don't want to miss the chance of using this great release because of new printer dialog. > Bottom line really is that all distros have a process for including software > which depends on software not in the distro yet. Generally, you package up the > dependency first, and then package up the app. In this specific case, the > dependency happens to be an new version of a library. It might make sense if > someone volunteers a gtk210 package to debian or something that Firefox can > depend on, or just a Firefox3 package with all of it's dependencies rolled in > or something. > > Making Firefox work with every distro out there isn't mozilla.org's job, its > our job as Linux distributors to make them work with our distros. > Ubuntu, Debian and others have gtk+ >= 2.10 on their new versions or development versions. But we are talking about users who use stable version or long term support version.(Oh! I forgot it!. even the users who use latest and greatest release of their distros! Asus Eee PC doesn't gave GTK+ 2.10, too!) You know those these versions of distros don't update packages to newer versions, and they don't add new packages to repos. And a user only want to download the tar.bz2, extract it and run it! He/she shouldn't even have to wait some volunteer to build a firefox3 or gtk210 package for him/her, and he/she shouldn't have to install those packages, too.
Attached patch Make Firefox at least usable in 2.8 (obsolete) — — Splinter Review
> Firefox is not ordinary software. It is great browser, it is one of the most > important programs of the users. Let's be sensible... Firefox is like any other piece of software in that it runs on the OS and talks to the OS. And sometimes older versions just don't provide the necessary functions to keep up with the growth of the software. This patch will make Firefox 3 at least run again on GTK 2.8, but I haven't made Firefox 3 compilable on those systems yet nor do I really know how. I only #if 0'd the dialog code because who knows what decisions will be made in the future. However we should no longer crash when wanting to print (we mean it this time!) Optimally, Firefox 3 still needs 2.10 and for that reason I'm still eager for bug 418131 to be fixed so Firefox 3 isn't offered in automatic updates for those users. But if you want to run an only-decent pre-built Firefox 3 thats your choice. I think the best course of action for these distros is to just keep supporting Firefox 2. Its not like Firefox 2 will go poof off the face of the Earth the second Firefox 3 is released. Many people still use Firefox 1.5. Alternatively, like Christopher, they can put in the extra work to package the required libs along with it.
Attachment #308331 - Flags: superreview?(roc)
Attachment #308331 - Flags: review?(roc)
> Then maybe Mozilla should put static copy of libraries into the tar.bz2 and as > user I shouldn't have to deal with them myself. Do you know what is static copy of library? > Ubuntu, Debian and others have gtk+ >= 2.10 on their new versions or > development versions. But we are talking about users who use stable version or > long term support version.(Oh! I forgot it!. even the users who use latest and > greatest release of their distros! Asus Eee PC doesn't gave GTK+ 2.10, too!) > You know those these versions of distros don't update packages to newer > versions, and they don't add new packages to repos. And a user only want to > download the tar.bz2, extract it and run it! He/she shouldn't even have to wait > some volunteer to build a firefox3 or gtk210 package for him/her, and he/she > shouldn't have to install those packages, too. Ubuntu has GTK+ 2.10 since 2006. Users with GTK+ 2.8 distros can use Firefox 2 until distro upgrade. mozilla.org shouldn't solve problems of some stupid Linux distros.
> This patch will make Firefox 3 at least run again on GTK 2.8, but I haven't > made Firefox 3 compilable on those systems yet nor do I really know how. I only > #if 0'd the dialog code because who knows what decisions will be made in the > future. However we should no longer crash when wanting to print (we mean it > this time!) Thank you Michael for this patch. This covers all of my points 2), 3), and 4), and I definitely hope that this patch is accepted. There are some parts you missed in gtk2drawing.c: - The "activate-slider" property needs the same protection. - There are three more sections that query "wide-separators" that need to be accounted for. (Two of them require splitting into two gtk_widget_style_get() calls since there is a third property being asked for that does exist and is needed.) Also, in nsWindow.cpp, what you have will fix the runtime issue but it doesn't eliminate the compile-time dependency on 2.10. Could you wrap the appropriate lines (after "switch (aInitData->mPopupHint)" and before "default:") with "#if GTK_CHECK_VERSION(2,10,0)" so that one less compile-time dependency exists? I'm still hoping that someone will chime in about the printer dialog with a proposed solution. Even with this patch it's still not possible to *compile* on 2.8, even if one is ok doing without *any* printer dialog. It probably wouldn't be hard to ifdef parts of the code (which would never be called anyway), but I think the trickiest thing would be figuring how to conditionally eliminate the dependence on the "gtk+-unix-print-2.0" pkg in the configure scripts.
By the way I wonder if it's worth re-instating the dialog but have it be a warning instead of a flat-out rejection. ("Printing requires GTK+ 2.10 or greater" or whatever.) Of course this is treading into "needs localization" territory and I'm not clear if it's too late for that for beta 5. Also bug 409202 is another 2.10 thing but I'm not sure what the fix would be. (And it's relatively minor, especially compared to the separators which really mess things up when they don't work.)
Comment on attachment 308331 [details] [diff] [review] Make Firefox at least usable in 2.8 I'm not aiming to fix the compile-time issues. Theres no point in #ifdef'ing the GTK version in some places if other places will just cause compile errors. In fact, I'm wondering whether I should even give gtk2drawing.c any protection; the console GTK warnings aren't fatal and these checks would just slow it down a little bit and make the code more complex.
Attachment #308331 - Attachment is obsolete: true
Attachment #308331 - Flags: superreview?(roc)
Attachment #308331 - Flags: review?(roc)
> I'm not aiming to fix the compile-time issues. Printer dialog aside, there is ample precendent in the source for maintaining compatibility with older GTK versions with both runtime and compile-time checks. Even the change you made in this patch slipped right alongside the "have_menu_shadow_type" check that already existed. A few boolean checks in some drawing code will not affect the performance in any significant way, not any more than a million other things that are going on in there. > Theres no point in #ifdef'ing > the GTK version in some places if other places will just cause compile errors. You say this as if there are a million such errors. *I* have been compiling using 2.8, and the printer issue and the nsWindow.cpp thing (both of which are from patches you wrote) are the *only* compile-time incompatibilities with 2.8. (And possibly earlier GTK+ versions, I but I can't confirm.) Maybe the printer thing will be addressed somehow, maybe not, but there is absolutely no harm in fixing half of the problem first with the hope that the other half will somehow be addressed. It doesn't complicate the code any more than any of the other checks for GTK_VERSION do. We get it. You don't use 2.8 or lower, nor do most (if not any) of the other developers. But Firefox 3 is rounding out the end of its beta cycle, which means more and more people are jumping on board, trying it and giving feedback. Soon the masses will arrive in even greater numbers. And the feedback we're giving is that compatibility with < 2.10 is important to us, and people such as myself have looked at the internals and said "hey, the dependency isn't strong, nor hard to fix". That is our feedback. Is that not important to anyone on the Firefox team?
Funny you should mention have_menu_shadow_type as I just submitted the patch removing it
Well, for completeness I will add that I found it is IS possible to get rid of the runtime checks by simply initializing the local variables "wide_separators" and "activate_slider" to FALSE and "tmp_border" to NULL in their respective functions. (Since gtk_widget_style_get() does not clear to 0 unknown properties, as I have found empirically.) This still causes the incredibly annoying and voluminous warnings, but at least things work. The runtime check is still the better way to go. Please do at least one of those things. I guess this comes down to how much the Firefox team is going to stand by its 2.10 guns. Of course if the 2.10 line is drawn in the sand, then sure, remove *every* check. But this problem is always going to continue to exist. There will always be new GTK versions with new API features. By far the most sensible thing is to continue doing what has been done all along: use new features conditionally with runtime and compile-time checks, except where it becomes grossly necessary to cut off old versions. The earlier comment about "why shouldn't we just support GTK+ 1.2" was a total staw-man argument for making 2.10 the cutoff. By that argument, why should Firefox strictly require GTK+ 2.12.8, which was released a month ago? The answer is that there is a reasonable time range in which to phase things out. We think that 2.10 as a requirement lies in an unreasonably small time range.
Attached patch Patch 2 (obsolete) — — Splinter Review
Assignee: nobody → ventnor.bugzilla
Status: NEW → ASSIGNED
Attachment #308354 - Flags: superreview?(roc)
Attachment #308354 - Flags: review?(roc)
its all comes down to how many users you would cut out. as a EEE user, i know at least 1 million of users lose. linux is where firefox has dominance, and linux users should not be taken for granted. its not about when 2.10 was shipped, if there is work around, and is not too difficult, for users sake, do it.
I am also an eeepc owner, and I really don't think that they should make it require gtk 2.10+. It would be cutting off alot of users. Especially because the eeepc isn't the most powerful, the fact that firefox 3 manages memory alot more efficiently is really appealing to the small umpc laptop crowd.
Comment on attachment 308354 [details] [diff] [review] Patch 2 doesn't this need to load 2.10-only symbols (like GtkPrintSettings) dynamically? Otherwise, the app will simply fail to start due to unsatisfied library dependencies.
Thanks Michael for the updated patch. This still has the compile dependency in nsWindow.cpp, but I'm willing to wait on that if and until the printer dialog dependency is removed and then all 2.10 compile-time dependencies can be dealt with at once. > linux is where firefox has dominance, and linux users should not be taken for > granted. By the way, I realized that I (we) have been incorrectly talking about Linux, when we should really be saying X11 Firefox. Here is a post of someone asking about this problem while trying to compile on AIX: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/e7272047729800f4/1493a347ecf5bd52#1493a347ecf5bd52 > doesn't this need to load 2.10-only symbols (like GtkPrintSettings) > dynamically? Otherwise, the app will simply fail to start due to unsatisfied > library dependencies. This may potentially be true on some platforms. Many (most?) Unix platforms that support shared libraries delay symbol lookup until the symbol is actually accessed. This is the case on Linux unless if LD_BIND_NOW is defined. (See also "RTLD_LAZY" in man dlopen.) If this weren't the case, then I assume people wouldn't even get the 2.10 error box. But they've been getting it, or at least some have. That said, if Michael's patch is applied for the next beta then we'll be able to find out, at least for the pre-compiled Linux releases.
> This is the case on Linux unless if LD_BIND_NOW is defined. Hmm, yes. I s/gtk_print_settings_get_scale/gtk_print_settings_get_fffff/ in libwidget_gtk2.so and my build started up and was fine until I tried to print. So, I guess we could remove the dynamic bits for the filepicker -- not that we even work with gtk that doesn't have the filepicker symbols at this point :) http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsFilePicker.cpp#176
(In reply to comment #13) > Do you know what is static copy of library? I dont, but Christopher A. Aillon's sayings make me thought it can be done. > Ubuntu has GTK+ 2.10 since 2006. Ubuntu 6.10 has GTK+ 2.10 it isn't long term support release (and probably it will reach end of life before Firefox 3 be released.). 6.06, which is a long term support release has 2.8. > Users with GTK+ 2.8 distros can use Firefox 2 until distro upgrade. > mozilla.org shouldn't solve problems of some stupid Linux distros. > Slighting users and calling distros stupid is not right thing to do.
(In reply to comment #11) > (In reply to comment #9) > > I fully intend to ship Firefox 3 all the way back to RHEL 2.1 which > > _ships with GTK+ 1.2, and doesn't have GTK+ 2.x at all_. All it means is that > > I need to include a static copy of the required libraries with the browser. I > > am personally OK with that, and other distros do the same AFAICT to ship e.g. > > new Evolution on older products. > Then maybe Mozilla should put static copy of libraries into the tar.bz2 and as > user I shouldn't have to deal with them myself. You misread me. I'm not saying users should do this at all. I also don't think Mozilla should do this. Mozilla provides the software and it is up to YOUR DISTRO to make it work for you. Red Hat Enterprise Linux 4 shipped originally on Feb 15, 2005. It currently contains GTK+ 2.4.13. I plan on creating Firefox 3 packages for it. Red Hat Enterprise Linux 3 shipped originally on Oct 23, 2003. It currently contains GTK+ 2.2.4. I plan on creating Firefox 3 packages for it. Red Hat Enterprise Linux 2.1 Advanced Server shipped originall on March 26, 2002. Nearly 6 years ago to the day. Back then we didn't even have GTK+ 2.x yet. It contains GTK+ 1.2.10. Yet I still plan on creating Firefox 3 packages for it. Mozilla will always be "too new" for some distributions. I could easily argue that Mozilla should still support GTK+ 1.2.10 because people are PAYING for that. (Really, where do you draw the line in which distros to support?) But that does not mean that the packages can't be done anyway. If you as a Debian user want something, you should ask your distro to provide it. Debian can provide Firefox 3 packages just like I plan to do for Red Hat Enterprise Linux.
(In reply to comment #25) > > This is the case on Linux unless if LD_BIND_NOW is defined. > > Hmm, yes. I s/gtk_print_settings_get_scale/gtk_print_settings_get_fffff/ in > libwidget_gtk2.so and my build started up and was fine until I tried to print. > > So, I guess we could remove the dynamic bits for the filepicker -- not that we > even work with gtk that doesn't have the filepicker symbols at this point :) > http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsFilePicker.cpp#176 Note that ABI of GtkFileChooser changed in 2.10 from earlier releases. Might not be an issue, but I'd rather not do this unless we're supporting 2.10 and up.
I think we should support running on GTK 2.8 if it's not too much trouble and especially if a volunteer is willing to do the work ... I'm willing to do the reviews. I don't really want to reenable all the old printing code though, so we might just not support printing on 2.8.
I am not terribly interested in supporting *building* on GTK 2.8, although if someone comes up with a patch I might be tempted. Michael, your patch looks good except that instead of #ifdefing out the version dialog, maybe we should keep the dialog, but if 2.8 is present then give users the option to continue? Maybe the string freeze makes that hard...
(In reply to comment #30) > I am not terribly interested in supporting *building* on GTK 2.8, although if > someone comes up with a patch I might be tempted. > > Michael, your patch looks good except that instead of #ifdefing out the version > dialog, maybe we should keep the dialog, but if 2.8 is present then give users > the option to continue? Maybe the string freeze makes that hard... I'd rather not... The string is not translatable because the code where the dialog is displayed is run before XPCOM is loaded. By then it would be too late since apparently it's naughty to make XPCOM depend on GTK, and the program is pretty much loaded anyway. So I'd prefer not to add a dialog that is potentially confusing and can be easily ignored especially by non-English users. By allowing users to continue and dismiss the dialog all we are doing is providing an unnecessary roadblock dialog, just like what the security UI did in Firefox 2. IMO, the best option would be to poke bsmedberg to hurry up and review bug 418131, and not offer Firefox 3 to GTK 2.8 users. If they still run it despite GTK+ 2.10 being listed in the minimum requirements section, thats their choice. I think most users get their software from the distribution maintainers anyway, so this should only be a problem for "half-early-adopters" (they are eager to get the latest version of their browser straight off the Mozilla site, but not eager enough to get the latest version of their libraries for optimal functionality).
Comment on attachment 308354 [details] [diff] [review] Patch 2 Well, this code is OK with me. Up to you whether you want the dialog or not.
Attachment #308354 - Flags: superreview?(roc)
Attachment #308354 - Flags: superreview+
Attachment #308354 - Flags: review?(roc)
Attachment #308354 - Flags: review+
Comment on attachment 308354 [details] [diff] [review] Patch 2 Requesting for 1.9 - I guess we should at least allow older GTK users to run Firefox 3.
Attachment #308354 - Flags: approval1.9?
I absolutely agree with comment #34. I believe that "half-early adopters" (see comment #31) are a substantial part of Firefox's userbase; unlike most other software, browsers are expected by users to be constantly changing, since they are tracking a rapidly-moving target in the form of evolving Web standards and security exploits. It should be possible to verify this quite quickly by counting user-agent strings for browsers hitting the Firefox download page. Suggesting that this large constituency should either stop using the latest Firefox, or be forced into upgrading from their current distribution's stable release to do so, would be seriously bad PR, and could be spun very negatively by the press. ("No Firefox 3.0 for the EEE", "Firefox abandons Debian", etc, etc) At the very least, there should be another official build made available ("Firefox 3.0 for GTK+ 2.8", "Firefox 3.0 LTS"?) with the relevant newer libraries statically linked, which, as far as I can see, would be a 100% fix for this problem.
I'll add my thoughts to this. There are a few things to consider here. A vast, vast majority of people get Firefox from their distributors. We know from our statistics that less than one hundredth of one percent of our registered user base reports a Linux operating system. We know that the Linux user base is a lot larger than that, but that most distributors turn off our auto-update system and use their own for updates. The result of this is that compile-time checks are a reasonable solution to the version problem. It hurts our beta testing community on Linux, but even that group isn't very large when compared to the number of people doing testing on Windows or the Mac. Helping to support the distributions who are running on older versions of the operating system is pretty important and keeps the pile of patches that they have to support to a minimum. I would rather see those changes merged into our tree in a maintainable way than asking the N distributions out there to handle their own patching. That leads to errors and has the potential to negatively affect the perception of Firefox's quality on Linux. As a result of this my thinking is that continuing to support the latest Gtk version with Mozilla-produced builds is important, but allowing distributions to compile their own with older versions is fine since the people who are going to get updated versions for their older platforms are going to get them from the vendor anyway. And I suspect that the same people who are running newer Linux distros are the ones who are also most likely to try our nightly builds. (OK, 2.10 isn't _that_ new, but I guess it's new enough.) We need to balance this against the other force at work here, which is the constant pressure from the community who complain that we're not native enough. If we can accomplish using the native look and feel by coming up to a pretty recent Gtk version, isn't that worth the cost? We've got pressure from two audiences (never change! change faster!) and we have a way out to support all of them but it involves getting the distributions who are supporting those older users to carry some of the cost of support. We're a reasonably large organization but the fragmentation in Linux means that we can't support everyone all the time - it's just totally unreasonable. Anyway, that being said, I much prefer a compile time option and let the distributions handle older compatibility problems. That is, after all, their main competency, right?
(In reply to comment #36) I think mozilla should provide two different builds.One for gtk+ 2.10(and newer) and one for older gtk's. So it won't hurt beta testing community on Linux.
The Firefox beta3 build didn't display the "must upgrade to Gtk 2.10" warning. Using it I experienced the problem described in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=417321 I run Debian Etch which has Gtk 2.8.20 installed by default. I just downloaded Beta 4 to test, and after seeing the Gtk 2.10 requirement, I manually compiled and installed Gtk 2.12.6. Now Beta 4 runs fine, and has no issue like in bug 417321! So.. I tried running Beta 3 again with my new Gtk 2.12.6 and it doesn't exhibit the problem either! Unsetting my LD_LIBRARY_PATH (which needs to have /usr/local/lib to use my custom compiled stuff) brings the problem back like a light switch. This warning is emmitted periodically: (Gecko:5078): Gtk-WARNING **: gtkwidget.c:7322: widget class `GtkSeparatorMenuItem' has no property named `wide-separators' Anyway, I just wanted to let you guys know, that even though Beta 3 would still start up if you had Gtk 2.8, there were definitely some problems. If Mozilla will official support using Gtk 2.8, then be sure to get it enough testing so that these problems don't slip through. Thanks!
Comment on attachment 308354 [details] [diff] [review] Patch 2 >+ is_gtk_2_10_or_later = >+ (gtk_major_version < 2 || >+ (gtk_major_version == 2 && gtk_minor_version >= 10)); Maybe this is a gtk version numbering quirk, but it looks like a gtk_major_version of 1 would set us to true there, while a gtk_major_version of 3 would set us to false. Is that not the opposite of what we want (specifically the first "< 2" test), or do we need to defend against GTK 3, and don't care about GTK 1 since it won't even start up?
we should not overlook the fact that no all linux ditroes are equal, major ditroes will take care of their users. but how about small ditroes? and half-hearted fake linux ditroes like ASUS? If mozilla doesn't take care of them, do anyone really believe ASUS will? Its repo just updated for firefox 2.0.0.11??!! Rhetoric might sounds reasonable and nice, but facts are cold, there are at least half million EEE users out there. I know its not even 1% of firefox user base, but still a large number. Again, If the work around will be too hard, then Im fine with it. But if not, why risk bad PR and abandon users?
Whiteboard: WONTFIX? → STOP THE SPAM - THIS WILL BE FIXED
Attached patch Patch 2.01 (obsolete) — — Splinter Review
I actually reversed the boolean's role and changed its name but forgot to change the major_version < 2.
Attachment #308354 - Attachment is obsolete: true
Attachment #308731 - Flags: approval1.9?
Attachment #308354 - Flags: approval1.9?
Comment on attachment 308731 [details] [diff] [review] Patch 2.01 a1.9+=damons
Attachment #308731 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Thanks everyone for the traction on this. Thank you commenter #36, I couldn't agree more with what you said. At this point it'll probably best to start a new bugzilla for compilation support. I'll submit that if no one else does first. I have tested the latest patch and there are two remaining issues: - The patch actually has problems applying right now since there have been even more recent checkins to gtk2drawing.c. (There is a new check called "have_arrow_scaling" that is tripping up the patch.) Perhaps this is just the responsibility of the checkin person to deal with, since it's easy to fix manually, but I thought I'd mention it. - More importantly, discovered one more 2.8 incompatibility: "scroll-arrow-hlength" in moz_gtk_get_tab_scroll_arrow_size() is also new in 2.10, so that is tripping things up (and in fact completely kills the browser if you open enough tabs to require scrolling since that function is returning bogus data). I couldn't figure out the best thing to do here other than return a hardwired number. 20 seemed ok in my tests. (If the tab widget scroll arrow for someone running GTK+ 2.8 doesn't honor the current theme, it's not gonna be the end of the world.)
(In reply to comment #43) > - More importantly, discovered one more 2.8 incompatibility: > "scroll-arrow-hlength" in moz_gtk_get_tab_scroll_arrow_size() is also new in > 2.10, so that is tripping things up (and in fact completely kills the browser > if you open enough tabs to require scrolling since that function is returning > bogus data). I couldn't figure out the best thing to do here other than return > a hardwired number. 20 seemed ok in my tests. (If the tab widget scroll arrow > for someone running GTK+ 2.8 doesn't honor the current theme, it's not gonna be > the end of the world.) > Reed, would it be trivial enough to add a check for that and initialise the value to 20, or must I attach a new patch and request a1.9 again? Since it would crash its pretty important...
i'd rather a new patch, it's ok to have the current one committed and then post a small patch for it. you'll get fast reviews+approvals. reed is acting as a checkin monkey, asking him to do work and manipulate patches in a non trivial way isn't fair to anyone.
(In reply to comment #45) > i'd rather a new patch, it's ok to have the current one committed and then post > a small patch for it. you'll get fast reviews+approvals. If it's a non-trivial change that really needs reviews, let's just make a new patch instead of going with the old one. I also would rather use gtk_check_version() / GTK_CHECK_VERSION() here instead of manually checking major and minor versions.
Component: OS Integration → Widget: Gtk
Keywords: checkin-needed
Product: Firefox → Core
QA Contact: os.integration → gtk
Also, if we're not going to use the code in toolkit XRE startup at all, why not remove it completely instead of just |#ifdef 0|ing it out?
I #ifdef'd it out just in case we decide to reenable it for an arbitrary GTK cutoff in the future.
...but I guess thats what CVS revisions are for.
Attached patch Patch 3 — — Splinter Review
Address more comments.
Attachment #308731 - Attachment is obsolete: true
Attachment #308852 - Flags: superreview?(roc)
Attachment #308852 - Flags: review?(roc)
Thanks, Ventron. :)
I guess I'm asking for too much if I'd like GTK 2.10 to be optional also at compiletime, not just at runtime?
(In reply to comment #52) > I guess I'm asking for too much if I'd like GTK 2.10 to be optional also at > compiletime, not just at runtime? > Yes. The entire Linux printing code now depends on GTK 2.10 and it would be hard to ifdef that.
FYI the system requirements still say gtk+2.0 or higher: http://www.mozilla.com/en-US/firefox/system-requirements-v3.html
(In reply to comment #54) > FYI the system requirements still say gtk+2.0 or higher: > http://www.mozilla.com/en-US/firefox/system-requirements-v3.html That's bug 405669.
So would the requirements say 2.8 or 2.10. It sounds like it would officially be 2.10 but could run on 2.8 without printing.
(In reply to comment #56) > So would the requirements say 2.8 or 2.10. It sounds like it would officially > be 2.10 but could run on 2.8 without printing. 2.10
> I guess I'm asking for too much if I'd like GTK 2.10 to be optional also at > compiletime, not just at runtime? I have opened a new bug for this: bug 422478
FWIW, I really think mconnor should weigh in here before any patch is committed to CVS, since he's been the one that's been setting these requirements with input from Linux distros. I do think this patch shouldn't be taken. Not being able to print is a major issue. If a distro specific patch broke printing, I can pretty much bet that we'd be threatened with not being able to use the Firefox trademarks...
Alright, let's make this depend on printing getting fixed on 2.8. That's basically bug 422478 as well.
Depends on: 422478
I seriously, seriously doubt printing will be fixed for 2.8 users before Firefox 3 because that would require re-introduction of the crufty code that we removed for the much smaller and cleaner GTK backend. Not being able to print may be a major issue but I think most users would rather not be able to print than not be able to do anything (I don't even think Eee users print anyway, at least not directly from the Eee). I think we should provide the option for 2.8 users to sacrifice the ability to print for the other Linux improvements should they choose to do so.
I do print from my EEE, occasionally, but you are absolutely right, I would rather not able to print from firefox 3 than not be able to do nothing. (realistically, I never even printed from firefox of mac or windows anyway..) However, I also agree that firefox should avoid publish an official version of firefox 3 that could not print. So, I think the way to go is to enable this patch, forget of printing. On release note, or whenever users first run firefox 3 on a 2.8 machine. Tell them printing will be broken due to older environment.
I suspect that the distros that do care about backwards compatibility will have a patch for 2.8 users and it will be spread far and wide. As for EEE, if they are distributing a really old firefox release (and it sounds like they are!) and they are failing to update it in a timely manner we should be having a conversation with them. 2.0.0.12 is current and 2.0.0.13 is going to be released at some point I'm sure. They are exposing their users to risk.
#63 Chris Absolutely a good way to go, we end users of EEE probably won't be able to pressure ASUS enough at all. the intervention of Mozilla would definitely help. and That would be a perfect way of solving this issue as well. Again, the final purpose is to help users, make sure they got served.
Whiteboard: STOP THE SPAM - THIS WILL BE FIXED
What's the latest on this? We don't have much time left until freeze for RC...
It's not clear to me that this patch is acceptable to Blizzard and caillon. The code itself looks OK.
Mozilla Firefox 3 should use Qt or GTK+, is really bad think only in GTK, some users maybe dont like GTK style or cant have GTK+ (for kde users for ex.) Firefox is Gnome thinked... and this do a impartial Firefox use. Please, consider that, do a Qt compatibility, im using Qt now, and for KDE4, firefox looks BAD, terrible, dont recomendable. And i dont like GTK style, but ONLY firefox ask me install that, and install some gnome libs.
To whom want to use Firefox 3 on Debian Etch, here is the recipe: 1) download gtk+ 2.10 debs from gnome 2.10 etch backport: http://people.debian.org/~nobse/gnome/etch/2.16/gtk+2.0/libgtk2.0-common_2.10.11-1~bpo.2_all.deb http://people.debian.org/~nobse/gnome/etch/2.16/gtk+2.0/libgtk2.0-0_2.10.11-1~bpo.2_i386.deb http://people.debian.org/~nobse/gnome/etch/2.16/gtk+2.0/libgtk2.0-bin_2.10.11-1~bpo.2_all.deb DON'T INSTALL THEM! We will extract it to a directory and add that dir to our LD_LIBRARY_PATH 2) Create gtk+ 2.10 directory wherever you want. It can be at your home dir or /usr/local or something else... I'm creating it on /opt mkdir /opt/gtk2.10 (as root) 3) Now extract the debs: for i in libgtk*.deb; do dpkg-deb -x "$i" /opt/gtk2.10 ; done 4) Now we can start Firefox 3 if we set our LD_LIBRARY_PATH properly. export LD_LIBRARY_PATH=/opt/gtk2.10/usr/lib:${LD_LIBRARY_PATH+":$LD_LIBRARY_PATH"} firefox You can create a shell script like this to start firefox 3: #! /bin/sh export LD_LIBRARY_PATH=/opt/gtk2.10/usr/lib:${LD_LIBRARY_PATH+":$LD_LIBRARY_PATH"} /home/user/progs/firefox/firefox
But that still being a GTK+ requirement. Why Firefox cant be like Opera?? Using only better compatibility with certain libs (like Qt), and not DEPENDING of a library, size is more higher, and times of compilations are BIGGER (im a gentoo user, but other users like Slack, etc). PD: Another user of EeePC :P
Depends on: 429369
Perhaps a solution might be to offer a special version with the appropriate GTK libraries statically linked into the binary, thus not requiring any of the old code to be supported?
Whiteboard: [not needed for 1.9]
Fernando, your "solution" to make works Firefox on debian etch have a conseguence: the extra mouse buttons (like side-buttons on logitech mx series), and keyboard shortcuts are changed at the gnome default, instead of using the kde shorcut by clicking on "Use my KDE style in GTK applications" of "kcmshell kcmgtk" commands. How can be solved this? If I press CTRL+F instead of search will open the xterm, if I press the side button don't do nothing instead of go back/forward on pages. That's boring!
So please update webpage http://www.mozilla-europe.org/en/firefox/system-requirements/ to explicitly say which version is really needed. Or provide staticly linked version.
I found that in Red Hat EL4, Firefox3 required some evolution28 packages - pango, atk, cairo, glib2, gtk2. Installing evolution28-gtk2-2.10.4-21 solved the gtk 2.10 dependency and Firefox is running great. YMMV. http://rpmfind.net/linux/rpm2html/search.php?query=evolution28-gtk2
I'm sorry to have re-reported this bug. I didn't find the original one. Anyway please consider the argument shown here: https://bugzilla.mozilla.org/show_bug.cgi?id=446337 There's people defending that "every distro should handle the situation", which I find amazing... because it won't happen. Distros like Fedora and Mandriva, without LTS won't have any new packages and FF3 will not run. Even for the distros that will handle this it is a waste of resources to have each one making new packages. Firefox is a very dynamic component and should "just work" on Linux as it does on Windows. Does FF3 fail to install on Windows 2000 which is 8 (eight) years old? No. So my suggestion is having a self-contained FF3 build which just works. Yes, it's alright if it takes more space to include the necessary libs.
So, that people have an idea of what it takes to install FF3 on say, Mandriva 2006, in a way that can be repeated to many workstations, please look at the Gtk+ related packages here: http://downloads.angulosolido.pt/LoginDesktop/testing/ FF3 itself is not there yet.
Comment on attachment 308852 [details] [diff] [review] Patch 3 +ing this because the patch looked OK. whether we take it or not is a policy decision that's not mine.
Attachment #308852 - Flags: superreview?(roc)
Attachment #308852 - Flags: superreview+
Attachment #308852 - Flags: review?(roc)
Attachment #308852 - Flags: review+
For future follow up on the relevant bug. Here is my original bug report. ---------- Firefox System Requirements: * Windows 2000 (8 year old OS) * Windows XP * Windows Server 2003 * Windows Vista * Linux with GTK+ 2.10 (1 year old at most) Source: http://www.mozilla.com/en-US/firefox/system-requirements.html The problem: It is a major mess to install Firefox 3 on Linux, except on a very new distribution. Some facts: - Business users do not upgrade distributions every year - It's common to use the same distribution with surgical updates for 3-4 years - Firefox is a very important package and business users use it for critical tasks - Users that work on 2 year old distros should still be able to have Firefox Practical case: A 20 workstation network with a 2 year old distribution (GTK+ 2.8): - firefox 3 doesn't work - either upgrade the whole distro (reconfigure hw, backup data, etc) or install GTK+ 2.10 - in order to install GTK+ 2.10 one must install Cairo, Pango, Libglib and other dependencies - this means creating packages and throwing them on a custom repository, unless one wants to mess up every single machine manually with packages on /usr/local - 22 packages had to be backported (rpm --rebuild), while others had to be recreated due to backport problems (./configure, make, checkinstall) - this took 3 days of specialized manpower, is distribution-specific, so doesn't help all the others with the same problem Conclusion: - the FF3 dependencies are not a good idea - FF3 will spread more slowly on Linux under these conditions - FF3 will pass a negative image of Linux when you compare the dificulty of installation with Windows (even windows2000 which is 8 years old) Solution: A self-contained Firefox 3 package that includes Gtk+ 2.10 and installs on generic Linux distro, could be created.
(In reply to comment #79) > - in order to install GTK+ 2.10 one must install Cairo, Pango, Libglib and > other dependencies Upgrading to gtk+ 2.10 on old distributions is safe. all you need is to upgrade glib, pango and gtk+ and rebuild gtk-engines. It won't break older applications.
There's also cairo. (sorry for the spam).
(In reply to comment #80) > (In reply to comment #79) > > - in order to install GTK+ 2.10 one must install Cairo, Pango, Libglib and > > other dependencies > > Upgrading to gtk+ 2.10 on old distributions is safe. all you need is to >upgrade glib, pango and gtk+ and rebuild gtk-engines. It won't break older >applications. Unless you suggest that one should rebuild all these packages on every client machine that needs to have Firefox 3 installed (installing all -dev packages and compiler) one needs to backport 20+ RPM packages and take care of the corresponding dependencies to ensure the upgrade is possible. This is absolutely unfeasible for the average user/admin. My team has actually backported every Gtk+ dependency (22 RPM packages including pango, cairo, gdk, glib, perl-cairo, perl-glib,...), only to find out that Firefox crashes on printing, for some yet unknown reason: https://bugzilla.mozilla.org/show_bug.cgi?id=449232 The result so far is: we can't run Firefox 3. We will have to upgrade 100+ *stable* *production* machines when Firefox 2 ends. Is this really a good way to spread Firefox?
(In reply to comment #80) > > Upgrading to gtk+ 2.10 on old distributions is safe. all you need is to upgrade > glib, pango and gtk+ and rebuild gtk-engines. It won't break older > applications. > *Every* upgrade is *risky*. And we are talking about libraries which tons of applications use! This is unaccaptable for production systems. (And if it is a home machine, it is very tiresome and maybe impossible to build all these libraries)
And the beast came forth surrounded by libraries, who keep its once best friends, away from its beauty. And a thousand houses will burn; A million systems will break under screams of horror; for the beast has changed for good. The Book of Mozilla - 3:0:1 (After another Gtk+ upgrade the final number of backported pacakges is 25)
Thankfully Debian 5 will be out in a few weeks^Wmonths^Wquarters.
Should this bug now be closed as WONTFIX?
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: