[Branch] Firefox 2.0.0.8 fixlist (NOW RELEASED)
- trolly
- Moderator
- Posts: 39851
- Joined: August 22nd, 2005, 7:25 am
Does anyone know how to get rid of the "chrome registration error" message?
Think for yourself. Otherwise you have to believe what other people tell you.
A society based on individualism is an oxymoron. || Freedom is at first the freedom to starve.
Constitution says: One man, one vote. Supreme court says: One dollar, one vote.
A society based on individualism is an oxymoron. || Freedom is at first the freedom to starve.
Constitution says: One man, one vote. Supreme court says: One dollar, one vote.
- a;skdjfajf;ak
- Posts: 17002
- Joined: July 10th, 2004, 8:44 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.
-
- Posts: 3483
- Joined: November 4th, 2002, 10:47 pm
- Location: Ann Arbor, Michigan
- Contact:
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?
Is there a way I can set up Firefox to automatically get branch release candidates, but not branch nightly builds?
-
- Posts: 1
- Joined: October 22nd, 2007, 7:24 am
- Location: Michigan, United States
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:
CSS:
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%;
}
- polidobj
- Posts: 3147
- Joined: March 31st, 2004, 9:10 am
- Location: Maryland USA - im in ur tinderbox, crashtesting ur firefox
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 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?
-
- Posts: 3483
- Joined: November 4th, 2002, 10:47 pm
- Location: Ann Arbor, Michigan
- Contact:
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
- Posts: 3147
- Joined: March 31st, 2004, 9:10 am
- Location: Maryland USA - im in ur tinderbox, crashtesting ur firefox
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.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.
- trolly
- Moderator
- Posts: 39851
- Joined: August 22nd, 2005, 7:25 am
Is it possible that the bug was not retested on branch after the regression came in?
Think for yourself. Otherwise you have to believe what other people tell you.
A society based on individualism is an oxymoron. || Freedom is at first the freedom to starve.
Constitution says: One man, one vote. Supreme court says: One dollar, one vote.
A society based on individualism is an oxymoron. || Freedom is at first the freedom to starve.
Constitution says: One man, one vote. Supreme court says: One dollar, one vote.
-
- Posts: 3483
- Joined: November 4th, 2002, 10:47 pm
- Location: Ann Arbor, Michigan
- Contact:
polidobj wrote: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.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.
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
- Posts: 3147
- Joined: March 31st, 2004, 9:10 am
- Location: Maryland USA - im in ur tinderbox, crashtesting ur firefox
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:
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/
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/
-
- Posts: 4283
- Joined: May 17th, 2003, 12:05 pm
- Location: London, UK
- polidobj
- Posts: 3147
- Joined: March 31st, 2004, 9:10 am
- Location: Maryland USA - im in ur tinderbox, crashtesting ur firefox
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.
#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.
-
- Posts: 4283
- Joined: May 17th, 2003, 12:05 pm
- Location: London, UK