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 tabs not ajax) then suddenly my whole website loads inside the tab.
i am using the standard code from the jquery ui tabs demo page.
<div id="productTabs">
<ul>
<li><a href="#tabDescription">Description</a></li>
<li><a href="#tabSpecs">Specifications</a></li>
<li><a href="#tabReviews">Reviews</a></li>
<li><a href="#tabDownloads">Downloads</a></li>
</ul>
<div id="tabDescription">test</div>
<div id="tabSpecs">test</div>
<div id="tabReviews">test</div>
<div id="tabDownloads">Sorry, no downloads available for this product.</div>
</div>
<script type="text/javascript">jQuery(document).ready(function(){jQuery("#productTabs").tabs();});</script>
But, i have a lot of other javascript around the site, just wondering if anyone has seen this before.
Many thanks
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.
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.