WebDialogs using Chrome : any interest ?

tbd

anyone tried Google Chrome Frame ? there is a non-admin install released lately - http://blog.chromium.org/2011/06/introducing-non-admin-chrome-frame.html

tomot

This is probably more meaningful to developers:
http://developer.android.com/guide/basics/what-is-android.html
I envision a screen sized dialog in Android format (same size as the typical smartphone), being used instead of the current Web dialog.

Dan Rathbun

@tomot said:

I envision a screen sized dialog in Android format (same size as the typical smartphone), being used instead of the current Web dialog.

Why don't you start another topic to discuss Android.. I'd like to keep THIS topic on Chrome / ChromeFrame WebDialog's, if you please.

Dan Rathbun

@unknownuser said:

anyone tried Google Chrome Frame ?

YES. And it works.. so far in my testing.

This is actually Option 1 (taking the least amount of time, on my part.)

@unknownuser said:

... there is a non-admin install released lately -

Yes... but it's an additional thing for the user to install, in order to "enable" plugins to be "pure Webkit."

I can make the process as painless as possible (Google shows how.. it's a matter of Cut & Paste code, from their website.)

Dan Rathbun

@thomthom said:

To keep it simple I just require my users to have an up to date Internet Explorer, as IE has shaped up very well in the recent releases. ..., because IE isn't the old dog it used to be any more.

Personally from a user standpoint, I've quit using IE altogether. Chrome is so much faster !!
I got so sick of waiting for IE to initialize.. and render websites, on a 64bit machine with a fresh Win7 install (my Dad's office machine,) that we installed Chrome on it last week. My Dad has not used used IE since.

From a developer perspective.. I'm just done with dealing with the MS quirks.. standards mode, emulated mode, and "there is no public standard that applies to this [HTML/CSS property or method.]" crap.

@thomthom said:

Nor do I see IE as a problem where I'd pay to eliminate it.

OK that's a fair opinion.. and valuable info.

I'm not about to waste time developing something no one wants.

I was under the impression awhile back (before SU8 came out,) that cross-platform WebKit / Chrome WebDialogs were high on the developer community's "wish list."

thomthom

@dan rathbun said:

I was under the impression awhile back (before SU8 came out,) that cross-platform WebKit / Chrome WebDialogs were high on the developer community's "wish list."

This is true, but IE9 is doing very well standard wise. And with the jQuery framework, or similar, scripting JS becomes easy. The main issue is that the WebDialog class itself behaves differently across platforms.

What I'd really find useful is a complete framework similar to what I have a feeble beginning of; a wrapper that lets you manipulate WebDialog content with Ruby classes.

fredo6

Personally I tend to agree with Thomthom:

It is preferable to have only one browser per platform to interact with Ruby. Coping with the different versions of IE (and Safari on Mac) is already a challenge.
IE is much more flexible for HTML and Javascript programming than WebToolkit. Most problems I encountered with Web dialog boxes are precisely on Mac / Safari, not on Windows/IE
It is true that IE might be slower than Firefox or Chrome in many instances, but for the type of web dialogs we need for Ruby scripts, I don't think it does matter too much.
All Windows users have an IE version installed on their PC (and Safari on Mac), so there is no dependency on alternate config.

It is sure that the SU team should spend time to improve the WebDialog class, in particular

for the odd asynchronous behavior on Safari and better exchange of data back and forth with Ruby
for changing the programming framework on Mac (Cocoa or Carbon) to have the click-though behavior like on Windows
for giving static info on the browser control characteristics (which version, size of screen, etc....)
for giving more flexibility in the appearance (web dialog without toolbars, hide which is not a close, etc...)

I hope they work on it in SU9,. After some hesitation, I must say that it was really a damned good choice to interface Sketchup Ruby to HTML controls, because it gives an unlimited power to the GUI.

Fredo

chrisglasier

I am very interested in this and in fact made some effort in a similar direction in this topic ...

@chrisglasier said:

...

Just today I wondered what would happen if I opened the localhost in a webdialog. Surprisingly (to me) the localhost worked just as before. I closed Sketchup and added a link in the localhost to a .skp file in the same directory. Clicking on the link launched Sketchup and opened the file. I also added a simple skp:callback which worked OK once I had opened the webdialog from the plugins menus.

...

I guess there are many if and buts but I very much like the idea of having a universal interface that can call up Sketchup as a kind of plugin and then transform itself into a plug in to Sketchup. So I think it is worth pursuing.

I may have got the wrong end of the stick but would be interested in whether any of this type of approach fits with yours.

iaselle

Hello Dan,

I'm very interested in your topic.

Sketchup uses IE7 as a renderer even on machines with a native IE9. And it seems to uses the quirks mode even with XHTML strict.

I'm developping a commercial plugin and this is an issue. Therefore, I'm interested in your development.

What would be the installation process of your plugin (any executable to run first) ?
Would it impact the usage of the native IE on the computer ?
What are your financial requirements (you can reply through private message if you wish) ?

By the way, "Google Frame" works on native IE but not in the frame of Sketchup IE !!

Dan Rathbun

@iaselle said:

Sketchup uses IE7 as a renderer even on machines with a native IE9. And it seems to uses the quirks mode even with XHTML strict.

It's NOT Sketchup that "does" this. It's the Microsoft WebBrowser control. (ie The native Win32 API HTMLDialog.)

The "IE7" mode is ONLY a default.

@unknownuser said:

(http://forums.sketchucation.com/viewtopic.php?f)":23z4tpg8]And then you can also force the browser mode via a META tag:
%(#8000BF)[<META http-equiv="X-UA-Compatible" content="IE=7" > ]
.. just in case they change the default mode, in the future.

Refering to: META Tags and Locking in Future Compatibility

@unknownuser said:

By default, Internet Explorer 8 uses EmulateIE8 mode to display pages loaded from the Internet Zone. Web pages loaded from the Intranet Zone or with the Web Browser control are displayed in EmulateIE7 mode. These defaults can be changed.

and ...

@unknownuser said:

EmulateIE7 mode tells Windows Internet Explorer to use the <!DOCTYPE> directive to determine how to render content. Standards mode directives are displayed in Internet Explorer 7 Standards mode, and Quirks mode directives are displayed in IE5 mode. Unlike IE7 mode, EmulateIE7 mode respects the <!DOCTYPE> directive.

iaselle

Ok Dan,

But back to your first post in this topic, are you about to succeed I implementing WebDialogs using Chrome on the PC ?

Because, there are still companies that have pools of computers with legacy XP+IE6 ... and javascript execution on IE6 (and even IE7) is very very slow (assuming you're using fancy webdialogs with jQuery etc).

So, I'm still interested and I'm staying tuned

Dan Rathbun

@iaselle said:

But back to your first post in this topic, are you about to succeed I implementing WebDialogs using Chrome on the PC ?

I CAN have (Option 1) working very soon, which is ChromeFrame inside an IE browser window.
(I DO have it working inside Sketchup WebDialogs.) But there are issues, concerning the settings. The settings are meant to control it's behavour for the normal IE browser. If the user or an IT admin make changes to the settngs, it could affect how GCF works with WebDialogs.
More testing is required.

Option 2 : Will take much more time. It will be writing a dedicated DLL, to implement a true ChromeDialog, that does not use IE or Safari, at all.

iaselle

Hello Dan,

I think that the option 1 is worth to be tested.
According to a Computerworld benchmark, IE8 + Google Chrome Fame is 10 times faster that IE8 on its own ... and IE7 and IE6 are 2x slower than IE8 !!

Option 2 seems to be kind of a burden, with a lot of developing, testing and maintenance concerns.

In my context, I will have to install an executable that will be shipped with my SU plugin (with imposed set of dlls I'll be obliged to cope with).

Therefore, a Windows setup will be required (Inno Setup for instance).
If your option 1 need registry keys to force Chrome Fame Usage, this setup could be used for it.

Dan Rathbun

@iaselle said:

If your option 1 need registry keys to force Chrome Frame Usage, this setup could be used for it.

Yes well I have several setup packages that can be used, or I could just use a reg file, or use my private Win32 registry library. Setting registry keys/values is not a problem.

The main issue is to allow use of GCF for local webdialog use without compromising the security of the normal IE browser.

The security policy is reversed for the two cases. In normal browser use, you want to keep the Internet Zone sandboxed within the "Temporary Internet Files" directory, and restrict access to local files, but with local HTMLdialogs, the opposite is usually true. (And if the user navigates in a local HTMLdialog, from the local zone into the Internet Zone, then normal security policies, are supposed to come into play.)

I do not wish to open up a big hole in security. But then perhaps I'm being overly cautious?

iaselle

Let me make sure I understand well the issue with your setup :

If the normal IE browser is not sandboxed anymore, this is an unacceptable security issue
If only webdialogs are not sandboxed anymore, the issue would be coming from other applications installed on the computer, that make use of webdialogs and that allow the user to surf on the web with it. I do not know if there are many of them

First, this problem is only for windows XP users (and the number of XP users is decreasing).
Users with Vista/seven would be adviced to upgrade to IE9 if necessary.

I can accept that for those remaining XP users, my plugin could be used only by administrators.
In that way, could the registry be changed trough the plugin at each startup (before starting the webdialog) and changed back when the users quit the webdialogs ?

Then the issue could happen only if the user would start another application with webdialog while SU is running.

Dan Rathbun

@iaselle said:

Let me make sure I understand well the issue with your setup :

If the normal IE browser is not sandboxed anymore, this is an unacceptable security issue

This is true.

@iaselle said:

If only webdialogs are not sandboxed anymore, the issue would be coming from other applications installed on the computer, that make use of webdialogs and that allow the user to surf on the web with it. I do not know if there are many of them.

Actually WebDialogs (and HTAs,) are not sandboxed by default. But.. (if memory serves,) if you were to have an FRAME or an IFRAME within a HTA that navigated into another domain (especially the Internet Zone,) then the Security Policies for the Internet Zone are supposed to "kick in" automatically.
I am not sure that this works as it should, even now, with the standard API UI::WebDialog class, as we have to explicitly call the set_full_security() method, if we want 'sandboxing.'

@iaselle said:

First, this problem is only for windows XP users (and the number of XP users is decreasing).
Users with Vista/seven would be adviced to upgrade to IE9 if necessary.

Perhaps.. from the point of view, of some here (and I respect that,) but me personally,... I am weary of having to deal with IE and all it's quirks, and all the MSIE only features.

So my point of view is wanting one cross-platform HTMLdialog where I don't need to have platform conditional code on the Ruby-side, and browser conditional code on the HTML/Js side of things.

Also, NaCl (NativeClient,) is looking good for the future, and it's likely to be implemented in Chrome (and Safari,) before it is in MSIE. .. unless I'm wrong and Microsoft has also taken an interest?

@iaselle said:

I can accept that for those remaining XP users, my plugin could be used only by administrators.
In that way, could the registry be changed trough the plugin at each startup (before starting the webdialog) and changed back when the users quit the webdialogs ?

Well.. that is the plan.. but I think that I'd need to "allow" it only for the show() methods, then switch it off again immediately, because the user may have the normal browser open. (I do, actually did have IE open all the time with many tabs open to reference websites like the Sketchup API, and MSDN, etc. But I have switched to Chrome. It just starts and runs, so much faster than IE8. Shuts down faster as well. I also find the options much easier to use than all those postage stamp sized nested dialogs that Microsoft is so fond of.)

@iaselle said:

Then the issue could happen only if the user would start another application with webdialog while SU is running.

No.. really it has to do with whether the user is using MSIE with GCF enabled, at the same time that they are using Sketchup webdialogs.

The main problem I have is, there seems to be a GCF bug... which I formally logged... where I CAN tell if CGF is installed.. but NOT whether it is enabled or disabled as an MSIE extension. (I need to do more testing.. but the ideal situation, would be to use GCF for Sketchup IE WebDialogs in both cases.)

Another "top" issue, is to be sure there is a way, for guys like Fredo and Thom, who have spent a lot of time, tweaking their PC editions of plugin webdialogs to render correctly in IE. Forcing those dialogs to render in GCF, may "break" their functionality at worst, make them look bad at best. I'm sure that they do not want to be inundated with complaints from customers, if things start acting "funny."

Dan Rathbun

@iaselle said:

I can accept that for those remaining XP users, my plugin could be used only by administrators.

Just a note on "usability" ...

We want everyone (and I'm sure Google does also,) to be able to use GCF easily (meaning transparently to the non-geek average user,) and safely.

It would be a 2 step process:

1) The end user, will need to install GCF (if they don't already have a full Chrome install,) by painlessly using the webinstall. (For companies, municiplaities or other organizations behind firewalls, their IT Admins can use the MSI installer if they wish. Set up an intranet install, etc.)

2) Install a little plugin that I'll write that will likely create a subclass of UI::WebDialog, so as not to interfer with plugins that rely on their webdialogs rendering in a pure IE dialog frame. (I think allowing users to force all webdialogs into GCF, may open up Pandora's Box, and cause problems. Testing will tell.)

iaselle

OK, so I'm staying tuned of your development and will in the meantime make sure that my plugin is compatible with the different flavors of IE.

Thanks to Virtualbox, it is now easier to do this ...

JD Hill

@dan rathbun said:

I think allowing users to force all webdialogs into GCF, may open up Pandora's Box, and cause problems. Testing will tell.

I hope you don't even consider doing that. It is not simply a matter of possibly breaking some plugins in relatively minor ways: there exist plugins which could potentially cease to function entirely. My plugin, for example, uses Silverlight, and I neither know, nor plan on finding out, how well it is supported in GCF -- if it is even supported at all.

Dan Rathbun

@jd hill said:

@dan rathbun said:

I think allowing users to force all webdialogs into GCF, may open up Pandora's Box, and cause problems. Testing will tell.

I hope you don't even consider doing that. ...

No JD, my previous language is just politically correct.

I DO NOT WISH TO SCREW UP ANYONE"S PLUGINS !!!!!