TWTR.Widget throws "unsafe javascript attempt to access frame" for search

[VirtualDevelop]

Hello,
I have been using the TWTR.Widget for a long time on my production site. Early this week, everything was working successfully. Today, the widget is throwing the exception “Unsafe JavaScript attempt to access frame with URL https://api.twitter.com/xd_receiver.html from frame with URL about:blank. Domains, protocols and ports must match.”.

Does anyone know why this would start happening? I’ve checked our internal version control system, and nothing has changed.

I would give an example of the error on my site, but the entire site is behind a paywall. Here is the script code:

  <div id="TimelineWrapper" style="position: static;">
    <script>
      var oTWTR = new TWTR.Widget({
        version: "2",
        type: "search",
        search: g_cShowDefaultValue,
        interval: 5000,
        rpp: g_oTwitterParams.iSocialMediaTwitterRPP,
        title: g_cMessages["SearchingFor"],
        subject: g_cShowDefaultValue,
        footer: g_cMessages["Join"],
        width: 'auto',
        height: g_iHeight,
        theme: g_oTwitterColors, 
        features: {
          scrollbar: true,
          loop: true,
          live: true,
          hashtags: true,
          timestamp: true,
          avatars: g_oTwitterParams.bSocialMediaTwitterDisplayAvatars,
          fullscreen: false,
          toptweets: false,
          favs: false,
          behavior: g_oTwitterParams.cSocialMediaTwitterBehavior
        }
      });
    </script>
  </div>

Thank you,

Chris

[PSTPL_India]

I am also getting same error suddenly.

[quantumpotato]

Also getting this. Anyone know why?

[VirtualDevelop]

Good day,
I’ve been doing research on this and found out a little (undocumented) tricky bit. If you are using the _play method on the TWTR.Widget, you MUST call the start method first. I believe that my issue was a timing issue where the dymanic loading of various things caused _play to be called before start (caused by an infrastructure change). When I ensure that start is called first, the error does not happen. When I ensure that start is never called, the error always happens.

Hope this helps,
Chris

[niall]

[niall]