RE: merging the framesupport branch: framesupport vs. proxy injection mode

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: merging the framesupport branch: framesupport vs. proxy injection mode

Nelson Sproul
Naturally I'm a huge fan of my own work.  Why, for aesthetic reasons
alone, we should adopt it as the one and only way!  :)

It is true that proxy injection mode supports frames without any of the
framesupport work, but there at least a couple of key motivations for
going the framesupport route.

(First, just to be sure that there is no confusion, in this e-mail, when
I say "framesupport" I am referring to Dan's work in the framesupport
branch that he just merged into the trunk.)

The way I see it, there are two central benefits to us if we can hunt
down those last (I hope!) framesupport bugs.

1.)  framesupport supports SSL in chrome and IEHTA modes.  In proxy
injection mode, all the data is coming through the proxy, and therefore
if we were to ever support SSL, we would need to handle the encryption
ourselves (like Sahi does).  Since framesupport doesn't proxy the data,
its only problem with SSL is the same origin constraint which typically
comes up in SSL scenarios as the web site switches back and forth
between, e.g., https://www.acmebank.com and http://www.acmebank.com.
(Note that proxy injection mode has no problem with multiple domains, so
if someone ever did implement SSL support a la Sahi, it would
immediately work for all browsers in all modes.  (I have no plans to do
this work, by the way, though it would certainly be an interesting
task.))

2.) Proxy injection mode achieves frame support by moving a significant
part of the solution to the selenium server.  For each frame and window
that the web site opens, a separate request queue is maintained by the
selenium server.  When the selenium-rc client calls the
selenium.selectFrame method, the selenium server does not delegate this
operation to selenium core; rather it loops over all the request queues
asking the copy of selenium core running in each frame/window "are you
the frame which has just been requested?"  This is how proxy injection
mode supports potentially complicated DOM expressions referring to the
new frame; it passes them on to selenium core to be evaluated.  The
drawback is that selenium core does not itself support selectFrame.

So if we were to go this route, this implies that one might end up
running a future selenium IDE (which has been enhanced to understand
frame selecting) and thereby generate a script which can be run by
selenium-rc clients but not by selenium core.  This would surely be
confusing for users, and an inconvenience even for people who understand
what's going on.

-----Original Message-----
From: Mike Williams [mailto:[hidden email]]

What about Nelson's recent work on proxy-injection in S-RC?  As I
understand it, that allows multi-frame apps to be supported without the
existing "onload" trickery, ie. even without the work done on the
"framesupport" branch.  Correct?  So, could that be a solution for
multi-window apps?  It does require use of the Selenium Server, but
perhaps that's better than requiring browser extensions?  Nelson, Dan:
tell me what I'm getting wrong.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: merging the framesupport branch: framesupport vs. proxy injection mode

Mike Williams-7
Nelson Sproul wrote:

>  ... there at least a couple of key motivations for going the
>  framesupport route ...

Thanks Nelson.  Okay, so it doesn't sound like proxy-injection will
solve the world hunger problem. Bother.

--
cheers, MikeW                            http://www.dogbiscuit.org/mdub/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]