Firefox 1.0 Preview Release

Release notes

What's new in Firefox 1.0 Preview Release (more detailed than release notes, less detailed than The Burning Edge).

mozillaZine article about the Preview Release and

Changes since 2004-09-11 builds:

  • Fixed: 259192 - In pop-ups, always show status bar instead of always showing address bar.
  • Fixed: 246375 - Themes should not be required to be whitelisted.
  • Fixed: 258798 - Reconsider InstallTrigger.enabled() return value.
  • Fixed: 259211 - StartSoftwareUpdate() should send install-blocked notification to UI.
  • Fixed: 259011 - Fix Ctrl+A Emacs keybinding for GTK1

Windows builds: Official Windows, Official Windows installer

Linux builds: Official Linux, Official Linux installer

Mac builds: Official Mac

33 Responses to “Firefox 1.0 Preview Release”

  1. Rirath Says:

    Yatta! :) Nice last minute switch with the popups too, that’s been bugging me a bit from time to time.

  2. Jesse Ruderman Says:

    Eh. I’m not happy with that change. It removes most of the anti-spoofing benefit (since the status bar doesn’t tell you what site you’re on) and only gives web app windows a few more pixels.

  3. Chris Trumbour Says:

    “Fixed: 259192 – In pop-ups, always show status bar instead of always showing address bar.”
    A better move would be to make this an option, with choices “Show only status bar”, “Show only Address bar”, “Show both”, and “Show none”

  4. Jugalator Says:

    Hmm, I’m not sure about that — is there a good reason for the user to select? If not, it will just clutter the interface. The point is after all to have a good solution for security, and I don’t think the user should be able to easily disable that.

  5. theefool Says:

    I also liked the address bar showing up in pop-ups. So, why not have both? Status bar and address bar. Make it a hidden setting or something.

  6. laszlo Says:

    It already *is* a “hidden setting”, and it always was. Look at all the dom.disable_window_open_feature.* prefs in about:config. The resolutions of these bugs weren’t more than changes in the defaults of these settings.

  7. Rirath Says:

    >only gives web app windows a few more pixels.

    A few pixels can make a large difference. When windows are suppose to be specific sizes and specific shapes, it can look quite funky in Firefox compared to IE. I’m not worried about spoofing, so having an address bar is just pointless for me on a popup window.

    I’m glad to hear there is a hidden setting at any rate, and also glad I used the word ‘switch’. ;) Must admit I hadn’t noticed that one before, got to love that kind of depth.

  8. C. Coimbra Says:

    I disagree with NOT showing the address of the pop-up, especially when it’s a valid, intended, pop-up.
    As it happens, just yesterday I had reason to use that information.
    Why for the status???

  9. theefool Says:

    It already *is* a “hidden setting”, and it always was. Look at all the dom.disable_window_open_feature.* prefs in about:config. The resolutions of these bugs weren’t more than changes in the defaults of these settings.
    Posted by: laszlo at September 14, 2004 06:30 AM ….

    Thanks. Now I know *THERE IS* a *hidden* setting. Not everyone knows everything there is about everything. But, it looks like some people do know quite a bit about firefox. Thanks for the info.

  10. AJ Says:

    Is it possible to dissable the new “Find Toolbar”. It’s terribly slow which is very annoying.

  11. It Says:

    isnt it wired that ctrl-f dosnt toggle the find-bar, only displays it?

  12. Noa Says:

    The height of the image tag for ‘header.png’ on the 1.0 PR release notes page should be changed from 102 to 150 pixels.

  13. baba Says:

    cool, another bug at the PR, now when i go to some site, when i middle-click on a link to open a new link, the mouse wheel dosnt scroll in the current page (even in this comment box, when i click in it, i can’t scroll using the mouse-wheel aroudn the page

  14. MikeP Says:

    Baba, I have no problems with the autoscroll like you described.

  15. C. Coimbra Says:

    Re: dom.disable_window_open_feature.* prefs in about:config.

    1. Can’t imagine why displaying the address on a pop-up (which was added the other day) could be considered a bug…

    2. So why, at the last moment, make what is a minor design change to the UI?

    3. If FF is ever to take off, nobody should expect that it’ll be with people having to make userpref changes!! Even with checkboxes on a regular preferences 80% of users never get around to changing anything!

    4. Re those hidden prefs, I looked at them, and still couldn’t tell WHICH would apply here, as I don’t even see the word ‘adress’ in any of them.

  16. Rirath Says:

    C. Coimbra, If you’re going to argue that 80% of users never change anything, then you should probably consider what the 80% crowd is likely to want to see. IE does not display the address bar on such popups, and they don’t expect Firefox to do so either.

    Every other user can simply change the setting. I highly doubt this is too much to ask of anyone who even remotely considers themselves a Firefox power user. If the user never changes anything, then chances are the user doesn’t care to begin with and the arguement is moot.

  17. as Says:

    on that site i have the auto-scroller bug mentioned 4 posts ago, please tell me if you have it as well

  18. Rirath Says:

    And for those who can’t find it, all you had to do was read the bug report…

    “We need to change dom.disable_window_open_feature.location to false, and dom.disable_window_open_feature.status to true.”

  19. aa Says:

    how come when i type in the address bar “gmail” it takes me to login page, and when i type it takes me directly to my mailbox ?

  20. Matt Brubeck Says:

    Jesse: “It removes most of the anti-spoofing benefit (since the status bar doesn’t tell you what site you’re on) and only gives web app windows a few more pixels.”

    Currently the status bar *does* display the site name for SSL pages. For the future, how about making it do the same for non-SSL pages when the address bar is hidden?

  21. C. Coimbra Says:

    Rirath: But if FF is BETTER (and it is), it should SHOW that it’s better, i.e., flaunt it! Flaunt it with a screenfull of flexible pref checkboxes that the user can change.
    Otherwise, the user will see with FF the same he sees with IE and will never guess that he could be seeing more (or differently).
    I’m quite adept at changing prefs, but like a normal person I’d prefer to see that type of thing in Options.
    Besides, this bit of using double-negatives in Prefs rubs me the wrong way: couldn’t one just use the positive+true to mean that “Yes, this thing shows up”? (I mean, rather than Disable+False?). That’s the way people think. Reminds of designing hardware using NAND gates…

  22. Bob Says:

    Found a bug which I think isnīt filed yet: the new “Find Toolbar” doesnt search forms (textareas). Can anyone confirm this and enter it into bugzilla as I am not familiar with the use of it (yet) ;-)

  23. philip Says:

    @as: the same auto-scroll problem for me on this site

  24. Hank Says:

    The OSX PR release brought back an old problem I used to see when reading Spamcop’s ‘held mail’ folder, which has a ‘check all’ checkbox above the list. Now that doesn’t work; the JavaScript console says “check all” is not defined. This happened intermittently with nightly builds and was usually fixed the next day, I vaguely recall, it’s been a few months. Something about a bit having to be reset each time a build was created…. but I’m not clear enough on it to know how to report it. If anyone else knows, and sees it, feel free. OSX.

    Oh, and — with Jesse on the treatment of anti-spoofing.

    And, that full-width gray bar — gack! takes the whole screen just to say ‘blocking popups’ where a little “tapdancing, farting”* icon could do it and be both more obvious and less of a thief of screen space. *how Tralfamadorians communicate

  25. Manoj Mehta Says:

    No one seems to have read the Security Advisory released by Secunia about the remotely exploitable vulnerability in Firefox versions prior to the Preview Release. I’d recommend that everyone download the latest bits and protect their systems from a possible remote exploit. More details about the vulnerabilities can be had from

  26. Brian Says:

    Anyone else besides me notice what happends when viewing a XML file within Mozilla, then using the auto-scroll feature (midde-click and scroll feature)?

  27. Hank Says:

    Opened my OSX 1.0PR just now, and opened the Extensions pulldown menu under tools, and the top bar of the window shows it now is named:

    Extensions[[Exception… “Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [NSLPrefBranch.getIntPref” nsresult: 0x8000…

    That’s as wide as I can make the window, but there must be more. I wonder who I should tell. There is nothing at all showing up in the JavaScript Console. Nothing in Talkback. “Firefox was not able to find any available updates” when I checked the loop-the-loop button just now.

    Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10

  28. anonymous Says:

    Hank: You are aware that you can disable it, or?

  29. Hank Says:

    What “it” would I be aware that I can disable, and how would “it” be disabled? All I’m doing is clicking the Tools menu then the Extensions menu, to see this window with the odd name at the top of it.
    (Problem survives reboot.) (Problem same using command-shift-E to open the window).

    Aside from that — “which build should we be testing now” again? The FAQ on that said test Aviary to help find bugs in the 0.1 release — but today, what should I test and comment on? 0.1PR still, or a nightly, and if so, which?

  30. Hank Says:

    OK, I figured the “latest Aviary branch” is still the right build to test —
    Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040915 Firefox/0.10
    — (found in the folder named “latest-0.9/” )

    AND the odd window name persisted. Next, I disabled half of my extensions and it went away. Enough for now.

  31. aa Says:

    another bug.. set a picture as background, selecting a color other then the default blue as the pic’s background dosnt matter, ff still makes it blue, any1 else see it?

  32. lm Says:

    I am campaigning for people to look at this bug before 1.0 final goes out:

  33. Craig Says:

    lm, the comments for that bug say that it is a account, meaning the Foundation gets the procedes. While I see your point, I don’t really see anything wrong with what they’re doing.