This project is archived and is in readonly mode.

#1070 ✓resolved
ronin-81857 (at lighthouseapp)

MooTools 1.3 Core fails to load in IE

Reported by ronin-81857 (at lighthouseapp) | November 6th, 2010 @ 10:26 AM | in 2.0 (closed)

I have some ad tags on the page, that sometimes get loaded right before the mootools library itself. The ad tags include some VBScript tags into the page to determine the flash version (or something) when running Internet Explorer. After the VBScript is inserted into the DOM, the "window.Window" property is taken over by the VBScript and seemingly cannot be changed afterwards. Some little script to reproduce:

<html>
  <body>
    <script type="text/javascript">
      document.write('<SCRIPT LANGUAGE=VBScript></SCRIPT\>');
    </script>
    <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/mootools/1.3.0/mootools.js"></script>
  </body>
</html>

Opening this HTML page in Internet Explorer results in the following error: "The object doesn't support this action (line 1310)", which is the following:

this.Window = this.$constructor = new Type('Window', function(){});

Broken down the whole problem can be written as:

<html>
  <body>
    <script type="text/javascript">
      document.write('<SCRIPT LANGUAGE=VBScript></SCRIPT\>');
    </script>
    <script type="text/javascript">
      window.Window = 1;
    </script>
  </body>
</html>

We upgraded to 1.3 about 2 weeks ago. I think the problem does not exist in 1.2.

Comments and changes to this ticket

  • Christoph Pojer

    Christoph Pojer November 9th, 2010 @ 05:43 PM

    • State changed from “new” to “wontfix”

    Unfortunately I don't think there is a way we can fix this. MooTools relies on the "Window" object to wrap "window".

  • ronin-81857 (at lighthouseapp)

    ronin-81857 (at lighthouseapp) November 9th, 2010 @ 05:53 PM

    I really understand your point and I'm not able to come up with a solution for this either. We're seeing a lot of bad ad codes out there and I think this will occur a lot more when 1.3 does really go "into the wild". There are many professional sites using MooTools that rely on advertising.

    What exactly is the reason to wrap 'window' in 'Window'? I can't think of any case that I needed to use 'new Window()' or something equal :)

  • gonchuki

    gonchuki November 11th, 2010 @ 07:41 PM

    ttmails, with all due respect, "professional" sites don't use VBScript. EVER.
    Unless of course they are obviously targeted at Internet Explorer in which case any attempt at playing nice or being standards compliant is futile.

  • ronin-81857 (at lighthouseapp)

    ronin-81857 (at lighthouseapp) November 11th, 2010 @ 07:45 PM

    I totally agree with that. With every character you said. I'm just talking about advertising snippets (javascripts) that you just cannot control. Your marketer provides these snippets and you're not event allowed to change them - which describes just my situation :(

  • Country

    Country November 15th, 2010 @ 09:53 PM

    • Assigned user set to “Christoph Pojer”
    • Tag changed from internet explorer, 1.3, mootools-core to internet explorer, 1.3, mootools-core, patch

    I think I found a fix.

    Just create a global Window variable (with the var keyword) and call Window instead of this.Window on line 1310 (full patch for Browser.js attached).

    It fix the bug under IE7/8 (not tested under IE6, and the bug was not present under IE9beta).

    ttmails, as temporary fix (and for not hacking the Mootools Core), you can create the global Window variable before inserting your Ads. Like this:

    <html>
     <head>
      <script type="text/javascript">
       var Window; // The fix
      </script>
     </head>
     <body>
      <script type="text/javascript">
       document.write('<SCRIPT LANGUAGE=VBScript></SCRIPT\>');
      </script>
      <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/mootools/1.3.0/mootools.js"></script>
     </body>
    </html>
    
  • Christoph Pojer

    Christoph Pojer November 16th, 2010 @ 12:00 AM

    In this case, shouldn't loading MooTools before any other third party libraries just work too?

  • Country

    Country November 16th, 2010 @ 10:32 AM

    Yeah, it works too, but I do not consider this as a solution. MooTools should work the same way if it's loaded at the top or at the bottom of the page.

    I know this is not really a MooTools bug but it occure when MooTools is used with some scripts that can not be controlled by the developper (Ads). And unfortunately this scripts are very common on websites.

  • Christoph Pojer

    Christoph Pojer November 16th, 2010 @ 11:27 AM

    Note that your assumption is incorrect. MooTools requires a clean environment to work. If you are modifying your environment in unexpected ways it is not MooTools fault if it doesn't properly work. Please load MooTools before any other environment modifying scripts. This is the correct way to fix your issue.

  • ronin-81857 (at lighthouseapp)

    ronin-81857 (at lighthouseapp) November 16th, 2010 @ 02:52 PM

    @Country:

    I'm pretty sure I tried this before but your patch does it for me :) Thanks! Works in IE6-8.

    @Christoph:

    Loading MooTools before any other scripts (especially ads) does the trick - but in terms of faster web page loading (e.g. http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without...) scripts need to be at the bottom (and async loaded). Ads (unfortunately) mostly have to be loaded in place because they use document.write().

    Even if Country's code fixes my issue without hacking the core I think a fix in the library would do better to prevent future complaints and hickups for other people using MooTools :) (This is such a simple fix that shouldn't really hurt).

    Anyway, thank you both for taking your time to fix this issue. I hope this can be merged to core or otherwise me and many other people will have to patch mootools with every new version... (Given they can even track down the problem to this bug report ;)

  • Thomas Aylott

    Thomas Aylott November 17th, 2010 @ 06:40 PM

    • State changed from “wontfix” to “open”
    • Milestone set to 1.3.1
    • Assigned user changed from “Christoph Pojer” to “Thomas Aylott”
    • Milestone order changed from “819” to “0”

    We need to ditch this.Foo = … anyway to solve a number of issues, so that change will solve this issue.

    IMHO MooTools Core policy should be that if there's a simple fix we can make to work around an issue that is otherwise incredibly difficult or impossible to solve, we should be willing to consider it.

    I might be willing to propose that as a MooTools Charter amendment.

  • Thomas Aylott

    Thomas Aylott November 17th, 2010 @ 06:41 PM

    • Tag changed from internet explorer, 1.3, mootools-core, patch to internet explorer, 1.3, mootools-core, patch, regression
  • Christoph Pojer

    Christoph Pojer February 23rd, 2011 @ 12:54 PM

    • State changed from “open” to “resolved”
    • Milestone changed from 1.3.1 to 2.0
    • Milestone order changed from “11” to “0”

    the .call(this) will be fixed in 1.3.1, the other issue will get resolved with 2.0 but not earlier.

  • Andrew Sutherland

    Andrew Sutherland March 11th, 2011 @ 11:08 PM

    I got bitten by this today in 1.3.1. We're starting to load all of our scripts asynchronously, and sometimes the ads load first and apparently screw with Window. This happens with and without .call(this).

    Adding a var Window; to the top of the page fixes it, but feels very delicate. What needs to happen to fix this?

  • Andrew Sutherland

    Andrew Sutherland March 11th, 2011 @ 11:15 PM

    Should I worry about this happening to things besides Window? Would var Document, Window, Element, Event; be a better workaround for now? What can i do to help provide a patch? I don't really undesrtand the scope issues we're dealing with. Can you explain why we're doing this.Window?

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

Attachments

Pages