Skip to main content

Search and Top Navigation

#7822 closed bug (worksforme)

Opened October 28, 2011 02:37PM UTC

Closed October 28, 2011 02:44PM UTC

Last modified January 10, 2017 01:53PM UTC

currentPage/isLocal doesn't take into account base href

Reported by: drewwells Owned by:
Priority: minor Milestone: 1.9.0
Component: ui.tabs Version: 1.8.16
Keywords: Cc:
Blocked by: Blocking:
Description

https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.tabs.js#L23

Currently, the URL of the page is being determined via location.href.replace, but this doesn't take into account a base href. As a result, local links ie '#hash' results in loading a foreign document into the page.

An accurate value is found in document.baseURI, but requires Dom lvl3. Padolsey has a decent solution, perhaps a simpler one can be employed. http://james.padolsey.com/javascript/getting-a-fully-qualified-url/

Attachments (0)
Change History (53)

Changed October 28, 2011 02:44PM UTC by scottgonzalez comment:1

resolution: → worksforme
status: newclosed

This does take into account the base href. The base only affects the anchor's href, not the current page's href. Please provide an example that actually breaks.

Changed October 28, 2011 03:20PM UTC by drewwells comment:2

Notice the difference: http://jsbin.com/uzecov/edit#javascript,html

"Relative URIs are resolved to full URIs using a base URI."

http://www.w3.org/TR/html401/types.html#type-uri

So "#ohjesusdontloadapageoverme" will return false from isLocal().

Changed October 28, 2011 03:40PM UTC by scottgonzalez comment:3

All that your test shows is that the base URI is different than the current page. That's pretty obvious, since that's what the base is for. #anything should return false from isLocal if you have a base that's different from the current page because it's a hash to a different page.

Changed October 28, 2011 04:03PM UTC by drewwells comment:4

Yes that's what base href is used for running the page as if external resources are from a different uri. Since isLocal makes assumptions that location.href is used for building uri requests, it fails since location.href has nothing to do with loading resources.

Replying to [comment:3 scott.gonzalez]:

All that your test shows is that the base URI is different than the current page. That's pretty obvious, since that's what the base is for. #anything should return false from isLocal if you have a base that's different from the current page because it's a hash to a different page.

Changed October 28, 2011 04:04PM UTC by drewwells comment:5

Here is a gist showing the issue

https://gist.github.com/1322615

Changed October 28, 2011 04:21PM UTC by scottgonzalez comment:6

_comment0: That gist properly loads the unicorn for the tab content. I'm not sure what you're trying to point out. location.href definitely is definitely related to loading resources. if location.href != anchor.href, then it's not local.1319818923699458

That gist properly loads the unicorn for the tab content. I'm not sure what you're trying to point out. location.href is definitely related to loading resources. if location.href != anchor.href, then it's not local.

Changed October 28, 2011 05:03PM UTC by drewwells comment:7

_comment0: The href is #cool-tab-1... so why would it make an ajax request? At least this should be flagged as 'wontfix' and put on the long list of edge cases for tabs. Or do you disagree that #cool-tab-1 is not a local href?1319821902041876

The href is #cool-tab-1...

At least this should be flagged as 'wontfix' and put on the long list of edge cases for tabs. Or... do you disagree that #cool-tab-1 is not a local href?

Changed October 28, 2011 06:03PM UTC by scottgonzalez comment:8

You don't understand how base URIs work. #cool-tab-1 is not a local href, it's the equivalent of unicorn/#cool-tab-1. Remove the tabs and click the link.

Changed October 28, 2011 06:38PM UTC by drewwells comment:9

What is this when in doubt, insult people? Go take it up with the specs not me, I don't write them.

All relative href tags like "#cool-tab-1" are resolved via the base element. The document's URI is resolved based off the location object. This is a hacky shortcut has confused the two and explains why my demo is broken.

http://htmlhelp.com/reference/html40/head/base.html

http://www.w3.org/TR/html4/struct/links.html#h-12.4.1

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#location

Changed October 28, 2011 07:06PM UTC by scottgonzalez comment:10

_comment0: I don't know what you're trying to prove at this point. You'er stating exactly the same thing I stated. "All relative href tags like "#cool-tab-1" are resolved via the base element." CORRECT! Which means that #cool-tab-1 is NOT LOCAL. It is resolved relative to the base, which is different from the current page. Did you even try what I said to see that the tabs plugin is doing exactly the same thing as what the browser does natively?1319828832455372

I don't know what you're trying to prove at this point. You're stating exactly the same thing I stated. "All relative href tags like "#cool-tab-1" are resolved via the base element." CORRECT! Which means that #cool-tab-1 is NOT LOCAL. It is resolved relative to the base, which is different from the current page. Did you even try what I said to see that the tabs plugin is doing exactly the same thing as what the browser does natively?

Changed October 28, 2011 07:55PM UTC by drewwells comment:11

Yes the link is NOT LOCAL. Changing the base href on a page makes every link NOT LOCAL. I really don't care what the link is, I'm using inline content and this naive 'unobtrusive ajax' feature is half replacing it with remote content. Even if the links are left BLANK, it will still continue trying to fetch content from the base href.

I want to break my content into pieces that can be shown via clicking a tab just like the description says on jQuery UI site. Instead what I get is a widget that cannot have it's ajax features turned off, cannot recognise when content is already in a div on the page when base href has been changed, and can not have it's behavior overridden short of rewriting the proccessTabs method which even if I did would be broken in the current release and probably broken again in the next release.

Changed October 28, 2011 08:00PM UTC by rdworth comment:12

Replying to [comment:9 drewwells]:

What is this when in doubt, insult people?

Let's keep objective and cool-headed. "You don't understand ..." is not an insult[*], it's a statement of fact. Not a fact that you don't understand, but a fact that Scott doesn't believe you understand. Based on what you've said in the discussion, Scott believes you lack some level of understanding of the specification, the behavior of browsers or both. A gentler way to say it would be "I don't believe you understand..." or "I don't think your understanding is correct..." but we're taught in english class "don't start a sentence with 'I think' or 'I believe'; you're the one talking, if you make a statement it's reasonably understood that it's a statement of your own belief, etc. so just come out and say it"


[*] Ok, it might be an insult if it were "You don't understand anything about web development!! Idiot!!1" That's an insult. Scott's not saying that and I'm not saying that, just drawing a contrast.

Changed October 28, 2011 08:02PM UTC by scottgonzalez comment:13

Or you could use proper hrefs in your tabs... Use an absolute or relative URL that actually points at the correct place and it'll work fine. Tabs are doing exactly what they should. <a href="#cool-tab-1"> does not point to <div id="cool-tab-1"> in your page.

Changed April 25, 2012 07:54AM UTC by willy comment:14

I know Tabs do what they should do. But I still want to ask what the good approach is when I meet the same situation. It is really hard to use "proper" hrefs as "http://api.jquery.com/add/" , "http://api.jquery.com/add" and "http://api.jquery.com/add?abc=123" are regarded different in isLocal() but linked to the same page. Or should I change the hrefs every time the page is loaded? Maybe it would be nice if there is an "isLocal" option.

Currently I add a line in isLocal() as workaround :

if ($(anchor).hasClass("local")) return true;

Changed October 11, 2012 12:19AM UTC by scottgonzalez comment:15

#8650 is a duplicate of this ticket.

Changed November 02, 2012 01:01PM UTC by scottgonzalez comment:16

#8768 is a duplicate of this ticket.

Changed November 19, 2012 06:53PM UTC by scottgonzalez comment:17

#8830 is a duplicate of this ticket.

Changed November 19, 2012 09:17PM UTC by scottgonzalez comment:18

#8831 is a duplicate of this ticket.

Changed November 25, 2012 06:29AM UTC by gnarf comment:19

It seems non-trivial to fix this anywhere but inside

isLocal
somehow... I thought about it for a bit. I mean, using
<base>
really messes this up, but if you want to FORCE a tab to be local, there isn't a way to do that currently.

Just my $0.02 - I'm starting to sympathize with this bug.

Changed November 25, 2012 03:16PM UTC by scottgonzalez comment:20

I don't see how this is non-trivial to fix. The users who are running into this problem have to be dealing with <base> day in and day out. They have to user proper URLs on every single link they create, this is no exception. They *MUST* know how to properly generate URLs to link to pages within their app, otherwise they can't create any links at all.

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 <base> 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.

Changed November 25, 2012 06:18PM UTC by mikesherov comment:21

Yeah, what's funny is that frameworks use the base tag specifically to avoid have to PHP to generate absolute urls. The real problem here is the existence of the base tag to begin with!

I too was starting to sympathize with those who run into this "bug", but then I remembered all the times I expected something to work and realized that I should understand the issue deeply first. Matching the spec and what browsers do is the right call here. If the base tag is a problem, then don't use it.

Changed November 26, 2012 02:22AM UTC by scottgonzalez comment:22

#8851 is a duplicate of this ticket.

Changed November 26, 2012 10:10AM UTC by kasakka comment:23

The current implementation doesn't take into account loading tabs in something loaded with AJAX e.g. into a modal dialog. The location.href does not change then, but the REQUEST_URI does change. You would need to feed the AJAX loaded page the URL of the containing page so that the correct links (referring to the page where the modal dialog was opened) can be formed. Using REFERER for this is no good because in IE it doesn't work consistently.

Would adding a simple "forceLocal" option be that big of a deal? I don't see how making development more difficult and more inconsistent (especially since the documentation offers no help with the base tag issue) is going to help anyone. Having users move away from using base tag (and thus having to change a lot of stuff) is going to be more hassle than implementing a simple workaround.

Changed November 26, 2012 03:39PM UTC by scottgonzalez comment:24

#8855 is a duplicate of this ticket.

Changed November 26, 2012 03:42PM UTC by scottgonzalez comment:25

@kasakka Presumably everything you load via ajax is either broken or using absolute URLs. You've opted into using <base>, so you need to use it properly.

Changed November 26, 2012 04:26PM UTC by kasakka comment:26

Replying to [comment:25 scott.gonzalez]:

@kasakka Presumably everything you load via ajax is either broken or using absolute URLs. You've opted into using <base>, so you need to use it properly.

So let's say that my BASE tag href is "http://www.example.com/", I'm currently on page "http://www.example.com/pages/index", which has a button that opens a modal dialog where content is loaded via AJAX from "http://www.example.com/pages/stuff". Inside the pages/stuff page there are two tabs, with links that have HREF "#tab1" and "#tab2".

These evaluate to "http://www.example.com/#tab1" as per the BASE tag. What jQuery UI expects is "http://www.example.com/pages/index/#tab1" aka location.href + tab ID. I could make this work by manually changing pages/stuff's links' HREFs to "pages/index/#tab1" etc, but this would make the pages/stuff page unusable everywhere else but on pages/index. Should I want to load for example a control panel via AJAX on any page, those links would have to be changed to reflect that containing page.

The links are all relative to the base tag, but the AJAX loaded content when processed with PHP would have to know the URL of the containing page. With earlier jQ UI versions this was not necessary as it expected that simple href="#tab1" referred to a local tab so nothing broke.

And this is why there should be a "forceLocal" option. Correct me if I'm doing something completely wrong.

Changed November 26, 2012 04:48PM UTC by scottgonzalez comment:27

Correct me if I'm doing something completely wrong.

You're doing something completely wrong. Just read the previous comments. As I said before, you've opted into using <base>, so you need to use it properly.

Honestly, after a year of explaining this over and over, I'm getting tired of it. The previous comments explain what's going on. We're doing exactly the right thing and we're not going to add a flag to take broken URLs and treat them as if they're correct.

Changed November 27, 2012 09:56AM UTC by kasakka comment:28

With many PHP frameworks, using base always as the root (as in my example) instead of the current page url saves a huge amount of aggravation with pretty much any url the framework generates. I still don't see how making tools harder to use is beneficial to anyone and I bet tickets for this same issue will keep popping up at least until the documentation is updated to explain the issue clearly.

Meanwhile I guess I'll just have to fork jQuery UI tabs and add in a workaround or move to using something else for tabs.

Changed December 27, 2012 06:03PM UTC by scottgonzalez comment:29

#8931 is a duplicate of this ticket.

Changed January 24, 2013 08:35PM UTC by frame1986 comment:30

I just have stumpled on this issue and have read the comments.

In my opinion, if jQuery UI deals with <div/> as anchor replacement you cannot say "we doing everything right, use base properly" because accessing a <div/> is not the common way a browser would handle this fragment.

A developer is expecting that when jQuery UI can handle with <div/> the script is checking that a id exists rather then just checking the href.

So if you give the feature a, you must also implement feature b.

Changed January 24, 2013 09:20PM UTC by scottgonzalez comment:31

_comment0: @frame1986 I have no idea what you're talking about. Where do we use divs as replacements for anchors? If you're talking about the fact that the hash points to a div, that's how HTML works. Hashes don't point to anchors elements, they point to elements based on their name or id.1359062474988495

@frame1986 I have no idea what you're talking about. Where do we use divs as replacements for anchors? If you're talking about the fact that the hash points to a div, that's how HTML works. Hashes don't point to anchor elements, they point to elements based on their name or id.

Changed January 28, 2013 01:31PM UTC by tj.vantoll comment:32

#9022 is a duplicate of this ticket.

Changed January 28, 2013 08:29PM UTC by henk verouden comment:33

I debugged 3 days after changing 1.8.3 to 1.10 en jquery to 1.9 and did finally find out that this is the problem, my use of the basetag. But it seems to be it for over 15 months now in the community. This is unbelievable and seen the discussion it looks that it will not be fixed in the next 15 months. If I must rewrite my framework to not use the basetag, it takes lots and lots of work. That is not an option. The only option is to hack the code or stop with jquery ui. This was more debugging time than writing a small tab set by myself.

I hate hacking, than i can't use the google cdn anymore. Could you please add an workaround? The isLocal class is workable for me.

Changed February 17, 2013 12:05AM UTC by Volfin comment:34

I too have to say I'm rather shocked at the arrogance the 'devs' are showing here. They are the ones that don't seem to understand how a <base href> works. It's just that, the *base* of all URLs on the given page. And that's all, there's nothing else special about it.

if you can resolve http://www.angrydev.com/pages/#tab-1 as being local to http://www.angrydev.com/pages/

There is No reason you shouldn't be able to resolve /#tab-1 as being local to / (with a base href of "http://www.angrydev.com/pages/")

it's the same damn situation. But you're refusing to support it just because it's using a Base HREF. and that is just not even sad, it's ridiculous.

You had no problem doing it up until 1.9.0. So why the hell can't you do it now? Especially when so many have shown it's needed, and so many have given you the code to do it?

Changed February 17, 2013 12:35AM UTC by Volfin comment:35

I will also add that I discovered a workaround that is simpler than any I've seen so far presented.

$("#tabs").tabs({beforeLoad: function( event, ui ) { event.preventDefault(); return; } });

calling with preventDefault() will kill any attempts to load remotely. But it's an all or nothing proposition, unless you add more logic.

Changed February 17, 2013 10:45PM UTC by scottgonzalez comment:36

#9092 is a duplicate of this ticket.

Changed February 18, 2013 04:29AM UTC by tj.vantoll comment:37

Due to the large number of duplicate submissions I felt the need to write up a guide on how to use the base tag and the tabs widget together properly - http://tjvantoll.com/2013/02/17/using-jquery-ui-tabs-with-the-base-tag/. I discuss why the tabs widget does what it does, how to fix your applications correctly, and how to add a JS hack to get things working immediately.

Changed March 25, 2013 01:01PM UTC by scottgonzalez comment:38

#9182 is a duplicate of this ticket.

Changed May 13, 2013 02:57PM UTC by scottgonzalez comment:39

#9288 is a duplicate of this ticket.

Changed August 22, 2013 10:14PM UTC by uvahiker comment:40

_comment0: Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages. It worked fine in my development environment and it did NOT work in a deployed/installed environment. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. \ \ Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20": \ \ function isLocal( anchor ) { \ // clone the node to work around IE 6 not normalizing the href property \ // if it's manually set, i.e., a.href = "#foo" kills the normalization \ anchor = anchor.cloneNode( false ); \ return anchor.hash.length > 1 && \ anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" ); \ } \ \ The addition is the ".replace( /\\s/g, "%20" )" on the end. \ \ Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself \ \ I would request that this fix be added to the jQuery baseline.1377209844397009
_comment1: Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages. It worked fine in my development environment and it did NOT work in a deployed/installed environment. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. (Also, I don't have a <base> tag.) \ \ Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20": \ \ function isLocal( anchor ) { \ // clone the node to work around IE 6 not normalizing the href property \ // if it's manually set, i.e., a.href = "#foo" kills the normalization \ anchor = anchor.cloneNode( false ); \ return anchor.hash.length > 1 && \ anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" ); \ } \ \ The addition is the ".replace( /\\s/g, "%20" )" on the end. \ \ Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself \ \ I would kindly request that this fix be added to the jQuery baseline since it is a simple.1377209899569402
_comment2: Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages. It worked fine in my development environment and it did NOT work in a deployed/installed environment. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. (Also, I don't have a <base> tag.) \ \ Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20": \ \ function isLocal( anchor ) { \ anchor = anchor.cloneNode( false ); \ return anchor.hash.length > 1 && \ anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" ); \ } \ \ The addition is the ".replace( /\\s/g, "%20" )" on the end. \ \ Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself \ \ I would kindly request that this fix be added to the jQuery baseline since it is a simple.1377209920637202
_comment3: Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages. It worked fine in my development environment and it did NOT work in a deployed/installed environment. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. (Also, I don't have a <base> tag.) \ \ Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20": \ \ function isLocal( anchor ) { \ anchor = anchor.cloneNode( false ); \ return anchor.hash.length > 1 && \ anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" ); \ } \ \ The addition is the ".replace( /\\s/g, "%20" )" on the end. \ \ Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself \ \ I would kindly request that this fix be added to the jQuery baseline since it is a simple.1377210038349150
_comment4: Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages. It worked fine in my development environment and it did NOT work in a deployed/installed environment. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. (Also, I don't have a <base> tag.) \ \ Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20": \ \ \ {{{ \ function isLocal( anchor ) { \ anchor = anchor.cloneNode( false ); \ return anchor.hash.length > 1 && \ anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" ); \ } \ }}} \ \ \ The addition is the ".replace( /\\s/g, "%20" )" on the end. \ \ Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself \ \ I would kindly request that this fix be added to the jQuery baseline since it is a simple.1377210158438542
_comment5: Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages. It worked fine in my development environment and it did NOT work in a deployed/installed environment. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. (Also, I don't have a <base> tag.) \ \ Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20": \ \ \ {{{ \ function isLocal( anchor ) { \ anchor = anchor.cloneNode( false ); \ return anchor.hash.length > 1 && \ anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" ); \ } \ }}} \ \ \ The addition is the ".replace( /\\s/g, "%20" )" on the end. \ \ Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself \ \ I would kindly request that this fix be added to the jQuery baseline since it is simple.1377210270490098

Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages with local links (see jQueryUI demo). It worked fine in my development environment and it did NOT work in a deployed/installed environment. When it didn't work, the entire page loaded into the tabs container. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. (Also, I don't have a <base> tag.)

Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20":

function isLocal( anchor ) {
    anchor = anchor.cloneNode( false );
    return anchor.hash.length > 1 &&
		anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" );
}

The addition is the ".replace( /\\s/g, "%20" )" on the end.

Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself

I would kindly request that this fix be added to the jQuery baseline since it is simple.

Changed August 23, 2013 02:02AM UTC by tj.vantoll comment:41

Replying to [comment:40 uvahiker]:

Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages with local links (see jQueryUI demo). It worked fine in my development environment and it did NOT work in a deployed/installed environment. When it didn't work, the entire page loaded into the tabs container. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. (Also, I don't have a <base> tag.) Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20":
> function isLocal( anchor ) {
>     anchor = anchor.cloneNode( false );
>     return anchor.hash.length > 1 &&
> 		anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" );
> }
> 
The addition is the ".replace( /\\s/g, "%20" )" on the end. Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself I would kindly request that this fix be added to the jQuery baseline since it is simple.

This was fixed in 1.10, see #8896.

Changed August 23, 2013 04:03AM UTC by uvahiker comment:42

Replying to [comment:41 tj.vantoll]:

Replying to [comment:40 uvahiker]: > Here is my setup: using jQuery 1.8.2 and jQuery UI 1.9.0 with HTML pages running in WebKit inside of a QT application. I am using tabs on one of my pages with local links (see jQueryUI demo). It worked fine in my development environment and it did NOT work in a deployed/installed environment. When it didn't work, the entire page loaded into the tabs container. All of the necessary files were present. Again, it worked in one case and not the other. What is the difference? The installed environment was under the "Program Files (x86)" directory which contains spaces. That was the difference. Period. (Also, I don't have a <base> tag.) > > Here is my fix: In jQuery UI 1.9.0, the isLocal() function is defined above the "$.widget( "ui.tabs", {" line. Replace spaces with "%20": > > >
> > function isLocal( anchor ) {
> >     anchor = anchor.cloneNode( false );
> >     return anchor.hash.length > 1 &&
> > 		anchor.href.replace( rhash, "" ) === location.href.replace( rhash, "" ).replace( /\\s/g, "%20" );
> > }
> > 
> > > The addition is the ".replace( /\\s/g, "%20" )" on the end. > > Credit to: user "MV." on StackOverflow: http://stackoverflow.com/questions/13837304/jquery-ui-non-ajax-tab-loading-whole-website-into-itself > > I would kindly request that this fix be added to the jQuery baseline since it is simple. This was fixed in 1.10, see #8896.

Thank you for the response. I haven't tested it with 1.10 yet (I'll upgrade after our release), but I'm sure it works if another bug was filed. I just wanted to provide more info for other developers running into this issue.

Changed September 09, 2013 10:45PM UTC by ladamson comment:43

Replying to [comment:41 tj.vantoll]:

This was fixed in 1.10, see #8896.

A note for others: that "fixed" message applies to a different issue reported by uvahiker in this thread, not the one this bug report was originally about.

My take on the original issue is:

  • The devs are correct that isLocal() called for #hash when a BASE element is present should return False.
  • However, the users are not actually asking to change that behavior. What the users actually want is a way to tell Tabs: "treat the href value as an ID, even if it looks like a URL". That seems reasonable, does not change the correct default behavior, and does not go against any specifications. It's just telling Tabs how you'd like it to behave on a specific page.

Given that, this should not be a bug report, but should be a feature request for a "treatAs" option with the values: "auto", "remote", "local", with "auto" being the default and having the current behavior.

Changed October 04, 2013 12:05PM UTC by sneps comment:44

please add the "treatAs" option... or a "noBaseTag" option... that would be very nice for everyone and you can keep your basetag standards when the option is not set...

Changed October 04, 2013 12:19PM UTC by scottgonzalez comment:45

#9587 is a duplicate of this ticket.

Changed October 21, 2013 08:46PM UTC by cwingrav comment:46

This took me a long time to figure out too. Let me explain, as I think the devs and users are ALL correct, in different ways.

UI-DEVS: "This links to the content AS INTENDED. 'nuff said."

UI-USERS: "This does not link to the div. Problem."

Problem: I think the problem is that the UI devs see the anchor tags as linking to both on-page and off-page content. A feature since it can load all kinds of things. The users however can't figure out why the href, which LOOKS like like a jQuery selector, isn't going to the div the selector of the anchor points too. Seems like the dual use of in-page links coming from both 'name' and 'id' attributes is what is screwing this up. That, and not even realizing that tabs can grab remote content.

Proposed Solution: I think merely changing the example code to demonstrate: a local div, a div using remote content and a fully qualified URL to a local div with a bit of text mentioning the base URL issue. For instance, I didn't even realize until this issue appeared, that I can load remote content in a tab.

Comments?

Changed October 21, 2013 11:10PM UTC by scottgonzalez comment:47

Replying to [comment:46 cwingrav]:

Proposed Solution: I think merely changing the example code to demonstrate: a local div, a div using remote content and a fully qualified URL to a local div with a bit of text mentioning the base URL issue. For instance, I didn't even realize until this issue appeared, that I can load remote content in a tab.

We already have this: http://jqueryui.com/tabs/#ajax

And the problem is that most people using <base> don't want to take the time to write the correct URL. You'll notice that everyone else complaining in this ticket isn't complaining about a lack of documentation (there is no such lack), they're all asking for a way to change what the anchor is referencing.

Changed October 22, 2013 03:49PM UTC by cwingrav comment:48

Thanks for the quick response. I appreciate it.

Replying to [comment:47 scott.gonzalez]:

Replying to [comment:46 cwingrav]: > Proposed Solution: I think merely changing the example code to demonstrate: a local div, a div using remote content and a fully qualified URL to a local div with a bit of text mentioning the base URL issue. For instance, I didn't even realize until this issue appeared, that I can load remote content in a tab. We already have this: http://jqueryui.com/tabs/#ajax

I never noticed that example since it's not on the 1st page, but under the ajax link... one of 8 links on the right, and since I'm not using Ajax with my tab, I never clicked it. It would be more helpful if one of the tabs on the 1st page demonstrated this loading of off-page content. It's not a bug at all. I realize that. It's a misunderstanding of how it works. That's what's tripping people like me up.

And the problem is that most people using <base> don't want to take the time to write the correct URL. You'll notice that everyone else complaining in this ticket isn't complaining about a lack of documentation (there is no such lack), they're all asking for a way to change what the anchor is referencing.

Hmm, maybe, but not me. For me, I thought it only loaded content on-page and the href of the tab was a link to an id of the div that was selected by the tab (and why I thought it was odd that you all did it this way... which you didn't I now know). I didn't know it had anything to do with a URL at all, even though it was an href. This was a misunderstanding on my part, because the href in the example code looked like a selector. But, I think if a single example in the front page demonstrated this, it would have saved me about 45 minutes.

Cheers and keep up the good work.

Changed December 13, 2013 12:48PM UTC by scottgonzalez comment:49

#9712 is a duplicate of this ticket.

Changed November 20, 2014 05:34PM UTC by scottgonzalez comment:50

#10702 is a duplicate of this ticket.

Changed October 11, 2016 12:08AM UTC by scottgonzalez comment:51

#15077 is a duplicate of this ticket.

Changed November 30, 2016 04:24PM UTC by scottgonzalez comment:52

#15107 is a duplicate of this ticket.

Changed January 10, 2017 01:45PM UTC by OzoneGrif comment:53

_comment0: This bug should not be closed. It's a big issue and the developer of the plugin doesn't understand what's going on. \ \ jQuery.tabs() should *not* use the href attribute for local Tabs because it conflicts with the <base> tag. \ \ Basically, you can't use local Tabs if there is a <base> tag on your page. The tabs() module is not working properly at all.1484056387346631
_comment1: This bug should not be closed. It's a big issue and the developer of the plugin doesn't understand what's going on. \ \ jQuery.tabs() should *not* use the href attribute for local Tabs because it conflicts with the <base> tag. \ \ Basically, you can't use local Tabs if there is a <base> tag on your page. The tabs() module is not working properly at all. \ \ \ I did a test by changing a line in the tabs() module code : \ \ anchorUrl = anchor.href.replace( rhash, "" ); \ locationUrl = document.getElementsByTagName('base')[0].href.replace( rhash, "" ); \ \ instead of \ \ anchorUrl = anchor.href.replace( rhash, "" ); \ locationUrl = location.href.replace( rhash, "" ); \ \ This fixed the bug. You should look in this direction.1484056414022331

This bug should not be closed. It's a big issue and the developer of the plugin doesn't understand what's going on.

jQuery.tabs() should *not* use the href attribute for local Tabs because it conflicts with the <base> tag.

Basically, you can't use local Tabs if there is a <base> tag on your page. The tabs() module is not working properly at all.

I did a test by changing a line in the tabs() module code :

anchorUrl = anchor.href.replace( rhash, "" );
locationUrl = document.getElementsByTagName('base')[0].href.replace( rhash, "" );

instead of

anchorUrl = anchor.href.replace( rhash, "" );
locationUrl = location.href.replace( rhash, "" );

This fixed the bug. You should look in this direction.