« 2006-09-20 Trunk builds
2006-10-18 Trunk builds »

2006-10-06 Trunk builds

Fixes:

  • Fixed: 353571 - Disable Places on Trunk.
  • Fixed: 353673 - Land the new theme on trunk.
  • Fixed: 352748 - Can't use JS 1.7 let/yield in JS components.
  • Fixed: 326469 - [Mac] Make Cocoa widgets default for all products on trunk.
  • Fixed: 300982 - [Mac] Ugly (bold) text, looks like a sub-pixel rendering of the text was drawn over itself.
  • Fixed: 321279 - [Windows] Drag+drop of link to location bar broken, anchor node text gets included.
  • Fixed: 319554 - Keyboard modifier (shift,ctrl,alt) and left-clicking on a link creates an event that is NOT cancelable by event handler.
  • Fixed: 317078 - Onchange event not fired for single selection single line SELECT elements first OPTION, if there was previously no selection made (selectedIndex == -1).
  • Fixed: 352750 - Exponential growth in number of timeouts hangs browser in InsertTimeoutIntoList.
  • Fixed: 52209 - JS timers can fire while a modal dialog is open.
  • Fixed: 224128 - Array.sort isn't a stable sort (switch to MergeSort).

Fixes for recent regressions:

  • Fixed: 352520 - Crash when deleting chars from url bar [@ nsEditor::DeleteSelectionImpl].
  • WFM: 324560 - Can't see many Unicode characters in Cairo.

Mac builds are now using Cocoa! This fixes a few long-standing bugs, and paves the way for Firefox to use Cairo on Mac. Once Cairo is used on Mac, it will be possible to make changes that depend on using Cairo on all platforms, such as Fix the use of units in Gecko. Note that the switch to Cocoa widgets does not affect the appearance of HTML form controls -- they retain their non-native appearance for now.

There are a lot of regressions from the switch to Cocoa. I'll list the regressions with the most votes in the next update.

Trunk regressions:

  • Since Sept 29: [Mac] Lots of regressions from the switch to Cocoa widgets.
  • Since Jan 26 (FDL): 325296 - [Mac] Opacity doesn't work in HTML. (Switching to Cairo will fix this bug.)
  • Since Jan 26 (FDL): 324819 - Fixed positioned elements now lag/flicker when scrolling.
  • Since Jan 26 (FDL): 324963 - [Windows] Menu highlight is broken/doesn't show up/not painted.

Trunk checkins between 2006-09-20 06:00 and 2006-10-06 06:00

Windows builds: Windows nightly (discussion)

Linux builds: Linux nightly

Mac builds: Mac nightly

This entry was posted on Friday, October 6th, 2006 at 10:24 pm and is filed under Trunk. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

8 Responses to “2006-10-06 Trunk builds”

  1. Raphael Says:
    October 6th, 2006 at 11:05 pm

    Could you explain how exactly “Disable Places on Trunk” is a fix? It should rather be listed as a regression… Leaving places off for a long time in the trunk (as indicated in the bug) will leave me no choice but to use my 20060920 nightly until places is reenabled. Exporting bookmarks from places is not an option for me since that removes all the shortcuts (of which I have more than 100).

  2. David Naylor Says:
    October 7th, 2006 at 8:16 am

    I think the places being disabled is only for the time being, to ease the landing of the new theme.

  3. Raphael Says:
    October 7th, 2006 at 9:41 am

    It says in the comment (https://bugzilla.mozilla.org/show_bug.cgi?id=353571#c10) that “Places will be going through a redesign before being reenabled”…

  4. Nathan Says:
    October 8th, 2006 at 10:59 pm

    If places requires a redesign before be enabled again, then in it’s current form it is broken, regardless of how well it works for you. This is a fix because it removes the broken code from use.

    This is the risk you take using prerelease software.

  5. Raphael Says:
    October 11th, 2006 at 12:24 pm

    I’m not using prerelease software, I’m using nightly builds which are almost expected to be unstable AND to contain new features enabled for testing. How can I test anything if the developers are afraid to enable it because it might be broken? If I’d be testing a branch build, I’d expect it to be stable but I’m testing trunk builds and I know why: I do want the new features and I consider the tradeoff – frequent crashes, data corruption or worse – to be less significant than the advantages of new features.

  6. J. McNair Says:
    October 13th, 2006 at 11:13 am

    Raphael, you seem to understand the risks of using unstable nightly builds. You must also understand that nightly builds are always in flux. Testing a new feature is just that, testing. The Places feature set was tested and found to be broken, so it needs to be fixed. Unfortunately, developer attention is elsewhere at the moment (it seems) so it is better to drop it (temporarily, we hope) and either re-evaluate its usefulness or reimplement it properly.

    Very simply, it wasn’t worth keeping in its current form, according to the devs. They don’t want to support a broken feature while trying to implement new (possibly broken) features. At worst, Firefox 3 will be places-free, but I think D. Baron doesn’t want that. Still, Fx 3 without Places is better than Fx 2 or 3 with a buggy, slow Places. :)

    –JM

  7. Chris Says:
    October 15th, 2006 at 3:54 pm

    For what it’s worth, I have to agree with Raphael here.
    THere are certain limits as to what you can put the ‘testers’ through.
    It’s like holding a small piece (as opposed to a reasonably complete piece) of nicely baked chicken in front of your nose, and then just after you take a small bite from it, it’s pulled away. Leaving you feeling hungry and frustrated.
    You can’t just throw anything in front of us and expect us not to bite.

  8. testboy Says:
    October 17th, 2006 at 2:55 pm

    Testing releases is not about getting new features first, but just about testing them to see if they work. One may be dissappointed if expecting more.