Tabs: Properly handle decoded/encoded anchor hashes & panel IDsHEADmain

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.

Fixes gh-2344
Closes gh-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 files changed, 0 insertions, 0 deletions