By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,848 Members | 3,202 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,848 IT Pros & Developers. It's quick & easy.

Two windows: one for IE7 and the other for FF3

P: n/a
DL

The rationale is that certain IE7 features are great while FF3 got
things that IE7 doesn't and the user has both browsers installed (not
assumption but a requirement for "controled" use environment).

Scenario: IE7 is the main browser, from there launch a small FF3, do
stuff and this child window has a hidden field for 'action' as well,
once done, the user switch back to the main IE window, continue doing
stuff, then save and (possibly exit as well), this save action from
the main window, ideally can perform: a) execute the hidden 'action'
of the FF3 child windown; b) execute an action of its own. Hence, for
this to happen, the key question is, how to reference the foreign
window's object (FF3 window here) from the main IE7 window? Oh, you
may ask, first how do you launch the FF3 window session, well, the
application would address that.
Any idea?

TIA.

Oct 19 '08 #1
Share this Question
Share on Google+
14 Replies


P: n/a

"DL" <ta********@gmail.comwrote in message
news:7d**********************************@m32g2000 hsf.googlegroups.com...
>
The rationale is that certain IE7 features are great while FF3 got
things that IE7 doesn't and the user has both browsers installed (not
assumption but a requirement for "controled" use environment).
You might be better off looking for solutions to the "missing" IE features.
Your proposal to mix IE and FF seems the wrong approach, even for a
"controlled" environment.

Tim

Scenario: IE7 is the main browser, from there launch a small FF3, do
stuff and this child window has a hidden field for 'action' as well,
once done, the user switch back to the main IE window, continue doing
stuff, then save and (possibly exit as well), this save action from
the main window, ideally can perform: a) execute the hidden 'action'
of the FF3 child windown; b) execute an action of its own. Hence, for
this to happen, the key question is, how to reference the foreign
window's object (FF3 window here) from the main IE7 window? Oh, you
may ask, first how do you launch the FF3 window session, well, the
application would address that.
Any idea?

TIA.

Oct 19 '08 #2

P: n/a
DL
On Oct 19, 7:19*pm, "Tim Williams" <timjwilliams at gmail dot com>
wrote:
"DL" <tatata9...@gmail.comwrote in message

news:7d**********************************@m32g2000 hsf.googlegroups.com...
The rationale is that certain IE7 features are great while FF3 got
things that IE7 doesn't and the user has both browsers installed (not
assumption but a requirement for "controled" use environment).

You might be better off looking for solutions to the "missing" IE features.
Your proposal to mix IE and FF seems the wrong approach, even for a
"controlled" environment.

Tim
Scenario: IE7 is the main browser, from there launch a small FF3, do
stuff and this child window has a hidden field for 'action' as well,
once done, the user switch back to the main IE window, continue doing
stuff, then save and (possibly exit as well), this save action from
the main window, ideally can perform: a) execute the hidden 'action'
of the FF3 child windown; b) execute an action of its own. *Hence, for
this to happen, the key question is, how to reference the foreign
window's object (FF3 window here) from the main IE7 window? * Oh, you
may ask, first how do you launch the FF3 window session, well, the
application would address that.
Any idea?
TIA.- Hide quoted text -

- Show quoted text -
Yes, stick with IE for 'everything' is the most desirable/elegant
solution, however, my understanding is, the the "missing" IE feature
is not going to be available any time soon (here we're talking about
in a few months time frame or the like...), building such feature
oneself to include security integration with existing IE, say, IE7,
would be daunting... hence, I opted to this approach, since my last
post I've made substantial progress already... I appreciate your
thought though.
Oct 20 '08 #3

P: n/a
On Oct 19, 11:11 pm, DL <tatata9...@gmail.comwrote:
On Oct 19, 7:19 pm, "Tim Williams" <timjwilliams at gmail dot com>
wrote:
"DL" <tatata9...@gmail.comwrote in message
news:7d**********************************@m32g2000 hsf.googlegroups.com...
The rationale is that certain IE7 features are great while FF3 got
things that IE7 doesn't and the user has both browsers installed (not
assumption but a requirement for "controled" use environment).
You might be better off looking for solutions to the "missing" IE features.
Your proposal to mix IE and FF seems the wrong approach, even for a
"controlled" environment.
Tim
Scenario: IE7 is the main browser, from there launch a small FF3, do
stuff and this child window has a hidden field for 'action' as well,
once done, the user switch back to the main IE window, continue doing
stuff, then save and (possibly exit as well), this save action from
the main window, ideally can perform: a) execute the hidden 'action'
of the FF3 child windown; b) execute an action of its own. Hence, for
this to happen, the key question is, how to reference the foreign
window's object (FF3 window here) from the main IE7 window? Oh, you
may ask, first how do you launch the FF3 window session, well, the
application would address that.
Any idea?
TIA.- Hide quoted text -
- Show quoted text -

Yes, stick with IE for 'everything' is the most desirable/elegant
solution, however, my understanding is, the the "missing" IE feature
is not going to be available any time soon (here we're talking about
in a few months time frame or the like...), building such feature
oneself to include security integration with existing IE, say, IE7,
would be daunting... hence, I opted to this approach, since my last
post I've made substantial progress already... I appreciate your
thought though.
Why not just create your own browser? Seems like it would be less work.
Oct 20 '08 #4

P: n/a
DL meinte:
The rationale is that certain IE7 features are great while FF3 got
things that IE7 doesn't and the user has both browsers installed (not
assumption but a requirement for "controled" use environment).

Scenario: IE7 is the main browser, from there launch a small FF3, do
stuff and this child window has a hidden field for 'action' as well,
once done, the user switch back to the main IE window, continue doing
stuff, then save and (possibly exit as well), this save action from
the main window, ideally can perform: a) execute the hidden 'action'
of the FF3 child windown; b) execute an action of its own. Hence, for
this to happen, the key question is, how to reference the foreign
window's object (FF3 window here) from the main IE7 window? Oh, you
may ask, first how do you launch the FF3 window session, well, the
application would address that.
Any idea?
Sounds pretty gaga.

Gregor
Oct 20 '08 #5

P: n/a
rf

"Gregor Kofler" <us****@gregorkofler.atwrote in message
news:VY*************@nntpserver.swip.net...
DL meinte:
>The rationale is that certain IE7 features are great while FF3 got
things that IE7 doesn't and the user has both browsers installed (not
assumption but a requirement for "controled" use environment).
I've been waiting for you to tell us what these features are. That is, what
does IE7 do that FF(any version) does not and what FF(any version) does that
IE7 does not. I can think of a very large number of such things but I don't
know which ones you intend to rely on.

I really think you are painting yourself into a very small corner. If not
you yourself then the person who has to pick up the pieces when you are gone
from your current position. Your replacement will IMHO very often get that
WTF feeling.

And what about people who buy new windows computers, the ones that ship with
vista and IE8? Another page for them? Or are you going to retrofit IE7 into
those computers under your "controlled" use environment. Recipe for total
disaster.

In any case there is no way at all you are going to reference anything in a
FF windew from IE, nor the other way round. Browsers simply do not do this,
especially when one of them is written by Microsoft.
Oct 20 '08 #6

P: n/a
On Oct 19, 7:10*am, DL <tatata9...@gmail.comwrote:
The rationale is that certain IE7 features are great while FF3 got
things that IE7 doesn't and the user has both browsers installed (not
assumption but a requirement for "controled" use environment).

Scenario: IE7 is the main browser, from there launch a small FF3, do
stuff and this child window has a hidden field for 'action' as well,
once done, the user switch back to the main IE window, continue doing
stuff, then save and (possibly exit as well), this save action from
the main window, ideally can perform: a) execute the hidden 'action'
of the FF3 child windown; b) execute an action of its own. *Hence, for
this to happen, the key question is, how to reference the foreign
window's object (FF3 window here) from the main IE7 window? * Oh, you
may ask, first how do you launch the FF3 window session, well, the
application would address that.
Any idea?
In a Mac this can be done with an applescript script. The main
browser's window can invoke Safari via an applescript://commandsHere
url and the Safari's applescript dictionary's command "do JavaScript"
allows you to insert+execute+retrieve any JS code/data into a page/
tab.

In Windozes, I don't know how much scriptable the apps are, or if they
are scriptable at all.

Another possibility is to have the pages talk to each other through
the server, isn't it ?

--
Jorge.
Oct 20 '08 #7

P: n/a
Jorge meinte:
Another possibility is to have the pages talk to each other through
the server, isn't it ?
Yes, but the OP wants to fire up FF from IE and vice-versa. *That's*
gonna be the (IMO unsolvable) problem.

Gregor
Oct 20 '08 #8

P: n/a
Gregor Kofler wrote:
Jorge meinte:
>Another possibility is to have the pages talk to each other through
the server, isn't it ?

Yes, but the OP wants to fire up FF from IE and vice-versa. *That's*
gonna be the (IMO unsolvable) problem.
It is possible to run Firefox (or any other application) from IE, using the
Windows Script Host.

It is also possible to a certain extent to run IE/MSHTML from/in Firefox,
using the MSHTML ActiveX/COM control. The IE Tab extension does that
already, and it can be configured so that it is automatically triggered with
certain URIs (a per-profile setting, though).
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Oct 21 '08 #9

P: n/a
DL
On Oct 21, 8:06*am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Gregor Kofler wrote:
Jorge meinte:
Another possibility is to have the pages talk to each other through
the server, isn't it ?
Yes, but the OP wants to fire up FF from IE and vice-versa. *That's*
gonna be the (IMO unsolvable) problem.

It is possible to run Firefox (or any other application) from IE, using the
Windows Script Host.

It is also possible to a certain extent to run IE/MSHTML from/in Firefox,
using the MSHTML ActiveX/COM control. *The IE Tab extension does that
already, and it can be configured so that it is automatically triggered with
certain URIs (a per-profile setting, though).

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
* -- Richard Cornford, cljs, <f806at$ail$1$8300d...@news.demon.co.uk>
Right on, and I wouldn't do it if I had another option. And not only
possible, I've made it work already, and yet I don't know how to call/
trigger action of the other brower, probably need to look further of
two types of underlining technologies...

Oct 21 '08 #10

P: n/a
Thomas 'PointedEars' Lahn meinte:
Gregor Kofler wrote:
>Jorge meinte:
>>Another possibility is to have the pages talk to each other through
the server, isn't it ?
Yes, but the OP wants to fire up FF from IE and vice-versa. *That's*
gonna be the (IMO unsolvable) problem.

It is possible to run Firefox (or any other application) from IE, using the
Windows Script Host.
Agreed (since you can start whatever application you wan't to start with
WS Host). But then it's just firing up FF - establishing interaction
between the FF JS and the IE JS gonna be tough part. One could try to
implement this communication with XHR, though I suppose it's gonna be
rather hit-or-miss and a rather arkward user experience.
Gregor
Oct 22 '08 #11

P: n/a
Gregor Kofler wrote:
Thomas 'PointedEars' Lahn meinte:
>Gregor Kofler wrote:
>>Jorge meinte:
Another possibility is to have the pages talk to each other through
the server, isn't it ?
Yes, but the OP wants to fire up FF from IE and vice-versa. *That's*
gonna be the (IMO unsolvable) problem.
It is possible to run Firefox (or any other application) from IE, using the
Windows Script Host.

Agreed (since you can start whatever application you wan't to start with
WS Host). But then it's just firing up FF - establishing interaction
between the FF JS and the IE JS gonna be tough part.
Correct. That is the part of the discussion that "DL" unfortunately does
not seem to get.
One could try to implement this communication with XHR, [...]
I don't think so. How do you suggest to distribute an XHR object between
two incompatible DOMs?
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Oct 22 '08 #12

P: n/a
Thomas 'PointedEars' Lahn meinte:
>One could try to implement this communication with XHR, [...]

I don't think so. How do you suggest to distribute an XHR object between
two incompatible DOMs?
I was thinking of both browsers doing their data exchange with the help
of a server and - naturally - two seperate XHR objects. This would need
constant polling on both sides, and... well, sounds all pretty ugly.

Anyway, since DL hasn't stated what "great features" of IE7 (and
Firefox) he was referring to, it's a pointless discussion. Perhaps he
should just browse through the FF extensions repository.

Gregor
Oct 22 '08 #13

P: n/a
The sponsored link opposite DL's post said "Try Google Chrome." Opera
also comes to mind.

Using the non-standard bits of anyone's browser is very bad practice.
Oct 22 '08 #14

P: n/a
DL
On Oct 22, 12:29*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Gregor Kofler wrote:
Thomas 'PointedEars' Lahn meinte:
Gregor Kofler wrote:
Jorge meinte:
Another possibility is to have the pages talk to each other through
the server, isn't it ?
Yes, but the OP wants to fire up FF from IE and vice-versa. *That's*
gonna be the (IMO unsolvable) problem.
It is possible to run Firefox (or any other application) from IE, using the
Windows Script Host.
Agreed (since you can start whatever application you wan't to start with
* WS Host). But then it's just firing up FF - establishing interaction
between the FF JS and the IE JS gonna be tough part.

Correct. *That is the part of the discussion that "DL" unfortunately does
not seem to get.
Are you saying because IE and FF uses different DOMs hence
communcation between them is a real challenge? (for the part I didn't
get). On XHR approach, if not reliable I'll have to skip it.
One could try to implement this communication with XHR, [...]

I don't think so. *How do you suggest to distribute an XHR object between
two incompatible DOMs?

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
* -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Oct 23 '08 #15

This discussion thread is closed

Replies have been disabled for this discussion.