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

Re: [caplet] Re: Javascript mystery

Expand Messages
  • Mark S. Miller
    ... I ve just repeated it on FF2.0.0.7 on Linux. For all the tests I ve done on both, I haven t yet seen any difference between FF on Linux vs. Mac. Ben s msg
    Message 1 of 13 , Oct 10, 2007
      On 10/9/07, Mike Samuel <mikesamuel@...> wrote:
      > I can't repeat your example under the squarefree shell on FF2.0.0.7 on Linux.
      > And I can't reproduce by playing around with 'with' blocks, window subclasses, or eval.call.

      I've just repeated it on FF2.0.0.7 on Linux. For all the tests I've
      done on both, I haven't yet seen any difference between FF on Linux
      vs. Mac. Ben's msg led to some more experiments:

      When I try this using the standalone squarefree shell page at
      http://www.squarefree.com/shell/shell.html I don't get the peculiar
      behavior. It only happens when I use the squarefree shell bookmarklet
      available from http://www.squarefree.com/bookmarklets/webdevel.html .
      When using the bookmarklet, it does open the shell up in a different
      window from the one it's examining. The mystery window from my example
      is the bookmarklet's new window. Typing

      function foo() {return this;}
      foo.call(null).close()

      into the bookmarklet's shell does cause it to close itself.

      --
      Cheers,
      --MarkM
    • Mike Samuel
      To make sure I m clear, you re using the square free bookmarklet (the first entry, [shell], at http://www.squarefree.com/bookmarklets/webdevel.html) not
      Message 2 of 13 , Oct 10, 2007
        To make sure I'm clear, you're using the square free bookmarklet (the first entry, [shell], at http://www.squarefree.com/bookmarklets/webdevel.html ) not http://www.squarefree.com/shell/shell.html.

        And then you do
          function foo() { print(this); print(this === window); }
          foo.call(undefined)
        and you get the output
          [Window]
          false
        ?

        I can repeat using the squarefree bookmarklet, but not the shell webpage.






        On 10/10/2007, Mark S. Miller <erights@...> wrote:

        On 10/9/07, Mike Samuel <mikesamuel@...> wrote:
        > I can't repeat your example under the squarefree shell on FF2.0.0.7 on Linux.
        > And I can't reproduce by playing around with 'with' blocks, window subclasses, or eval.call.

        I've just repeated it on FF2.0.0.7 on Linux. For all the tests I've
        done on both, I haven't yet seen any difference between FF on Linux
        vs. Mac. Ben's msg led to some more experiments:

        When I try this using the standalone squarefree shell page at
        http://www.squarefree.com/shell/shell.html I don't get the peculiar
        behavior. It only happens when I use the squarefree shell bookmarklet
        available from http://www.squarefree.com/bookmarklets/webdevel.html .
        When using the bookmarklet, it does open the shell up in a different
        window from the one it's examining. The mystery window from my example
        is the bookmarklet's new window. Typing

        function foo() {return this;}
        foo.call(null).close()

        into the bookmarklet's shell does cause it to close itself.

        --
        Cheers,
        --MarkM


      • Mark Miller
        ... Yes exactly. -- Text by me above is hereby placed in the public domain Cheers, --MarkM
        Message 3 of 13 , Oct 10, 2007
          On 10/10/07, Mike Samuel <mikesamuel@...> wrote:
          > To make sure I'm clear, you're using the square free bookmarklet (the first entry, [shell], at
          > http://www.squarefree.com/bookmarklets/webdevel.html ) not
          > http://www.squarefree.com/shell/shell.html.
          >
          > And then you do
          > function foo() { print(this); print(this === window); }
          > foo.call(undefined)
          > and you get the output
          > [Window]
          > false
          > ?
          >
          > I can repeat using the squarefree bookmarklet, but not the shell webpage.


          Yes exactly.


          --
          Text by me above is hereby placed in the public domain

          Cheers,
          --MarkM
        • Mike Samuel
          The reason for this is in the first line of the bookmarklet with(window.open(...)) { ... } Each window object has an eponymous property, window . This with
          Message 4 of 13 , Oct 10, 2007
            The reason for this is in the first line of the bookmarklet
                with(window.open(...)) { ... }

            Each window object has an eponymous property, 'window'.

            This 'with' block causes apparent globals to instead be interpreted as properties of the opened window, so this may still be the window that was in focus when you clicked the bookmark, but this.window !== this, since this.window is resolved as a property of the window.

            I tried deleting the window and assigning window to this, but rerunning it doesn't change behavior.  I think that may be a cross-domain thing though.  window's are manipulable across domain since a window needs to be able to set a frame's location, but they don't allow setting of arbitrary properties such as "window" cross-domain.

            mike




            On 10/10/2007, Mike Samuel <mikesamuel@...> wrote:
            To make sure I'm clear, you're using the square free bookmarklet (the first entry, [shell], at http://www.squarefree.com/bookmarklets/webdevel.html ) not http://www.squarefree.com/shell/shell.html.

            And then you do
              function foo() { print(this); print(this === window); }
              foo.call(undefined)
            and you get the output
              [Window]
              false
            ?

            I can repeat using the squarefree bookmarklet, but not the shell webpage.







            On 10/10/2007, Mark S. Miller <erights@...> wrote:

            On 10/9/07, Mike Samuel <mikesamuel@...> wrote:
            > I can't repeat your example under the squarefree shell on FF2.0.0.7 on Linux.
            > And I can't reproduce by playing around with 'with' blocks, window subclasses, or eval.call.

            I've just repeated it on FF2.0.0.7 on Linux. For all the tests I've
            done on both, I haven't yet seen any difference between FF on Linux
            vs. Mac. Ben's msg led to some more experiments:

            When I try this using the standalone squarefree shell page at
            http://www.squarefree.com/shell/shell.html I don't get the peculiar
            behavior. It only happens when I use the squarefree shell bookmarklet
            available from http://www.squarefree.com/bookmarklets/webdevel.html .
            When using the bookmarklet, it does open the shell up in a different
            window from the one it's examining. The mystery window from my example
            is the bookmarklet's new window. Typing

            function foo() {return this;}
            foo.call(null).close()

            into the bookmarklet's shell does cause it to close itself.

            --
            Cheers,
            --MarkM



          • Mike Samuel
            ... err assigning window to this - assigning window to this.window cross-domain thing though. window s are manipulable across domain since a
            Message 5 of 13 , Oct 10, 2007
              On 10/10/2007, Mike Samuel <mikesamuel@...> wrote:
              The reason for this is in the first line of the bookmarklet
                  with(window.open(...)) { ... }

              Each window object has an eponymous property, 'window'.

              This 'with' block causes apparent globals to instead be interpreted as properties of the opened window, so this may still be the window that was in focus when you clicked the bookmark, but this.window !== this, since this.window is resolved as a property of the window.

              I tried deleting the window and assigning window to this, but rerunning it doesn't change behavior.  I think that may be a

              err assigning window to this -> assigning window to this.window
               

              cross-domain thing though.  window's are manipulable across domain since a window needs to be able to set a frame's location, but they don't allow setting of arbitrary properties such as "window" cross-domain.

              mike





              On 10/10/2007, Mike Samuel < mikesamuel@...> wrote:
              To make sure I'm clear, you're using the square free bookmarklet (the first entry, [shell], at http://www.squarefree.com/bookmarklets/webdevel.html ) not http://www.squarefree.com/shell/shell.html.

              And then you do
                function foo() { print(this); print(this === window); }
                foo.call(undefined)
              and you get the output
                [Window]
                false
              ?

              I can repeat using the squarefree bookmarklet, but not the shell webpage.







              On 10/10/2007, Mark S. Miller <erights@...> wrote:

              On 10/9/07, Mike Samuel <mikesamuel@...> wrote:
              > I can't repeat your example under the squarefree shell on FF2.0.0.7 on Linux.
              > And I can't reproduce by playing around with 'with' blocks, window subclasses, or eval.call.

              I've just repeated it on FF2.0.0.7 on Linux. For all the tests I've
              done on both, I haven't yet seen any difference between FF on Linux
              vs. Mac. Ben's msg led to some more experiments:

              When I try this using the standalone squarefree shell page at
              http://www.squarefree.com/shell/shell.html I don't get the peculiar
              behavior. It only happens when I use the squarefree shell bookmarklet
              available from http://www.squarefree.com/bookmarklets/webdevel.html .
              When using the bookmarklet, it does open the shell up in a different
              window from the one it's examining. The mystery window from my example
              is the bookmarklet's new window. Typing

              function foo() {return this;}
              foo.call(null).close()

              into the bookmarklet's shell does cause it to close itself.

              --
              Cheers,
              --MarkM




            • Mike Samuel
              The below causes the same symptoms in both squarefree shells: var f = document.createElement( iframe ); document.body.appendChild(f); with (f.contentWindow) {
              Message 6 of 13 , Oct 10, 2007
                The below causes the same symptoms in both squarefree shells:
                      var f = document.createElement('iframe');
                      document.body.appendChild(f);
                      with (f.contentWindow) {
                        (function foo() { alert(this + ' : ' + (this === window)); }).call(null);
                      }

                If the goal is to detect at the beginning of a function body whether `this` is the global scope, I don't think there's any underlying equivalence between between 'this' and 'window' in a normal browser environment, but it does raise questions for applications that execute javascript cross-frame.

                mike


                On 10/10/2007, Mike Samuel <mikesamuel@...> wrote:


                On 10/10/2007, Mike Samuel < mikesamuel@...> wrote:
                The reason for this is in the first line of the bookmarklet
                    with(window.open(...)) { ... }

                Each window object has an eponymous property, 'window'.

                This 'with' block causes apparent globals to instead be interpreted as properties of the opened window, so this may still be the window that was in focus when you clicked the bookmark, but this.window !== this, since this.window is resolved as a property of the window.

                I tried deleting the window and assigning window to this, but rerunning it doesn't change behavior.  I think that may be a

                err assigning window to this -> assigning window to this.window
                 

                cross-domain thing though.  window's are manipulable across domain since a window needs to be able to set a frame's location, but they don't allow setting of arbitrary properties such as "window" cross-domain.

                mike





                On 10/10/2007, Mike Samuel <mikesamuel@...> wrote:
                To make sure I'm clear, you're using the square free bookmarklet (the first entry, [shell], at http://www.squarefree.com/bookmarklets/webdevel.html ) not http://www.squarefree.com/shell/shell.html.

                And then you do
                  function foo() { print(this); print(this === window); }
                  foo.call(undefined)
                and you get the output
                  [Window]
                  false
                ?

                I can repeat using the squarefree bookmarklet, but not the shell webpage.







                On 10/10/2007, Mark S. Miller <erights@...> wrote:

                On 10/9/07, Mike Samuel <mikesamuel@...> wrote:
                > I can't repeat your example under the squarefree shell on FF2.0.0.7 on Linux.
                > And I can't reproduce by playing around with 'with' blocks, window subclasses, or eval.call.

                I've just repeated it on FF2.0.0.7 on Linux. For all the tests I've
                done on both, I haven't yet seen any difference between FF on Linux
                vs. Mac. Ben's msg led to some more experiments:

                When I try this using the standalone squarefree shell page at
                http://www.squarefree.com/shell/shell.html I don't get the peculiar
                behavior. It only happens when I use the squarefree shell bookmarklet
                available from http://www.squarefree.com/bookmarklets/webdevel.html .
                When using the bookmarklet, it does open the shell up in a different
                window from the one it's examining. The mystery window from my example
                is the bookmarklet's new window. Typing

                function foo() {return this;}
                foo.call(null).close()

                into the bookmarklet's shell does cause it to close itself.

                --
                Cheers,
                --MarkM





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