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
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 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.
Fixesgh-2344Closesgh-2345
Ref gh-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
0 commit comments