Loading ...
Sorry, an error occurred while loading the content.

Re: Crossframe and XP SP2

Expand Messages
  • Robert E Boughner
    ... earlier problem had to do with the way that IE was set up. I previousely had a dialup service and recently switched to a a DSL connection and the previous
    Message 1 of 15 , Sep 13, 2004
    • 0 Attachment
      --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
      > ----- Original Message -----
      > From: Robert E Boughner
      > To: overlibmws@yahoogroups.com
      > Sent: Monday, September 13, 2004 12:00 PM
      > Subject: [OLmws] Re: Crossframe and XP SP2
      >
      > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
      wrote:
      > <snip>
      > http://www.macridesweb.com/oltest/CrossFrame/
      > >snip>
      > I was able to access your reduced set without any problems. My
      earlier problem had to do with the way that IE was set up. I
      previousely had a dialup service and recently switched to a a DSL
      connection and the previous setup was no longer applicable with the
      new service. A quick call to my ISP this morning got me straightened
      out and going. I moused over all of the links in your right most
      frame including the bottom link which setup an exclusive popup in the
      second frame. I then clicked on your link in the second frame to
      reload it with the second file and went back to the links in the right
      hand frame. They all seemed to work except for the popups in the
      second frame. They were displayed but were hidden by the select box
      in that frame. Try restoring your previous setup and I'll rerun it
      again in IE6 on my Win XP SP2 setup and let you know the results.
      >
      > Bob
      >
      > I was going to restore it in stages, but OK, I restored the whole
      ball of wax. If you run into problems and it's not obvious which
      plugin is the culprit, we can go back to restoring it one plugin at a
      time.
      >
      > Regarding principles we can draw at this point about writing
      javascript for IE on WinXP SP2, we indeed can test whether an old over
      pointer (i.e., after navigation) is equal (==) or not (!=) to a fresh
      pointer to the overDiv layer. What's not yet clear is whether we can
      do something like if (typeof over.style == 'undefined') with the old
      pointer and not get a denial of access (I suspect that is a problem
      with IE on WinXP SP2).
      >
      Okay I'll test out the page again and let you know the results. With
      reqard to your previous comment, yes you can check whether the pointer
      is == or != to a fresh pointer to the overDiv layer but you cn't tell
      whether that layer is in the source or target frame because they'll
      both give the same result. I do not suspect that can try something
      like you suggest because it will give you an access denied error.
      However, I've tried just with if (over) alert('typeof: ' + typeof
      over) and what I got was an object for that. I'll try it again and
      make sure that was happening and let you know.

      Bob
    • Foteos Macrides
      ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Monday, September 13, 2004 4:49 PM Subject: [OLmws] Re: Crossframe and XP SP2 ...
      Message 2 of 15 , Sep 13, 2004
      • 0 Attachment
        ----- Original Message -----
        Sent: Monday, September 13, 2004 4:49 PM
        Subject: [OLmws] Re: Crossframe and XP SP2
         
        --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>wrote:
        Fote, just before that statement that you talked about before I put in a statement to print out some things after a renavigation of my two frame setup and what I got is shown in the attached screen shot on IE6 WinXP SP2 [sent by private email because the Yahoo groups archive does not retain attachments].  As you can see over has no value but it is an object but it reports that over.style is of unknown type  (incidentally you can check for this using typeof over.style == 'unknown' and you don't get an error message and it reports true for this condition.

        Also rechecked your full crossframe page and had no problems with it at all on my IE6.0 WinXP SP2 machine.

        Bob
         
        I'm glad the access problem you had yesterday with IE on WinXP SP2 was with your ISP setup, not my code, and that there in fact are no apparent crossframe support problems for that browser and platform with the current overlibmws code set.  Thanks for checking that out.
         
        Regarding the "programming for WinXP SP2" issues, whenever the over pointer is set to o3_frame.document.all['overDiv'], it automatically has a style object associated with it, and so
         
        if (over) alert('typeof over.style='+over.style);
         
        will report 'object' normally.  That had remained so even if over were pointing to the overDiv container in a prior document, i.e., that is now gone due to navigation in the relevant frame.  The change for WinXP SP2 appears to be that it instead reports 'unknown' meaning that it has not been changed to 'undefined' but by virtue of the changes in object caching you no longer can access it and know what it is. :<)
         
        The next important question is "What about over.scroll?"  In contrast to style, our scroll object is not automatically added to over. but is an object we add programmatically to over only if the SCROLL command (for overlibmws) or the FOLLOWSCROLL command (for the "Erik and Bob" code sets) was included in an overlib function call.  So normally over.scroll has a typeof of either 'undefined' or 'object'.  But does it also become 'unknown' on WinXP SP2 for an over that has been defined but can't be accessed due to navigation?  Because I didn't yet know the answer to that question, I avoided a crossframe scrolling problem for IE on WinXP SP2 by other means, apparently successfully based your not having any problems with the test suite at the above URL.  But you would be wise to take my heads up about problems on navigation for your followscroll plugin, because it still looks to me that it could have problems.
         
        Regarding the heads up I gave you about your shadow plugin which you think you tested and ruled out, you did not test it properly, and have not in fact ruled it out.  You need to actually look at your code and think it through before designing and trying to draw any valid inferences from such tests.  Your hook in the core module's hideObject function to your shadow plugin is for a cleanup operation if SHADOWOPACITY had been set to a value for semi-transparency of the shadow.  In your test there was "no indication of any errors" because you must have left the shadow fully opaque, thereby blocking that cleanup operation.
         
        The problem is in your shadow plugin's cleanUpBrowserOpacity(lyr) function, which you created on August 13, 2004 (according to your change log:) in an effort to incorporate into the "Erik and Bob" code sets my August 9, 2004 (according to my change log: http://www.macridesweb.com/oltest/changeHistory.html) enhancements of opacity handling in the overlibmws code set.  It is obvious (at least to me :<) simply from looking at your code that if you include a SHADOWOPACITY value for semi-transparency of the shadow, then IE will give you a prominent indication of an error in your test.
         
        Also note that Jon Burke's assertion that opacity was implemented by Microsoft only for IE v5.5 or higher is not correct.  As explained at the msdn developers knowledge base, it was implemented in IE v4.0, but a different way of handling it was added as of IE v5.5.  The 'Erik and Bob" code sets are using the procedure that is specific for IE v5.5 or higher, and that is why it doesn't work for Jon's clients with v4.0.  In contrast, the handling of opacity in overlibmws is set up to work as intended for IE v4.0 and v5.0 as well as v5.5 and v6.0.
         
        I hope the above information is helpful to you, and if your can answer my question about over.scroll please do.
         
        Fote
        --
         
      • Robert E Boughner
        ... ... contrast to style, our scroll object is not automatically added to over. but is an object we add programmatically to over only if the SCROLL
        Message 3 of 15 , Sep 14, 2004
        • 0 Attachment
          --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
          <snip>
          >
          > The next important question is "What about over.scroll?" In
          contrast to style, our scroll object is not automatically added to
          over. but is an object we add programmatically to over only if the
          SCROLL command (for overlibmws) or the FOLLOWSCROLL command (for the
          "Erik and Bob" code sets) was included in an overlib function call.
          So normally over.scroll has a typeof of either 'undefined' or
          'object'. But does it also become 'unknown' on WinXP SP2 for an over
          that has been defined but can't be accessed due to navigation?
          Because I didn't yet know the answer to that question, I avoided a
          crossframe scrolling problem for IE on WinXP SP2 by other means,
          apparently successfully based your not having any problems with the
          test suite at the above URL. But you would be wise to take my heads
          up about problems on navigation for your followscroll plugin, because
          it still looks to me that it could have problems.
          >
          To answer your question here Fote, it appears that because of
          navigation in IE under Win XP SP2, the over object remains defined
          (although it has no value) and it is of type object, none of its
          properties like over.id, over.scroll, over.style have a known type at
          all. (A typeof YYYY where YYYY is one of the above all report
          'unknown'). I made use of this fact to change how I treat that now.
          Basically I changed the line if (over) cClick(); at that beginning of
          the overlib routine (at about line 250) to the following:

          if (over) {
          over = (typeof over.id != 'string') ? null : over;
          if (over) cClick();
          }

          which should only affect IE under WinXP SP2 since only that will
          report the typeof over.id in this case to be 'unknown'. Thus the over
          object is reinitialized to null just as if it is starting a new. Some
          tests in IE, Netscape 7.2, and Opera 7.54 indicate no problems with
          this approach. Incidentally when using this I've removed the line
          that I had previously inserted into the hideObject() function.
          >
          > Regarding the heads up I gave you about your shadow plugin which you
          think you tested and ruled out, you did not test it properly, and have
          not in fact ruled it out. You need to actually look at your code and
          think it through before designing and trying to draw any valid
          inferences from such tests. Your hook in the core module's hideObject
          function to your shadow plugin is for a cleanup operation if
          SHADOWOPACITY had been set to a value for semi-transparency of the
          shadow. In your test there was "no indication of any errors" because
          you must have left the shadow fully opaque, thereby blocking that
          cleanup operation.
          >
          > The problem is in your shadow plugin's cleanUpBrowserOpacity(lyr)
          function, which you created on August 13, 2004 (according to your
          change log:) in an effort to incorporate into the "Erik and Bob" code
          sets my August 9, 2004 (according to my change log:
          http://www.macridesweb.com/oltest/changeHistory.html) enhancements of
          opacity handling in the overlibmws code set. It is obvious (at least
          to me :<) simply from looking at your code that if you include a
          SHADOWOPACITY value for semi-transparency of the shadow, then IE will
          give you a prominent indication of an error in your test.
          >
          Thanks for this reminder. I had forgotten about this totally and with
          my earlier change I do get a "Permission denied" error for both the
          shadow and followscroll plugins. However, I now no longer get that
          error with the new approach to handling this case. I guess further
          testing will reveal whether it does indeed do the job.
          >
          > Also note that Jon Burke's assertion that opacity was implemented by
          Microsoft only for IE v5.5 or higher is not correct. As explained at
          the msdn developers knowledge base, it was implemented in IE v4.0, but
          a different way of handling it was added as of IE v5.5. The 'Erik and
          Bob" code sets are using the procedure that is specific for IE v5.5 or
          higher, and that is why it doesn't work for Jon's clients with v4.0.
          In contrast, the handling of opacity in overlibmws is set up to work
          as intended for IE v4.0 and v5.0 as well as v5.5 and v6.0.
          >
          > I hope the above information is helpful to you, and if your can
          answer my question about over.scroll please do.
          >
          Yes your information has been very helpful to me. The dialog these
          past few days shows that we can have some really productive and
          fruitful discourses if we both remain civil to one another and don't
          interdict one's inuendo's into the discussion.

          Bob
        • Foteos Macrides
          ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Tuesday, September 14, 2004 4:53 PM Subject: [OLmws] Re: Crossframe and XP SP2
          Message 4 of 15 , Sep 15, 2004
          • 0 Attachment
             
            ----- Original Message -----
            Sent: Tuesday, September 14, 2004 4:53 PM
            Subject: [OLmws] Re: Crossframe and XP SP2
             
            <snip>
            Basically I changed the line if (over) cClick(); at that beginning of the overlib routine (at about line 250) to the following:

            if (over) {
             over = (typeof over.id != 'string') ? null : over;
             if (over) cClick();
            }
             
            which should only affect IE under WinXP SP2 since only that will report the typeof over.id in this case to be 'unknown'. 
            <snip>
             
            I'm sorry to say IMHO that is a bad programming strategy.  You've created the situation in which if it is IE on WinXP SP2 and there has been navigation, you completely by-pass all of the mop-up operations in cClick(), hideObject(), and any plugins.  But for IE on earlier Wintel systems and for all the other supported browsers and platforms you still do all of the mop-up operations, including ones that involve manipulation of an obsolete over pointer.  If you have good reason to believe that it is OK not to do any of the mop-up operations (e.g., canceling any outstanding timer operations, and resetting flags that have nothing directly to do with the over pointer) when there has been navigation, then you shouldn't do it for any of the browsers and platforms.  But making such a change in a mindlessly selective way to avoid an access denied error for IE on WinXP SP2, while knowing that obsolete pointers will continue to be used for the other browsers and platforms and that other cancellations and resets will still be done for them but not IE on WinXP SP2, is the kind of "trial and error" rather than "logic and principles-based" programming strategy that already has introduced too much crapolla in the "Erik and Bob" code sets.  I say that not to offend you personally, but out of my own strong distaste for that kind of programming strategy.  In any case, that's not how I'm dealing with this issue in overlbmws.
             
            I at this point have expanded my crossframe support test suite:
             
             
            so that it uses all of the overlibmws plugins except debug and function.  Could you play with it again, and in particular try the crossframe secondary popups via the primary popups in Frame [2] and Frame [3][1] (before and after navigation)?  That's hairy enough that I'm not certain I've eliminated all access attempts for obsolete pointers.  Also, please check the consequences of navigation via the three new links at the bottom of Frame [2], using them when a popup was being displayed in Frame [2] via the links in Frame [3][0][1].  As complex as the test suite has become, it all works great with IE and other browsers on Win98.
             
            Fote
            --
          • Robert E Boughner
            ... report the typeof over.id in this case to be unknown . ... created the situation in which if it is IE on WinXP SP2 and there has been navigation, you
            Message 5 of 15 , Sep 16, 2004
            • 0 Attachment
              --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
              >
              > ----- Original Message -----
              > From: Robert E Boughner
              > To: overlibmws@yahoogroups.com
              > Sent: Tuesday, September 14, 2004 4:53 PM
              > Subject: [OLmws] Re: Crossframe and XP SP2
              >
              > <snip>
              > Basically I changed the line if (over) cClick(); at that beginning
              of the overlib routine (at about line 250) to the following:
              >
              > if (over) {
              > over = (typeof over.id != 'string') ? null : over;
              > if (over) cClick();
              > }
              >
              > which should only affect IE under WinXP SP2 since only that will
              report the typeof over.id in this case to be 'unknown'.
              > <snip>
              >
              > I'm sorry to say IMHO that is a bad programming strategy. You've
              created the situation in which if it is IE on WinXP SP2 and there has
              been navigation, you completely by-pass all of the mop-up operations
              in cClick(), hideObject(), and any plugins. But for IE on earlier
              Wintel systems and for all the other supported browsers and platforms
              you still do all of the mop-up operations, including ones that involve
              manipulation of an obsolete over pointer. If you have good reason to
              believe that it is OK not to do any of the mop-up operations (e.g.,
              canceling any outstanding timer operations, and resetting flags that
              have nothing directly to do with the over pointer) when there has been
              navigation, then you shouldn't do it for any of the browsers and
              platforms. But making such a change in a mindlessly selective way to
              avoid an access denied error for IE on WinXP SP2, while knowing that
              obsolete pointers will continue to be used for the other browsers and
              platforms and that other cancellations and resets will still be done
              for them but not IE on WinXP SP2, is the kind of "trial and error"
              rather than "logic and principles-based" programming strategy that
              already has introduced too much crapolla in the "Erik and Bob" code
              sets. I say that not to offend you personally, but out of my own
              strong distaste for that kind of programming strategy. In any case,
              that's not how I'm dealing with this issue in overlbmws.
              >
              <snip>
              Fote, the whole purpose of this statement, as you have pointed out in
              an earlier post, was to handle the situation for popups in a
              crossframe situation. In all other statements this statement is not
              needed and its whole intent was to just set the visibility of the
              popup to hidden. The fact that it does other things too is just
              fortuitous. I just called a built in function rather than just
              turning off the visibility was to eliminate some code. If what I did
              there was offensive to you, you can change the statement:

              over = (typeof over.id != 'string') ? null : over;

              to

              over = (typeof over.id != 'string' && o3_frame != ol_frame) ?
              o3_frame.document.all['overDiv'] : over;

              and then just call cClick() after it without the check.

              But to answer your question, my rationale for going this route is
              because for this particular case where a page has been loaded into the
              frame where the popup was being shown, the popup is wiped out as if it
              had already been closed and the rest of the program functions as if
              the value of over were null just like the first time that it is
              called. All of the functions should be set up to handle this situation.

              In addition, what comes after this in the overlib code is to
              re-instanstiate a new over popup with new properties and timers as
              such. What was there before doesn't make any difference. In this
              reqard, the same approach can be taken with all of the other browsers
              but for them, I couldn't come up with a way to tell whether navigation
              has occurred. Maybe this discussion will be helpful in that regard.

              Bob
            Your message has been successfully submitted and would be delivered to recipients shortly.