Javascript call to invisible applet fails after upgrading to 1.5 (IE)

Discussion in 'Java' started by Dag Sunde, May 4, 2006.

  1. Dag Sunde

    Dag Sunde Guest

    I have an applet with some public methods
    I call from Javascript in a .html page.

    I load it , and set the css-style 'visibility'
    to hidden.

    Then i call a method in the applet from JS.

    This have worked perfectly in IE6 witj jre 1.4.x

    Now I have recompiled the applet with 1.5 and
    updated the java plugin to 1.5, and the method
    call from JS fails as long as the applets style is hidden.

    Can someone shed some light on this for me?
     
    Dag Sunde, May 4, 2006
    #1
    1. Advertising

  2. Dag Sunde

    Andrew T. Guest

    Dag Sunde wrote:
    > I have an applet with some public methods
    > I call from Javascript in a .html page.


    URL?

    > I load it , and set the css-style 'visibility'
    > to hidden.


    I have been expecting to see problems with hidden
    applets for some time. It is a natural* consequence
    of the tightening security .

    * As far as I understand it.

    > Then i call a method in the applet from JS.
    >
    > This have worked perfectly in IE6 witj jre 1.4.x
    >
    > Now I have recompiled the applet with 1.5 and
    > updated the java plugin to 1.5, and the method
    > call from JS fails as long as the applets style is hidden.


    Is it a security problem? (Make sure you check both
    JS and Java consloles)

    > Can someone shed some light on this for me?


    Not sure, need more info.
    (URL's to the applet both visible and hidden would help,
    and I am presuiming you are not swallowing exceptions.)
    A third including the applet with a width/height of 0
    might also be interesting.

    Andrew T.
     
    Andrew T., May 5, 2006
    #2
    1. Advertising

  3. Dag Sunde

    Roedy Green Guest

    On 4 May 2006 20:20:35 -0700, "Andrew T." <>
    wrote, quoted or indirectly quoted someone who said :

    >> I have an applet with some public methods
    >> I call from Javascript in a .html page.

    >
    >URL?
    >
    >> I load it , and set the css-style 'visibility'
    >> to hidden.


    Let's say you do that. If it is a dangerous signed applet, you still
    see the request for permission. If it is an unsigned Applet, what
    dangerous thing could it do?
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, May 5, 2006
    #3
  4. Dag Sunde

    Dag Sunde Guest

    "Andrew T." <> skrev i melding
    news:...
    > Dag Sunde wrote:
    >> I have an applet with some public methods
    >> I call from Javascript in a .html page.

    >
    > URL?


    Thanks for responding Andrew.
    I'm sorry, but it is a customer owned 'closed'
    system, so I can't give any.

    I also need to correct some information. I was
    dragged into this when one of our other programmers
    hit the problem, so my first info wasn't entirely accurate.

    calling an applet-methods fail in 1.4.2 too, as long as the applet
    or its container's visibility is set to hidden.

    The case/problem we enconter is:
    (Imagine a applet containing ie. a JTable
    for entering bids, et.c)

    When the user click on a link to enter new bids, the applets
    container is set to visible, and on the following line,
    one of the applet's methods are called:

    //JS-code (IE 6.0)
    var gridApplet = document.getElementById('gridapplet');
    document.getElementById('mainContentPane').style.visibility = 'visible';
    gridApplet.initMarket(market);

    in 1.4.2, the above worked, but in 1.5 the call to initMarket(...) fails.
    BUT! if we introduce a small delay between making it visible and calling
    the method, it works with the 1.5 plugin too.

    I've done a little research, and it turns out that IE doesn't call an
    applet's init() and start() methods at page load/parse time if it determine
    that the applet or its container is hidden. The Applet is initialized
    first when it is made visible. (Firefox initializes the applet at page load,
    regardless of it's visible state).

    It seems like jre 1.5 plugin needs a little more time to 'wake up' before
    you can call any of the applet's methods...?

    <snip>
    > Is it a security problem? (Make sure you check both
    > JS and Java consloles)


    Have done so, nothing. Our Applet is signed, and given full privileges.
    It *might* be that the developer have swallowed one or more
    exceptions, but he promised me he had not... :-\

    <snip>
    > A third including the applet with a width/height of 0
    > might also be interesting.


    That will work, because in that case the applet is 'visible', and already
    initialized.

    The reason we want to avoid this, is the ugly flashing that occurs when
    one resizes the applet from 0 to its full size.

    Thanks for your interest and tips...

    --
    Dag.
     
    Dag Sunde, May 5, 2006
    #4
  5. Dag Sunde

    Dag Sunde Guest

    "Roedy Green" <> skrev i
    melding news:...
    > On 4 May 2006 20:20:35 -0700, "Andrew T." <>
    > wrote, quoted or indirectly quoted someone who said :
    >
    >>> I have an applet with some public methods
    >>> I call from Javascript in a .html page.

    >>
    >>URL?
    >>
    >>> I load it , and set the css-style 'visibility'
    >>> to hidden.

    >
    > Let's say you do that. If it is a dangerous signed applet, you still
    > see the request for permission. If it is an unsigned Applet, what
    > dangerous thing could it do?


    That's what we concluded too, and I couldn't find *anyting* from MS or
    Sun indicating that such changes have been made. Neither to the browser nor
    to the java VM.

    --
    Dag.
     
    Dag Sunde, May 5, 2006
    #5
  6. Dag Sunde

    Andrew T. Guest

    Dag Sunde wrote:
    > "Andrew T." <> skrev i melding
    > news:...
    > > Dag Sunde wrote:
    > >> I have an applet with some public methods
    > >> I call from Javascript in a .html page.

    ....
    > It seems like jre 1.5 plugin needs a little more time to 'wake up' before
    > you can call any of the applet's methods...?


    Uh-Huh, OK. To safeguard yourself for that situation, you can
    delay your JS a little and check the applet.isAlive(?) method to
    wait for it.

    ( But depsite yours and Roedy's logical countering of my
    security worries, I still feel it is only a matter of time before
    most invisible elements in pages will be considered at least
    slightly suspicious. ;)

    Andrew T.
     
    Andrew T., May 6, 2006
    #6
  7. Dag Sunde

    Chris Uppal Guest

    Dag Sunde wrote:

    > > > > I load it , and set the css-style 'visibility'
    > > > > to hidden.

    > >
    > > Let's say you do that. If it is a dangerous signed applet, you still
    > > see the request for permission. If it is an unsigned Applet, what
    > > dangerous thing could it do?

    >
    > That's what we concluded too, and I couldn't find *anyting* from MS or
    > Sun indicating that such changes have been made.


    I'm with Andy in suspecting that this will cause you problems in the future if
    it isn't already.

    a) "Invisible" elements in general are getting a very bad name, not matter what
    they are expressed in. Browser designers would be very well advised to be
    /extremely/ cautious about providing the ability to create stealth elements --
    or indeed any elements which don't look like what they are.

    b) Security thinking requires a mental model of how things behave, if things
    are allowed to move outside that model, then /you just don't know/ what will
    happen. If the browser-designers have managed (/if/) to learn that lesson,
    then they will insist that applets (and all other elements) are constrained to
    work within the limits of the /designers'/ mental model of what applets are
    for.

    The fact that I, personally, cannot think of an attack vector which is
    available to an invisible applet, but not to a visible one, is irrelevant. The
    point is that, in the absence of convincing formal proof[*], my not being able
    to imagine a problem doesn't mean there isn't one there. Browser designers,
    and creators of other highly security-sensitive software, are slowly learning
    this way of thinking.

    -- chris

    [*] Quite difficult to provide, since the proof would surely require mapping
    the problem domain into some formalism, and it's /precisely/ when that mapping
    is performed, that divergences between the mental model of the domain, and the
    actual physical domain[**], tend to get lost.

    [**] i.e. real instructions operating on physically real RAM in a physically
    real computer.
     
    Chris Uppal, May 6, 2006
    #7
  8. Dag Sunde

    Dag Sunde Guest

    "Andrew T." <> skrev i melding
    news:...
    > Dag Sunde wrote:
    >> "Andrew T." <> skrev i melding
    >> news:...
    >> > Dag Sunde wrote:
    >> >> I have an applet with some public methods
    >> >> I call from Javascript in a .html page.

    > ...
    >> It seems like jre 1.5 plugin needs a little more time to 'wake up' before
    >> you can call any of the applet's methods...?

    >
    > Uh-Huh, OK. To safeguard yourself for that situation, you can
    > delay your JS a little and check the applet.isAlive(?) method to
    > wait for it.


    That's what we did. But I was suprised by the difference and the
    need to do so.

    We developed two different ways to "wait". The first one we used
    a small loop with a JS try/catch block, calling the method in the
    try, and introducing a small (250mS) delay in the catch before retrying.

    The otherone uses the netscape JSObject in the applet to call back to
    a JS function when the Applet's start() method is executed.

    I like the latter best, leaving it to the applet to announce when its
    ready.

    >
    > ( But depsite yours and Roedy's logical countering of my
    > security worries, I still feel it is only a matter of time before
    > most invisible elements in pages will be considered at least
    > slightly suspicious. ;)


    I definitely share your worries... Thats why I made some effort to
    understand and check the consequences. And my conclusion is that
    there is none.

    But, that doesn't solve the problem that the users or their
    IT-departmens will be suspicious about hidden, active content.

    The only solution I can see to that is education and documentation.

    --
    Dag.
     
    Dag Sunde, May 6, 2006
    #8
  9. Dag Sunde

    Andrew T. Guest

    Dag Sunde wrote:

    'applet not ready'
    ....
    > We developed two different ways to "wait". The first one we used
    > a small loop with a JS try/catch block, calling the method in the
    > try, and introducing a small (250mS) delay in the catch before retrying.
    >
    > The otherone uses the netscape JSObject in the applet to call back to
    > a JS function when the Applet's start() method is executed.
    >
    > I like the latter best, leaving it to the applet to announce when its
    > ready.


    I cannot see the advantage. I prefer the former since it can easily
    be applied to third party applets that you don't have the option of
    altering.

    As for the security concerns, I think Chris put it into words
    better than I could. My best explanation would be
    'better safe than sorry'. ;-)

    Andrew T.
     
    Andrew T., May 10, 2006
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mcdeveloper
    Replies:
    1
    Views:
    4,217
    mcdeveloper
    Jun 13, 2006
  2. Replies:
    0
    Views:
    343
  3. Andy B
    Replies:
    5
    Views:
    600
    Andy B
    May 29, 2008
  4. crazytazo
    Replies:
    3
    Views:
    1,261
    Daniel Pitts
    Oct 7, 2008
  5. Trueman
    Replies:
    1
    Views:
    138
    Martin Honnen
    Oct 6, 2005
Loading...

Share This Page