jQuery UI non ajax tab loading whole website into itself?

Question

Having a large problem with jQuery Tabs.

Im trying to load the tabs on my sites product page... When the page loads i see that tabs content for a second (standard html t

Answer 1

You are right, it's the BASE meta tag. This is a problem you'll face with the latest version of jQuery UI (1.9), it worked with 1.8. There were lot of changes to the Tabs API, but nothing seemed to cause this problem until you check the jQuery source code.

1. The BASE meta tag instructs the browser to transform the href attribute in the tabs (that you use as reference for the tabs content) from hash+id to a full URL (using your BASE tag value). That's the expected behavior.
2. Previous versions of the Tabs UI would try hard to guess if the href was really remote or not, spliting the href tab value, then comparing it to the current URL AND to the BASE tag, then deciding if it was actually local.
3. Latest version of jQuery doesn't check the BASE tag value.
4. So, the latest version, when used with BASE meta tag, will try to load the tab content using Ajax, reloading themselves (or whatever is in the BASE URL).

This is what jQuery UI Tabs used in version 1.8.24:

    this.anchors.each(function( i, a ) {
      var href = $( a ).attr( "href" );
      // For dynamically created HTML that contains a hash as href IE < 8 expands
      // such href to the full page url with hash and then misinterprets tab as ajax.
      // Same consideration applies for an added tab with a fragment identifier
      // since a[href=#fragment-identifier] does unexpectedly not match.
      // Thus normalize href attribute...
      var hrefBase = href.split( "#" )[ 0 ],
        baseEl;
      if ( hrefBase && ( hrefBase === location.toString().split( "#" )[ 0 ] ||
          ( baseEl = $( "base" )[ 0 ]) && hrefBase === baseEl.href ) ) {
        href = a.hash;
        a.href = href;
      }

This is what jQuery UI Tabs uses in version 1.9.2:

    function isLocal( anchor ) {
      return anchor.hash.length > 1 &&
        anchor.href.replace( rhash, "" ) ===
          location.href.replace( rhash, "" )
            // support: Safari 5.1
            // Safari 5.1 doesn't encode spaces in window.location
            // but it does encode spaces from anchors (#8777)
            .replace( /\s/g, "%20" );
     }

The code is organized differently because of the extensive rewriting of the Tabs code, but you can get the idea (The $( "base" )[ 0 ] is the BASE meta tag value).

So far I haven't found any way to tell the tabs "this is local, don't use Ajax" using the normal tabs API. What I can offer you is what I did to quick fix it in the mean time (while I ask, recheck and maybe fill a bug report): a hack.

    function isLocal( anchor ) {
      return anchor.hash.length > 1 &&
        ( (anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\s/g, "%20" )) ||
          (anchor.href.replace( rhash, "" ) === $( "base" )[ 0 ].href));
    }

This is the newer version plus the check done in the previous version.

In a non-minified copy of the latest jQuery UI, replace the isLocal function with that. Then minify the file. Replace the original version. Test.

It worked for me in Firefox (17.0.1) and Chromium (18.0.1025.168).

The disadvantage is that you cannot use a third-party copy (from a CDN). For me that is not a problem as most of my applications are used in intranets.

If anybody finds a better solution or is aware of how to do it without hacking the jQuery UI code, please let us know.

UPDATE: I found this bug report (with several duplicates): http://bugs.jqueryui.com/ticket/7822 I was tempted to add my own comment but it seems the jQuery developers won't "fix" this as they consider the problem is elsewhere. Quote from the bugtracker:

I don't see how this is non-trivial to fix...

Here's the trivial, dynamic PHP implementation: 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] . '#foo'.

It's also fairly trivial to fix this in JavaScript, but I won't provide sample code because that is the wrong place to be fixing this and should be highly discouraged. The behavior of links are clearly defined and consistent across all browsers. There is absolutely no reason people should be using incorrect URLs and then hacking around them in JavaScript.

Finally, it's important to note that "fixing" this would mean breaking the correct behavior for everyone who uses properly. Keep in mind that this was fixed because people with proper URLs were running into the real bug that existed in the old code.