Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Mozilla The Internet IT

A First Look At Firefox 3 Alpha 5 217

abhinav_pc writes "PC World is reporting that Mozilla today made an early testing release available from its Firefox 3 browser. This alpha version (code-named Gran Paradiso) for the first time adds the anticipated Places feature for bookmarks. Firefox 3 alpha 5 also features a new password manager. A new crash reporting system called Breakpad is also now available in some Mac OS X and Windows builds but is not yet supported on Linux. 'Places will also be less likely to lose data in the event of program or Windows crashes. In fact, according to Connor, "We haven't figured out how to make Places lose data." For backwards compatibility and manual backups, Firefox 3 will save bookmarks in the traditional bookmarks.htm file when it closes. For other bookmark upgrades, Mozilla is planning to enable bookmark tagging, and is considering building its own synchronization client into the browser capable of backing up and sharing bookmarks. '"
This discussion has been archived. No new comments can be posted.

A First Look At Firefox 3 Alpha 5

Comments Filter:
  • by Tumbleweed ( 3706 ) * on Friday June 08, 2007 @03:28PM (#19443655)
    Multithreaded UI yet?
    • by starwed ( 735423 ) on Friday June 08, 2007 @03:41PM (#19443825)
      Well, here's what Brendan Eich, Mozilla's chief technology officer, has to say about multithreading: Threads suck [mozillazine.org]

      I'm not very clueful on such matters, but it seems like maybe the most important statement is:

      A requirement for JS3 (along with hygienic macros) is to do something along these more implicit lines of concurrency support. In all the fast yet maintainable MT systems I've built or worked on, the key idea (which Will Clinger stated clearly to me over lunch last fall) is to separate the mutable unshared data from the immutable shared data. Do that well, with language and VM support, and threads become what they should be: not an abstraction violator from hell, but a scaling device that can be composed with existing abstractions.
      • by kat_skan ( 5219 ) on Friday June 08, 2007 @04:17PM (#19444409)
        Yeah, that's great. Know what else sucks, Mr. Eich? The whole app becoming completely inoperative because one script on one tab is stuck doing who knows what. Smacks of the old "dialog boxes suck" line that was used [mozilla.org] to explain why we couldn't have a confirmation box to avoid accidentally shutting down the entire app when we were just trying to close a tab.
        • by starwed ( 735423 ) on Friday June 08, 2007 @04:29PM (#19444595)

          You do realize the statement that X is not a solution to problem Y is not the same as saying that problem Y won't or shouldn't be solved. Right?

          (And make sure to read his comments on the main post for specific responses to the issue of UI.

        • Re: (Score:2, Insightful)

          by kervel ( 179803 )
          The problem with avoiding threads and using the alternatives (like cooperative multitasking + event driven models), is that it will become increasingly difficult to be responsive as an application grows. trying to handle GUI events every now and then while you are doing a lot of computation will very quickly go wrong when the amount of work you have to do becomes longer and longer. Threads are difficult indeed, and trying to avoid them might look reasonable, but it doesn't always work well. The KDE core app
      • by gbjbaanb ( 229885 ) on Friday June 08, 2007 @04:46PM (#19444857)
        After reading his blog entry, I think that I know the reason he doesn't like threads. If he codes even a tiny bit like he writes then I wouldn't be surprised if his single-threaded apps had race conditions and deadlocks.

        I think he's also a little stuck in the 80s - 'virtual method calls cost'. yup they do, but on a 3GHz machine, the cost is literally negligible. The cost to allocate 1 byte of memory from main ram costs more than the entire time spent fixing up virtual method calls for an entire day! (and if I exaggerate about the comparison, let me remind you firefox allocates a little more than 1 byte of memory...)

        He could easily put 1 thread per tab and not have any concurrency issues, no race conditions, no deadlocks. As long as he slapped a single mutex around memory shared between tabs and held it for as short a time as possible, then there will be no problems. Simple, easy, safe and yet so effective! You don't need to add threading within a javascript script - that'd be overengineering worthy of the FF memory leak.

        Mozilla needs a new CTO, someone who can talk abotu stuff they know what they're talking about, not someone who likes to speak as eruditely as possibly (probably to make himself sound more intelligent) and leave the incomprehensible, management-style buzzword-speak alone.
        • You don't need to add threading within a javascript script - that'd be overengineering worthy of the FF memory leak.

          Doesn't Firefox render itself using XUL and Javascript?

          David Hyatt (former Mozilla coder) seems to have figured out how to do threading in Safari, anyhow. Firefox is still my main browser, but Safari is very slick.
          • There is no threading in Safari.. Sorry.
          • Yes. All XUL browsers have a single-threaded javascript instance running the interface.
            No. Safari's javascript engine is not multithreaded among open windows/tabs (but the interface is).

            It would benefit all browsers if multi-threaded javascript were possible, and the event model kept "document" (i.e. window/tab) centric with cooperative event dispatch being the rule there unless otherwise specified in the language (for backwards compatibility).
        • He could easily put 1 thread per tab and not have any concurrency issues, no race conditions, no deadlocks. ... You don't need to add threading within a javascript script - that'd be overengineering worthy of the FF memory leak.

          Please dont contradict yourself. It makes yourself look stupid. :P

          Everything using Gecko uses a UI powered by (yep you guessed it) Javascript and XUL.
          Click the Home button? Thats javascript swapping the clicked image in and changing the url.
          Kinda makes you realize what a bloody good job the Mozilla guys have done.

          The javascript engine needs threading because every single thing you see on the screen was created by javascript.

      • by dedazo ( 737510 )
        Which can be clearly translated to "The current code base is a mess and we'd be committing suicide if we tried to do this simple thing with it. Therefore, we need to rewrite large chunks, and that's going to take a bloody eternity, so don't hold your breath"

        However, I believe the OP was referring to the Mozilla UI core. Is that affected by the JS engine since the browser itself is a XUL component? I have no idea. I tried to look at the Firefox code once and nearly gouged my eyes out after a few hours.

        Bu

      • by suv4x4 ( 956391 ) on Friday June 08, 2007 @05:42PM (#19445475)
        A requirement for JS3 (along with hygienic macros) is to do something along these more implicit lines of concurrency support.

        He said that? Shit.

        Let me put things perspective. Tamarin (the Adobe Flash script engine) is currently implementation of JavaScript 2.0 and not 3.0. It'll show up not in Firefox 3, but Firefox 4 earliest.

        To get it from JS 2.0 to 3.0 (which doesn't exist even in the form of a draft yet), it'll probably mean few more major versions, Firefox 7, Firefox 8 maybe?

        Firefox doesn't just run JavaScript in the pages on JavaScript. Instead, the whole damn thing is a big swat of JavaScript, that talks to the XUL/Gecko components.

        So it'll be some 5-10 years before we see multithreaded Firefox? Nice. Perfect.

        Now.. when do we expect multicore desktops and laptops to start showing up, and the competition (IE/Opera/Safari) making use of multiple threads to massively improve the responsiveness of their UI? Oh yes... yesterday.

        Why is this whole story so familiar? It's Netscape all over again:

        "Let's just wait and add bloat and not do much about our biggest problem, since The Solution Has To Be Perfect. Threads suck, instead we'll wait for Something Perfect to manifest in reality for us."

        At the same time the competition uses whatever's out there and works, and runs past them.

        And they will be like "oh shoot, we can never fix this in time, it's all based on JavaScript/XUL, we need a rewrite". Then they disappear for 5 years while trying to rewrite their newly formed mess, and Microsoft stops development at IE8 and stagnates.

        Nice.
        • by Dan Ost ( 415913 )
          I wish I had mod points.

          That was the most insightfully depressing summation of things I've ever seen.
        • Spidermonkey has (simple) patches to support threading. While there's no built-in language primitives for it the core was almost already threadsafe anyway... it just needed an interface.
          I've actually played with it in jsext and I was kind of surprised.

          Of course it's not so cleanly implemented as in java with monitors and critical sections being a language component. You have to interface objects that wrap stuff if you want to share mutable data between threads.

          Nevertheless it would be a quicker fix for Fire
        • Why is this whole story so familiar? It's Netscape all over again:
          What? Does IE really have excellent threading? :S

          Gecko runs very nicely on old single core computers.
          I really dont see why your bitching about it not being able to use 256 cpu cores.
          It simply doesnt need to.
  • Places (Score:5, Funny)

    by morgan_greywolf ( 835522 ) on Friday June 08, 2007 @03:35PM (#19443759) Homepage Journal

    "We haven't figured out how to make Places lose data."


    rm -rf .mozilla

    • Re:Places (Score:5, Funny)

      by WhyDoYouWantToKnow ( 1039964 ) on Friday June 08, 2007 @03:43PM (#19443867)
      Come on, that's hardly a cross platform solution.
    • The fact that crash handling system does not support Linux yet is not a big problem. I have used Linux distros for five years as my main system, and I use computers __a lot__ each day, and I never had a unrecoverable freeze-up or crash like in Windows, I have had other problems of course, but I have had never had Linux crash. I have also had Firefox instances open for weeks with no trouble.

      No if they could make it look less ugly and more native on GNOME, that would be nice.

      • Create a file named "freeze.sh" with the following contents:

        bash freeze.sh &
        bash freeze.sh &
        bash freeze.sh &
        sleep 10h

        Run it, count to 100, and then fix it without rebooting.

  • Alpha? (Score:3, Funny)

    by FlyByPC ( 841016 ) on Friday June 08, 2007 @03:35PM (#19443763) Homepage
    There's just something about hearing "Alpha" and "browser" in the same sentence that's scary. The *release* versions are dodgy enough, even in Firefox.

    I'll wait, thanks.
    • by rayvd ( 155635 )
      True. :-) However, I've been using Gran Paradiso for the last 3 or 4 months now as my primary browser. It does crash once in a while, but the session recovery works very well and the new Gecko engine is just much speedier (especially for large tables) than Firefox 1.5.x/2.x. Worth it for me.
  • Losing Data (Score:2, Funny)

    by Anonymous Coward
    "We haven't figured out how to make Places lose data."

    Call the Microsoft Office Design Team. They'll help you with that in a snap!
  • I've discovered google bookmarks, and nothing beats bookmarking at work and going home or using the laptop to pickup where I left off. Places is a quantum leap behind that. You can use del.icio.us bookmarks and that toolbar too. Unless all you ever use is a single computer, I really don't see a good reason for Places. Using Places is like paying per minute for domestic long distance, you can do it, buy why?
    • Call me paranoid, but I don't want my home bookmarks mixed in with my work bookmarks. Nor do I want to go home and have work staring back at me. Separation is good.

      But if you want there are add-ons [mozilla.org] that sync your places bookmarks with your del.icio.us/google/etc bookmarks. So really it's helping facilitate the use of those services.
    • Re: (Score:3, Insightful)

      by Ctrl-Z ( 28806 )

      Using Places is like paying per minute for domestic long distance, you can do it, buy why?
      Pardon me? How is it anything like that at all? I don't have any problem paying per minute for domestic long distance. If you don't make a lot of long distance calls, it can be cheaper than a flat-rate plan. But, I guess I also keep separate bookmarks at home and work, so maybe you are onto something.
    • Why prefer local bookmarks to Google Bookmarks, you ask?

      Because what I choose to bookmark reveals a good deal about me, and I'd prefer not to hand that information to a corporation. Even one whose motto is "don't be evil."

      The article mentions that the Mozilla devs might integrate their own bookmark synchronization code straight into Firefox. I might consider using that, as long as I can set it up to use MY server for storing the data.
    • by daeg ( 828071 )
      Places has a lot more capabilities than just bookmark organization.

      Places also introduces the ultra-compact SQLite into the bookmark and history arena. Hopefully as adoption of SQLite continues we can see less Mork files and other file types in the Mozilla applications.

      As a system administrator, it would be completely awesome to integrate directly with my users' SQLite files, introducing bookmarks at logon, reorganizing them at logon, etc. Currently I have to parse HTML files and other such atrocities.

      And b
  • by Anonymous Coward on Friday June 08, 2007 @04:03PM (#19444177)
    I want to know if the geriatric, yet debilitating, bugs have been fixed. For example, bug #154892, "splitting absolutely positioned frames" that prevents people from printing many web pages from Firefox.

    I'd also like the developers to think about the little subtleties that, as a Mac user, I take for granted from other applications. For example, when Firefox creates a new window it shouldn't be falling off the bottom of the screen.

    Also, why does Firefox insist on displaying two different Mozilla pages after Firefox has been updated rather than just displaying my regular start page? This is rude and insulting. It does nothing for me. Finally, after 45 minutes with Google, I did figure out how to effectively disable this "feature" (about:config then change the keys named startup.homepage_welcome_url and startup.homepage_override_url to my regular start page) so that I merely get two start pages instead. (BTW, this "feature" cannot be disabled in Camino -- it appears to be hard coded in to the application bundle.)

    There are many things I like about Firefox, specifically several extensions, but other things like those mentioned above that routinely drive me nuts -- I could keep listing them, but will spare everyone.

    I would like to kindly suggest that the Firefox developers sit down and fix the irritating quirks, ancient bugs, and brain dead behaviors before adding new ones.
  • by eddan ( 903540 ) on Friday June 08, 2007 @04:08PM (#19444265) Homepage
    Quote from the blog entry on the new password manager [mozilla.com]:

    The first part, a long slog of untangling and porting the old C++ code to JS, is now complete.
    Now, THAT sounds like something you want to do. I always mock up something quick in C++ and port it to JS afterwards.
  • Nothing to see here. (Score:3, Interesting)

    by the_kanzure ( 1100087 ) on Friday June 08, 2007 @04:20PM (#19444455) Homepage
    Maybe it is time that we seriously discuss the state of browsing the world wide web and suggest some new browser features to implement, not just "bookmark tagging". Can't we come up with something to increase browsing productivity more than "bookmark sharing" ? Brainstorming in groups is useful in this situation.

    I use the Opera browser to open up 200+ tabs in one single session at a time, and it would be useful if they implemented more session management, such as the ability to add tabs to specifically saved sessions. Same goes for Firefox.

    Let's increase the number of pages that we can view per day. When you look at the numbers, we view a surprisingly small percentage of the content available on the WWW re: nearly any subject. The fact that the limit to the number of tabs that can be opened in one active browsing session is somewhat dependent on how much the browser can handle at once seems silly- cached tabs and an ability to predict which tabs the user might pull up next would be useful (though no fancy prediction algorithms, that would be too much).

    There is a suggestion on the Opera discussion boards about a "rush mode" for viewing tabs such that you can strategize which tabs you are to go to next when you close the current tab. That would be a useful plugin to implement. Speaking of which, where do we draw the line between plugin and component to distribute with the browser?

    The web history features can also be improved, perhaps graphical illustrations of the pathways through the world wide web would be an improvement, such that there is no longer this linear time dependency, when in truth we go through many tabs and have many separate histories building at once. There's lots of information being lost in current history tracking.

    And, does anybody else use browsers as extensively as I do? I would be interested in meeting with some of you and discussing strategies for increasing web browsing and content consumption rates.
    • I would like a way to organize my tabs into trees(2 dimensional) This way I can create a logical organization to the pages I've found and how they relate
  • It'd be nice to see some progress on :nth-child() support [mozilla.org] and positioning for generated content support [mozilla.org]. Konqueror supports both of these already, and it'd be nice to have feature parity there. Don't bother mentioning IE, because I don't care about IE.

    • by Kelson ( 129150 ) *

      Well, you could always look at what they have added [mozilla.org] to CSS support:

      • The display property's inline-block and inline-table values are now implemented.
      • The font-size-adjust property now works on all platforms; previously it was only supported on Windows.
      • rgba() and hsla() color values support (bug 147017)
      • :default pseudo-class support (bug 302186)
  • by obender ( 546976 ) on Friday June 08, 2007 @06:40PM (#19445981)
    Out of curiosity I did a find and grep on the source tree to see what companies contributed to the code base. I have to say there is at least one I did not expect. Here they are in no particular order:

    IBM, Intel, Oracle, Mozilla, Microsoft, Netscape, MITRE, Digital Equipment, Novell, Activestate

    I looked for the Microsoft code and it was just stuff copied from the SDK samples. Still, I did another count:

    find . -name '*.c*' -exec grep -i Microsoft {} \; | wc -l
    332
    I would be really curious to do the same search on the IE7 code base, this time looking for Mozilla
    • Re: (Score:3, Insightful)

      find . -name '*.c*' -exec grep -i Microsoft {} \; | wc -l
      Buddy, you just counted the lines that contain microsoft. Without doing an actual analysis myself I take most lines will be code and comments for/on compatibility with MS targeted sites/pages. I don't expect MS to actually contribute to FF since they have a competing product.
  • Up and down arrows still activate the dropdown in the location bar instead of move to the front and end of the typed text like on every other mac application in existence. Won't use it until it's fixed. Can't use it until it's fixed.

    And fan boys, don't try and say that it up and down arrows are stupid, that's irrelevant. It's platform convention. Don't say that it's impossible to use a drop down without binding activation to the down arrow. Safari does it just fine.
    • Firefox runs its own UI/user-experience engine. The whole XUL bit. Keypresses enter the front and they get treated the same on every platform. There are no isOS="MacOS" checks in the keyboard code in Chrome to determine what to do if you press up or down. It does the same thing everywhere.

      So, use Camino. It uses the Mac UI and just renders using Gecko.

There are never any bugs you haven't found yet.

Working...