Search and Top Navigation
#9984 closed bug (notabug)
Opened April 16, 2014 10:10AM UTC
Closed April 16, 2014 12:13PM UTC
Last modified April 16, 2014 02:05PM UTC
Page reloads itself infinitely in tab
| Reported by: | jrooster | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | none |
| Component: | ui.tabs | Version: | 1.10.4 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
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:password@www.mydomain.com/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
Attachments (0)
Change History (4)
Changed April 16, 2014 12:13PM UTC by comment:1
| resolution: | → notabug |
|---|---|
| status: | new → closed |
Changed April 16, 2014 12:44PM UTC by comment:2
Replying to [comment:1 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:password@www.mydomain.com/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!
Changed April 16, 2014 12:55PM UTC by comment:3
Replying to [comment:2 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:foo@whatever.com and jane:bar@whatever.com? 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:password@www.mydomain.com/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.
Changed April 16, 2014 02:05PM UTC by comment:4
Replying to [comment:3 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:foo@whatever.com and jane:bar@whatever.com? 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:pass@www.mydomain.com 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
Those are in fact two different resources. The fact that you're serving identical content is irrelevant.