OOPHM Update & Next Steps

[Kelly Norton]

[+ gwt-contrib]

Just an update on the status of Out-of-Process Hosted Mode since most of the work is happening off in the nether regions of a change branch. Feel free to follow up with any questions. But to address the most common question now:

No, it's not really usable yet ... unless you're extremely adventurous.

@John & @Bob - Feel free to follow up if I failed to mention something important or if I totally lied.

What we have working:

1 - NPAPI plugin is functional on FF-Linux and FF-Mac and jat has it compiling properly for Windows, so that's not far off either.

2 - WebKit plugin is functional on OSX/WebKit browsers.

3 - Common/cross-platform library is functional for Linux, Mac and Windows. The library includes debugging utilities, the all important HostChannel, classes representing the various messaging payloads, marshaled value types, utility methods for interacting with Java classes over the channel, and pure virtual classes for common interfaces.

4 - On the server side (aka the GWTShell), the BrowserChannel and all the associated complements to the native HostChannel are complete at this point. The UI has remained virtually untouched for now, as planned.

5 - We have minimal installers for both plugins. XPI to install the NPAPI plugin on Firefox and a mpkg in a dmg for installing the WebKit plugin.

Current issues:

1 -  Remote objects are given logical id's in OOPHM. jat has a scheme that recycles id's and uses std::vector for storage. bobv has instead used std:map with sparsity and no recycling of id's. Both implementations remain for now, but we'd like to line up the trade-offs and pick a scheme we're happy with.

2 - Firefox presented us with a weird issue in NPAPI where calling document.body.overflow = 'hidden' results in a DOM reconstruction and causes our plugin to get shutdown and reinitialized. jat has a bandaid in place for now and we're in the process of trying to create a reduction for investigation. Sadly, the bandaid is to remove calls to Window.enableScrolling() in the sample apps. jat had originally tried to hack around it by making use of NPSavedData, but that didn't pan out. We currently don't have a good solution besides creating an XPCOM layer and converting the NPAPI to more of a flyweight pattern, but we're going to get a handle on the core problem before we go that route. This one is pretty urgent.

3 - Refactoring more into common code. We see a few small opportunities to refactor pieces of the NPAPI and WBPL into common code. For now, though, we've decided it would be a pointless exercise until we have a working implementation of the IE plugin.

4 - The issue of loading multiple instances of a single module has come back up. For us, this means using something other than module name for the id when we put our plugin into the DOM. While the use case has never been particularly important, we all feel it's worth exploring the idea of not depending on module names for the id's since it actually is the right architecture. Currently, the hosted.html includes a static embed with the id __gwt_Plugin so this would require a more dynamic solution (Finding the plugin adjacent to our script block, or creating the DOM structure on the fly).

5 - UI for remembered settings. We're realizing that we now have some remembered settings for the plugins (Always trust this host, for instance), so we'll need UI components to un-remember these. We're currently discussing where these should be located and whether to favor the native way (configure UI in XUL for Firefox plugin or System Preference plugin for OSX, for example) or to create a consistent way (create a web UI that calls into the plugin to persist the changes). There are also some complicating factors here, like the fact that NPAPI doesn't have a standard method of talking to the chrome whereas the WebKit plugin does, so going that route will likely result in the need for an XPCOM layer on Firefox.

Next steps:

1 - Port the current branch to an updated near-trunk branch. (jat)

2 - Begin the IE plugin. (bobv)

3 - Implement the new swing UI and begin refactoring more of GWTShell internals (jaimeyap? + jat).

4 - Front-end security process. Flush out the remaining design and begin working on implementation for the confirmation UI. (jat + bobv)

5 - Find good ways to test the plugins and the GWTShell server. (???)

6 - Code reviews (all)

/kel

--
If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States).

[Scott Blum]

It's great to see how quickly this is all coming together.  A couple of thoughts below on some of the issues you bring up.

On Wed, May 14, 2008 at 4:03 PM, Kelly Norton <kno...@google.com> wrote:

4 - The issue of loading multiple instances of a single module has come back up. For us, this means using something other than module name for the id when we put our plugin into the DOM. While the use case has never been particularly important, we all feel it's worth exploring the idea of not depending on module names for the id's since it actually is the right architecture. Currently, the hosted.html includes a static embed with the id __gwt_Plugin so this would require a more dynamic solution (Finding the plugin adjacent to our script block, or creating the DOM structure on the fly).

Just FYI, it's very likely this doesn't even work correctly in web mode.  I'm all for doing the right thing, but I wouldn't get involved in a rabbit hunt just to solve same-module-twice.

 

5 - UI for remembered settings. We're realizing that we now have some remembered settings for the plugins (Always trust this host, for instance), so we'll need UI components to un-remember these. We're currently discussing where these should be located and whether to favor the native way (configure UI in XUL for Firefox plugin or System Preference plugin for OSX, for example) or to create a consistent way (create a web UI that calls into the plugin to persist the changes). There are also some complicating factors here, like the fact that NPAPI doesn't have a standard method of talking to the chrome whereas the WebKit plugin does, so going that route will likely result in the need for an XPCOM layer on Firefox.

Personally, I've been kind of fond of the way Google Desktop does its settings via web app, so I'd be in favor of that.  It's also bound to be far less work in the long run and most likely yield a better UI.

Scott

[John Tamplin]

On Wed, May 14, 2008 at 11:15 PM, Scott Blum <sco...@google.com> wrote:

On Wed, May 14, 2008 at 4:03 PM, Kelly Norton <kno...@google.com> wrote:

4 - The issue of loading multiple instances of a single module has come back up. For us, this means using something other than module name for the id when we put our plugin into the DOM. While the use case has never been particularly important, we all feel it's worth exploring the idea of not depending on module names for the id's since it actually is the right architecture. Currently, the hosted.html includes a static embed with the id __gwt_Plugin so this would require a more dynamic solution (Finding the plugin adjacent to our script block, or creating the DOM structure on the fly).

Just FYI, it's very likely this doesn't even work correctly in web mode.  I'm all for doing the right thing, but I wouldn't get involved in a rabbit hunt just to solve same-module-twice.

Isn't this something we will want to support for Gadgets, for example?  Anyway, I think doing it in a way that will handle the same module multiple times is no harder to do than supporting multiple modules at all.
 

5 - UI for remembered settings. We're realizing that we now have some remembered settings for the plugins (Always trust this host, for instance), so we'll need UI components to un-remember these. We're currently discussing where these should be located and whether to favor the native way (configure UI in XUL for Firefox plugin or System Preference plugin for OSX, for example) or to create a consistent way (create a web UI that calls into the plugin to persist the changes). There are also some complicating factors here, like the fact that NPAPI doesn't have a standard method of talking to the chrome whereas the WebKit plugin does, so going that route will likely result in the need for an XPCOM layer on Firefox.

Personally, I've been kind of fond of the way Google Desktop does its settings via web app, so I'd be in favor of that.  It's also bound to be far less work in the long run and most likely yield a better UI.

My opinion, but it seems to me the preferences should be presented in the way that was native to the platform.  If I am setting preferences for a Firefox extension, I want to be able to use all the Firefox facilities for them (about:config, Tools->Extensions->*->Preferences, etc) -- I do not want to have to run some other app to alter the preferences.

--
John A. Tamplin
Software Engineer, Google

[Scott Blum]

On Wed, May 14, 2008 at 11:21 PM, John Tamplin <j...@google.com> wrote:

My opinion, but it seems to me the preferences should be presented in the way that was native to the platform.  If I am setting preferences for a Firefox extension, I want to be able to use all the Firefox facilities for them (about:config, Tools->Extensions->*->Preferences, etc) -- I do not want to have to run some other app to alter the preferences.

I do see your point, I really do.  But I could also imagine that as the set of things we'd like to provide options for grows, the net amount of effort we'll save by doing a web UI will increase.

[Panagiotis Astithas]

Ah, the classic trade-off: make users or developers happier?
:-)

[Ray Cromwell]

Don't forget that there should also be a common command line way of manipulating these preferences, so that scripts that run unit tests, especially those that distribute tests across a network of machines, won't require you to go login to each machine, fire up each browser in a UI window, and uncheck a bunch of proxies.  This could get *extremely* irritating if it has to be done every time.

The android SDK for example, provides ample command line parameters that mimic phone emulator settings UIs.

-Ray

[John Tamplin]

On Thu, May 15, 2008 at 4:18 AM, Ray Cromwell <cromw...@gmail.com> wrote:

Don't forget that there should also be a common command line way of manipulating these preferences, so that scripts that run unit tests, especially those that distribute tests across a network of machines, won't require you to go login to each machine, fire up each browser in a UI window, and uncheck a bunch of proxies.  This could get *extremely* irritating if it has to be done every time.

That gets pretty awkward -- for example, if Firefox is running in the profile you want to edit, you simply can't safely update the prefs outside of Firefox (short of killing Firefox).

Regarding proxies, there has been no attempt to make the wire protocol proxiable, and I don't think it would be a good idea since it is latency sensitive and already we have work to do to make it faster -- doubling (or more) the payload per message so it can go through an HTTP proxy doesn't seem useful.  Also, most proxies do not like long-lived connections (either forcibly terminating them or dying as connection tables fill up), so I don't think this is a good fit for them anyway.

So, the preferences I current foresee are the whitelist of hosted mode servers, logging options, and perhaps an option to show some sort of status in the browser chrome.

In general, I think suppressing/dismissing browser-generated dialogs is the job of something like Selenium rather than trying to address it in this plugin.  For example, there are many more dialogs in the browser that don't have anything to do with our plugin which need to be considered in such an environment (such as Firefox asking if you want to restore the previous crashed session, IE warning about security, etc).

[John Tamplin]

On Thu, May 15, 2008 at 4:08 AM, Panagiotis Astithas <pas...@gmail.com> wrote:

Ah, the classic trade-off: make users or developers happier?
:-)

Well, from that point of view it is easy -- we have already decided to favor end users over developers and even more over our effort.

[Ray Cromwell]

s/proxies/preferences/

Anyway, it's something to think about. A dialog box isn't always something selenium can deal with, it can only deal with dialogs generated by JS methods. Can Selenium cancel a "slow script" modal dialog? I guess these dialogs can only be dealt with by timing out the HM in unit test mode.

I don't care if there is no command line way of resetting preferences, as long as the plugin doesn't introduce preferences that may need to be reset on each run. If they only require setup once, that's fine. 

Still, I like the way Android's emulator can be driven.

[Scott Blum]

I'm going to go out on a limb and say that with a web UI, we could really make the users happier as well, because we could do a better UI than we'd be able to do plugging into browser settings.  The other nice thing this would accomplish is that it would ensure all the settings would be tweakable via script.  Obviously, there are some security considerations to that route, but having the ability to tweak the settings through script could be particularly useful for some purposes.

[John Tamplin]

On Thu, May 15, 2008 at 11:44 AM, Scott Blum <sco...@google.com> wrote:

I'm going to go out on a limb and say that with a web UI, we could really make the users happier as well, because we could do a better UI than we'd be able to do plugging into browser settings.  The other nice thing this would accomplish is that it would ensure all the settings would be tweakable via script.  Obviously, there are some security considerations to that route, but having the ability to tweak the settings through script could be particularly useful for some purposes.

So does no one else feel strongly that we should use the native preferences method?  Personally, I would be really annoyed to have to run 100 different tools to manage preferences for 100 different extensions.

[Scott Blum]

Bob actually brought up a really great point with regards to this.  The fact is, many of our users are going to install the OOPHM plugin on several different browsers.  I know you Linux guys suffer from having very few browser options, but on Windows (for example) you might install the plugin on IE, FF, and Safari in order to test out your app on all three major browsers.  So the question quickly changes from the one you posed to a very different one-- "Do I want to have to learn three different ways of configuring the GWT browser plugin?"

What I think would be great would be if you could have, say, a native FF extension preferences page with one button on it, "Configure", that would launch the preferences web app.  I can't imagine what could be any easier for the users.

[John Tamplin]

On Thu, May 15, 2008 at 9:36 PM, Scott Blum <sco...@google.com> wrote:

Bob actually brought up a really great point with regards to this.  The fact is, many of our users are going to install the OOPHM plugin on several different browsers.  I know you Linux guys suffer from having very few browser options, but on Windows (for example) you might install the plugin on IE, FF, and Safari in order to test out your app on all three major browsers.  So the question quickly changes from the one you posed to a very different one-- "Do I want to have to learn three different ways of configuring the GWT browser plugin?"

How many browsers is one going to support vs. how many extensions would you have installed?  If all the extension writers took your point of view, you would be using far more little apps, all different, to configure those plugins.
 

What I think would be great would be if you could have, say, a native FF extension preferences page with one button on it, "Configure", that would launch the preferences web app.  I can't imagine what could be any easier for the users.

The problem is the web app would then not be able to actually change the preferences because those require privileged access.  If your web app is XUL JS code, it could, but that doesn't solve the other browsers and would require some work to make XUL libraries.  Conceivably we could write a different XPCOM object that exposes preference setting abilities from unprivileged web apps, but there are security concerns there, not to mention more a lot more work than a few dozen lines of XUL JS.

You also did not answer any of my points about losing all the platform independence and profile support that using native Mozilla abilities provides.

[Ray Cromwell]

I don't think one can compare the OOPHM extension to other browser extensions. OOPHM is a developer tool. GWT still isn't write once, run everywhere, it's write once, test everywhere. No one who is serious about commercially deploying GWT is going to just install OOPHM on one browser, they're going to test on every platform, and every browser that is supported. 

I personally don't care how the plugin is configured UI wise, my concerns are:

1) how often do I need to configure the plugin

and

2) are there any config variables that might be relevant to toggle on a per-test basis. 

If #1 and #2 are the care, then I think a consistent, remote-controllable mechanism needs to exist so that people running tests or continuous integration don't need to manually intervene.

-Ray

[Scott Blum]

100% agreement, Ray.  Part of my feeling of doing it as a web app (if possible) is that you force the issue of allowing configuration via JavaScript-- this ensures that the kind of automated configuration you describe is possible.

[John Tamplin]

On Thu, May 15, 2008 at 11:53 PM, Scott Blum <sco...@google.com> wrote:

100% agreement, Ray.  Part of my feeling of doing it as a web app (if possible) is that you force the issue of allowing configuration via JavaScript-- this ensures that the kind of automated configuration you describe is possible.

There are a couple of issues with this approach:
 1) security concerns about arbitrary JS being able to modify the preferences.  You can't use the preferences to control access to the preferences, so I am not sure how you fix it without Vista-like annoying dialogs asking the user if it is ok each time.
 2) for Firefox, if you allow the standard preferences to be set (even more security issues to address), these preferences are per profile and you can only have one process running in a given profile.  That negates Ray's desired ability to modify them from a command line, as if that profile is already running you can't start a new browser to change them.  If you don't use native Firefox preferences, then you lose the ability to have different setups in different profiles, you have to figure out where to put them on each platform, and you have to deal with all the concurrent access issues yourself.

[Cameron Braid]

For Ray's item #2, could the server send them to the plugin for each individual run ?

Regards

Cameron

[John Tamplin]

On Fri, May 16, 2008 at 1:30 AM, Cameron Braid <cam...@braid.com.au> wrote:

For Ray's item #2, could the server send them to the plugin for each individual run ?

Since the only preference we currently have a need for (other than perhaps some debug trace options) is the whitelist of which servers the plugin is allowed to connect to, that doesn't help much.

[Scott Blum]

On Fri, May 16, 2008 at 12:37 AM, John Tamplin <j...@google.com> wrote:

There are a couple of issues with this approach:

 1) security concerns about arbitrary JS being able to modify the preferences.  You can't use the preferences to control access to the preferences, so I am not sure how you fix it without Vista-like annoying dialogs asking the user if it is ok each time.

That's simple: running our own web app from a preferences "Configure" page automatically works.  For anyone else to get access to the API, you would have had to configure an JS access password, and the JavaScript would have to know the password in order to configure settings.  You could also lock out any page that used an incorrect password to prevent guessing attacks.

 

 2) for Firefox, if you allow the standard preferences to be set (even more security issues to address), these preferences are per profile and you can only have one process running in a given profile.  That negates Ray's desired ability to modify them from a command line, as if that profile is already running you can't start a new browser to change them.  If you don't use native Firefox preferences, then you lose the ability to have different setups in different profiles, you have to figure out where to put them on each platform, and you have to deal with all the concurrent access issues yourself.

firefox file://path/to/configure-oophm.html?oophm-settings-password=thepasswordiconfigured

Scott

[John Tamplin]

On Fri, May 16, 2008 at 10:53 AM, Scott Blum <sco...@google.com> wrote:

On Fri, May 16, 2008 at 12:37 AM, John Tamplin <j...@google.com> wrote:

There are a couple of issues with this approach:

 1) security concerns about arbitrary JS being able to modify the preferences.  You can't use the preferences to control access to the preferences, so I am not sure how you fix it without Vista-like annoying dialogs asking the user if it is ok each time.

That's simple: running our own web app from a preferences "Configure" page automatically works.  For anyone else to get access to the API, you would have had to configure an JS access password, and the JavaScript would have to know the password in order to configure settings.  You could also lock out any page that used an incorrect password to prevent guessing attacks.

How would the plugin verify that it is "our own web app" that couldn't be spoofed by someone else's JS code?  Having the privileged XUL code set a flag before running it doesn't solve it because
 

firefox file://path/to/configure-oophm.html?oophm-settings-password=thepasswordiconfigured

As I understood it he wanted a way to set preferences from the command line, not startup a browser running the preferences app -- even if you aded URL params to set preferences you would be leaving browser processes around, which is why RemoteBrowser* exist for testing.

[John Tamplin]

Sent too early.

On Fri, May 16, 2008 at 11:34 AM, John Tamplin <j...@google.com> wrote:

That's simple: running our own web app from a preferences "Configure" page automatically works.  For anyone else to get access to the API, you would have had to configure an JS access password, and the JavaScript would have to know the password in order to configure settings.  You could also lock out any page that used an incorrect password to prevent guessing attacks.

How would the plugin verify that it is "our own web app" that couldn't be spoofed by someone else's JS code?  Having the privileged XUL code set a flag before running it doesn't solve it because 

... there is still a window of vulnerability that other apps could make use of.

[Scott Blum]

On Fri, May 16, 2008 at 11:34 AM, John Tamplin <j...@google.com> wrote:

On Fri, May 16, 2008 at 10:53 AM, Scott Blum <sco...@google.com> wrote:

On Fri, May 16, 2008 at 12:37 AM, John Tamplin <j...@google.com> wrote:

There are a couple of issues with this approach:

 1) security concerns about arbitrary JS being able to modify the preferences.  You can't use the preferences to control access to the preferences, so I am not sure how you fix it without Vista-like annoying dialogs asking the user if it is ok each time.

That's simple: running our own web app from a preferences "Configure" page automatically works.  For anyone else to get access to the API, you would have had to configure an JS access password, and the JavaScript would have to know the password in order to configure settings.  You could also lock out any page that used an incorrect password to prevent guessing attacks.

How would the plugin verify that it is "our own web app" that couldn't be spoofed by someone else's JS code?  Having the privileged XUL code set a flag before running it doesn't solve it because

Start up our Web UI with a query param that is the current correct password and have our UI use that?

 

[John Tamplin]

On Fri, May 16, 2008 at 11:49 AM, Scott Blum <sco...@google.com> wrote:

Start up our Web UI with a query param that is the current correct password and have our UI use that?

So if we keep the password in cleartext how do we protect it?