Tabs: Properly handle decoded/encoded anchor hashes & panel IDs, support URL-based credentials #2345
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
mgol changed the title mgol force-pushed the tabs-url-handling branch 4 times, most recently from cc0038d to 2a4e6b4 Compare tagliala added a commit to activeadmin/activeadmin that referenced this pull request Mar 29, 2025
When credentials are provided directly in the URL, e.g.: https://username:password@www.example.com/ `location.href` strips out the auth part, but anchor links contain them, making our `isLocal` computation broken. This fixes it by only looking at `origin`, `pathname` & `search`. Fixes jquerygh-2213 Closes jquerygh-2345
Prior to jQuery UI 1.14.1, hashes in anchor hrefs were used directly. In jquerygh-2307, that was changed - by decoding - to support more complex IDs, e.g. containing emojis which are automatically encoded in `anchor.hash`. Unfortunately, that broke cases where the panel ID is decoded as well. It turns out the spec mandates checking both. In the "scrolling to a fragment" section of the HTML spec[^1]. That uses a concept of document's indicated part[^2]. Slightly below there's an algorithm to compute the indicated part[^3]. The interesting parts are steps 4 to 9: 4. Let potentialIndicatedElement be the result of finding a potential indicated element given document and fragment. 5. If potentialIndicatedElement is not null, then return potentialIndicatedElement. 6. Let fragmentBytes be the result of percent-decoding fragment. 7. Let decodedFragment be the result of running UTF-8 decode without BOM on fragmentBytes. 8. Set potentialIndicatedElement to the result of finding a potential indicated element given document and decodedFragment. 9. If potentialIndicatedElement is not null, then return potentialIndicatedElement. First, in steps 4-5, the algorithm tries the hash as-is, without decoding. Then, if one is not found, the same is attempted with a decoded hash. This change replicates this logic by first trying the hash as-is and then decoding it. Fixes jquerygh-2344 Closes jquerygh-2345 Ref jquerygh-2307 [^1]: https://html.spec.whatwg.org/#scrolling-to-a-fragment [^2]: https://html.spec.whatwg.org/#the-indicated-part-of-the-document [^3]: https://html.spec.whatwg.org/#select-the-indicated-part
mgol added a commit that referenced this pull request Mar 31, 2025
When credentials are provided directly in the URL, e.g.: https://username:password@www.example.com/ `location.href` strips out the auth part, but anchor links contain them, making our `isLocal` computation broken. This fixes it by only looking at `origin`, `pathname` & `search`. Fixes gh-2213 Closes gh-2345
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
1. Tabs: Support URL-based credentials
When credentials are provided directly in the URL, e.g.:
location.hrefstrips out the auth part, but anchor links contain them, makingour
isLocalcomputation broken. This fixes it by only looking atorigin,pathname&search.Fixes gh-2213
2. Tabs: Properly handle decoded/encoded anchor hashes & panel IDs
Prior to jQuery UI 1.14.1, hashes in anchor hrefs were used directly. In
gh-2307, that was changed - by decoding - to support more complex IDs, e.g.
containing emojis which are automatically encoded in
anchor.hash.Unfortunately, that broke cases where the panel ID is decoded as well.
It turns out the spec mandates checking both. In the "scrolling to a fragment"
section of the HTML spec1. That uses a concept of document's indicated
part2. Slightly below there's an algorithm to compute the indicated part3.
The interesting parts are steps 4 to 9:
4. Let potentialIndicatedElement be the result of finding a potential
indicated element given document and fragment.
5. If potentialIndicatedElement is not null, then return
potentialIndicatedElement.
6. Let fragmentBytes be the result of percent-decoding fragment.
7. Let decodedFragment be the result of running UTF-8 decode without BOM on
fragmentBytes.
8. Set potentialIndicatedElement to the result of finding a potential indicated
element given document and decodedFragment.
9. If potentialIndicatedElement is not null, then return
potentialIndicatedElement.
First, in steps 4-5, the algorithm tries the hash as-is, without decoding. Then,
if one is not found, the same is attempted with a decoded hash.
This change replicates this logic by first trying the hash as-is and then
decoding it.
Fixes gh-2344
Ref gh-2307
Footnotes
https://html.spec.whatwg.org/#scrolling-to-a-fragment ↩
https://html.spec.whatwg.org/#the-indicated-part-of-the-document ↩
https://html.spec.whatwg.org/#select-the-indicated-part ↩