Last update: 2007-08-01 -- 05:20 PDT = 12:20 UTC (all check-ins since the latest nightly included)
The tree is CLOSED for Alpha 7 and ready for release. sqlite and cairo updates will land before the tre will be reopened for M8.
Fixed:
#368587[Firefox:Software Update]-avoid the second UAC prompt for helper.exe on software update by launching it directly from the elevated updater.exe process [Win]
#389878[Firefox:General]-Gmail , Contacts and Settings links are broken [Win]
#390222[Core:XPConnect]-Trunk topcrash at XPC_XOW_GetOrSetProperty [Mac]
#390398[Firefox:Phishing Protection]-need to bump uuid for nsIUrlClassifierDBServiceWorker [All]
#389753[Core:JavaScript Engine]-Frequent crashes at Gmail [@ JS_GetParent] [All] (FIXED as of 20070731?)
#390001[Firefox:General]-Yahoo Mail beta crashes firefox [@ JS_GetClass()] [All] (FIXED as of 20070731?)
To copy your useragent+buildtime to clipboard, use the Nightly Tester Tools extension.
Get more out of the Javascript Console, see this page for Console²
If you're a daily tester then backup the valuable data in your profile !
Trunk fixes since branching for 1.5 (20050812) = ~ 9776
Just a weird observation with page zoom:
You know the two OK buttons below the search fields at the right of the forum here. Normally they are below the input fields. If you zoom in they jump behind the the input fields. If you zoom out they jump between the two positions. Some rounding issues?
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.
I just noticed this bug: I have Minefield set that when I type "g *text*" it searches google for that text (bookmark with address http://www.google.com/search?hl=en&q=%s and Keyword "g"). Now, if I type "g ć" (Serbian character), google lists results for æ , not ć. But if I enter in in Search box, it works normally... Same with č->è and đ->ð .
Could someone tell me if there's bug filled for this?
KOLE89 wrote:I just noticed this bug: I have Minefield set that when I type "g *text*" it searches google for that text (bookmark with address http://www.google.com/search?hl=en&q=%s and Keyword "g"). Now, if I type "g ć" (Serbian character), google lists results for æ , not ć. But if I enter in in Search box, it works normally... Same with č->è and đ->ð .
Could someone tell me if there's bug filled for this?
related to #387723[Firefox:Search]-smart/keyword/bookmark searches don't work with non-ascii (russian) characters with the new urlbar binding [Win] ?
trolly wrote:Just a weird observation with page zoom: You know the two OK buttons below the search fields at the right of the forum here. Normally they are below the input fields. If you zoom in they jump behind the the input fields. If you zoom out they jump between the two positions. Some rounding issues?
Confirmed. If you zoom in, after a certain zoom factor, the buttons jump behind the input fields. But also if you zoom out enough, they do that. Strange
supergirl260 wrote:well considering google has many employees coding for firefox its not a suprise
I don't believe there's actually anyone from Google working on Firefox at work right now. They contributed a lot to Firefox 2.0, but not recently. I think the reason bugs in Google products get filed/fixed faster is simply that more developers use them on a daily basis. Most of the developers I know use GMail either as their primary bugmail account or as a backup searchable archive. (timeless actually filled his GMail account with bugmail...) Because of this, developers using nightly builds are more likely to notice bustage and file it or fix it.
I know most of the blogosphere thinks Google exerts some nefarious control over Mozilla, but it's really not true.
supergirl260 wrote:well considering google has many employees coding for firefox its not a suprise
I don't believe there's actually anyone from Google working on Firefox at work right now. They contributed a lot to Firefox 2.0, but not recently.
That's what I thought. I think a reason that Places didn't happen in 2.0 was because Google yanked developers like Ben Goodger and Bryan Ryner that were working at least part time on Firefox/Mozilla to do other things. I haven't seen anything from them since Places 2.0 died. Thanks Google.
When they were hired by Google they were like oh we will still be working on Firefox, but working for Google instead of Mozilla. And that lasted for what a few months?
MoCo has at least done a good job of getting new devs for Firefox.
Brian J Polidoro - Today's bugs brought to you by Raid. :P Windows7 - Firefox user since ~Feb 2002
#390319 [Core:General]-No "Server not found" error message; just a blank screen, when loading an URL that doesn't exist from third party program? [Win]
Ahha finally figured this one out. Go to yahoo.com and hover over any of the six boxes (mail, messenger, radio, weather, local or horoscopes) in the top right corner until they expand. While they are expanded move the mouse to the location bar and click in there, as soon as you click the boxes that you earlier hovered over collapse and then the yahoo search bar steals focus. I do this very fast and after clicking in the location bar start to type and it always goes in the yahoo search bar and I couldn't figure out why until now. Anybody else? Bug filed already?
Edit: Found it! Bug 359549 - Yahoo search box (input field) steals focus under different scenarios
EDIT*2: Is anyone worried about not having a fully functional crash reporter for a release? Granted it is only an alpha but should still have some kind of working crash reporter. I would think you wouldn't want beta 1 to be possibly crashy as all hell because it wasn't known that some crashes were more widespread and frequent then they thought because there were not that many reports during alpha 6/7/nightlys due to the stupid crash reporter not working.
supernova_00 wrote:EDIT*2: Is anyone worried about not having a fully functional crash reporter for a release? Granted it is only an alpha but should still have some kind of working crash reporter. I would think you wouldn't want beta 1 to be possibly crashy as all hell because it wasn't known that some crashes were more widespread and frequent then they thought because there were not that many reports during alpha 6/7/nightlys due to the stupid crash reporter not working.
If I were the project team, I would have that as the top priority. Look at it this way. FF2 has a working (Talkback) crash reporter. That has been replaced by a new crash reporter that is so buggy it not only does not work at all on Windows 2000 OS systems, it only works occasionally on other systems.
I can appreciate that they have major changes/features they want to have in place. But, have they thought that if they have a bug-free and functioning crash reporter, it may help them fix everything else more quickly?
I just noticed this. I have to read my email in IE so I copied a link to an extension, pasted it firefox location bar, hit enter, and I get the what do you want Firefox to do with this dialog (1st bug because firefox should always know what to do with its extensions and always has for me until now) i select firefox to open it, the xpi install dialog opens, a blank tab opens (2nd bug) and the download manager opens (3rd bug) all at the same time.
I just noticed this. I have to read my email in IE so I copied a link to an extension, pasted it firefox location bar, hit enter, and I get the what do you want Firefox to do with this dialog (1st bug because firefox should always know what to do with its extensions and always has for me until now) i select firefox to open it, the xpi install dialog opens, a blank tab opens (2nd bug) and the download manager opens (3rd bug) all at the same time.
supernova_00 wrote:EDIT*2: Is anyone worried about not having a fully functional crash reporter for a release? Granted it is only an alpha but should still have some kind of working crash reporter. I would think you wouldn't want beta 1 to be possibly crashy as all hell because it wasn't known that some crashes were more widespread and frequent then they thought because there were not that many reports during alpha 6/7/nightlys due to the stupid crash reporter not working.
If I were the project team, I would have that as the top priority. Look at it this way. FF2 has a working (Talkback) crash reporter. That has been replaced by a new crash reporter that is so buggy it not only does not work at all on Windows 2000 OS systems, it only works occasionally on other systems.
I can appreciate that they have major changes/features they want to have in place. But, have they thought that if they have a bug-free and functioning crash reporter, it may help them fix everything else more quickly?
Worried , yes, a nightmare, no.
As long as we test hourly builds and narrow down regressions to 1 single build it shouldn't be much of a problem.
There are enough guys with debug builds that can simply reproduce the steps to crash and get a stack.
It's sub-optimal, no more no less.
Last edited by Peter(6) on July 31st, 2007, 1:15 pm, edited 2 times in total.
The second got it's regression range. But the first one was broken very long ago (probably between 1.5 and 2.0, but I wasn't able to test a 1.5 build).
The second got it's regression range. But the first one was broken very long ago (probably between 1.5 and 2.0, but I wasn't able to test a 1.5 build).
I hope I never find a bug again^^
No hard feelings I hope. (I made the bug invalid).
So now you have no bugs left and have to file another one, that is valid.
(don't worry, this has happened to all of us at one time or another)
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.
