Great analysis. Some thoughts and questions appear in-line.
On Mon, Aug 30, 2010 at 6:13 AM, Jim Evans <james.h....@gmail.com> wrote:
> First, we could dictate that to work with IE, all zones must have the
> same Protected Mode setting. As long as it's on for all zones, or off
> for all zones, we can make it work pretty well using many of the
> techniques in the existing code base. The pros of this solution are
> that protected mode settings are per user, and usually don't require
> admin privileges to set. It allows our users to continue to run with
> UAC turned on, and to run securely in the browser if they set
> Protected Mode "on" for all zones. On the downside, there's no
> documented or easy way to programmatically set this setting; the user
> will have to do it themselves.
How is this a better situation than installing a DLL with regsvr32?
It could be installed under HKCU and not affect the entire machine.
I'm probably missing something very obvious, but it seems if the user
already has to jump through hoops, we may as well make it easier for
ourselves. It'd probably be easier for the user, too, instead of
setting the zone settings.
Having said that, I'm pretty sure you can manipulate the zone settings
via the registry. We already do some of this in the IE launcher for
Se 1.x. The tricky point (if it works at all) is figuring out how to
unroll the changes to end back up in a clean state when multiple IE
instances are being run.
> Second, we could let the Protected Mode preferences alone and do some
> sort of "best guess" algorithm to find new browser windows as they
> appear. On the plus side, it will appear to "just work" for users. On
> the other hand, it almost completely invalidates the multiple IE
> driver use case, and it's almost a certainty that we will guess wrong
> at some point, leading to unexpected behavior in tests.
This could be tricky, but always grabbing the most recently created IE
window should be a good enough heuristic. It probably would require
looking up the process hierarchy to make sure a new tab wasn't created
in an older window VS a new window being created. But, if it's
documented and deterministic, it's probably good enough.
Otherwise, an in-process COM server should let you operate on the
> If you're talking about creating and installing a BHO via regsvr32,
> you can't create a per-user BHO. It *must* be per-machine, and you
> *have* to register it in HKLM, which requires elevation.
Ahh, right. Sorry, I forgot about that. I've been playing with NPAPI
which will read out of HKCU.
> I'd be interested in seeing how the zone manipulation works though. I used
> procmon to view the registry calls made by IE when I changed my
> settings, and the results looked to be really, really obscure.
Take a look through the source and you can see where some of these
entries exist. I've found it much easier to snapshot the registry,
make the change, snapshot again, and then diff the results. It's
laborious, but seems to work rather well.
> Incidentally, how do you tell the "most recently created" one? I don't
> know what API to call to get that information. Do we always keep a
> list of every IE window open on the system? Use IShellWindows (or more
> correctly DShellWindowsEvents)?
You could have timing issues at creation time, but then again, they're
browsers that haven't been associated with any WebDriver instance yet
so it probably doesn't matter a whole lot. Once one is associated
with the WebDriver instance, you'd just keep track of the proc ID or
GetProcessTimes looks like the API call you'd want to dig up creation time:
Of course, you'll still need to find the list of processes with name
"iexplore.exe," but that should be fairly straightforward.
I should preface that you've spent way more time looking at this than
I have, so I'll defer to you on the finer points. My BHO experience
is largely relegated to out-of-Selenium work and the work done on
SnapsIE. I've audited a bit of the WebDriver IE code, but don't know
it well enough to speak authoritatively about it.
More comments below:
On Mon, Aug 30, 2010 at 9:01 AM, Jim Evans <james.h....@gmail.com> wrote:
> Could be that I'm way off base here and trying to make this harder
> than it is. My approaches to solving these problems rest on the
> following assumptions:
> 1. We do not want to interfere with browser processes the user creates
> manually (either before or during test execution).
I guess this one I don't care all that much about. It'd be great if
we could do it, but if we can't, I'm personally okay with dropping it.
A test machine really shouldn't be interactively used.
> 2. We want to be able to instantiate multiple drivers and run them in
> 3. We want a driver session to be able to control all of the browsers
> that are opened by actions taken in the context of that session.
I'd have to look at the process hierarchy to see if any ancestry is
established or not to see how easily that could be supported.