WebDialogs using Chrome : any interest ?

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

JD Hill

I'm very sure of that, and it was not my intention to imply otherwise. It just sounded like you were keeping that possibility open, so I felt the need to speak up. If it's your intention that it be strictly opt-in though, the idea sounds nothing but good to me.