Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Development, Privacy, and Standards for Chrome

Soulskill posted more than 6 years ago | from the chrome-chrome-chrome-chrome-chrome dept.

Google 114

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.

Sorry! There are no comments related to the filter you selected.

Completely good and noble (2, Funny)

David Gerard (12369) | more than 6 years ago | (#24900369)

Webkit is completely safe; Apple is completely good and noble. Google will maintain complete confidentiality within the marketing department [today.com] 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 (1)

ionix5891 (1228718) | more than 6 years ago | (#24900415)

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 (0)

bogaboga (793279) | more than 6 years ago | (#24900419)

Webkit is completely safe...

I think it is better to say Webkit is completely safe for now. This is because in this IT world, we never know of vulnerabilities and exploits till they surface.

Second, Webkit in my opinion, is still "young". 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.

Re:Completely good and noble (4, Interesting)

David Gerard (12369) | more than 6 years ago | (#24900433)

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 (0)

bogaboga (793279) | more than 6 years ago | (#24900523)

If they (KDE folks), finally settle on Webkit, it will be better for them. With Konqueror, I kind-of got tired and sick of having to change my user agent in order to even view contents of a web site's home page. Even in the beginning, it appeared to me that KHTML was a non-starter.

Re:Completely good and noble (2, Informative)

David Gerard (12369) | more than 6 years ago | (#24900533)

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

Re:Completely good and noble (1)

bogaboga (793279) | more than 6 years ago | (#24900601)

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 (1)

David Gerard (12369) | more than 6 years ago | (#24900637)

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 (1)

Firehed (942385) | more than 6 years ago | (#24902943)

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 (2, Interesting)

truthsearch (249536) | more than 6 years ago | (#24903795)

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 (1, Informative)

Anonymous Coward | more than 6 years ago | (#24900771)

You do realize WebKit is a fork a KHTML right?

Re:Completely good and noble (2, Interesting)

EsbenMoseHansen (731150) | more than 6 years ago | (#24900969)

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 (1)

slimjim8094 (941042) | more than 6 years ago | (#24904073)

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 (0)

Anonymous Coward | more than 6 years ago | (#24903129)

Even in the beginning, it appeared to me that KHTML was a non-starter.

You realize that Webkit started out as a fork of KHTML, dont you?

Re:Completely good and noble (2, Insightful)

foniksonik (573572) | more than 6 years ago | (#24900579)

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 (4, Insightful)

kestasjk (933987) | more than 6 years ago | (#24900677)

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 (1)

nog_lorp (896553) | more than 6 years ago | (#24901819)

True. Google "GDI+ vulnerability" for proof.

Re:Completely good and noble (1)

Bobdog (1350481) | more than 6 years ago | (#24900515)

LOL

is the LHC safe running chrome tho [today.com]

nice one

Say "no" to Google spyware (2, Informative)

Anonymous Coward | more than 6 years ago | (#24900379)

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

Re:Say "no" to Google spyware (4, Informative)

David Gerard (12369) | more than 6 years ago | (#24900485)

Direct Google link [google.com] 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 (3, Informative)

pablomme (1270790) | more than 6 years ago | (#24900543)

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

Re:Say "no" to Google spyware (1)

David Gerard (12369) | more than 6 years ago | (#24900587)

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 (0)

Anonymous Coward | more than 6 years ago | (#24902543)

Now all that's missing from wine is stuff that is actually hard, like HTTPS and graphics and performance.

It works with Wine... here's the recipe (2, Insightful)

dkegel (904729) | more than 6 years ago | (#24901397)

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

Re:Say "no" to Google spyware (2, Informative)

ksd1337 (1029386) | more than 6 years ago | (#24901619)

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 (1)

David Gerard (12369) | more than 6 years ago | (#24902553)

Wine but not Win2k? We all LOLed.

Re:Say "no" to Google spyware (1)

phanboy_iv (1006659) | more than 6 years ago | (#24903997)

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

Re:Say "no" to Google spyware (0)

Anonymous Coward | more than 6 years ago | (#24900867)

That one did install for me without problems with the newest wine release. I was having fun today with running the latest windows nightly of firefox against chrome both under wine and making performance tests. Without the just in time compiler activated in firefox it lost in most benchmarks against chrome. With JIT activated Firefox wins probably two thirds of the tests. There is really fascinating progress in the browser market.

Re:Say "no" to Google spyware (1)

Tim C (15259) | more than 6 years ago | (#24908683)

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 (5, Funny)

FloydTheDroid (1296743) | more than 6 years ago | (#24900407)

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 (2)

kasot (1274250) | more than 6 years ago | (#24900423)

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 (3, Funny)

drseuk (824707) | more than 6 years ago | (#24900473)

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

Re:Chrome is a resource hog (3, Interesting)

David Gerard (12369) | more than 6 years ago | (#24900553)

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 (1)

Helios1182 (629010) | more than 6 years ago | (#24900789)

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 (1)

David Gerard (12369) | more than 6 years ago | (#24900859)

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 (1)

tedu_again (980692) | more than 6 years ago | (#24901437)

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 (1)

David Gerard (12369) | more than 6 years ago | (#24902561)

In this case I suspect Flash is the major offender.

Re:Chrome is a resource hog (0)

Anonymous Coward | more than 6 years ago | (#24903753)

I'm on an Athlon XP 1Ghz (single core, 7? years old now?) with 256Mb Ram total.

Chrome runs just fine - faster than firefox, actually. With 5 tabs open (including one at newgrounds - meaning flash is working as well) total memory consumption is just under 80Mb.

Cpu is pretty much idle - taskman reports it as 1%, as high as 32% if I cycle through all the tabs as quickly as possible.

Given the age of the machine, that's pretty impressive.

Re:Chrome is a resource hog (1)

Beryllium Sphere(tm) (193358) | more than 6 years ago | (#24905179)

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 (1)

jonaskoelker (922170) | more than 6 years ago | (#24906709)

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 (1)

nomadic (141991) | more than 6 years ago | (#24900753)

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 (1)

Muffinmasher (1147183) | more than 6 years ago | (#24907785)

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.

In other news: CFCs found all over California (1)

drseuk (824707) | more than 6 years ago | (#24900425)

That's "Chrome Fatigue Clinics"

I would love to see Firefox move to WebKit (2, Interesting)

whatUrunning.com (1358393) | more than 6 years ago | (#24900447)

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 (1)

roman_mir (125474) | more than 6 years ago | (#24900487)

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

Re:I would love to see Firefox move to WebKit (1)

David Gerard (12369) | more than 6 years ago | (#24900525)

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.

WTF? (0)

Anonymous Coward | more than 6 years ago | (#24900855)

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

Yeah, because when scripts that always worked fine in KHTML break in WebKit based browsers - that makes my life "easier". Drosera is undocumented and the new debugger isn't enabled for GTK builds - double the "easyness".

Application developers looking to embed a layout engine prefer webkit, from a web developers perspective there's absolutely nothing wrong with Gecko. You made the suggestion, why don't you tell us what the specific problems are?

Re:WTF? (1)

whatUrunning.com (1358393) | more than 6 years ago | (#24901443)

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? (2, Insightful)

Your.Master (1088569) | more than 6 years ago | (#24902369)

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? (1)

David Gerard (12369) | more than 6 years ago | (#24902639)

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.

Re:WTF? (0)

Anonymous Coward | more than 6 years ago | (#24902967)

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.

If everyone was running the same version of the same browser, you'd have a point. Which revision of WebKit are you running in which vendors browser, with which scripting host (KJS, Googles V8 or Apples SquirrelFish) and with which network backend?

if FF and Chrome were both using WebKit it would make life easier for developers and also help to reduce the IE market share.

Competing implementations drive the standards and I honestly find Firefox and Opera easiest to develop for. Then I fix for IE and finally WebKit (which I've frequently had to bundle with IE and has freqently taken more work to support than IE).

As for IE's entrenched market share, that has plenty to do with organizational IT policies and isn't going to be impacted without a compelling reason to change and not at all by Mozilla swapping out their layout engine. Afterall, I stuck with Netscape back in the day simply because it was installed both at school and at work.

'Do no harm' is still in effect... (1)

davidsyes (765062) | more than 6 years ago | (#24900511)

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 (5, Insightful)

Simon (S2) (600188) | more than 6 years ago | (#24900593)

So google stripped [ejohn.org] 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 (3, Informative)

David Gerard (12369) | more than 6 years ago | (#24900611)

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 (1)

Simon (S2) (600188) | more than 6 years ago | (#24900697)

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 (2, Insightful)

David Gerard (12369) | more than 6 years ago | (#24900729)

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 (2, Interesting)

Simon (S2) (600188) | more than 6 years ago | (#24900749)

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

I do actually. The HTML 5 compatible client side storage API [webkit.org] 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 (1)

David Gerard (12369) | more than 6 years ago | (#24900765)

Dunno. Have you asked them?

Re:Gears and the storage API (1)

Simon (S2) (600188) | more than 6 years ago | (#24900803)

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 (4, Interesting)

Awptimus Prime (695459) | more than 6 years ago | (#24900955)

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 (0)

Anonymous Coward | more than 6 years ago | (#24901281)

hey twitter long time no see

lawl g@@gle gear$$$$

Re:Gears and the storage API (1)

Awptimus Prime (695459) | more than 6 years ago | (#24903797)

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

Re:Gears and the storage API (1)

David Gerard (12369) | more than 6 years ago | (#24901325)

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 (1)

Awptimus Prime (695459) | more than 6 years ago | (#24903829)

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 (0)

Anonymous Coward | more than 6 years ago | (#24900857)

You don't ask google. You post the question and wait for the page to get indexed. Unless you have chrome: in that case just save the question in confidential.txt :D

I agree with this person (0)

Anonymous Coward | more than 6 years ago | (#24904309)

See here [encycloped...matica.com] for more information.

Re:Gears and the storage API (1)

centuren (106470) | more than 6 years ago | (#24902847)

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 (2)

Anpheus (908711) | more than 6 years ago | (#24901295)

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 (0, Flamebait)

Simon (S2) (600188) | more than 6 years ago | (#24901337)

The webkit implementation in Chrome right now is over a year out of date...

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

Wabkit has the local storage api in place [webkit.org] since Friday, October 19th, that's a pretty long time for a HTML rendering engine, and without backporting stuff to their local implementation.
No conspiracy theory here: companies pushing their own stuff over standard implementations is pretty normal stuff.

Re:Gears and the storage API (1)

gsnedders (928327) | more than 6 years ago | (#24902225)

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 (1)

Simon (S2) (600188) | more than 6 years ago | (#24902405)

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 [webkit.org] 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 (1)

gsnedders (928327) | more than 6 years ago | (#24908215)

http://html5.org/tools/web-apps-tracker?from=1200&to=1201&context=10 [html5.org] -- 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.

Bug (3, Insightful)

The MAZZTer (911996) | more than 6 years ago | (#24900671)

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 (0)

Anonymous Coward | more than 6 years ago | (#24901127)

Yes! It's open source, so that means if the product is broken it's not Google's fault for a crappy pre-alpha product. It's YOUR fault for not reporting it.

Re:Bug (4, Insightful)

DancesWithBlowTorch (809750) | more than 6 years ago | (#24901339)

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 (1)

jack2000 (1178961) | more than 6 years ago | (#24901731)

Google should switch their moto to: Google: In beta until we acquire 100% of the market share..

Re:Bug (3, Interesting)

Koiu Lpoi (632570) | more than 6 years ago | (#24901739)

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 [google.com] (real)? We feel for you man, but it's a beta, nothing we are required to, er, can do.

Re:Bug (2, Insightful)

Tim C (15259) | more than 6 years ago | (#24908603)

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 (1)

blahplusplus (757119) | more than 6 years ago | (#24902035)

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 (1)

magus_melchior (262681) | more than 6 years ago | (#24902969)

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...

Beta nomenclature (1)

this great guy (922511) | more than 6 years ago | (#24906741)

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:Bug (2)

ya really (1257084) | more than 6 years ago | (#24901609)

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.

Unique process model, come on! (0)

Anonymous Coward | more than 6 years ago | (#24900843)

Let's see. Separate windows are controlled by
separate processes. And you can pick which window
you are looking at. And if a process dies, only
that window goes away. Sounds like a window manager
on a multi-tasking OS to me, not some unique new
invention! And with pretty limited choice of layouts. What if you want to look at two pages
at once?

Re:Unique process model, come on! (3, Interesting)

bhtooefr (649901) | more than 6 years ago | (#24900961)

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

Multithreaded tabs (1, Interesting)

AmiMoJo (196126) | more than 6 years ago | (#24900851)

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 (1)

abigor (540274) | more than 6 years ago | (#24901541)

You mean processes rather than threads. Big difference.

Re:Multithreaded tabs (0)

Anonymous Coward | more than 6 years ago | (#24901795)

Each process would contain at least one thread.

Assuming the GP doesn't care about protection from one tab crashing all others, the GP is quite correct - the symptoms described can be fixed by having multiple threads (that aren't blocking each other all the time).

Re:Multithreaded tabs (1)

David Gerard (12369) | more than 6 years ago | (#24902779)

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! (1, Redundant)

Vexorian (959249) | more than 6 years ago | (#24900881)

tagged: chromethischromethat

Open Source? (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#24900907)

Why isn't chrome open source? Are there plans to make it open source?

Bad habbits formed from Firefox useage (1)

file_reaper (1290016) | more than 6 years ago | (#24901163)

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 (1)

Bota (968795) | more than 6 years ago | (#24901207)

middle click? thatisall

Re:Bad habbits formed from Firefox useage (1)

Bota (968795) | more than 6 years ago | (#24901227)

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 (1)

ya really (1257084) | more than 6 years ago | (#24901655)

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

Re:Bad habbits formed from Firefox useage (0)

Anonymous Coward | more than 6 years ago | (#24901807)

until you want to look at two pages side by side :)

Re:Bad habbits formed from Firefox useage (0)

Anonymous Coward | more than 6 years ago | (#24902741)

It's just you. As long as there isn't a better way to group tabs, windows will have to do.

Re:Bad habbits formed from Firefox useage (2, Informative)

shvytejimas (1083291) | more than 6 years ago | (#24902507)

From firefox help [mozilla.com] :
Open in New Window : Shift+Left-click

Re:Bad habbits formed from Firefox useage (1)

jisatsusha (755173) | more than 6 years ago | (#24905153)

shift + click works for opening a link in a new window.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?