[New Upstream] Firefox 3 RC2 is available

Bug #237690 reported by Nick Ellery on 2008-06-05
20
Affects Status Importance Assigned to Milestone
cairo (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
devhelp (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
epiphany-browser (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
firefox-3.0 (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
language-pack-de (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
nspr (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
nss (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
xulrunner-1.9 (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
yelp (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned

Bug Description

Binary package hint: firefox-3.0

Firefox 3 RC2 has been released upstream, and Hardy and Intrepid need to be updated.

In , Kliu (kliu) wrote :

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

In , Kliu (kliu) wrote :

Could you get a regression range?

Sorry, I was sick.

Scaling worked including version
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008033105 Minefield/3.0pre

It is broken since
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008040106 Minefield/3.0pre

I hope that helps!

In , Kliu (kliu) wrote :

Probably the result of bug 394103

--> Core::GFX/Thebes, I don't think this is a Firefox 3 blocker, but we'll want to fix it in one of the dot-dot updates, probably.

I'm a little worried that this is going to come down to a choice between addressing the concerns of those who filed bug 394103 or this one, though in that case, I think since those running into bug 394103 were hitting it due to kookiness in their Linux configs, this bug is gonna win.

In , Kliu (kliu) wrote :

I had marked bug 424822 as a dependency, as that would allow users to override the behavior added in bug 394103. Alternatively, the new behavior in bug 394103 could be reverted, and bug 424822 could be used to allow Linux users to hack around their problem. Either way, we'll need bug 424822.

I think at this point I'm more about reverting bug 394103, but again, I can wait until after we ship, I think.

Vlad believes that we should #ifdef MOZ_WIDGET_GTK2 the change from bug 394103, since the misrepresentation of DPI appears to be limited to Linux, and that's the conservative play. I have no reason to doubt him.

I guess whiteboard isn't one of the fields that bugzilla lies about in the mid-air message. ;(

Roc: can you implement the fix from comment 8 and put it up for review ASAP? Thanks!

Created an attachment (id=322574)
fix

(From update of attachment 322574)
Sure, add a comment at least referencing this bug number? (Or explaining what's going on, if you understand what the underlying issue is)

You mean something like
   // be more conservative about activating scaling on GTK2, since the dpi
   // information is more likely to be wrong
?

perfect :)

(From update of attachment 322574)
a=beltzner, please land on cvsroot asap

mozilla/gfx/src/thebes/nsThebesDeviceContext.cpp 1.78

...and the comment:
mozilla/gfx/src/thebes/nsThebesDeviceContext.cpp 1.79

Created an attachment (id=322801)
hppa.patch

This should do it(i've tested it)

Nick Ellery (nick.ellery) wrote :

Binary package hint: firefox-3.0

Firefox 3 RC2 has been released upstream, and Hardy and Intrepid need to be updated.

Richard Seguin (sectech) wrote :

Thank you for reporting this issue... Our firefox team actually gets updated on a regular basis about new releases... As a result I am closing out this bug as they have there own work flow methods on releases.

Richard Seguin

Changed in firefox-3.0:
status: New → Invalid

On Thu, Jun 05, 2008 at 05:43:32PM -0000, Richard Seguin wrote:
> Thank you for reporting this issue... Our firefox team actually gets
> updated on a regular basis about new releases... As a result I am
> closing out this bug as they have there own work flow methods on
> releases.
>
> Richard Seguin
>
> ** Changed in: firefox-3.0 (Ubuntu)
> Status: New => Invalid
>

Its ok to have it open as a tracking bug for this upgrade. We will do
it as soon as RC1 is out in hardy.

 affects ubuntu/firefox-3.0
 status confirmed
 affects ubuntu/xulrunner-1.9
 status confirmed

not yet sure if cairo needs to be updated for this.
 affects ubuntu/cairo
 status incomplete

not yet sure about nss/nspr ... if those are now final we should
probably update them too.

 affects ubuntu/nspr
 status incomplete
 affects ubuntu/nss
 status incomplete

not yet sure about epiphany, yelp and devhelp ... but most likely
thats not needed.

 affects ubuntu/epiphany-browser
 status incomplete
 affects ubuntu/yelp
 status incomplete
 affects ubuntu/devhelp
 status incomplete

language pack update should not be required from what i can tell ...

 affects ubuntu/language-pack-de
 status invalid

OK, thats it from my mind ... lets see what else comes up during QA.

 - Alexander

Changed in firefox-3.0:
status: Invalid → Confirmed
Changed in cairo:
status: New → Incomplete
Changed in devhelp:
status: New → Incomplete
Changed in epiphany-browser:
status: New → Incomplete
Changed in firefox-3.0:
status: New → Confirmed
Changed in language-pack-de:
status: New → Invalid
Changed in nspr:
status: New → Incomplete
Changed in nss:
status: New → Incomplete
Changed in xulrunner-1.9:
status: New → Confirmed
Changed in yelp:
status: New → Incomplete

(From update of attachment 322801)
>Index: configure.in
>===================================================================
>- if test "$CPU_ARCH" != "ia64" && test "$CPU_ARCH" != "sparc" \
>+ if test "$CPU_ARCH" != "hppa" && test "$CPU_ARCH" != "ia64" && test "$CPU_ARCH" != "sparc" \
> && test -z "$INTEL_CC"; then
>- # don't use -Wcast-align on ia64 or sparc, it's noisy on those platforms
>+ # don't use -Wcast-align on hppa, ia64 or sparc, it's noisy on those platforms
> # icc doesn't support this flag.
> _WARNINGS_CFLAGS="${_WARNINGS_CFLAGS} -Wcast-align"
> fi

This is getting unwieldy, could you refactor this into a case statement? Same thing with the other bit. Other than that, looks ok.

Created an attachment (id=324467)
hppa-v2.patch

There we go

Created an attachment (id=324468)
hppa-v3.patch

Wrong patch, this is the good one

Alexander Sack (asac) wrote :

see branch.

Changed in xulrunner-1.9:
status: Confirmed → Fix Committed
Changed in firefox-3.0:
status: Confirmed → Fix Committed
Alexander Sack (asac) wrote :

yelp, appears to work fine with this update. no action required here.

Changed in yelp:
status: Incomplete → Invalid
Alexander Sack (asac) wrote :

... hardy yelp works good too.

Changed in yelp:
status: Incomplete → Invalid
Alexander Sack (asac) wrote :

devhelp verified to work well with this update.

Changed in devhelp:
status: Incomplete → Invalid
status: Incomplete → Invalid
Alexander Sack (asac) wrote :

no cairo upgrade required for this update. new upstream versions of cairo should get their own SRU.

Changed in cairo:
status: Incomplete → Invalid
status: Incomplete → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xulrunner-1.9 - 1.9+nobinonly-0ubuntu1

---------------
xulrunner-1.9 (1.9+nobinonly-0ubuntu1) intrepid; urgency=low

  * New upstream release 1.9 (LP: #237690)

  [ Alexander Sack <email address hidden> ]
  * Fix LP: #236266 - "Build Failure on HPPA architecture" by applying patch
    from bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=436133
    - add debian/patches/bz436133_att322801.patch
    - update debian/patches/series
  * drop image scaling patches - previously applied and finally superseeded
    upstream to fix Vista bug https://bugzilla.mozilla.org/show_bug.cgi?id=434157
    - delete debian/patches/bz394103_dont_scale_images.patch
    - delete debian/patches/bz394103_scale_images_for_192+dpi.patch
    - update debian/patches/series
  * update patch for Bug 368428 – "XUL FastLoad cache corruption when
    application running"; fix deadlock by using "antiLockZipGrip".
    (LP: #236984)
    - update debian/patches/bz368428_attachment_308130.patch

  [ Fabien Tassin <email address hidden> ]
  * drop synchronous = NORMAL patch, now applied upstream
    - delete debian/patches/bz421482_att320806_synchronous_NORMAL_for_storage_connections.patch
    - update debian/patches/series
  * Fix regression with venkman accessing chrome by applying patch
    from bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=428848
    - add debian/patches/bz428848_att319775_fix_venkman_chrome_access.patch
    - update debian/patches/series
  * Touch .autoreg in postinst with the exact GRE version as the glob is
    causing troubles when multiple xulrunner are installed
    - update debian/xulrunner-1.9.postinst
    - update debian/xulrunner-1.9-gnome-support.postinst
  * Don't install a libsqlite3.so.0 symlink if we are using system sqlite
    - update debian/rules

 -- Fabien Tassin <email address hidden> Tue, 10 Jun 2008 12:51:56 +0200

Changed in xulrunner-1.9:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox-3.0 - 3.0+nobinonly-0ubuntu1

---------------
firefox-3.0 (3.0+nobinonly-0ubuntu1) intrepid; urgency=low

  * New upstream release: 3.0 (LP: #237690)

  [ Alexander Sack <email address hidden> ]
  * Fix LP: #236266 - "Build Failure on HPPA architecture" by applying patch
    from bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=436133
    - add debian/patches/bz436133_att322801.patch
    - update debian/patches/series
  * drop left-over patch that disabled parts of safe-browsing by default.
    - delete debian/patches/force_safebrowsing_off.patch
    - update debian/firefox.js
    - update debian/patches/series

 -- Alexander Sack <email address hidden> Tue, 10 Jun 2008 12:51:01 +0200

Changed in firefox-3.0:
status: Fix Committed → Fix Released
Alexander Sack (asac) wrote :

initiating SRU for firefox 3 (RC2)

uploaded firefox-3.0_3.0+nobinonly-0ubuntu0.8.04.1_source.changes to ubuntu/hardy-proposed.

Changed in firefox-3.0:
status: Confirmed → In Progress
Alexander Sack (asac) wrote :

initiating SRU for xulrunner 1.9 (RC2)

uploaded xulrunner-1.9_1.9+nobinonly-0ubuntu0.8.04.1_source.changes to ubuntu/hardy-proposed

Changed in xulrunner-1.9:
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

xulrunner and firefox-3.0 accepted into hardy-proposed, please test.

Changed in firefox-3.0:
status: In Progress → Fix Committed
Changed in xulrunner-1.9:
status: In Progress → Fix Committed
Alexander Sack (asac) wrote :

didn't see any regressions in epiphany-browser due to this bug yet. If you get to know about any, please reopen this one.

Changed in epiphany-browser:
status: Incomplete → Invalid
status: Incomplete → Invalid
Nukeador (nukeador) wrote :

es-ES language pack has changed since RC1, and I suppose that other locales too due to some unfixed bugs that where pushed with RC2.

http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0rc2/linux-i686/xpi/

On Wed, Jun 11, 2008 at 07:43:58AM -0000, Nukeador wrote:
> es-ES language pack has changed since RC1, and I suppose that other
> locales too due to some unfixed bugs that where pushed with RC2.
>
> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0rc2/linux-i686/xpi/
>

Hmm, this doesn't belong to this bug. However, we will regularaly
update langpacks through hardy-proposed, so those fixes will become
available sooner or later.

If you have a critical bug about langpacks, please open a bug against
the right language-pack-XX package and get my attention on IRC if this
requires instant action.

 - Alexander

Scott Beamer (angrykeyboarder) wrote :

Richard Seguin wrote on 2008-06-05:

> Thank you for reporting this issue... Our firefox team actually gets updated on a
> regular basis about new releases...
> As a result I am closing out this bug as they have there [sic] own work flow
> methods on releases..

That's just it. The problem is the workflow. Our otherwise *extremely* efficient Mozilla team has been very slow when it comes to Firefox 3.0 updates.

As of this writing, 3.0 RC2 is only in hardy-proposed and not in hardy-updates. RC1 spent most of it's time in hardy-proposed and only recently made it to hardy-updates. And of course RC1 is no longer the latest version.

Firefox 3.0 Beta 5 is the *default* web browser in hardy and therefore should have been updated as frequently as the 2.0.0.x releases are in gutsy (and prior).

Therefore, your typical user who doesn't change any default sources.list settings is still running Firefox 3.0 RC1 which has been out for quite some time. RC2 has been out for for a week (as of this writing).

Alexander Sack (asac) wrote :

On Wed, Jun 11, 2008 at 07:08:10PM -0000, Scott wrote:
> Richard Seguin wrote on 2008-06-05:
>
> > Thank you for reporting this issue... Our firefox team actually gets updated on a
> > regular basis about new releases...
> > As a result I am closing out this bug as they have there [sic] own work flow
> > methods on releases..
>
> That's just it. The problem is the workflow. Our otherwise *extremely*
> efficient Mozilla team has been very slow when it comes to Firefox 3.0
> updates.
>
> As of this writing, 3.0 RC2 is only in hardy-proposed and not in hardy-
> updates. RC1 spent most of it's time in hardy-proposed and only
> recently made it to hardy-updates. And of course RC1 is no longer the
> latest version.
>
> Firefox 3.0 Beta 5 is the *default* web browser in hardy and therefore
> should have been updated as frequently as the 2.0.0.x releases are in
> gutsy (and prior).
>
> Therefore, your typical user who doesn't change any default sources.list
> settings is still running Firefox 3.0 RC1 which has been out for quite
> some time. RC2 has been out for for a week (as of this writing).
>

thats not a problem and you cannot compare a b5 to RC1 transition with
a security 2.0.0.x release. Delay was expected here in order to do
proper QA. And we would even hold back 2.0.0.x if we discover a
critical regression.

In future all will be fine again and releasing 3.0 final in sync would
be nice ;)

 - Alexander

Scott Beamer (angrykeyboarder) wrote :

Cool.

Meanwhile 3.0 RC3 was released today... :D

http://www.mozilla.com/en-US/firefox/3.0rc3/releasenotes/

As far as I know, there is no change of the code between rc2 and rc3 for Windows and Linux. They had to do a rc3 for Mac.

Till Ulen (tillulen) wrote :

On Thu, Jun 12, 2008 at 04:40, LumpyCustard wrote:
> As far as I know, there is no change of the code between rc2 and rc3 for
> Windows and Linux. They had to do a rc3 for Mac.

Are there any detailed changelogs between Firefox release candidates?
I tried to find them on their web sites but failed.

Alexander Sack (asac) wrote :

On Thu, Jun 12, 2008 at 08:47:05AM -0000, Alexander Konovalenko wrote:
> On Thu, Jun 12, 2008 at 04:40, LumpyCustard wrote:
> > As far as I know, there is no change of the code between rc2 and rc3 for
> > Windows and Linux. They had to do a rc3 for Mac.
>
> Are there any detailed changelogs between Firefox release candidates?
> I tried to find them on their web sites but failed.
>

bonsai.mozilla.org provides the commit log and thus somewhat the
changelog. only things happening in the last week at least are mac
changes and changes to unrelated code (e.g. mailnews, mail, calendar).

 - Alexander

http://wiki.mozilla.org/QA/Firefox3/TestResults/RC3

Quote: "This respin of RC3 is primarily focused on mac 10.5.3 users only. Windows and Linux builds will remain at RC2."

Also, the date of the final release should be Tuesday June 17th (if you hadn't already heard).

http://developer.mozilla.org/devnews/index.php/2008/06/11/coming-tuesday-june-17th-firefox-3/

Alexander Sack (asac) wrote :

On Thu, Jun 12, 2008 at 10:34:04AM -0000, LumpyCustard wrote:
> Also, the date of the final release should be Tuesday June 17th (if you
> hadn't already heard).
>
> http://developer.mozilla.org/devnews/index.php/2008/06/11/coming-
> tuesday-june-17th-firefox-3/
>

and my call for testing the wanna-be final packages currently in hardy-proposed:

http://www.asoftsite.org/s9y/archives/140-Firefox-3-to-be-released-next-week-Tue,-Jun-17.html

 - Alexander

Swistak (swistakers) wrote :

Here's a bug:

1. create a fresh profile
2. open firefox, open preferences dialog
3. go to Advanced->Updates
4. "Automatically download ..." radio buton should be selected, change to "Ask me ..."
5. both radio buttons are grayed out, why?

This doesn't happen on official builds. I tested RC3 and beta5. Happens on firefox3 from hardy-proposed.

Nukeador (nukeador) wrote :

Swistak it's not a bug, it's a feature ;)

These options are disabled because the application should be updated by the Ubuntu repository, not by itself.

Swistak (swistakers) wrote :

I know that. It's a minor bug. These options should be grayed out from the very beginning. Follow steps I wrote and you'll see. IMHO a better solution would be to remove them completely from that dialog or add some info like "your firefox is updated by Ubuntu repository"

Alexander Sack (asac) wrote :

On Fri, Jun 13, 2008 at 07:48:12PM -0000, Swistak wrote:
> I know that. It's a minor bug. These options should be grayed out from
> the very beginning. Follow steps I wrote and you'll see. IMHO a better
> solution would be to remove them completely from that dialog or add some
> info like "your firefox is updated by Ubuntu repository"
>

Thanks for the idea. I will keep this in mind for the future ...

 - Alexander

Swistak (swistakers) wrote :

Note that analogous radio buttons in Thunderbird are not grayed out. It's a bit inconsistent.

Is everything on schedule to get this out on time?

Alexander Sack (asac) wrote :

On Sat, Jun 14, 2008 at 12:18:44PM -0000, Swistak wrote:
> Note that analogous radio buttons in Thunderbird are not grayed out.
> It's a bit inconsistent.
>

thunderbird's rendering engine is behind of what firefox ships
... thus the difference most likely.

 - Alexander

Steve Langasek (vorlon) wrote :

copied to hardy-updates.

Changed in xulrunner-1.9:
status: Fix Committed → Fix Released
Steve Langasek (vorlon) wrote :

firefox-3.0 copied to hardy-updates.

Changed in firefox-3.0:
status: Fix Committed → Fix Released
Alexander Sack (asac) wrote :

nspr/nss are updated in intrepid.

Changed in nspr:
status: Incomplete → Fix Released
Changed in nss:
status: Incomplete → Fix Released
Alexander Sack (asac) wrote :

nspr is already final in hardy.

Changed in nspr:
status: Incomplete → Fix Released
Alexander Sack (asac) wrote :

nss wont be tracked in this bug. the latest version is already in hardy-proposed.

Changed in nss:
status: Incomplete → Invalid

Pushed as 15835:101087d57ba5.

this is still an issue on windows xp with 144 dpi. firefox 3.5 worked just great. i upgraded to 3.6.b3 and suddenly the gui collapsed. screenshots with 3.5 and 3.6b3:

http://clip2net.com/page/m0/2714596 (3.6b3) TOO SMALL
http://clip2net.com/page/m0/2714709 (3.5) SLIGHTLY TOO LARGE, BUT IT'S MUCH MORE CONFORTABLE TO THE EYE, working 8 hours a day at 37' from 2 meters distance

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.