Hello,
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished version and we appreciate if you test it and report all issues to bugzilla (like missing locales, broken plugins and so on).
If you're interested and don't want to switch to rawhide, you can run Firefox 3 on Fedora 8, too. Just download and compile the latest xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install firefox from rawhide.
There's one side effect of this update. The former firefox-devel package has been removed from rawhide and gecko-libs 1.8 is no more shipped. All packages have to run with xulrunner (gecko-libs 1.9) now.
If you're a package maintainer and your package already uses xulrunner, please rebuild it against the new rawhide version. Xulrunner directory has been changed and many gecko packages (if not all) are linked with --rpath linker directive. As long as rpath is used you have to rebuild gecko-libs based packages after each xulrunner change so please consider to remove it. Gecko libraries are registered system wide by /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
Happy testing&hacking! :)
ma.
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
Hello,
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished version and we appreciate if you test it and report all issues to bugzilla (like missing locales, broken plugins and so on).
If you're interested and don't want to switch to rawhide, you can run Firefox 3 on Fedora 8, too. Just download and compile the latest xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install firefox from rawhide.
There's one side effect of this update. The former firefox-devel package has been removed from rawhide and gecko-libs 1.8 is no more shipped. All packages have to run with xulrunner (gecko-libs 1.9) now.
If you're a package maintainer and your package already uses xulrunner, please rebuild it against the new rawhide version. Xulrunner directory has been changed and many gecko packages (if not all) are linked with --rpath linker directive. As long as rpath is used you have to rebuild gecko-libs based packages after each xulrunner change so please consider to remove it. Gecko libraries are registered system wide by /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
Happy testing&hacking! :)
ma.
Hi,
That's good news! Just some little questions. Has epiphany been ported on xulrunner or do I need to wait just a little more to upgrade firefox?
Are you interested also in gtk rendering issues? I noticed so far (using mozilla's nightly builds of FF3) that the close buttons on tabs aren't highlighted on mouseover action and checkboxes and radiobuttons seems to have slightly wrong positioning when displayed on web pages. Also widget's backgrounds seem to be derived from window's background, but IMHO it should be derived from page element background it is on (but this is really just a small issue).
Thanks, Martin
Martin Sourada wrote:
That's good news! Just some little questions. Has epiphany been ported on xulrunner or do I need to wait just a little more to upgrade firefox?
Epiphany in rawhide still runs with firefox-devel, xulrunner support will be included in epiphany-2.22.
Are you interested also in gtk rendering issues? I noticed so far (using mozilla's nightly builds of FF3) that the close buttons on tabs aren't highlighted on mouseover action and checkboxes and radiobuttons seems to have slightly wrong positioning when displayed on web pages. Also widget's backgrounds seem to be derived from window's background, but IMHO it should be derived from page element background it is on (but this is really just a small issue).
Please check if that issues are in the fedora package and when they are not fedora related please report them at upstream. We generally don't have an ability to fix all bugs.
ma.
On 12/20/2007 09:41 AM, Martin Sourada wrote:
That's good news! Just some little questions. Has epiphany been ported on xulrunner or do I need to wait just a little more to upgrade firefox?
Christian Persch has a private branch that he's been working on that he hasn't released yet, to get it to more or less work. He said he wants to clean up the code for it, but it depends on when he feels like releasing it. I'm not sure when that will be, but hopefully soon. :-)
Are you interested also in gtk rendering issues?
Getting linux type issues sorted is one of the reasons we're shipping FF3 in rawhide now. Before it becomes final and "too late" to fix any non-security/stability type things.
Please report bugs upstream since we're taking it pretty much as-is. Additionally, please check any bugs you may have filed in RH bugzilla about firefox 2, to see if they still exist in FF3.
I noticed so far (using mozilla's nightly builds of FF3) that the close buttons on tabs aren't highlighted on mouseover action and checkboxes and radiobuttons seems to have slightly wrong positioning when displayed on web pages.
Please report it upstream, if you haven't! Nobody can fix it without knowing about it. This is the reason it's a beta still.
Also widget's backgrounds seem to be derived from window's background, but IMHO it should be derived from page element background it is on (but this is really just a small issue).
More upstream, please :-)
On Thu, 2007-12-20 at 13:43 +0100, Christopher Aillon wrote:
On 12/20/2007 09:41 AM, Martin Sourada wrote:
That's good news! Just some little questions. Has epiphany been ported on xulrunner or do I need to wait just a little more to upgrade firefox?
Christian Persch has a private branch that he's been working on that he hasn't released yet, to get it to more or less work. He said he wants to clean up the code for it, but it depends on when he feels like releasing it. I'm not sure when that will be, but hopefully soon. :-)
Are you interested also in gtk rendering issues?
Getting linux type issues sorted is one of the reasons we're shipping FF3 in rawhide now. Before it becomes final and "too late" to fix any non-security/stability type things.
Please report bugs upstream since we're taking it pretty much as-is. Additionally, please check any bugs you may have filed in RH bugzilla about firefox 2, to see if they still exist in FF3.
I noticed so far (using mozilla's nightly builds of FF3) that the close buttons on tabs aren't highlighted on mouseover action and checkboxes and radiobuttons seems to have slightly wrong positioning when displayed on web pages.
Please report it upstream, if you haven't! Nobody can fix it without knowing about it. This is the reason it's a beta still.
Also widget's backgrounds seem to be derived from window's background, but IMHO it should be derived from page element background it is on (but this is really just a small issue).
More upstream, please :-)
OK, will do when I am at home :)
Thanks, Martin
Hi.
On Thu, 20 Dec 2007 09:22:46 +0100, Martin Stransky wrote:
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished version and we appreciate if you test it and report all issues to bugzilla (like missing locales, broken plugins and so on).
Does not start for me (says "Could not fild compatible GRE between version 1.9b3pre and 1.9b3pre"). I just pulled the firefox RPM from koji and installed, so all deps are met.
Ralf Ertzinger wrote:
Hi.
On Thu, 20 Dec 2007 09:22:46 +0100, Martin Stransky wrote:
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished version and we appreciate if you test it and report all issues to bugzilla (like missing locales, broken plugins and so on).
Does not start for me (says "Could not fild compatible GRE between version 1.9b3pre and 1.9b3pre"). I just pulled the firefox RPM from koji and installed, so all deps are met.
Had the same problem. Seems like it needs xulrunner from koji as well. After I installed that it starts fine (although most of my Add-ons are incompatible).
Rgds.
Ola (T)
Hi.
On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote:
Had the same problem. Seems like it needs xulrunner from koji as well. After I installed that it starts fine (although most of my Add-ons are incompatible).
adding "extensions.checkCompatibility = false" to about:config got some of them back (especially adblock, which is quite essential).
On Thu, 2007-12-20 at 11:22 +0100, Ralf Ertzinger wrote:
Hi.
On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote:
Had the same problem. Seems like it needs xulrunner from koji as well. After I installed that it starts fine (although most of my Add-ons are incompatible).
adding "extensions.checkCompatibility = false" to about:config got some of them back (especially adblock, which is quite essential).
Does it work OK with java-icedtea-plugin and also flash?
On Thu, 20 Dec 2007 14:23:43 +0100 Ralf Ertzinger fedora@camperquake.de wrote:
Java-Applets that work with icedtea (even in Firefox 2).
Huh. Every java applet I've come across has worked in IcedTea.
Hi.
On Thu, 20 Dec 2007 08:50:09 -0500, Jesse Keating wrote:
Java-Applets that work with icedtea (even in Firefox 2).
Huh. Every java applet I've come across has worked in IcedTea.
Well, most of those I come across don't. Not that I care about Java applets in general, but from time to time I look at the state of icedtea.
On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote:
Huh. Every java applet I've come across has worked in IcedTea.
Sorry, but situation is not that rosy. Trivial applets work, that's true, but more complicated (and interesting ones) depend on LiveConnect, and those break badly.
In fact, for some cases the situation is worse than not having Java, because it looks like its available (and thus prevent a decent fallback), and when they start they block/crash the browser.
* Dimi Paun dimi@lattica.com [2007-12-20 09:50]:
On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote:
Huh. Every java applet I've come across has worked in IcedTea.
Sorry, but situation is not that rosy. Trivial applets work, that's true, but more complicated (and interesting ones) depend on LiveConnect, and those break badly.
This is being worked on. It's not trivial and there is no free implementation at the moment. I'm sure Tom Fitzsimmons and others would love help in this area if anyone is able to give it.
Andrew
On Thu, 20 Dec 2007 09:49:49 -0500 Dimi Paun dimi@lattica.com wrote:
Sorry, but situation is not that rosy. Trivial applets work, that's true, but more complicated (and interesting ones) depend on LiveConnect, and those break badly.
In fact, for some cases the situation is worse than not having Java, because it looks like its available (and thus prevent a decent fallback), and when they start they block/crash the browser.
How much of that is icedtea vs just not being java 1.5 or 1.4, given that icedtea is 1.7 I think.
* Jesse Keating jkeating@redhat.com [2007-12-20 10:00]:
On Thu, 20 Dec 2007 09:49:49 -0500 Dimi Paun dimi@lattica.com wrote:
Sorry, but situation is not that rosy. Trivial applets work, that's true, but more complicated (and interesting ones) depend on LiveConnect, and those break badly.
In fact, for some cases the situation is worse than not having Java, because it looks like its available (and thus prevent a decent fallback), and when they start they block/crash the browser.
How much of that is icedtea vs just not being java 1.5 or 1.4, given that icedtea is 1.7 I think.
None. LiveConnect is the java<->javascript bridge. Tom Fitzsimmons is working on it.
Andrew
On Dec 20, 2007 5:49 AM, Dimi Paun dimi@lattica.com wrote:
On Thu, 2007-12-20 at 08:50 -0500, Jesse Keating wrote:
Huh. Every java applet I've come across has worked in IcedTea.
Sorry, but situation is not that rosy. Trivial applets work, that's true, but more complicated (and interesting ones) depend on LiveConnect, and those break badly.
All I know is, the realtime display java applet for the superdarn radar system works... and that's all i need.
-jef"Now if I could just get the license of superdarn related C libraries changed so I could re-distribute them, I could start submitting packages to Fedora and work on a superdarn spin"spaleta
On Thu, Dec 20, 2007 at 08:50:09AM -0500, Jesse Keating wrote:
On Thu, 20 Dec 2007 14:23:43 +0100 Ralf Ertzinger fedora@camperquake.de wrote:
Java-Applets that work with icedtea (even in Firefox 2).
Huh. Every java applet I've come across has worked in IcedTea.
Citrix Java ICA client doesnt work with IcedTea. Worse, native ICA client has bugs with seamless windows. Workaround is to disable seamless windows. -- Michael
Jesse Keating Ãrta:
On Thu, 20 Dec 2007 14:23:43 +0100 Ralf Ertzinger fedora@camperquake.de wrote:
Java-Applets that work with icedtea (even in Firefox 2).
Huh. Every java applet I've come across has worked in IcedTea.
Head in the sand, ostrich? :-) Please try this link, a gaming site: http://jojatek.hu/indexold.html At the left column you will find single-person games. I tried some, none worked. Try e.g. REX at the end of the page, both i386 and x86_64 Firefox/IcedTea shows "Applet not initialized" after loading the applet. Sun Java 1.6u3 works for the FF2/i386.
Best regards, Zoltán Böszörményi
On Dec 25, 2007 10:48 AM, Zoltan Boszormenyi zboszor@freemail.hu wrote:
Please try this link, a gaming site: http://jojatek.hu/indexold.html
do you have to register to play them? I don't understand the language, so it's difficult to know how to get to the games, just clicking on the title takes me to what looks like a registration page.
In contrast, the free non-registation games I've tried listed at http://www.java.com/en/games/ are working in IcedTea.
http://www.java.com/en/games/desktop/astrocrusher.jsp looks like a great 5 minute time waster.
-jef
Jeff Spaleta Ãrta:
On Dec 25, 2007 10:48 AM, Zoltan Boszormenyi zboszor@freemail.hu wrote:
Please try this link, a gaming site: http://jojatek.hu/indexold.html
do you have to register to play them? I don't understand the language, so it's difficult to know how to get to the games, just clicking on the title takes me to what looks like a registration page.
The button with the text "Belépés próbajátékra" should give you the game without registering. It's something like "Enter for a trial game". Registering has the advantage of keeping your own high scores, etc.
In contrast, the free non-registation games I've tried listed at http://www.java.com/en/games/ are working in IcedTea.
http://www.java.com/en/games/desktop/astrocrusher.jsp looks like a great 5 minute time waster.
-jef
On 12/20/2007 02:17 PM, Mike Chambers wrote:
On Thu, 2007-12-20 at 11:22 +0100, Ralf Ertzinger wrote:
Hi.
On Thu, 20 Dec 2007 10:58:32 +0100, Ola Thoresen wrote:
Had the same problem. Seems like it needs xulrunner from koji as well. After I installed that it starts fine (although most of my Add-ons are incompatible).
adding "extensions.checkCompatibility = false" to about:config got some of them back (especially adblock, which is quite essential).
Does it work OK with java-icedtea-plugin and also flash?
To avoid answering everyone's "does it work with XYZ?" questions, I'm going to suggest you try it and file bugs if it doesn't. :-)
On Thu, 2007-12-20 at 07:17 -0600, Mike Chambers wrote:
Does it work OK with java-icedtea-plugin and also flash?
On two x86_64s, one running Fedora 7 and the other 8, it runs the flash-plugin quite well (mostly YouTube) and IcedTea java plugin seems to run this applet alright:
http://www.java.com/en/download/help/testvm.xml
Again, that's on x86_64. --
Richi Plana
On Dec 20, 2007 8:22 AM, Martin Stransky stransky@redhat.com wrote:
Hello,
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished version and we appreciate if you test it and report all issues to bugzilla (like missing locales, broken plugins and so on).
If you're interested and don't want to switch to rawhide, you can run Firefox 3 on Fedora 8, too. Just download and compile the latest xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install firefox from rawhide.
There's one side effect of this update. The former firefox-devel package has been removed from rawhide and gecko-libs 1.8 is no more shipped. All packages have to run with xulrunner (gecko-libs 1.9) now.
If you're a package maintainer and your package already uses xulrunner, please rebuild it against the new rawhide version. Xulrunner directory has been changed and many gecko packages (if not all) are linked with --rpath linker directive. As long as rpath is used you have to rebuild gecko-libs based packages after each xulrunner change so please consider to remove it. Gecko libraries are registered system wide by /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
Happy testing&hacking! :)
Is anyone seeing issues with adding sites with problematic SSL cert (self generated etc) to the exceptions list? I get the error "If you still wish to add an exception for this site, you can do so in your advanced encryption settings." but if I go into prefs -> advanced -> encryption I don't see the option to add exceptions. Or am i just looking in the wrong location. Other than that its excellent!
Peter
On Thu, 20 Dec 2007 16:06:19 +0000 "Peter Robinson" pbrobinson@gmail.com wrote:
Is anyone seeing issues with adding sites with problematic SSL cert (self generated etc) to the exceptions list? I get the error "If you still wish to add an exception for this site, you can do so in your advanced encryption settings." but if I go into prefs -> advanced -> encryption I don't see the option to add exceptions. Or am i just looking in the wrong location. Other than that its excellent!
You have to click on View Certificates.
Is anyone seeing issues with adding sites with problematic SSL cert (self generated etc) to the exceptions list? I get the error "If you still wish to add an exception for this site, you can do so in your advanced encryption settings." but if I go into prefs -> advanced -> encryption I don't see the option to add exceptions. Or am i just looking in the wrong location. Other than that its excellent!
You have to click on View Certificates.
Ah yes. So you do. So intuitive :)
Thanks for your help.
Pete
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
[snip]
If you're a package maintainer and your package already uses xulrunner, please rebuild it against the new rawhide version. Xulrunner directory has been changed and many gecko packages (if not all) are linked with --rpath linker directive. As long as rpath is used you have to rebuild gecko-libs based packages after each xulrunner change so please consider to remove it. Gecko libraries are registered system wide by /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
But isn't it the case that the libraries in question do not have soversions?
If the rpath is eliminated, how do we know when things really *do* need to break?
Braden McDaniel wrote:
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
[snip]
If you're a package maintainer and your package already uses xulrunner, please rebuild it against the new rawhide version. Xulrunner directory has been changed and many gecko packages (if not all) are linked with --rpath linker directive. As long as rpath is used you have to rebuild gecko-libs based packages after each xulrunner change so please consider to remove it. Gecko libraries are registered system wide by /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
But isn't it the case that the libraries in question do not have soversions?
If the rpath is eliminated, how do we know when things really *do* need to break?
gecko-libs 1.9 exports only frozen interfaces so ideally we don't need to rebuild any package unless we move to a completely new gecko (firefox 4 ;-))
Martin Stransky wrote:
Braden McDaniel wrote:
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
[snip]
If you're a package maintainer and your package already uses xulrunner, please rebuild it against the new rawhide version. Xulrunner directory has been changed and many gecko packages (if not all) are linked with --rpath linker directive. As long as rpath is used you have to rebuild gecko-libs based packages after each xulrunner change so please consider to remove it. Gecko libraries are registered system wide by /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
But isn't it the case that the libraries in question do not have soversions?
If the rpath is eliminated, how do we know when things really *do* need to break?
gecko-libs 1.9 exports only frozen interfaces so ideally we don't need to rebuild any package unless we move to a completely new gecko (firefox 4 ;-))
I don't find that rationale particularly confidence-inspiring. (Since when did software development proceed "ideally"? ;-)
Are we sure there are no external symbols accessible from public headers that aren't considered "frozen"? Or are we just sure that blessed interfaces are frozen?
I don't like the idea of playing without a net here. soversions are how we track backward compatibility; software that doesn't follow conventions *should* be handled with the kind of caution that is reflected in (for example) an rpath. It's a pain in the ass because it breaks a lot. But it breaks *predictably*. I'm sure I'm as unhappy with the rebuilds as anyone; but I *like* determinism *a lot*.
Do we have any statements of intent from upstream regarding these issues? A commitment to change library names when frozen interfaces change, perhaps?
Miro needs updating, I think.
(This is on f8) --> Finished Dependency Resolution Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package Miro
Neal Becker wrote:
Miro needs updating, I think.
(This is on f8) --> Finished Dependency Resolution Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package Miro
And then there's this:
ERROR with rpm_check_debug vs depsolve: Package devhelp needs libgtkembedmoz.so, this is not available. Package devhelp needs gecko-libs = 1.8.1.10, this is not available. Package devhelp needs gecko-libs = 1.8.1.10, this is not available.
"NB" == Neal Becker writes:
NB> Miro needs updating, I think. (This is on f8) --> Finished Dependency Resolution NB> Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by NB> package Miro
Unfortunately this isn't as simple as a rebuild, this requires upstream changes to enable Miro to compile against xulrunner:
https://bugzilla.redhat.com/show_bug.cgi?id=393521
There's a minimal patch on that bug, but it's incomplete and will need further work upstream to get it work properly (according to Martin Stransky, xulrunner maintainer). I've filed this bug upstream:
http://bugzilla.pculture.org/show_bug.cgi?id=9370
but have had no response yet. (I'll try to bug the Miro maintainers on IRC).
Many packages don't current compile out of the box against xulrunner unfortunately and require patches and/or adding support from-scratch in upstream, see the full list here:
http://fedoraproject.org/wiki/Releases/FeatureXULRunner
This will take a *lot* of work from various packagers to make sure that F-9 works out of the box. With all the packages that used to build against firefox and we should probably bug all those package maintainers to test the various packages and/or report things against upstream to give them time to fix them so these packages work properly. Otherwise, I fear, Release Engineering will be forced drop them from the next release (at least from the the final package list).
Alex
Alex Lancaster wrote:
This will take a *lot* of work from various packagers to make sure that F-9 works out of the box. With all the packages that used to build against firefox and we should probably bug all those package maintainers to test the various packages and/or report things against upstream to give them time to fix them so these packages work properly.
Since i maintain galeon, i got word from an upstream developer that xulrunner is still not exactly in a nice state to work with. To quote him: "I'm holding off on this until mozilla sorts out the microb problem. Apparently a good chunk of the brokenness is due to a bunch of unreviewed microb (the n800 browser) patches being committed. They claim they are going to back them out. Hopefully after that, [galeon] won't be so crippled.".
Galeon now compiles thanks to Martin's patch, but it still has a number of issues and disabled features..
I know almost nothing about mozilla/xulrunner upstream development, but I have to ask: it's not just them (the packages that depend on firefox) that have to be ready for xulrunner, will xulrunner also be ready for them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?)
Otherwise, I fear, Release Engineering will be forced drop them from the next release (at least from the the final package list)
If it comes to that, I hope we can debate whether it should not be xulrunner that gets dropped and firefox-devel restored (assuming that's even possible).
-denis
Denis Leroy wrote:
Since i maintain galeon, i got word from an upstream developer that xulrunner is still not exactly in a nice state to work with. To quote him: "I'm holding off on this until mozilla sorts out the microb problem. Apparently a good chunk of the brokenness is due to a bunch of unreviewed microb (the n800 browser) patches being committed. They claim they are going to back them out. Hopefully after that, [galeon] won't be so crippled.".
I know almost nothing about mozilla/xulrunner upstream development, but I have to ask: it's not just them (the packages that depend on firefox) that have to be ready for xulrunner, will xulrunner also be ready for them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?)
I hope this will be fixed before the final firefox 3 release. If you have any serious problem please file a bug at bugzilla.mozilla.org (or bugzilla.redhat.com and I'll move it upstream).
Things are still fresh and any feedback is highly appreciated.
If it comes to that, I hope we can debate whether it should not be xulrunner that gets dropped and firefox-devel restored (assuming that's even possible).
We are not going to ship two firefox versions (2 and 3). Xulrunner-devel is generally a firefox3-devel package, there isn't any difference and I believe all developers will be able to transfer their packages to Firefox 3 (or xulrunner in our distro).
Martin
Martin Stransky wrote:
Denis Leroy wrote:
Since i maintain galeon, i got word from an upstream developer that xulrunner is still not exactly in a nice state to work with. To quote him: "I'm holding off on this until mozilla sorts out the microb problem. Apparently a good chunk of the brokenness is due to a bunch of unreviewed microb (the n800 browser) patches being committed. They claim they are going to back them out. Hopefully after that, [galeon] won't be so crippled.".
I know almost nothing about mozilla/xulrunner upstream development, but I have to ask: it's not just them (the packages that depend on firefox) that have to be ready for xulrunner, will xulrunner also be ready for them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?)
I hope this will be fixed before the final firefox 3 release. If you have any serious problem please file a bug at bugzilla.mozilla.org (or bugzilla.redhat.com and I'll move it upstream).
Things are still fresh and any feedback is highly appreciated.
If it comes to that, I hope we can debate whether it should not be xulrunner that gets dropped and firefox-devel restored (assuming that's even possible).
We are not going to ship two firefox versions (2 and 3). Xulrunner-devel is generally a firefox3-devel package, there isn't any difference and I believe all developers will be able to transfer their packages to Firefox 3 (or xulrunner in our distro).
Ah i see, so the porting problems stem from the transition to firefox 3 (gecko 1.9), not so much from the the xulrunner packaging transition. That makes sense, thanks.
Finally had a chance to try galeon on rawhide (tough to run rawhide on vmware currently), unfortunately it segfaults on startup.
Maybe we should create a firefox/mozilla/xulrunner SIG, to bring together the people that are comfortable around mozilla code ? The SIG page could track the various porting efforts to gecko 1.9.
On 12/23/2007 12:27 AM, Denis Leroy wrote:
I know almost nothing about mozilla/xulrunner upstream development, but I have to ask: it's not just them (the packages that depend on firefox) that have to be ready for xulrunner, will xulrunner also be ready for them ? :-) (i.e. with enough time for maintainers/upstream to port/debug ?)
As a maintainer of gecko-dependent packages, you're on the hook for determining this. The code is still beta. If it isn't ready for your application(s) to make use of it, you should make sure bugs get filed. With either Mozilla or your package's upstream(s) or both. This is sort of the whole purpose of sticking XULRunner in now... so we can find any showstopper bugs and get them fixed.
On Thu, 20 Dec 2007, Martin Stransky wrote:
Hello,
Firefox 3 has finally landed in Rawhide. It's a slightly unpolished version and we appreciate if you test it and report all issues to bugzilla (like missing locales, broken plugins and so on).
If you're interested and don't want to switch to rawhide, you can run Firefox 3 on Fedora 8, too. Just download and compile the latest xulrunner (xulrunner-1.9-0.beta2.1.fc9) and then compile and install firefox from rawhide.
I have installed it on F8 and it seems to have brought back the annoying behaviour of moving the Firefox window when opening a link. Is this Fedora-specific?
Adam Huffman wrote:
I have installed it on F8 and it seems to have brought back the annoying behaviour of moving the Firefox window when opening a link. Is this Fedora-specific?
Please check the generic upstream version (http://developer.mozilla.org/devnews/index.php/2007/12/18/firefox-3-beta-2-n...)
On Sun, 2007-12-23 at 10:09 +0100, Martin Stransky wrote:
Adam Huffman wrote:
I have installed it on F8 and it seems to have brought back the annoying behaviour of moving the Firefox window when opening a link. Is this Fedora-specific?
Please check the generic upstream version (http://developer.mozilla.org/devnews/index.php/2007/12/18/firefox-3-beta-2-n...)
I was going to post about this, too (FF3 window popping up in the virtual desktop that the user is in around the time a link is clicked), but assumed that it had always been the behavior of the upstream version of FF (including ver. 2) and that we were just applying patches to it in Fedora to adopt a different behavior.
So that isn't the case? --
Richi Plana
On 12/22/2007 05:42 PM, Adam Huffman wrote:
I have installed it on F8 and it seems to have brought back the annoying behaviour of moving the Firefox window when opening a link. Is this Fedora-specific?
This is a metacity bug[1].
walters added a patch to our rawhide metacity package, which ought to be fixed in metacity-2.21.5-2.fc9.
I don't know what's causing this: gcjwebplugin.cc:1045: thread 0x821fb0: Error: Failed to spawn applet viewer: Failed to execute child process "/usr/lib64/mozilla/plugins/../../bin/pluginappletviewer" (No such file or directory)
So 2 things about this: 1) gcjwebplugin? I thought iced-tea replaced gcj. 2) Obviously that path is wrong - but I have clue where it came from
To make things complicated, I have nspluginwrapper installed. But, I expect most Fedora x86_64 users also do.
Neal Becker wrote:
I don't know what's causing this: gcjwebplugin.cc:1045: thread 0x821fb0: Error: Failed to spawn applet viewer: Failed to execute child process "/usr/lib64/mozilla/plugins/../../bin/pluginappletviewer" (No such file or directory)
So 2 things about this:
- gcjwebplugin? I thought iced-tea replaced gcj.
- Obviously that path is wrong - but I have clue where it came from
To make things complicated, I have nspluginwrapper installed. But, I expect most Fedora x86_64 users also do.
After removing nspluginwrapper, the problem is removed. BTW, I was testing using this page: http://www.java.com/en/download/help/testvm.xml
For me it refuses to load any site until I change "network.dns.disableIPv6" to "true" So I propose to make this the default ..
On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote:
For me it refuses to load any site until I change "network.dns.disableIPv6" to "true" So I propose to make this the default ..
Works fine for me without doing that. Let's not supposedly "fix" things by crippling new functionality and discouraging adoption of new technology, shall we? What is the real problem here? We should be focused on fixing that instead.
On Dec 23, 2007 1:43 AM, Chuck Anderson cra@wpi.edu wrote:
On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote:
For me it refuses to load any site until I change "network.dns.disableIPv6" to "true" So I propose to make this the default ..
Works fine for me without doing that. Let's not supposedly "fix" things by crippling new functionality and discouraging adoption of new technology, shall we? What is the real problem here? We should be focused on fixing that instead.
the problem is that it does not work with some ISP .. and thats not something that we can fix that easily (well or we can try to add some fallback logic)
drago01 wrote:
On Dec 23, 2007 1:43 AM, Chuck Anderson cra@wpi.edu wrote:
On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote:
For me it refuses to load any site until I change "network.dns.disableIPv6" to "true" So I propose to make this the default ..
Works fine for me without doing that. Let's not supposedly "fix" things by crippling new functionality and discouraging adoption of new technology, shall we? What is the real problem here? We should be focused on fixing that instead.
the problem is that it does not work with some ISP .. and thats not something that we can fix that easily (well or we can try to add some fallback logic)
Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address locally while your ISP won't respond properly to IPv6 -> IPv4 nat translation? I'd suggest making sure your local network configuration has IPv6 disabled and see if that firefox now does not care whether IPv6 is not disabled.
If your ISP misbehaves, try not letting IPv6 traffic out of your machine (don't configure an address for the family). The application should not choose to try and generate IPv6 traffic if it is not told you have IPv6 connectivity.
Andrew Farris wrote:
drago01 wrote:
On Dec 23, 2007 1:43 AM, Chuck Anderson cra@wpi.edu wrote:
On Sun, Dec 23, 2007 at 12:16:40AM +0100, drago01 wrote:
For me it refuses to load any site until I change "network.dns.disableIPv6" to "true" So I propose to make this the default ..
Works fine for me without doing that. Let's not supposedly "fix" things by crippling new functionality and discouraging adoption of new technology, shall we? What is the real problem here? We should be focused on fixing that instead.
the problem is that it does not work with some ISP .. and thats not something that we can fix that easily (well or we can try to add some fallback logic)
Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address locally while your ISP won't respond properly to IPv6 -> IPv4 nat translation? I'd suggest making sure your local network configuration has IPv6 disabled and see if that firefox now does not care whether IPv6 is not disabled.
If your ISP misbehaves, try not letting IPv6 traffic out of your machine (don't configure an address for the family). The application should not choose to try and generate IPv6 traffic if it is not told you have IPv6 connectivity.
well my ISP is connected to a wireless router and I got the configuration over dhcp from the router. There seems to be indeed a ipv6 adress assigned to the interface in question (dunno why maybe because the router does support ipv6 but the ISP does not). nevertheless if ipv6 does not work it should atleast fall back to ipv4. I know how to deal with this but I doubt that all other users affected will be able to deal with it. And a webbrowser _must_ work out of the box .. else they cannot even try to google for a solution etc.
drago01 wrote:
Andrew Farris wrote:
drago01 wrote:
On Dec 23, 2007 1:43 AM, Chuck Anderson cra@wpi.edu wrote: the problem is that it does not work with some ISP .. and thats not something that we can fix that easily (well or we can try to add some fallback logic)
Is it perhaps 'prefering' IPv6 and you've configured an IPv6 address locally while your ISP won't respond properly to IPv6 -> IPv4 nat translation? I'd suggest making sure your local network configuration has IPv6 disabled and see if that firefox now does not care whether IPv6 is not disabled.
If your ISP misbehaves, try not letting IPv6 traffic out of your machine (don't configure an address for the family). The application should not choose to try and generate IPv6 traffic if it is not told you have IPv6 connectivity.
well my ISP is connected to a wireless router and I got the configuration over dhcp from the router. There seems to be indeed a ipv6 adress assigned to the interface in question (dunno why maybe because the router does support ipv6 but the ISP does not). nevertheless if ipv6 does not work it should atleast fall back to ipv4. I know how to deal with this but I doubt that all other users affected will be able to deal with it. And a webbrowser _must_ work out of the box .. else they cannot even try to google for a solution etc.
I agree that the primary browser *should just work*. But I do not think the right path is to go and disable IPv6 entirely by default (in a hidden option)... the longer this type of ad hoc 'fix' for ISPs that are not yet making the conversion the longer the entire internet will suffer with it.
The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails (and yes I know that is more work). In the meantime if it has an option to 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't think disabling it is a good option.
We still probably should not be enabling the IPv6 address unless requested by the users (for which there is a very obvious UI option already right in the network configuration), but that is a broader discussion that has happened a few times before.
On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote:
The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails (and yes I know that is more work). In the meantime if it has an option to 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't think disabling it is a good option.
We still probably should not be enabling the IPv6 address unless requested by the users (for which there is a very obvious UI option already right in the network configuration), but that is a broader discussion that has happened a few times before.
A better fix (and one that other subsystems could use) is a program that detects whether IPv6 will be a problem for the user and set a flag somewhere global that programs can check or scripts can recognize and thus set the defaults for programs like FF to enable or disable IPv6. Cascade effect from a global config to a minor. After all, if IPv6 isn't enabled in the Network layer, then applications shouldn't either.
It's an ugly solution for an ugly situation.
As for not enabling IPv6 by default, you'll find by going back through fedora-devel archives that you'll find just as many IPv6 proponents for the sake of enabling new technologies as you'll find anti-IPv6 for the sake of security/not-installing-unneeded-functionality/etc. Can o' worms for you. --
Richi Plana
On Dec 23, 2007 8:28 PM, Richi Plana myfedora@richip.dhs.org wrote:
On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote:
The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails (and yes I know that is more work). In the meantime if it has an option to 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't think disabling it is a good option.
We still probably should not be enabling the IPv6 address unless requested by the users (for which there is a very obvious UI option already right in the network configuration), but that is a broader discussion that has happened a few times before.
A better fix (and one that other subsystems could use) is a program that detects whether IPv6 will be a problem for the user and set a flag somewhere global that programs can check or scripts can recognize and thus set the defaults for programs like FF to enable or disable IPv6. Cascade effect from a global config to a minor. After all, if IPv6 isn't enabled in the Network layer, then applications shouldn't either.
It's an ugly solution for an ugly situation.
As for not enabling IPv6 by default, you'll find by going back through fedora-devel archives that you'll find just as many IPv6 proponents for the sake of enabling new technologies as you'll find anti-IPv6 for the sake of security/not-installing-unneeded-functionality/etc. Can o' worms for you.
I have no problem with ipv6 enabled by default as long as ipv4 only networks still work whit out requiring the user to change a hidden option. (as it did until now).
On Dec 23, 2007 9:00 PM, drago01 drago01@gmail.com wrote:
On Dec 23, 2007 8:28 PM, Richi Plana myfedora@richip.dhs.org wrote:
On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote:
The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails (and yes I know that is more work). In the meantime if it has an option to 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't think disabling it is a good option.
We still probably should not be enabling the IPv6 address unless requested by the users (for which there is a very obvious UI option already right in the network configuration), but that is a broader discussion that has happened a few times before.
A better fix (and one that other subsystems could use) is a program that detects whether IPv6 will be a problem for the user and set a flag somewhere global that programs can check or scripts can recognize and thus set the defaults for programs like FF to enable or disable IPv6. Cascade effect from a global config to a minor. After all, if IPv6 isn't enabled in the Network layer, then applications shouldn't either.
It's an ugly solution for an ugly situation.
As for not enabling IPv6 by default, you'll find by going back through fedora-devel archives that you'll find just as many IPv6 proponents for the sake of enabling new technologies as you'll find anti-IPv6 for the sake of security/not-installing-unneeded-functionality/etc. Can o' worms for you.
I have no problem with ipv6 enabled by default as long as ipv4 only networks still work whit out requiring the user to change a hidden option. (as it did until now).
one thing that I noticed: ipv6 is NOT disabled in firefox 2 but it still works for me. So this is a regression in firefox 3's ipv6/ipv4 handling.
On 12/23/2007 09:00 PM, drago01 wrote:
I have no problem with ipv6 enabled by default as long as ipv4 only networks still work whit out requiring the user to change a hidden option. (as it did until now).
So if you are having problems, file a bug at https://bugzilla.mozilla.org/
On Sun, Dec 23, 2007 at 12:28:37PM -0700, Richi Plana wrote:
On Sun, 2007-12-23 at 10:51 -0800, Andrew Farris wrote:
The correct fix is to make firefox fallback on IPv4 if an IPv6 address fails (and yes I know that is more work). In the meantime if it has an option to 'prefer IPv4' even if IPv6 is configured that might be fine, but I really don't think disabling it is a good option.
We still probably should not be enabling the IPv6 address unless requested by the users (for which there is a very obvious UI option already right in the network configuration), but that is a broader discussion that has happened a few times before.
A better fix (and one that other subsystems could use) is a program that detects whether IPv6 will be a problem for the user and set a flag somewhere global that programs can check or scripts can recognize and thus set the defaults for programs like FF to enable or disable IPv6. Cascade effect from a global config to a minor. After all, if IPv6 isn't enabled in the Network layer, then applications shouldn't either.
It's an ugly solution for an ugly situation.
As for not enabling IPv6 by default, you'll find by going back through fedora-devel archives that you'll find just as many IPv6 proponents for the sake of enabling new technologies as you'll find anti-IPv6 for the sake of security/not-installing-unneeded-functionality/etc. Can o' worms for you.
There is no technical reason why we should have to choose between enabling and disabling IPv6 in firefox. If it correctly follows the RFC 3484 for DNS resolution then it would 'just work'. Applications which are correctly written will use 'getaddrinfo' to resolve names. This will automatically decide whether to return IPv4 addrs, or IPv6 addrs or both, and will sort them in the order most likely to succeed. If you have only link-local IPv6 addresses (which all Fedora installs do by default) then it will *not* give you back IPv6 addrs since you can't reach them. Likewise if you have a site-local IPv6 address, it will not give you back IPv6 addrs that are out on the internet because they would not be routable. There's all sorts of rules on prioritization, but the effect is IPv4 & IPv6 will always be enable in the DNS lookup and apps should 'just work' whatever interface address config they have.
http://people.redhat.com/drepper/userapi-ipv6.html http://www.rfc-editor.org/rfc/rfc3484.txt
Dan.
On Dec 23, 2007 6:49 PM, Kevin Kofler kevin.kofler@chello.at wrote:
drago01 <drago01 <at> gmail.com> writes:
For me it refuses to load any site until I change "network.dns.disableIPv6" to "true" So I propose to make this the default ..
You can't be serious... Trying IPv4 first would make sense, but disabling IPv6 altogether?
disabling it seems to be too much .. but should atleast fallback to ipv4 when v6 does not work.
On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote:
[snip]
Gecko libraries are registered system wide by /etc/ld.so.conf.d and rpath should not be necessary in rawhide.
Does this also mean that rpm can be smart and "Requires: gecko-libs" is no longer necessary?
devel@lists.stg.fedoraproject.org
-
Adam Huffman -
Alex Lancaster -
Andrew Farris -
Andrew Overholt -
Braden McDaniel -
Christopher Aillon -
Chuck Anderson -
Daniel P. Berrange -
Denis Leroy -
Dimi Paun -
drago01 -
Janina Sajka -
Jef Spaleta -
Jesse Keating -
Kevin Kofler -
Martin Sourada -
Martin Stransky -
Michael E Brown -
Mike Chambers -
Neal Becker -
Ola Thoresen -
Peter Robinson -
Rahul Sundaram -
Ralf Ertzinger -
Richi Plana -
Zoltan Boszormenyi