Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Firefox GUI Mozilla Upgrades IT

Firefox 4 Beta 1 Shines On HTML5 256

snydeq writes "InfoWorld's Peter Wayner takes a first look at Firefox 4 Beta 1 and sees several noteworthy HTML5 integrations that bring Firefox 4 'that much closer to taking over everything on the desktop.' Beyond the Chrome-like UI, Firefox 4 adds several new features that 'open up new opportunities for AJAX and JavaScript programmers to add more razzle-dazzle and catch up with Adobe Flash, Adobe AIR, Microsoft Silverlight, and other plug-ins,' Wayner writes. 'Firefox 4 also adds an implementation of the Websockets API, a tool for enabling the browser and the server to pass data back and forth as needed, making it unnecessary for the browser to keep asking the server if there's anything new to report.'"
This discussion has been archived. No new comments can be posted.

Firefox 4 Beta 1 Shines On HTML5

Comments Filter:
  • by tyrione ( 134248 ) on Thursday July 08, 2010 @04:14PM (#32844062) Homepage
    He's living in a cloud if he thinks it's going to ``take over everything on the desktop.''
    • Re: (Score:3, Funny)

      by Anonymous Coward

      I left a cloud on your mom's desktop last night.

    • Re: (Score:3, Interesting)

      Famous last words.

      Well no... okay okay okay... I see what you're saying, there's no way Firefox could possibly take over EVERYTHING on the desktop, there are many things that operate outside of applications.

      However, for what most people use a computer for, a web browser does most of it. Email? Who here has an email address and check it using their favourite browser. I know I've got a hotmail and a gmail. Surfing the web? Thats a given. Aside from games, what do most people do on computers? Word processing,

      • Re: (Score:3, Interesting)

        by Requiem18th ( 742389 )

        But what's the point of installing a word editor as a pluging? Just install OpenOffice.org already, it will do more and run faster than anything firefox can offer(, yes it's Java but firefox is *Javascript* which is slower still).

        The beauty of web apps is noth that they can be installed as plugins but that they are accessible from any platform with a browser. From your PC to your phone to your gaming console, to your plane sit, to your toilet, if you live in Japan.

        Any web-enabled machine becomes your deskto

        • Re: (Score:3, Informative)

          yes it's Java

          Where does this myth come from? Most of OOo is written in C++, and even many parts written in Java are compiled to machine-code using GCJ. The only parts of OOo that require a JRE (Java interpreter/JIT compiler) are:
          * the media player on Unix-like systems
          * all document wizards in Writer
          * accessibility tools
          * Report Autopilot
          * JDBC driver support

  • by Pojut ( 1027544 ) on Thursday July 08, 2010 @04:16PM (#32844078) Homepage

    ::grumble grumble:: Memory leak
    ::grumble grumble:: Bloated
    ::grumble grumble:: Not nearly as good as it once was
    ::grumble grumble:: Most development money comes from Google
    ::grumble grumble:: Not as good as Gecko/Opera/Safari/Chrome/etc

    • by silverkniveshotmail. ( 713965 ) on Thursday July 08, 2010 @04:23PM (#32844162) Journal

      ::grumble grumble:: Memory leak
      ::grumble grumble:: Bloated
      ::grumble grumble:: Not nearly as good as it once was
      ::grumble grumble:: Most development money comes from Google
      ::grumble grumble:: Not as good as Gecko/Opera/Safari/Chrome/etc

      Plugins?

    • Re: (Score:2, Informative)

      by Anonymous Coward

      ::grumble grumble:: Not as good as Gecko/Opera/Safari/Chrome/etc

      Gecko is the rendering engine of Firefox.

    • rabble rabble rabble.

      rabble!

    • For me it would be;
      New tabs opening right next to the current tab
      Tabs on top now!? *grumble grumble hissyfit grumble rant on /.*
    • Re: (Score:2, Interesting)

      by Khyber ( 864651 )

      ::grumble grumble:: fixing a fucking FACEBOOK flaw instead of focusing on security.

    • I believe you left out ::grumble grumble:: bugzilla is no help, everyone still ignores me

    • by kobaz ( 107760 )

      You missed: ::grumble grumble:: Crashy

      Beta 4 crashes any time I right click on a link
      It crashes any time I load a new plugin
      It crashes any time I open a new tab

  • by elucido ( 870205 ) * on Thursday July 08, 2010 @04:24PM (#32844172)

    Firefox needs to have better built in support for Ironkey, smartcards and security tokens. So we can once and for all switch away from passwords.

    If Firefox actually supports security tokens, it's not very intuitive.

  • by Burz ( 138833 ) on Thursday July 08, 2010 @04:37PM (#32844296) Homepage Journal

    Mozilla and Google have got this one WRONG:

    Merging the address and search fields is a big drawback. It further confuses people about what a URL is, and it encourages them and others (esp. advertisers) to give directions to web sites as if the keywords == addresses. (Hey, like AOL!)

    If this trend continues, we'll have shenanigans and lawsuits claiming that "squatters" are using keywords on their pages that "belong to us". It will open another "IP" can of worms.

    Encouraging people to rely on keywords also opens them up to phishing big time. It's like having them clean their teeth with their enema: Very semantically dirty!

    • by blair1q ( 305137 ) on Thursday July 08, 2010 @04:50PM (#32844448) Journal

      well, no, actually, that's a good thing.

      URIs have become cumbersome. Making the net content-addressable is a big efficiency measure.

      You can still give out a key that will only map to you, and return a URI that is clearly you. Or at least as clearly as happens now when someone does a Google search.

      But now you're not constrained to identifying yourself with some bogus fqdn with a limiting TLD stuck on it.

      As for Phishing, banks have moved to authentication systems that use graphics on the page to tell you that the password-entry box you're looking at is legit. If you don't see your predetermined secret glyph, you don't enter your password. And the glyph isn't sent until your browser and the server are connected by SSL, so it can't be sniffed and hacked into a phishing site. And it isn't sent unless your browser already has a cookie identifying it as having been validated previously, using a secret-question protocol. If you deleted the cookie, you go through the secret-question routine again.

      Short of adding more layers of such things, or using in-person pre-validated biometrics over secure links, you're not getting much more security than that on the internet. Using simple, recognizable URIs won't help you, and really, just invites social engineering based on URIs that look almost legit.

      • Re: (Score:2, Insightful)

        by Anonymous Coward
        Uh, the method you described does almost nothing to stop phishing. Doing a man-in-the-middle on it is trivial, so really all it does it is require the phisher to handle each bank separately... which they probably have to do anyway in order to make their sites look the same. The only trip-off to the user would be an extra security question being asked, which no one will notice because banks randomly ask those security questions anyway.
      • by lennier ( 44736 )

        But now you're not constrained to identifying yourself with some bogus fqdn with a limiting TLD stuck on it.

        I think you've hit on the exact opposite of the definition of 'bogus' there.

        A keyword can be spoofed by anyone. A URL, not so much.

    • Your posts defines two distinct categories: URLs and Search Terms. Most people don't think about those things as separate ideas. They're just means of telling the internet to show a website.

      The key distinction between a URL and a search term is that URLs are hard to remember and prone to typos. Search terms are far easier (and tend to be helpful even if you spell them wrong). why would I want to type in "http://krugman.blogs.nytimes.com/" when I can just type in "krugman [google.com]" (or "krugrman [google.com]") and get my daily Keynesian economic analysis that way.

      For the browser, the URL and the search term are completely distinct. For an engineer or a software programmer, it's clear why they would have separate fields for entry of one or the other.

      But for a user (even a technically savvy user) semantic cleanliness doesn't make any sense and causes more problems than benefits.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      All is good as long as I can disable search from the toolbar.

    • Re: (Score:3, Insightful)

      Yea, and it'll also reduce the incentive for people to squat and typo-squat domain names.

      I'm frankly tired of all that crap: if ICANN wants to deal with the rampant squatting, I'll start supporting "address bar for addresses only" thinking. Until then, I'd rather google hijack me to a meaningful result than accidentally direct myself to some damn squatter site.

    • Re: (Score:3, Insightful)

      by PhxBlue ( 562201 )
      Grandma doesn't care what a URL is, only that she can get to the sites she needs. If Firefox 4 is intuitive to her, then it doesn't owe me any apology.
      • Your grandma should use a device designed for her age then. Stop thinking PC usage based on grandmas anymore. That's not 90s. Current generation is growing with computers, and they should be intelligent enough to know and grasp the basics of computing.
      • by Kaboom13 ( 235759 ) <kaboom108@@@bellsouth...net> on Thursday July 08, 2010 @05:52PM (#32845020)

        Firefox started as the browser that wasn't for your grandma. It had rough edges, pages didn't always display properly, but it was fast and tabbed an light weight with an installer in the single digits. This is how it grew it's user base, Trying to shoehorn it into the browser for grandma is retarded (Chrome already is better for that, by a good margin). Fuck your grandma, I don't want to use the best browser for your grandma. Our requirements are completely different. I want Firefox to be the best browser for me. I want separate url and search fields because I know exactly what I am trying to accomplish. If I want to stick some search terms through google I will, if I want to go to slashdot.com instead of slashdot.org I had a specific reason. I want the url bar to make a best effort at turning what I entered into a working url with as little guessing as possible and run with it.

        Let chrome be the browser for grandma, they have the resources and the marketing power behind them. Leave Firefox pure to the roots it came from, and focus on technical aspects. If people want to change the ui, the wonderful extension system lets them do just that.

    • Couldn't agree more. There is no need to engineer in favor of computer illiteracy.
    • Re: (Score:2, Insightful)

      Definitely. I love having them separate. Besides, even my netbook has a resolution of 1366x768. Who needs an address bar that's over a thousand pixels wide? I mean, really. So much of their efforts go into optimizing screen space usage, but I feel that a unified bar that's mostly blank really defeats this purpose.
    • by BZ ( 40346 ) on Thursday July 08, 2010 @07:55PM (#32846114)

      > Merging the address and search fields is a big drawback

      Of course Mozilla hasn't merged them. So I'm not sure what you think they got wrong.

    • Re: (Score:3, Insightful)

      by boxwood ( 1742976 )

      I think the opposite. DNS has gone to shit because of the squatters. To the point that its pretty much useless now.

      And with all the phishing sites.... well we should be discouraging people from typing in $COMPANY_NAME.com to get information they need. They make one typo or if the site they want is under a TLD other than .com then at best they're going to be inconvenienced by loading up the wrong page, and at worst they've entered their banking logon into a phishing site.

      Its far better for people to simply e

  • Great, more client side slow down.

    No, not trolling, i just long for the old days where the processing was done on the server side, and all you needed was a tiny client.

    • Re: (Score:3, Insightful)

      by blair1q ( 305137 )

      Hmm. Have ten million users doing the same ten million calculations each on different data on the sever, or have the ten million users download their data and do the calculations on their own machine...which one will complete faster?

      Server-side scripting is a massive bottleneck if the page has any complexity at all.

      What you should be complaining about is the disastrous state of the code sent to the client side. Most of it is painfully bad.

    • by guruevi ( 827432 )

      These days however, clients are about as fast as their servers (if not faster) and servers have thousands of requests to handle. Most recent clients should be able to handle it. However, I wish that more developers also developed a site that would still work without JS however for simpler clients. There are simple ways to do that, to submit information, just use standard forms and AJAX those up. Same goes for menu's - they should be workable without a mouse (no 'hover' functionality) and use CSS instead of

      • JavaScript is not the problem for blind users, there is WAI-ARIA for that. The newest crop of screen readers can deal just fine with Ajax sites, provided they're wired correctly.

        Also, I think the leap from the lightest mobile device to the heaviest desktop user is too big. You have to split your UI into a few key segments and optimize each. If you try to make a single UI fit all purposes, you end up fitting no purpose exactly right, and spend a lot more effort than when building a few dedicated UI's.

  • Horray Websockets! (Score:5, Informative)

    by DontLickJesus ( 1141027 ) on Thursday July 08, 2010 @04:40PM (#32844350) Homepage Journal
    As a javascript developer I'd simply like to applaud this addition from the HTML5 spec. Simulating the effect with Web Workers wasn't cutting it.
    • Re: (Score:3, Interesting)

      by h4rr4r ( 612664 )

      As a developer, sysadmin and end user I would like to tell you that HTTP is not for this there are other ports than 80 and the web browser is not a virtual machine.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        As a developer, sysadmin and end user I would like to tell you that HTTP is not for this there are other ports than 80 and the web browser is not a virtual machine.

        With the addition of canvas and now websockets... it is now.

  • by dionyziz ( 736817 ) on Thursday July 08, 2010 @05:07PM (#32844616) Homepage
    Interestingly, Firefox compares poorly to other browsers when it comes to heavy rendering in "canvas". Here's a demo I made that allows measuring the speed of rendering in FPS (frames per second).

    http://dionyziz.kamibu.com/3d/heli/

    Chrome 6: 31 FPS
    Opera 10.60: 46 FPS
    Safari 5.0: 25 FPS; visually poor results
    Internet Explorer 9: 19 FPS
    Firefox 4.0 Beta 1: 19 FPS
    • I get about 25-30 FPS in the Firefox beta 1 (32-bit version) under Linux.

      I get about the same as you in Chrome and Opera (64-bit versions, also Linux).

  • Browsers are designed and implemented to display documents, not to be as interactive as normal desktop apps, sure we try to cross that bridge with all the tricks and yet the browsers are just too slow for using as good desktop apps. They render and re-render to get the layout right the way the designers wanted it, but while recalculating all of those layouts and all of the elements that come in later, scripts that execute after the html is parsed and dom is created and css are applied and then re-rendering

    • by jsebrech ( 525647 ) on Thursday July 08, 2010 @05:51PM (#32845014)

      You do realize that flash internally manages a display object hierarchy not unlike the DOM? There isn't much difference between writing apps in flex/flash and writing apps in javascript with something like ExtJS toolkit. All rich app frameworks I know, on any platform, use the HTML-like approach of having an element hierarchy and a set of layout rules that are constantly re-calculated.

      HTML may be ill-suited to rich app development, but so is everything else. Win32 and X11 are both truly horrible API's, arguably much worse than HTML+JS+CSS, but combined they hold the majority share of native apps.

      And by the way, the browsers of today are designed for rich applications. They have been for a few years now. Cars were originally designed to make it up to a brisk walking pace at best. Things change.

      • Re: (Score:3, Funny)

        Things change.

        Heresy!

      • whatever the browsers of today are designed for, I still find that when I try to display a table with 20,000 rows in it in 8 columns, it takes almost a minute to create/render this table in a browser, vs less than 1 second in a Java applet running in the same browser, so I can scroll to the very bottom of the JTable in the applet 1 second after the data starts loading, in the same time the browser renders maybe 300-400 rows.

        This is not helped by any of the technologies that exist, GWT compiler/code cutter d

  • The article doesn't say so but another one (http://digitizor.com/2010/06/30/review-of-firefox-4-0-beta-1-for-linux/) when googling the question reveals that Firefox 4.0 beta scores 97/100. This is less than perfect which is currently achieved by other browsers. I have to wonder what the issue is. While 97/100 is better than the 94/100 of the current version 3.6.6, I have to wonder why it hasn't targeted 100/100 for this release.

    Perhaps someone in the know will have something interesting to reveal on the

    • Re: (Score:3, Informative)

      by t0y ( 700664 )
      The remaining tests target SVG font functionalities which are not being actively developed.
      You can find a semi-official rationale for not implementing them here: http://weblogs.mozillazine.org/roc/archives/2010/06/not_implementin.html [mozillazine.org]
    • by BZ ( 40346 ) on Thursday July 08, 2010 @10:05PM (#32847010)

      Those remaining 3 points are SVG Fonts.

      Opera and Webkit implemented (very brokenly, in at least Opera's case) a small subset of SVG 1.1 Fonts; basicallu just enough to pass Acid 3. We don't particular want to do that small subset in Gecko, since it gives no benefits to authors or users over the existing downloadable font support (beyond the brownie points on Acid3). On the other hand, support for the full specification in a UA that also supports HTML is ... very difficult. SVG fonts are just not designed with integration with HTML in mind. Once you put an in a glyph, all sorts of issues arise (both in terms of the spec being underdefined and in terms of the behavior being very difficult to implement no matter what the spec said).

      One of the previous commenters here linked to Robert O'Callahan's post about this, which covers the issues pretty well.

      At this point, the SVG working group has decided that SVG Fonts will no longer be a core part of SVG but will be a separate specification, and that it might need some serious work if anyone is ever to implement it in full.

  • this last change in the last version that has the flash and other plugins run in a separate plugin container which prevents firefox from crashing when any of these plugins (Especially flash) crashes, has set a lot of things right already. all you need to do now is to refresh the page to get the plugins rolling again.
  • Why would the developers only reduce the title bar size by half? It's like a landing strip: if you're going to go through the trouble of shaving some off, you might as well shave it all off.

"If it ain't broke, don't fix it." - Bert Lantz

Working...