This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1463 [details] Test cases: A file with 3 sets of tests. Problem: 1 For percent-encoded bytes in an activated link, some browsers try a literal match for the raw, percent-encoded string before they try a ”semantic” match for the string of decoded characters. 2 When this happens, the URL can target two different destinations - e.g. an idref that matches the raw percent-encoded string plus an idref that matches the decoded characters. If the raw string exists in an idref, it will ”win” over the an idref with the decoded string. 3 The URL spec clarify whether testing for a literal match before before testing for a decoded match is permitted. Affected browsers: (*Not* affected: Firefox and IE11.) * Blink: problem manifests itself only if author uses percent-encoded strings as URL value (e.g. href='#%C3%A5' or href="#%61"). * Webkit: problem manifests itself even for directly typed URLs when the code points are higher than U+009F (in which case the coded points are converted to percent-encoded bytes by the URL parser). Affects href="å" + also href="å" href="å" Example - how to replicate: 1) To a document with this fragment, <div id="å">Fragment 1.</div> 2) add the following two links, a) <a href='#å' >Link A.</a> - directly typed; b) <a href='#%C3%A5'>Link B.</a> - percentage encoded; 3) and activate Link A + Link B to verify that each targets Fragment 1 4) Now, add yet another fragment: <div id='%C3%A5'>Fragment 2.</div> 4) Activate Link A and Link B, and check which fragment is targeted: Expected results: * Both links should target Fragment 1. * No link should target Fragment 2. Actual results: * IE11/Firefox: Both links targets Fragment 1. * Blink: Link B targets Fragment 2. * Webkit: Both links targets Fragment 2.
Created attachment 1464 [details] Test cases: A file with 3 sets of tests.
Created attachment 1465 [details] Test cases: A file with 3 sets of tests. Corrected test data about Safari. Conclusion remains the same.
Created attachment 1466 [details] Test cases: A file with 4 sets of tests. Added an extra set of tests to the test cases file. The new set shows that IE11’s main advantage over Blink and Webkit is that it looks for a match for the ”semantic”, UTF-8 decoded string **before** it looks for a literal match.
Created attachment 1467 [details] Test cases: A file with 6 sets of tests. Added 2 more test sets.
Created attachment 1468 [details] Test cases: A file with 6 sets of tests. Fixed an error in the second set of test.
This is already defined in HTML. All the URL Standard should do is define parsing a URL and exposing a fragment component HTML can use to perform its further processing on. Since I'm in a good mood, you can find that algorithm here: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid Is there anything you think needs changing still?