Page reloads itself infinitely in tab

[jrooster]

Problem: Tabs load the complete page into a panel infinitely (see closed but not solved bugs #7822 or #8931).

The discussion gave me the hint to take a look at the function isLocal() in the tabs widget code and simply compare "anchor.href" and "location.href" because I've the same weird reloading problem (in Firefox 20-28) on my development server as described by others in the bugs 7822 and 8931.

The solution is simple. Because of a password protection via .htaccess and .htpasswd on my development server Firefox defines

anchor.href as "​http://username:[email protected]/index.php" but
location.href as "​http://www.mydomain.com/index.php"

The isLocal() function identifies these two links correctly as to different URIs allthough their targets are identical.

My solution: Please enhance the isLocal() function and strip the leading "username:password@" from the anchor's href attribute before compare it with the location.href .

E.g. like this (in function isLocal(), line 11540, jQuery UI 1.10.4):

function isLocal( anchor ) {
    // support: IE7
    // IE7 doesn't normalize the href property when set via script (#9317)
    anchor = anchor.cloneNode( false );

    // Bugfix: remove possible "username" and "password" from URI, if page is protected via .htpasswd
    anchor.href = anchor.href.replace(/(http(s)?\:\/\/)(.*\:.*\@)?/g, '$1')

    return anchor.hash.length > 1 &&
        decodeURIComponent( anchor.href.replace( rhash, "" ) ) ===
        decodeURIComponent( location.href.replace( rhash, "" ) );
})

Thanx, Joe

[Scott González]

Those are in fact two different resources. The fact that you're serving identical content is irrelevant.

[jrooster]

Replying to scott.gonzalez:

Those are in fact two different resources. The fact that you're serving identical content is irrelevant.

... sorry, I don't understand your answer. My proposed solution for the function isLocal() in tabs widget solves the problem, that is reported in bug #8931 (see comment 11!). The reason is - as I described - that Firefox notes the same URI in different ways whether a page is protected by .htpasswd or not.

The URIs in Firefox:
​http://username:[email protected]/index.php (.htpasswd protected page)
​http://www.mydomain.com/index.php (same page, not protected by .htpasswd)

point to the same resource/ page/ content! The tab shouldn't care about if a page is password protected or not. So the anchor.href has to be cleaned from username and password before it is compared with location.href in function isLocal() for a correct result!

The jQuery UI tab function isLocal() results different values for the same URI whether the page behind the URI is protected by .htpasswd or not. That's IMHO a bug!

[Scott González]

Replying to jrooster:

My proposed solution for the function isLocal() in tabs widget solves the problem

No it doesn't. It merely works around something that you think is incorrect, which is in fact quite important. Would you feel the same way if the URLs you were talking about were john:fo[email protected] and jane:[email protected]? I certainly hope not.

The reason is - as I described - that Firefox notes the same URI in different ways whether a page is protected by .htpasswd or not.

And those are in fact different pages. If you don't believe me, load ​http://jsbin.com/wikewumi/1 and click the different links while watching the network tab.

The URIs in Firefox:
​http://username:[email protected]/index.php (.htpasswd protected page)
​http://www.mydomain.com/index.php (same page, not protected by .htpasswd)

point to the same resource/ page/ content!

They point to different resources which resolve to the same file on your server which happens to serve the same content.

[jrooster]

Replying to scott.gonzalez:

No it doesn't. It merely works around something that you think is incorrect, which is in fact quite important. Would you feel the same way if the URLs you were talking about were john:fo[email protected] and jane:[email protected]? I certainly hope not.

... ok, I understand your arguments. The current URI handling may be 100% correct but causes sometimes problems in real life usage (e.g. when you use login data directly in links like ​http://user:[email protected] in Firefox). So if this is not a bug, I'll suggest that you build in an option for tab initialization like

$('#tabs').tabs({
	cleanLoginDataInTabURI : true	// default: false
});

As I read in bug #8931 there could be a need for a solution. Just my 42 Cents.

Thanks and best regards, Joe