Google Chrome & IE Beta2

tliebeck's picture

I tested both Google Chrome and IE8 Beta2 today.

Google Chrome might as well be Safari. It works perfectly, albeit the Safari escaping bugs are present (completely wild guess: the problem is in the WebKit layout engine used by both). Chrome is pretty darn fast. It beats Safari 3.0.4 on the same Windows box with the Echo3 client-side demo's performance test (9 vs 8.3 frames per second). Need to install Safari 3.1 on that one though. I've added detection of this browser to Echo3/CoreJS and it's currently running the same single bug flag as Safari.

IE8 is another story. So far it's nothing short of horrible. Beta1 was bad, and this appears to be as bad if not worse. New bugs this time around.... opening/closing windowpanes results in a blank white screen in Echo3. Scrollbars constantly snap back in Echo2 and Echo3. And of course there are some general rendering errors. Have not specifically ruled out that each beta2 problem is in IE and not in Echo (this is a huge pain to do, but with all the major beta1 bugs IE was at fault.) They do seem to have fixed a couple of the more egregious bugs I reported in IE8 beta 1. That said, I really just wish they would simply stop trying to write new browsers.

If anyone wants to play around with IE8 + Echo3, I'd really appreciate any patches / suggestions / workarounds / etc.

a.schild's picture

I also did some small tests

I also did some small tests with chrome, and yes, it realy works fine for a initial beta release (Google software is always beta, just like.... ).
As for IE8, I did not even bother to install it, the final version will have enough bugs to fight with, no need for the beta bugs for me. (But I'm glad for everyone who does help debug it.)

But the one thing I realy don't like is are the terms and conditions, especially this one:

Quote:
11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services.By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This license is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.

I just don't like google to have the right to publish the content of EVERY webpage I will display in the chrome browser. For example when doing onlinebanking.....

tliebeck's picture

Just like WHAT? I hate

Just like WHAT? I hate companies that do that. :D

I'm sure that EULA was by accident, but that is fairly hilarious!

a.schild's picture

Quote:I'm sure that EULA was

Quote:
I'm sure that EULA was by accident, but that is fairly hilarious!

Of course it was by accident, that company is so small, has no money and no advocats to make a good eula...

It has almost the same terms as for the online word/calc apps they provide. There also all work and content made with these apps can be freely used by google.

The same applies for the online photoshop.

The EULA has already been

The EULA has already been changed, it was a simple copy/paste error *cough*. See http://arstechnica.com/news.ars/post/20080903-google-on-chrome-eula-controversy-our-bad-well-change-it.html for some more details.

tliebeck's picture

Well posted this to the MS

Well posted this to the MS bug reporting newsgroup...

Quote:
Hello,

I'm the lead developer of the Echo web application framework. I'm seeing major issues with IE8's rendering of Echo-based applications when "compatibility mode" is not enabled. These applications work in literally every other browser market, e.g.:

- Opera
- Mozilla/Firefox 1.0-current
- Safari 1.3-current
- IE6, IE7
- Konqueror
- Google Chrome

Great care has been taken in developing the Echo platform such that it respects all W3C specifications for HTML, CSS, and DOM manipulation, in addition to following the ECMA-262 v3 scripting spec. It supports all of the above browsers quite well (running in the most standards compliance mode each has to offer) using a single codebase with only minimal browser specific workarounds (most of which target IE6).

I'm seeing major issues with IE8. Significant manipulations of the DOM result in the entire screen turning white, with elements that moments before had "clientWidth" values of say 1000 suddenly having values of 0 even though they have not been modified. Scrollbars jump to the top within DIVs after trivial CSS manipulations (e.g. rollovers). CSS attributes are sometimes simply not rendered, or only show up in wierd circumstances, such as when a user is highlighting text.

An example of the issues can be seen here: http://demo.nextapp.com/echo3csjs

Click the pull down menus or press any button within it for an example of the disappearing content. You can see for example the clientWidth changing by visiting the following URL...

javascript:alert(document.getElementById("rootArea").firstChild.clientWidth);

....when the echo3csjs demo URL above is being displayed, before/after the disappearance occurs.

This application is written entirely in JavaScript, HTML and CSS, the source can be viewed or downloaded with a Subversion client from https://svn.nextapp.com/svn/echo3demo/trunk/

I'd be happy to help in any way I can, short of spending days trying to reproduce these bugs in standalone test cases. :D

Please feel free to email me if you want to discuss this further, tliebeck (at) nextapp (dot) com.

Best
--Tod Liebeck / NextApp, Inc.

No idea if that will be well received or not, but I just can't stand the idea of taking a few days to tear into that thing unless I absolutely have to.

tliebeck's picture

From their site: This post

From their site:

This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

So please vote for this:
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.beta&tid=86badd72-ca62-4f2b-850d-a7ec56ae6810&cat=en_us_2BAF8EC5-645C-4477-A380-0F1CF6C102F9&lang=en&cr=us&sloc=&p=1

tpoindex's picture

Not quite perfect, one small problem found

I installed Chrome (sorry not IE8), and tested my Echo2 framework (Æjaks), and found one problem - a custom table cell SelectField component cannot be changed. When clicking on the table cell, the row becomes highlighted, but I am unable to change the contents of the SelectField.

This problem also effects Safari 3 and Konqueror, and of course it works perfectly in
FF 2/3, IE 6/7.

Another custom table field with a RadioButton component works fine.

No Scrollbars in certain areas

I downloaded Chrome today and tried to load our Echo2 application. For the most part, it appeared to work quite well. However, there seems to be a problem with scrollbars in certain components.

We have an accordion pane as provided in Echo2 Extras, and populate each pane with a column, and add a tree (EchoPointNG) to each column. When the tree is expanded, it can often exceed the dimensions of the accordion pane both horizontally and vertically. However, no scrollbars appear. Scrollbars do appear in IE 6 and 7 and FF 2 and 3.

We have another window pane that may have rows of text fields added by a user. When the number of rows exceeds the vertical size of the window pane, the scrollbars don't appear. Again, it does work properly with the other "big" browsers.

On a hunch, I downloaded Safari for Windows, and it exhibits the same problem that Chrome does.

<edit>
I resolved the second problem that I mentioned -- it was something silly on my part. The lack of scrollbars inside an accordion pane is still a problem, however.
</edit>