You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ui.tabs _isLocal fails if url contains username:password@ #2213
Sorry, I'm not a JavaScript dev. The function is depending on username + password being in the url, so a 1:1 example with any code plattform is unlikely to work.
The code in latest git seems to be the same. The culprit is that the anchor and location can have different values for the same URL.
I understand but we cannot do much without a test case.
One thing you may be able to help with is saying whether jQuery UI 1.12.1 exhibits the same issue. You can find links to all releases on https://releases.jquery.com.
It's not clear to me what the JS Bin is supposed to show. Can you use the stock version of jQuery UI without repeating its source in the JS pane and explain exactly what you expect to happen in this test case and what is happening instead?
It's not clear to me what the JS Bin is supposed to show. Can you use the stock version of jQuery UI without repeating its source in the JS pane and explain exactly what you expect to happen in this test case and what is happening instead?
The way browser and JS bin work, make it impossible to reproduce it (at least for me). I cannot call JS bin like https://user:password@jsbin.com.
The problem is quite easy:
anchor.href behaves differently than location.href - it just does not contain the user:password part.
#tabs- links causes the whole page to be reloaded for ever on the tabs :(
I am on 1.13.2 build
Same issue with 1.12.1
When I copy the URL, remove the "username:password@" part and paste it on it on the browser, then it works as expected.
My (bad hack) solution is to open the page through a popup, with an absolute link and without the credentials on it (not needed when already authenticated)
Activity
mgol commentedon Mar 5, 2024
Thanks for the report. Does the issue you describe exist when jQuery UI 1.12.1 is used or only with jQuery UI 1.13.0 or newer?
Also, please provide a runnable test case on a platform like JS Bin.
IAMJDA commentedon Mar 13, 2024
Sorry, I'm not a JavaScript dev. The function is depending on username + password being in the url, so a 1:1 example with any code plattform is unlikely to work.
The code in latest git seems to be the same. The culprit is that the anchor and location can have different values for the same URL.
mgol commentedon Mar 13, 2024
I understand but we cannot do much without a test case.
One thing you may be able to help with is saying whether jQuery UI 1.12.1 exhibits the same issue. You can find links to all releases on https://releases.jquery.com.
IAMJDA commentedon Mar 13, 2024
Please check https://jsbin.com/rinenupiba/edit?html,js,output
I faked _isLocal with user+password in location:
locationUrl = location.href.replace("://", "://test:test@").replace( rhash, "" );Rendering of the page will change if you revert that line.
mgol commentedon Mar 14, 2024
It's not clear to me what the JS Bin is supposed to show. Can you use the stock version of jQuery UI without repeating its source in the JS pane and explain exactly what you expect to happen in this test case and what is happening instead?
mgol commentedon Mar 14, 2024
BTW, the
_isLocaldefinition is identical between 1.12.1 & 1.13.2. Whatever the issue is, since it is already in 1.12, given limited team resources it's not likely to be fixed by the UI team; see the project status at https://blog.jqueryui.com/2021/10/jquery-maintainers-update-and-transition-jquery-ui-as-part-of-overall-modernization-efforts/. PRs are welcome if they're not too complex and contain tests.IAMJDA commentedon Mar 15, 2024
The way browser and JS bin work, make it impossible to reproduce it (at least for me). I cannot call JS bin like https://user:password@jsbin.com.
The problem is quite easy:
anchor.href behaves differently than location.href - it just does not contain the user:password part.
mgol commentedon Mar 15, 2024
OK, my last comment about issues shared with 1.12 still stands, though.
Pascal76 commentedon Mar 17, 2024
Same issue here :
#tabs- links causes the whole page to be reloaded for ever on the tabs :(
I am on 1.13.2 build
Same issue with 1.12.1
When I copy the URL, remove the "username:password@" part and paste it on it on the browser, then it works as expected.
My (bad hack) solution is to open the page through a popup, with an absolute link and without the credentials on it (not needed when already authenticated)
Tabs: Support URL-based credentials
mgol commentedon Mar 26, 2025
Fixed in PR #2345.
Tabs: Support URL-based credentials
Tabs: Support URL-based credentials
Tabs: Support URL-based credentials