[Branch] Firefox 2.0.0.8 fixlist (NOW RELEASED)

Post by **trolly** » October 22nd, 2007, 4:52 am

Does anyone know how to get rid of the "chrome registration error" message?

mark7144 · Post by **mark7144** » October 22nd, 2007, 6:09 am

I'm suffering badly from that blasted CSS issue, hopefully the developers will give us a work around until it is fixed.

a;skdjfajf;ak · Post by **a;skdjfajf;ak** » October 22nd, 2007, 6:20 am

mark7144 wrote:I'm suffering badly from that blasted CSS issue, hopefully the developers will give us a work around until it is fixed.

Read the bug posted by chob back one page, see also :
https://bugzilla.mozilla.org/show_bug.cgi?id=400406#c13 in the bug reference a possible temp workaround.

schapel · Post by **schapel** » October 22nd, 2007, 7:07 am

Apparently <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=400406#c15">the branch builds need more testers</a>. This isn't the first time a fairly obvious bug has made it into a branch release.

Is there a way I can set up Firefox to automatically get branch release candidates, but not branch nightly builds?

jefflundberg · Post by **jefflundberg** » October 22nd, 2007, 7:30 am

Anyone using the ALA Holy Grail 3-column layout along with jQuery can use this JavaScript hack which applies the clearfix hack which should get around the float clear issue with negative margins in Firefox.

I hope this helps someone.

JavaScript:

Code: Select all

$(function(){
   if($.browser.mozilla && $.browser.version == '1.8.1.8')
      $('#container').addClass("clearfix");
});

CSS:

Code: Select all

   .clearfix:after {
      content: ".";
      display: block;
      clear: both;
      visibility: hidden;
      line-height: 0;
      height: 0;
   }
   
   .clearfix {
      display: inline-block;
   }
   
   html[xmlns] .clearfix {
      display: block;
   }
   
   * html .clearfix {
      height: 1%;
   }

colfer · Post by **colfer** » October 22nd, 2007, 7:44 am

schapel: the branch is not very active, so the nightlies are pretty safe. In other words, testing the nightlies is not that different from testing the RC's. And I don't know the answer to your question.

polidobj · Post by **polidobj** » October 22nd, 2007, 7:54 am

schapel wrote:Apparently <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=400406#c15">the branch builds need more testers</a>. This isn't the first time a fairly obvious bug has made it into a branch release.

Is there a way I can set up Firefox to automatically get branch release candidates, but not branch nightly builds?

Yeah but this case should not have needed to be caught by testers. The regression was known more than a week before release. There's not enough info from just the bug reports to know who dropped the ball. I probably wouldn't put it on one person. One thing that looks like it should have happened was because the dependency for the regression was marked in the first bug before the first bug got approval to land on the 1.8.1 branch, the approval for the first bug should have been held up until the regression was taken care of. This way either both the patches land on 1.8.1 branch at the same time or a new patch should have been made.

schapel · Post by **schapel** » October 22nd, 2007, 8:40 am

colfer wrote:schapel: the branch is not very active, so the nightlies are pretty safe. In other words, testing the nightlies is not that different from testing the RC's. And I don't know the answer to your question.

It's not really a matter of whether it's safe. They update daily, so you always need to be on the lookout for regressions. With release candidates, you can pay close attention when a new one comes out. The nightlies update daily, so you can have a hard time running the nightlies for a long period of time, but it's easy to run a release candidate until a new one comes out. There's also only so much testing I can do by myself. We need others to test as well, and they would be more likely to test release candidates than nightly builds.

polidobj wrote:Yeah but this case should not have needed to be caught by testers.

Testers provide a second line of defence. Acknowledging that developers are not perfect, we do still need testers to test each release before the final release. In short, if there isn't a way to automatically test release candidates, there should be.

polidobj · Post by **polidobj** » October 22nd, 2007, 9:14 am

schapel wrote:
polidobj wrote:Yeah but this case should not have needed to be caught by testers.

Testers provide a second line of defence. Acknowledging that developers are not perfect, we do still need testers to test each release before the final release. In short, if there isn't a way to automatically test release candidates, there should be.

I didn't say anything against testing. Testing had already caught the regression on the trunk. So that put the blame on the approval process. My impression is that the point of the approval process is to catch things like this. If this had happened with a fire drill release like 2.0.0.7 then some slack could be given.

Post by **trolly** » October 22nd, 2007, 9:38 am

Is it possible that the bug was not retested on branch after the regression came in?

schapel · Post by **schapel** » October 22nd, 2007, 12:42 pm

polidobj wrote:
schapel wrote:
polidobj wrote:Yeah but this case should not have needed to be caught by testers.

Testers provide a second line of defence. Acknowledging that developers are not perfect, we do still need testers to test each release before the final release. In short, if there isn't a way to automatically test release candidates, there should be.
I didn't say anything against testing. Testing had already caught the regression on the trunk. So that put the blame on the approval process. My impression is that the point of the approval process is to catch things like this. If this had happened with a fire drill release like 2.0.0.7 then some slack could be given.

Yes, you can make the argument that this "should" have been caught by the approval process. But, recognizing that the work is done by human beings, who are not infallible automatons and sometimes make mistakes, we need an additional level of protection against mistakes. This is the purpose of testing. With more testers to verify that the branch builds are okay, fewer problems will get through.

In short, I'm not looking to blame anyone. I'm looking at how we can help.

trolly wrote:Is it possible that the bug was not retested on branch after the regression came in?

Yes, that seems to be the problem that Boris described. There are so few people testing the branch that this bug got through. Apparently a patch that made it into the branch had a bug in it. The bug was fixed on the trunk, but a mistake was made that caused the bug not to be fixed on the branch before the release. With so few testers, this mistake was not caught. With more testers of branch release candidates, mistakes like these will be more likely to be caught. If there were a way to automatically download and install release candidates, that would help provide these testers.

polidobj · Post by **polidobj** » October 22nd, 2007, 1:50 pm

There is an automated way to test release candidates. You just need to be on the beta update channel.

In reference to 2.0.0.8:

Pushed updates to beta users on Wednesday (10/10)

From:
http://wiki.mozilla.org/WeeklyUpdates/2 ... Fx_2.0.0.8

This was done in response to more testing being needed. I think it was started a few 2.0.0.x versions ago.

EDIT: Ah I found it. There's the announcement:
http://developer.mozilla.org/devnews/in ... a-program/

chob · Post by **chob** » October 22nd, 2007, 2:57 pm

sounds like there's going to be a quick 2.0.0.9 turnaround to fix some stupid regressions introduced in 2.0.0.8

polidobj · Post by **polidobj** » October 22nd, 2007, 2:59 pm

More testing needed indeed, new 2.0.0.8 bugs:
#400735[Core:XBL]-New startup crash [@ nsXBLBinding::AllowScripts] [Win]
#400714[Core:Plug-ins]-Flash crashes on Mac skyrocketed in Firefox 2.0.0.8 [Mac]

Even with the automated testing happening on trunk there will be problems that won't be caught by those tests because of the plugins/extensions that users have.

chob · Post by **chob** » October 23rd, 2007, 5:28 am

Firefox 2.0.0.8 update to be updated