Development, Privacy, and Standards for Chrome

Continuing our coverage of Google Chrome, snydeq points out an Infoworld story about looking at the new browser from a developer's perspective, and another about how WebKit should be the focus of development efforts, rather than the browsers that use it. TGdaily notes that Chrome's search box will fetch all types of data, and can be made to display banking information with little effort. ABC and coderrr have slightly more paranoid articles questioning Google's commitment to privacy. NetworkWorld suggests that Chrome's unique process model (explained here) will require the development of new measurement standards.

Comments

Completely good and noble

[David Gerard]

Webkit is completely safe; Apple is completely good and noble. Google will maintain complete confidentiality within the marketing department of whatever the browser accessed concerning your confidential business data, bank account details, medical information and personal preferences in pornography. Apple won't even tell you about you.

Re:Completely good and noble

[ionix5891]

personal preferences in pornography.
well they did provide a incognito "porn" mode which meant to give you privacy, or so were told....

Re:Completely good and noble

[David Gerard]

Even KDE's switching to WebKit, at least as an option. It appears to be sinking into Apple's head that they can 0wn this project, but playing nice with others is more likely to get them something that works well. You know ... open source.

Re:Completely good and noble

[Bobdog]

LOL

is the LHC safe running chrome tho

nice one

Re:Completely good and noble

[David Gerard]

Eh? Non-starter? Apple used it in Safari because it was technically way easier to work with than Gecko.

Re:Completely good and noble

[foniksonik]

Uh... Webkit doesn't have vulnerabiities it has bugs... the browser is what has vulnerabilities. Webkit has no network stack... it can't communicate. All it can do is accept input and render output.

The javascript engine can have vulnerabilities because of XMLHttp, cookies and filesystem access... but even then it passes all comms through the browser or directly through the filesystem.

Re:Completely good and noble

[bogaboga]

Non starter (to me) because many websites would never allow you to even get close while using it! For Gecko, the story was very different.

This situation is similar to Apple's and Microsoft's OS.

Though many believed Apple's OS was better in many ways, it never really caught on. Other reasons might be behind this too, I agree.

Simply put, KHTML is better in many ways but "better" is not and has never been a panacea for success.

Re:Completely good and noble

[David Gerard]

Yeah, I forgot website developers are often idiots ;-p

I haven't had anything keep me out with Konqueror for a while. Except my bank, which accepts Firefox but not SeaMonkey. o_0

Re:Completely good and noble

[kestasjk]

I don't see why a rendering engine can't have security vulnerabilities, just like any other software which processes input from an untrusted source.

Re:Completely good and noble

[Anonymous Coward]

You do realize WebKit is a fork a KHTML right?

Re:Completely good and noble

[EsbenMoseHansen]

And a rather close one, too. It is amazing people let Apple get away with rebranding KHTML "Webkit", but hey. As long as it makes the world better, and the less code from Apple the better :P

Re:Completely good and noble

[nog_lorp]

True. Google "GDI+ vulnerability" for proof.

Re:Completely good and noble

[Firehed]

Are there still web developers out there that do anything with server-side user-agent detection, with the exception of forwarding to a mobile page? If you're, as a web developer, doing anything more than IE-conditional stylesheets, you should be immediately stripped of your job and title and forced to spend an eternity browsing the web with Lynx.

Seriously, outside of long-outdated intranets, has this been an issue in the last five years or so? I haven't seen issues related to ActiveX in years which is the only somewhat-reasonable reason to block a browser/UA. The types of developers who would do that are almost certainly stuck in the land of table hell, which despite all of their other problems are pretty safe in terms of cross-browser display consistency so that's out as a reason.

Re:Completely good and noble

[truthsearch]

I'm a web developer and no one in my small company has ever used user-agent detection in the years I've been there. The closest we've ever come is checking for what's available to the JavaScript runtime, but even that is done by checking for the existence of objects and methods rather than seeing what browser is running.

With few exceptions (and those mostly only in design considerations), coding to standards has generally worked pretty well in recent years.

Re:Completely good and noble

[slimjim8094]

Eh, not that close. Remember, the Apple guys fixed a bunch of CSS bugs (think Acid2) and passed them upstream.

They did a lot of work, and kudos to them.

Re:Completely good and noble

[Kz]

I'd be happier if Google had chosen Firefox's engine instead of Webkit. You might wonder why...it's because Apple tried to play "hard ball" with the KHTML developers whose product Apple based Webkit on. I just do not trust Apple.

AFAICT, WebKit isn't driven by Apple anymore. people from the original KHTML and from Qt (now at nokia) are doing great things on the shared codebase. neither of those groups have any (obvious) vested interests in doing sneaky things to your browser.

Also, any 'bad' things would be easier to do on the app level, not the rendering engine level. so no difference in 'trustfullness' by using WebKit or Gecko.

Re:Completely good and noble

[tobiasly]

Uh... Webkit doesn't have vulnerabiities it has bugs... the browser is what has vulnerabilities. Webkit has no network stack... it can't communicate. All it can do is accept input and render output.

Hahaha... your understanding of security is so 1995. I remember another great one, "you can't get malware via email unless you double-click an attachment." If WebKit has a single buffer overflow bug, then yes, it does have vulnerabilities.

Remember this gem from a couple years ago, "Vulnerability in Graphics Rendering Engine Could Allow Remote Code Execution (912919)"? But it's just a graphics rendering engine, how could it allow remote code execution?

Re:Completely good and noble

[corrie]

Absolultely. Also, all sources are actually untrustworthy. Security is not about being paranoid, necessarily, it's about the simple fact that things can and do go wrong. And when something that goes wrong can be caused or reproduced, then you have yourself an exploitably vulnerability.

Re:Completely good and noble

[foniksonik]

I stand by it even if it is from 1995... all that means is that the browser should put the rendering engine in a sandbox and should handle the output before letting it out.

The only reason this isn't done already is probably performance... reading data twice is probably too much overhead, so they don't do it the right way.

Still a render engine shouldn't need to worry about anything but rendering.

Again, it's a bug not a vulnerability. So the render engine allows for a buffer overflow... shouldn't that be handled at a lower level? As in should there be a registration of some sort happening where the render engine can broadcast the stated buffer it is expecting to use, then an overflow handler at a lower level will check the actual output against the expected output?

Say "no" to Google spyware

[Anonymous Coward]

If you want to try Chrome, use this version without the silently installed, never removed and hard to disable 'Google Update'.

Re:Say "no" to Google spyware

[David Gerard]

Direct Google link to standalone installer.

Note that this doesn't install under Wine - you need the binary Zip file (which I can't find a direct link to) to try it under Wine. And it still doesn't actually work, so find the missing functions and get to work writing them for Wine ;-)

Re:Say "no" to Google spyware

[pablomme]

Wine 1.1.4 specifically includes "Several fixes for Google Chrome support". https support is still missing, though.

Re:Say "no" to Google spyware

[David Gerard]

winnah!

Yeah, the fixes are simple enough. Someone just has to write them. That's how Wine gets better :-D

Re:Say "no" to Google spyware

[ksd1337]

Oh, that's real nice. Chrome runs on Wine, but it doesn't even run on Windows 2000. I was disappointed to learn it didn't run on Win2k, because I have no XP/Vista machines.

Re:Say "no" to Google spyware

[David Gerard]

Wine but not Win2k? We all LOLed.

Re:Say "no" to Google spyware

[phanboy_iv]

Yes, it does run on Windows 2000. It just complains about not supporting it officially on startup.

Re:Say "no" to Google spyware

[Tim C]

I noticed that, and disabled it using Windows Defender. Now after a reboot, it's not showing in Windows Defender that I can see, and yet it's running again...

I'm getting pretty sick and tired of companies bundling that sort of thing with their main product - Apple does it (Bonjour, MobileMe, the Apple Updater, a couple of always-running iTunes helper processes), Real does it, Sun does it with Java, and now Google.

I appreciate that it makes things easier for the average, non-technical user, but I'm not one of them and would much prefer the ability to pick and choose what is installed; I'm perfectly capable of checking for updates myself, thank you.

Two was bad enough

[FloydTheDroid]

I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror as their managers noticed that this Webkit browser has a couple of percentage points.

Chrome is a resource hog

[kasot]

Yes, it's fast. With a couple of tabs up it also takes up half of my CPU. Browsing three norwegian news sites (ap.no db.no vg.no - all use flash for ads etc.) on my AMD Athlon X2 6000+ uses at least 50% of the CPU and nearly 200 MB of RAM. Try it yourself...

Re:Chrome is a resource hog

[drseuk]

Obviously you've never been married then. >=50% resource use is perfectly normal.

Re:Chrome is a resource hog

[David Gerard]

How's it run on a lesser box? Using available resources to do their job is what apps are supposed to do, after all ...

Re:Chrome is a resource hog

[nomadic]

Yes, it's fast.

FAST?? Are we talking about the same browser?? The only thing Chrome seems to be faster at is javascript; everything else crawls.

Re:Chrome is a resource hog

[Helios1182]

I would mod this up if I could. So Chrome uses 50% of the CPU and some even smaller amount of memory. How much of the CPU is still idle? It wouldn't surprise me if it is ~40%. So most of your CPU power is still being wasted.

Re:Chrome is a resource hog

[David Gerard]

200MB memory sounds reasonable too. In my experience of rejuvenating old PCs, a 2000-era Pentium II does just fine doing modern things ... if you put 768 to 1024MB memory in it. Modern browsing is fat. (Even Opera, which achieves its speed mostly by cutting corners, and makes Firefox 2 look solid in memory leaks.)

Re:Chrome is a resource hog

[tedu_again]

CPUs use a let less power idle than working. I'd rather waste potential CPU power than real electric power.

Re:Chrome is a resource hog

[David Gerard]

In this case I suspect Flash is the major offender.

Re:Chrome is a resource hog

[Beryllium Sphere(tm)]

I've been playing with it in a Parallels virtual machine with 256M of RAM, on a 1.2GHz processor. It's functional and snappy, showing none of the problems you'd expect from a memory-constrained program.

Re:Chrome is a resource hog

[jonaskoelker]

Using available resources to do their job is what apps are supposed to do, after all ...

In a similar vein, using available money to give you a place to live is what a home is supposed to do?

You seem to think that it's fine for an application to use all available resources. In and of itself, that's no big deal; you could save some money if it saved CPU usage, but let's ignore that.

The interesting bit comes when you run multiple applications. If the applications blindly hog all resources for themselves, you'll begin to swap memory out to the disk which is horribly slow, and the CPU will get contended, delaying the operations you want performed. Sure, the kernel may be a little smart about allocating resources (like always giving enough to your media player, and enough CPU to the app that's currently being interacted with, if the kernel knows this); however, there's limits to this.

If the applications try to be smart about resource usage (say, cache less stuff if RAM is more contended than CPU), they could easily oscillate, or converge to extremes: when one application frees up memory, the other grabs it and then either waits and grabs some more, or frees some which is grabbed by the first.

You get much better results running multiple applications if they don't all try to use all the resources themselves. Getting them to not do this is easiest done by keeping resource usage at a reasonable level at all times, whether contended or not.

Re:Chrome is a resource hog

[Muffinmasher]

I happen to have precisely the same CPU as you and after opening those sites, ONE of the cores was at 19% (this includes other things running in the background, as well as an extra slashdot tab) and it only used 85 megs of my RAM, which compared to Firefox is 4 megabytes less. . That's what all this newfangled hardware is for, to use. If you have a relatively modern computer 200 MBs should be around 5-10% of your RAM, heck itunes and my anti-virus both use more resources than chrome.

Re:Chrome is a resource hog

[DragonWriter]

CPUs use a let less power idle than working. I'd rather waste potential CPU power than real electric power.

And I'd rather get whatever I'm doing done quicker so I can put the computer back in hibernation and turn the monitor off, and not waste anything.

In other news: CFCs found all over California

[drseuk]

That's "Chrome Fatigue Clinics"

I would love to see Firefox move to WebKit

[whatUrunning.com]

I would love to see Firefox move to WebKit, it would certainly make life easier for web developers.

Re:I would love to see Firefox move to WebKit

[roman_mir]

Wouldn't be able to simply port any extensions though.

Re:I would love to see Firefox move to WebKit

[David Gerard]

Nah. They're both good and up-to-date renderers; competition improves quality. The way KDE and Gnome staying separate improves the desktop for both, even though they could happily interchange code.

'Do no harm' is still in effect...

[davidsyes]

Just as with doctors, as long as Google isn't the one doing any/the slashing with the scalpel. Granted, though, Google manufactures the scalpel. So long as they provide autoclaves to sterilise any contaminants (bad guys/excessively-snooping feds/cops) and make the digital nooks and crannies... 'unhospitable' to nefarios/vermin...

Gears and the storage API

[Simon (S2)]

So google stripped the HTML 5 standard local storage api from Webkit to use their own implementation Google Gears. Why? The api was already there, and it worked, so they had to strip it out to go with google gears, their own, not w3c compliant. I think they are starting to become evil.

Re:Gears and the storage API

[David Gerard]

Uh, Google is participating wholeheartedly in the HTML5 effort. Which isn't a W3C standard as yet to become compliant with. Also, Ian Hickson, the editor of HTML5, works for Google (and has previously worked for Opera and Mozilla). It's entirely too much in flux to assert that they're trying to break a standard here.

Re:Gears and the storage API

[Simon (S2)]

Do you have an explanation then why they included google gears instead of Webkits HTML 5 api? Really, just asking. The only reason I can think of is that they want to push their own implementation, but I would gladly be corrected.
Now, as it stands, web developers who want to use local, client side storage have to test for google gears AND for the webkit api, yet another fragmentation. Looks just like ie6 all over again to me, but as I sad, pleas correct me if I am wrong.

Re:Gears and the storage API

[David Gerard]

I see no reason not to assume stupidity instead of malice. Remember, they started writing this as a pure Windows application they now have to try to port to Mac and Linux (registry twiddling, DLL hell, etc), rather than writing it cross-platform from the outset - there's copious evidence of stupidity along the way. Developers set free to go "not invented here, I could sooo roll my own better" is hardly unique to Google ...

Re:Gears and the storage API

[Simon (S2)]

I see no reason not to assume stupidity instead of malice.

I do actually. The HTML 5 compatible client side storage API was lready there. To remove it, they HAD to know it is there. So they stripped it out and replaced it whit google gears. No stupidity there. Any other excuses?

Re:Gears and the storage API

[David Gerard]

Dunno. Have you asked them?

Re:Gears and the storage API

[Simon (S2)]

No, I don't care that much (at least until Chrome remains at 1%), and it looks very much self-explanatory to me.

Re:Gears and the storage API

[Awptimus Prime]

After several real-life friends began working for Google, their views on the company have been extreme. It much reminds me of my time at some early mid-90's startups that, no matter what, said company could do no wrong.

With that in mind, I would not be surprised at all to a lot of the Google hype on /., especially when it comes to blindly justifying possible "evils" of this corporate entity, are simply a bunch of Google employees operating independently in their off-time.

The drive behind my thoughts on this was one company I worked for ended up having a lot of controversy when multiple employees were doing this, but made the mistake of doing it from the corp lan, and got exposed internally, but when news hit other sites, it was considered some kind of evil campaign funded by said company while actually just frenzied staff operating on their own.

Re:Gears and the storage API

[Anpheus]

The webkit implementation in Chrome right now is over a year out of date, due to Google using it internally while writing Chrome and not changing the subsystem. So, for example, webkit can do Acid 3 to 100/100, but Google Chrome can't.

No conspiracy theory here. Wait for Google to update the current webkit version.

Re:Gears and the storage API

[David Gerard]

I'm not a Google employee, and per the first post on this story I'm less than enthralled with their habits regarding personal data about people. (I don't see them releasing it, but I do feel uneasy at gathering it all in one place at all.)

That said, I have Google employee friends who regard the place in a sensible manner, certainly as much as my Microsoft employee friends do. It's a company, y'know? Nice place to work, highly imperfect, etc.

Re:Gears and the storage API

[gsnedders]

localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.

Re:Gears and the storage API

[Simon (S2)]

localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.

[Citation needed]
Webkit has a HTML5 compliant local storage api since Friday, October 19th, 2007. So, if they branched Webkit in January 2008 as you state, the implementation was already there. But anyway, can you backup your statement with some links?

Re:Gears and the storage API

[centuren]

Do you have an explanation then why they included google gears instead of Webkits HTML 5 api? Really, just asking. The only reason I can think of is that they want to push their own implementation, but I would gladly be corrected.

I can't offer explanations, but I can think of an alternative theory or two.

1) Diversity and competition. This one stands out as most relevant / important here. We already have a popular browser using Webkit's HTML 5 API. Google has their own API. Really, we'd be at a disadvantage if they had gone the full Webkit route, because it would give us less of an opportunity to compare. ANY improvements and innovations in the browser-platform that favor web applications benefit Google, so I don't think one needs to assume an agenda of pushing their own implementation.

2) Seeing Gears as a larger project than a HTML5 API. "Webkit is an open source browser engine", and it has an HTML5 API. "Gears is a plug-in that extends your browser to create a richer platform for web applications", and it has an HTML5 API. It's entirely possible the Gears people have ambitious plans in the works to really extend what a browser can do with a web application (in the good sense). Building Chrome with Gears sets it up for a later attempt to shake up with browser market with innovation.

3) Development preference. Without being stupid or malicious, developers have preferences. Didn't Gears coders work on Chrome, at least to some extent? A chance to fully implement it in a browser and have a platform that really integrates it is a reason to make the choice on the development level.

Now, as it stands, web developers who want to use local, client side storage have to test for google gears AND for the webkit api, yet another fragmentation.

That's a big assumption. I can tell you from industry that fringe browser support is something to be considered if there's room in the timeline, or if the client has a preference. The numbers are still not persuasive enough. Firefox (Win/Mac) and Internet Explorer are always must-supports, Safari is a should-support if the client is a PC user (if something isn't working and the deadline comes, too bad Safari for users). Opera isn't even considered.

Chrome may have been released by Google, and it may jump to an amazing market share in terms of a brand new browser, but if it presents another fragmentation in support (which it claims no to), that doesn't mean developers will be clamoring to put in the extra work for a brand new browser.

It's not comparable to IE6, because IE is the dominant platform by a huge margin, and every site is expected to work on it. "Fringe" browsers (in quotes, to denote any browser that can easily be argued as fringe, regardless of use) do not produce that sort demand from clients.

Re:Gears and the storage API

[Awptimus Prime]

Yes, because anyone with a different point of view lately is "twittered" by ACs. Nice try.

Re:Gears and the storage API

[Awptimus Prime]

The evil problem with data collections is it's fairly obvious it will be in the hands of the public, criminals, or government at some point in the future.

It's very short-sighted to think otherwise, especially if Google ever fell on hard times. They could sell that information, legally, for a wad of money to advertisers. Don't think they wouldn't? Imagine shareholders demanding it and suing until it happens. That's what happens with "assets" when a company runs short on cash.

Re:Gears and the storage API

[gsnedders]

http://html5.org/tools/web-apps-tracker?from=1200&to=1201&context=10 -- I can't find that change in the WebKit repo quickly, but it must be after 2008-02-09. I don't have anything to cite for Chrome using WebKit from Saf3.1 or it being branched in Jan (though you should find that in the WebKit repo), as it was only ever said in IRC, by developers of the respective products. See if globalStorage exists in Chrome, as that was in WebKit then.

Re:Gears and the storage API

[Kz]

AFAIK, Gears SQLite storage API predates HTML5 local storage API; but on late builds, they're adding an HTML5-compatible API. I guess integrating those would let the web developer choose which one to use and access the same storage. see proposal here: http://code.google.com/p/gears/wiki/Database2API

I guess when they did the Gears-WebKit integration they had to choose what to do. obviously they wouldn't want to remove Gears SQLite API, but which one to use for HTML5? their own unfinished one, or webkit's one? in the end, i guess tweaking webkit's implementation to use the same storage as Gears would be the best of both, but seems that for now they just disabled it in hope of 'doing it better' later. remember it's a very first release yet.

Re:Gears and the storage API

[Fastolfe]

Do all web browsers support HTML 5? How many browsers support the Gears plug-in? I know nothing about the HTML5 stuff you're talking about, so I don't know why it would be *removed* in favor of the Gears APIs (why not have both?), but since Gears is available as a plug-in for other browsers, it stands to reason that at least in the short-term, supporting Gears is actually *better* for cross-browser compatibility, at least until someone comes up with a plugin that implements these same features using HTML5, or until all of the browser vendors implement it independently.

Bug

[The MAZZTer]

Indexing of HTTPS pages is most certainly a bug. Did the poster of the article report it to make Google Chrome a better product or is he just going to complain? It's only in beta.

And the work around is simple: Use Incognito mode for all sensitive work. Which is what it's for.

Re:Bug

[DancesWithBlowTorch]

It's only in beta.

I don't accept this excuse from Google, because they have effectively destroyed the concept of a beta version. Even gmail is still in beta, and it's probably among the world's top three email providers now.

Google, please do official releases of your products. Or, if you really need to childishly continue to call them development versions, invent a new category. Maybe, call them "gamma" versions. You are spoiling a useful metaphor for everyone else.

Re:Bug

[ya really]

Gmail has been in beta for how long now though? Roughly 4.5 years, right? So, will chrome still be in beta half a decade from now? Beta to me starts sounding more like an excuse for why it has bugs. After all, firefox, opera safari all have bugs, but they're not hiding behind the beta excuse. IE on the other hand, should have probably never left beta or alpha for that matter.

Re:Bug

[Koiu Lpoi]

Maybe I'm a little cynical, but it's an easy excuse for them. It basically strips them of all liability. Did it delete your %PROGRAM_FILES% and post your bank account numbers on a website (theoretical)? No problem for Google! You were using a beta product, you should have known better using a beta for anything important. Does GMail lose all your mail (real)? We feel for you man, but it's a beta, nothing we are required to, er, can do.

Re:Bug

[blahplusplus]

I don't think anyone really cares, except us who know what "beta" is. Personally I think it should just be understood that if you're online, it's constantly in development. The idea of "product releases" is in itself we might say an out-dated model, if we look at windows and windows update, software is now organic/live, it "lives" and static software will (eventually, probably not in my lifetime) have to go the way of the dodo (i.e. self-configuring, self-healing).

We want tools that can do better then we can ultimately, an adaptive program, or self-programming program, at least in some respects, is more ideal then one where you need developers to constantly baby and monitor it and updated it. It's an inhuman task that costs enormous amounts of money and man hours.

Re:Bug

[magus_melchior]

If they're using the BSD license, how about a development/release model similar to FreeBSD's* or Debian's? Maintain 2 branches, 1 for testing anything and everything, and 1 for pushing to management as a stable, "will-not-blow-up" release? Default the online services to the stable branch, but allow limited opt-ins for the testing branch; for locally-installed software like Chrome, allow downloads of both branch builds.

* Yeah, only related by history and name...

Re:Bug

[Tim C]

We feel for you man, but it's a beta, nothing we are required to, er, can do.

I wouldn't be too sure about that. I know where you're coming from, and ordinarily I'd agree, but I think if someone wanted to push the point a court would probably be sympathetic to the argument that it really isn't a beta any more - it's been in extensive, public use for far too long, and as another poster points out is probably one of the top 3 email providers. Just slapping on a label that says "this shit might break" doesn't necessarily save you.

Re:Bug

[Raenex]

Google's "beta" reminds me of those stupid under construction signs that everybody used in the early days of the web.

Re:Bug

[loyukfai]

Alpha, Beta, Gamma...

Granted, software (and to a larger extent, the human civilization), is in ever-development. From a certain perspective, one may call the previous version of a software a "Beta" of the current version.

While there are people out there refrained from using a positive integer version number for software with years of development history. Some others keep pumping out higher version numbers (or sometimes, skip some in between) for every single little feature added on top of some every-buggy software (worse still, keep charging for the "updates" a.k.a. "bugfixes").

Is Google's habit in classifying some of her products (forever?) in "Beta" stage, as others have claimed, lie in her ability to defend itself from liability claims...? Or, if it's just a kind of humour...? Or, if it's just some philosophic foresight...?

Cheers.

Multithreaded tabs

[AmiMoJo]

A thread for each tab is something that people have been requesting in Firefox for a long time now. I suppose architectural issues are what prevent it being implemented, but hopefully now people can see the real benefits that come with it the Moz devs will be encouraged to make the effort too.

Firefox freezes up a lot when opening multiple tabs, due to having to render and scale images, run Javascript and do the layout. FF3 is faster because it uses hardware acceleration for graphics, but the pauses are still annoying. In Chrome there is none of that.

Re:Multithreaded tabs

[abigor]

You mean processes rather than threads. Big difference.

Re:Multithreaded tabs

[David Gerard]

All the JavaScript in Firefox, including the entire interface, runs in a single thread.

The big change for Firefox 4 will be multithreaded JavaScript, where one tab or bad AJAX app or UI bug won't freeze every damn thing.

new tag!

[Vexorian]

tagged: chromethischromethat

Re:Unique process model, come on!

[bhtooefr]

You realize that the windows don't have to be maximized all the time, right?

Bad habbits formed from Firefox useage

[file_reaper]

I for one am constantly launching links in new windows from Firefox's retarded right click menu, it's actually really noticeable when I use Google Chrome...I have to force myself to choose the first menu option when I right click a link.

Hey Mozilla, forget Javascript performance, how about more simple things like making a decent right click menu?

Re:Bad habbits formed from Firefox useage

[Bota]

middle click? thatisall

Re:Bad habbits formed from Firefox useage

[Bota]

Yes I am so stupid that I didn't notice you wanted new window. my apologies. I'll blame late night and no caffeine yet this morn.

Re:Bad habbits formed from Firefox useage

[ya really]

Maybe it's just me, but I thought new windows went out with the invention of tabs.

Re:Bad habbits formed from Firefox useage

[shvytejimas]

From firefox help:
Open in New Window : Shift+Left-click

Re:Bad habbits formed from Firefox useage

[jisatsusha]

shift + click works for opening a link in a new window.

Re:Bad habbits formed from Firefox useage

[Raenex]

The way I read it is that he uses right-click to get a new tab, but accidentally hits New Window because it's the first option. So yes, he should learn to middle-click.

I met a developer once who would use the menus to copy and paste instead of the usual shortcut keys. Painful.

Re:Bad habbits formed from Firefox useage

[whyloginwhysubscribe]

In Chrome you can just drag a tab into it's own new window, or drag a window back into a new tab.

It works with Wine... here's the recipe

[dkegel]

http://wiki.winehq.org/Chrome https is not yet supported, but page loading speed isn't bad.

Re:Open Source?

[swimin]

It is:

http://code.google.com/chromium/

Re:WTF?

[whatUrunning.com]

I totally agree that there is nothing wrong with Gecko, but when it comes down to it, the fewer rendering engines there are the fewer quirks there are to deal with. Chrome is going to eat into the IE market share more than the FF market share, all those people who have never even heard of FF now have this sitting under their noses: "New! Download Chrome (BETA) - the new browser from Google". The mobile browser market share of WebKit based browsers is also on the rise so if FF and Chrome were both using WebKit it would make life easier for developers and also help to reduce the IE market share.

Re:WTF?

[Your.Master]

You know the whole problem with IE started when it became the only rendering engine in town?

We all benefit if Webkit, KHTML, Gecko, Presto, and yes, even Trident are upgraded.

Re:WTF?

[David Gerard]

The key point you're missing is that interoperability is everything to those who aren't IE. And that HTML5 is being driven by vendors sorting out what's actually implementable in reasonable time to a reasonable degree - compare the car crash that is the CSS spec, where someone wrote a wishlist that was largely ambiguous and/or unimplementable. Multiple good implementations of a good spec are to our advantage.

Beta nomenclature

[this great guy]

Why do so many people seem to hate theses beta tags ? You are in effect complaining about their products being too stable and polished to be called beta ! Vendors already have different views on what "beta" means, eg. a Vista RC1 might be less stable than a Firefox "beta" version even though conceptually the beta stage preceeds the RC stage.

Re:Beta nomenclature

[DancesWithBlowTorch]

You are in effect complaining about their products being too stable and polished to be called beta !

No, I'm complaining about them being called beta forever. For what it's worth, Chrome might well be a true beta. But gmail certainly is not a beta product in the "old" sense of the concept.

"Beta" is supposed to convey the idea that the product has reached a late stage of development, where a larger deployment base is needed to complete bugfixing. The public is invited to test the product for free, but is strongly dissuaded from expecting a complete product and should not use it for any critical applications.

Google, it seems, is instead using the "beta" tag as a perpetual excuse for any bugs that might show up at any point during the lifetime of the product, even long after a full release. Gmail is now used in mission critical settings by many companies (as in, their whole e-mail infrastructure), showing that nobody considers it beta any more, except for Google themselves.

The reason why I posted my little rant up there was the GP's statement implying one cannot critizise Google for any bugs in programs that "are still in beta". Of course Chrome is buggy, it's a true beta release. But Google, in my eyes, have lost the right to use this excuse, since they have cheekily extended it's validity to cover almost their whole product range, with the exception of search. I happily accept Microsoft's IE8b2 as a beta (at this point, it actually seems to have less bugs than Chrome), because I know MS will release a full version within a reasonable time-frame. Google, however, will have to decide whether they want to have their cake or eat it.

Delete RLZ.DLL

[emiraga]

Delete RLZ.DLL from Chrome installation. They advise it in source code http://src.chromium.org/svn/trunk/src/chrome/browser/rlz/rlz.h

Chrome memory eater

[Vedanuzal]

I read the comic book style chrome blurb that google put up and part of it proclaimed that chrome would not crash your system like other browsers cause it opens each tab in a separate process and you can just close the tab to release the memory.
Well being a software engineer i installed chrome, opened a few tabs and task manager and well i watched the memory grow. Instead of one process that leaks memory you now have numerous processes that leak memory.
And they all seemed to get to 10Mb very fast and you could just sit there and watch the Kb tick over, all while your not doing anything. (the first tab was at 25mb)
So if your like me and use a minimum of 5 tabs I bet the amount of memory that you use for chrome will actually be more than firefox as there will be a memory leak in each tab and they will all grow.
But at least it gives the google devs and excuse not to fix the memory leaks.

Chrome

[rosoft2001]

While using Chrome I found that a lot of sites sites don't work, due to missing plugins for the new platform. Sometimes just quitting the site is not an option so I created an easy way to open the page in your "old" browser. Just drag and drop the URL from the Chrome URL bar into the Mirror form and you can continue your Chrome browsing. Download: http://www.zonator.com/mirror.zip