10624 2010-09-13 11:22:37 +0000 [Selection] Selection anchorNode/anchorOffset/focusNode/focusOffset do not match existing browser behaviour 2011-12-21 09:10:40 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified All All RESOLVED FIXED P2 major --- 10798 1 timdown ayg annevk ayg ehsan ian mike Ms2ger public-html-admin public-html-wg-issue-tracking public-webapps www-dom sideshowbarker+html-editing-api oldest_to_newest 38961 0 timdown 2010-09-13 11:22:37 +0000 The anchorNode, anchorOffset, focusNode and focusOffset properties of a Selection object lack the subtlety of current browser implementations. Specifically, they make no provision for a selection to be "backwards"; that is, for a selection to have been made by starting at a point in the document and stopping at a point earlier in the document. In Mozilla, WebKit and Opera the point at which the user started creating the selection is reflected in anchorNode and anchorOffset and the finish point of the selection in focusNode and focusOffset, which crucially may be earlier in the document than anchorNode and anchorOffset. This feature is lost in HTML 5's Range-obsessed Selection specification, which guarantees that focusNode and focusOffset cannot be a point earlier in the document than that specified by anchorNode and anchorOffset. This is a serious loss of the richness of current browser implementations. The relevant section of the spec that needs to be revised is the following: "The anchorNode attribute must return the value returned by the startContainer attribute of the last Range object in the list, or null if the list is empty. The anchorOffset attribute must return the value returned by the startOffset attribute of the last Range object in the list, or 0 if the list is empty. The focusNode attribute must return the value returned by the endContainer attribute of the last Range object in the list, or null if the list is empty. The focusOffset attribute must return the value returned by the endOffset attribute of the last Range object in the list, or 0 if the list is empty." I would suggest that you can still specify these properties in terms of the final Range within the selection but make provision for backwards selections. Something like the following for anchorNode, coupled with a definition of the direction of the selection: "The anchorNode attribute must return the value returned by either the startContainer or endContainer attribute of the last Range object in the list depending on the direction of the selection, or null if the list is empty." 44020 1 ayg 2011-01-10 20:48:10 +0000 Behavior here is extremely inconsistent. Opera 11, Chrome dev, and Firefox 4.0b8 all do provide backwards anchor/focus points if the user selects backwards. IE9 beta exactly matches the Selection anchor/focus points to its first Range, meaning they're always forwards. (Not the last Range -- Firefox does the last Range like the spec, everyone else does first.) Where it gets weird is when you try modifying the Range when the Selection is backwards. In IE9 it acts pretty logically. Chrome and Opera seem to simply not reflect changes made to the Range in the Selection's anchorOffset/focusOffset. IE9 works as you'd expect from the spec. Firefox uses some unclear logic to decide whether to keep the Selection reversed or not. Test page: <!DOCTYPE html> <p>Click after the "c" and drag backward to the "b" so that both letters are highlighted, then click the button. <p id=target>Abcd <p><button onclick=output()>Click</button> <div id=out></div> <script> function output() { var selection = window.getSelection(); var range = selection.getRangeAt(0); var div = document.getElementById("out"); var target = document.getElementById("target").firstChild; div.innerHTML = selection.anchorOffset + ", " + selection.focusOffset + "; "; range.setStart(target, 2); range.setEnd(target, 3); div.innerHTML += selection.anchorOffset + ", " + selection.focusOffset + "; "; var range = document.createRange(); range.setStart(target, 0); range.setEnd(target, 1); selection.addRange(range); div.innerHTML += selection.anchorOffset + ", " + selection.focusOffset + "; "; if ("removeRange" in selection) { // Skip this for WebKit selection.removeRange(selection.getRangeAt(0)); div.innerHTML += selection.anchorOffset + ", " + selection.focusOffset + "; "; } selection.removeAllRanges(); selection.addRange(range); div.innerHTML += selection.anchorOffset + ", " + selection.focusOffset; } </script> Firefox 4.0b8: 3, 1; 3, 2; 1, 0; 3, 2; 0, 1 Chrome dev: 3, 1; 3, 1; 0, 3; 0, 1 Opera 11: 3, 1; 3, 1; 3, 1; 3, 1; 0, 1 IE9 beta: 1, 3; 2, 3; 2, 3; 0, 0; 0, 1 Notice that when you change the Range's start and end points, Firefox keeps it reversed. When you append a new Range, it's still reversed. But when you do removeAllRanges(), that resets it so now it's forwards. This all seems kind of crazy. (Notice that this test is kind of confused by the fact that Firefox has anchorOffset/focusOffset key off the last Range, per spec, while the other three key off the first Range, so the third output is inconsistent partly because of that.) So it looks like the Selection has some type of "backwards" flag associated with it that's maintained across certain operations and cleared by certain operations. I could try to reverse-engineer this, but it seems like Firefox is the only one that does anything like this at all, so maybe it would be simplest to ask Firefox what they do. 44021 2 ayg 2011-01-10 20:59:14 +0000 . . . by the way, what are the use-cases for exposing backwards selections like this? What's wrong with the IE9 behavior in practice? 44045 3 timdown 2011-01-10 22:46:48 +0000 The use case I had in mind is simple: complete restoration of a previous selection state. For example, imagine a browser-based editor with a custom undo stack. Undo should ideally restore the selection so that it's identical to its state prior to the action being undone. This includes the selection's direction, which is important since it affects cursor key behaviour. 44228 4 ayg 2011-01-11 20:42:39 +0000 How are you restoring the state? There's no way I see to clone a Selection, and cloning Ranges doesn't work in my testing. In Firefox, the direction info seems to be part of the Selection object; if you store the Ranges somewhere and later wipe out the Selection's Ranges and replace them, you get the second Selection's direction, not the first. 44239 5 timdown 2011-01-11 21:32:18 +0000 A list of Ranges and a Boolean flag indicating direction is enough to completely recreate a selection. If you don't modify the DOM in between saving and restoring selection state, you can use clones of the selection Ranges (which works fine). Otherwise, you need some application-specific means of storing Range information. None of which is important: the real point is that you can use the extend() method of the selection to create a backwards selection. For example: function selectRangeBackwards(range) { var sel = window.getSelection(); var endRange = range.cloneRange(); endRange.collapse(false); sel.addRange(endRange); sel.extend(range.startContainer, range.startOffset); } This is slightly off topic for this bug, since I filed a separate one for adding extend() to the spec (#10691). This one is about being able to tell programmatically whether a selection is backwards, something that the spec does not allow for and redefines anchor* and focus* properties to prevent them being able to tell you. 44241 6 timdown 2011-01-11 21:45:32 +0000 One other point you touched on in your post: when getRangeAt() is called, Firefox is the only one to return the same actual Range object as the one that was supplied to addRange(). WebKit and Opera (haven't tested IE9, I have Windows XP at home) mangle Ranges on the way in and in some situations store ranges with different properties to those that were added, in WebKit's case because there are serious problems with its selection object (for example, you cannot place the caret at the start of a text node). Whether or not getRangeAt() should return the self-same Range that was added via addRange() does not seem to be specified. What should happen when a Range that has been added to a selection is mutated is also not specified. I would say both are very good candidates for being added to the spec, even if it's just to say that the behaviour is up to the implementation. 44256 7 ayg 2011-01-12 00:47:50 +0000 (In reply to comment #5) > None of which is important: the real point is that > you can use the extend() method of the selection to create a backwards > selection. Ah, okay. I've confirmed that this works. A bit roundabout, but I can see the utility. I'll write up some spec changes. 44258 8 941 ayg 2011-01-12 01:20:57 +0000 Created attachment 941 Proposed spec patch This specs a reasonable approximation of Firefox's behavior, based on a combination of black-box testing and source code inspection. No other browser seems to do anything sane here. I haven't actually tried running the preprocessor or anything since I have no idea how that works, so I'm more or less cargo-culting the specific markup. Some stylistic thoughts: * Is the "(respectively)" wording clear enough, or should it be more long-winded and explicit? * Should it be "should" or "must" for the direction of the selection if created by the user? 44259 9 ayg 2011-01-12 01:21:17 +0000 Ms2ger, can you look at this and accept it if appropriate? 44268 10 Ms2ger 2011-01-12 09:08:33 +0000 LGTM. https://bitbucket.org/ms2ger/dom-range/changeset/7963331ee0cb (In reply to comment #8) > Created attachment 941 [details] > Proposed spec patch > > This specs a reasonable approximation of Firefox's behavior, based on a > combination of black-box testing and source code inspection. No other browser > seems to do anything sane here. I haven't actually tried running the > preprocessor or anything since I have no idea how that works, so I'm more or > less cargo-culting the specific markup. It worked out fine; ping me on IRC if you'd like to get it set up. > Some stylistic thoughts: > > * Is the "(respectively)" wording clear enough, or should it be more > long-winded and explicit? That's fine, IMO. > * Should it be "should" or "must" for the direction of the selection if created > by the user? I made it a must, people can complain if that's too harsh. (Also, note that IE's implementation is spec-based.) 44291 11 ayg 2011-01-12 19:36:46 +0000 Also committed a test (to the HTML5 test repo for now): http://dvcs.w3.org/hg/html/raw-file/6243b5d14211/tests/submission/AryehGregor/selection-dir.html 44296 12 ian 2011-01-12 20:35:50 +0000 Some more things to test for this: * what happens on either side of bidi situations? e.g. in rtl text, use drags r-to-l, is it "forwards"? user drags l-to-r, is it "backwards"? How about going from rtl text into ltr text? Vice versa? Forwards and backwards? * what happens when the user manually extends the selection? e.g. drag a selection, then shift click elsewhere to extend it, both before and after the selection, with both a backwards and a forwards selection. * what happens when the user selects a range by clicking once then shift-clicking elsewhere, as opposed to dragging? * what happens when DOM nodes that contain the selection move? (e.g. if the selection starts in a span and ends outside it, and that span gets moved to after the end of the selection, as well as vice-versa) what happens if the direction of the text changes? (e.g. you have a backwards selection in a <bdo> element, and the dir="" of the <bdo> gets flipped.) * what happens when the selection spans blocks, floats, positioned elements, scrolling containers? * what happens when the selection spans from SVG to HTML, where the SVG has a reflection transform? * combinations of the above. 44315 13 ayg 2011-01-13 00:56:28 +0000 I added some more tests, but as discussed on IRC, I don't think it makes sense to do loads of manual tests here. People just aren't going to run them enough to make it worth it to test comprehensively, given the low odds of any given test finding additional bugs. I'll do zillions of automated tests when I spec extend(). 941 2011-01-12 01:20:57 +0000 2011-01-12 01:20:57 +0000 Proposed spec patch patch text/plain 6570 ayg IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIEFyeWVoIEdyZWdvciA8YXlnK3NwZWNAYXJ5ZWgu bmFtZT4KIyBEYXRlIDEyOTQ3OTUxNDMgMjUyMDAKIyBOb2RlIElEIDc5NjMzMzFlZTBjYjI0MWZk MDdhZTQ4YjliNjE3YjhhMjUzNzlmZGUKIyBQYXJlbnQgIGRlODE4ZmRjZGFjMWZmMGRiMTA1MjQx YzU0M2ZlYjQyY2NiMzMzZDQKRmlyc3QgcGFzcyBhdCBkaXJlY3Rpb24gc3VwcG9ydCBmb3Igc2Vs ZWN0aW9ucwoKaHR0cDovL3d3dy53My5vcmcvQnVncy9QdWJsaWMvc2hvd19idWcuY2dpP2lkPTEw NjI0CgpkaWZmIC0tZ2l0IGEvc291cmNlLmh0bWwgYi9zb3VyY2UuaHRtbAotLS0gYS9zb3VyY2Uu aHRtbAorKysgYi9zb3VyY2UuaHRtbApAQCAtODE3LDE2ICs4MTcsMzEgQEAgdGhhdCBpdCBoYXMg b25seSBvbmUgc2VnbWVudCBhbmQgdGhhdCBzZQogc2FtZSkgdGhlbiB0aGUgPHNwYW4gdGl0bGU9 Y29uY2VwdC1zZWxlY3Rpb24+c2VsZWN0aW9uPC9zcGFuPidzIHBvc2l0aW9uCiBzaG91bGQgZXF1 YWwgdGhlIGNhcmV0IHBvc2l0aW9uLiBXaGVuIHRoZQogPHNwYW4gdGl0bGU9Y29uY2VwdC1zZWxl Y3Rpb24+c2VsZWN0aW9uPC9zcGFuPiBpcyBub3QgZW1wdHksIHRoaXMKIHNwZWNpZmljYXRpb24g ZG9lcyBub3QgZGVmaW5lIHRoZSBjYXJldCBwb3NpdGlvbjsgdXNlciBhZ2VudHMgc2hvdWxkIGZv bGxvdwogcGxhdGZvcm0gY29udmVudGlvbnMgaW4gZGVjaWRpbmcgd2hldGhlciB0aGUgY2FyZXQg aXMgYXQgdGhlIHN0YXJ0IG9mIHRoZQogPHNwYW4gdGl0bGU9Y29uY2VwdC1zZWxlY3Rpb24+c2Vs ZWN0aW9uPC9zcGFuPiwgdGhlIGVuZCBvZiB0aGUKIDxzcGFuIHRpdGxlPWNvbmNlcHQtc2VsZWN0 aW9uPnNlbGVjdGlvbjwvc3Bhbj4sIG9yIHNvbWV3aGVyZSBlbHNlLgogCis8cD5FYWNoIDxzcGFu IHRpdGxlPWNvbmNlcHQtc2VsZWN0aW9uPnNlbGVjdGlvbjwvc3Bhbj4gaGFzIGEgPGRmbgordGl0 bGU9Y29uY2VwdC1zZWxlY3Rpb24tZGlyPmRpcmVjdGlvbjwvZGZuPiwgZWl0aGVyIDxpPmZvcndh cmRzPC9pPiBvcgorPGk+YmFja3dhcmRzPC9pPi4gIElmIHRoZSB1c2VyIGNyZWF0ZXMgYSA8c3Bh bgordGl0bGU9Y29uY2VwdC1zZWxlY3Rpb24+c2VsZWN0aW9uPC9zcGFuPiBieSBpbmRpY2F0aW5n IGZpcnN0IG9uZSA8c3BhbgordGl0bGU9Y29uY2VwdC1ib3VuZGFyeS1wb2ludD5ib3VuZGFyeSBw b2ludDwvc3Bhbj4gb2YgdGhlIDxzcGFuCit0aXRsZT1jb25jZXB0LXNlbGVjdGlvbj5zZWxlY3Rp b248L3NwYW4+IGFuZCB0aGVuIHRoZSBvdGhlciAoc3VjaCBhcyBieQorY2xpY2tpbmcgb24gb25l IHBvaW50IGFuZCBkcmFnZ2luZyB0byBhbm90aGVyKSwgYW5kIHRoZSA8c3BhbgordGl0bGU9Y29u Y2VwdC1icC1wb3NpdGlvbj5wb3NpdGlvbjwvc3Bhbj4gb2YgdGhlIGZpcnN0IGluZGljYXRlZCA8 c3BhbgordGl0bGU9Y29uY2VwdC1ib3VuZGFyeS1wb2ludD5ib3VuZGFyeSBwb2ludDwvc3Bhbj4g cmVsYXRpdmUgdG8gdGhlIHNlY29uZCBpcworImFmdGVyIiwgdGhlbiB0aGUgY29ycmVzcG9uZGlu ZyA8c3BhbiB0aXRsZT1jb25jZXB0LXNlbGVjdGlvbj5zZWxlY3Rpb248L3NwYW4+CitzaG91bGQg aW5pdGlhbGx5IGJlIGJhY2t3YXJkcy4gIE90aGVyd2lzZSwgaXQgc2hvdWxkIGJlIGZvcndhcmRz IChpbmNsdWRpbmcgaWYKK3RoZSB1c2VyIGRpZG4ndCBjcmVhdGUgdGhlIDxzcGFuIHRpdGxlPWNv bmNlcHQtc2VsZWN0aW9uPnNlbGVjdGlvbjwvc3Bhbj4sCitjcmVhdGVkIGl0IGJ5IHNlbGVjdGlu ZyBhbiBlbnRpcmUgcGFydCBvZiB0aGUgcGFnZSB1c2luZyBhIGtleWJvYXJkIHNob3J0Y3V0LAor ZXRjLikuCisKIDxwPk9uIHNvbWUgcGxhdGZvcm1zIChzdWNoIGFzIHRob3NlIHVzaW5nIFdvcmRz dGFyIGVkaXRpbmcgY29udmVudGlvbnMpLCB0aGUKIGNhcmV0IHBvc2l0aW9uIGlzIHRvdGFsbHkg aW5kZXBlbmRlbnQgb2YgdGhlIHN0YXJ0IGFuZCBlbmQgb2YgdGhlCiA8c3BhbiB0aXRsZT1jb25j ZXB0LXNlbGVjdGlvbj5zZWxlY3Rpb248L3NwYW4+LCBldmVuIHdoZW4gdGhlCiA8c3BhbiB0aXRs ZT1jb25jZXB0LXNlbGVjdGlvbj5zZWxlY3Rpb248L3NwYW4+IGlzIGVtcHR5LiBPbiBzdWNoIHBs YXRmb3JtcywgdXNlcgogYWdlbnRzIG1heSBpZ25vcmUgdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhl IGN1cnNvciBwb3NpdGlvbiBiZSBsaW5rZWQgdG8gdGhlCiBwb3NpdGlvbiBvZiB0aGUgPHNwYW4g dGl0bGU9Y29uY2VwdC1zZWxlY3Rpb24+c2VsZWN0aW9uPC9zcGFuPiBhbHRvZ2V0aGVyLgogCiA8 cD5Vc2VyIGFnZW50cyBtYXkgc2VsZWN0aXZlbHkgaWdub3JlIGF0dGVtcHRzIHRvIHVzZSB0aGUg QVBJIHRvIGFkanVzdCB0aGUKQEAgLTkyNCwzNCArOTM5LDUwIEBAIGFueSBleHBsaWNpdGx5IGNh bGxlZCBvdXQgYmVsb3cuCiAgIDxkZD4KICAgICA8cD5SZXR1cm5zIHRoZSBvZmZzZXQgb2YgdGhl IGVuZCBvZiB0aGUgc2VsZWN0aW9uIHJlbGF0aXZlIHRvIHRoZSBlbGVtZW50CiAgICAgdGhhdCBj b250YWlucyB0aGUgZW5kIG9mIHRoZSBzZWxlY3Rpb24uCiAgICAgPHA+UmV0dXJucyAwIGlmIHRo ZXJlJ3Mgbm8gc2VsZWN0aW9uLgogPC9kbD4KIAogPGRpdiBjbGFzcz1pbXBsPgogPHA+VGhlIDxk Zm4gdGl0bGU9ZG9tLVNlbGVjdGlvbi1hbmNob3JOb2RlPjxjb2RlPmFuY2hvck5vZGU8L2NvZGU+ PC9kZm4+Ci1hdHRyaWJ1dGUgbXVzdCByZXR1cm4gdGhlIHZhbHVlIHJldHVybmVkIGJ5IHRoZQot PGNvZGUgdGl0bGU9ZG9tLVJhbmdlLXN0YXJ0Q29udGFpbmVyPnN0YXJ0Q29udGFpbmVyPC9jb2Rl PiBhdHRyaWJ1dGUgb2YgdGhlIGxhc3QKLTxjb2RlPlJhbmdlPC9jb2RlPiBvYmplY3QgaW4gdGhl IGxpc3QsIG9yIG51bGwgaWYgdGhlIGxpc3QgaXMgZW1wdHkuCithdHRyaWJ1dGUgbXVzdCByZXR1 cm4gbnVsbCBpZiB0aGUgbGlzdCBpcyBlbXB0eS4gIE90aGVyd2lzZSwgaWYgdGhlIDxzcGFuCit0 aXRsZT1jb25jZXB0LXNlbGVjdGlvbj5zZWxlY3Rpb248L3NwYW4+J3MgPHNwYW4KK3RpdGxlPWNv bmNlcHQtc2VsZWN0aW9uLWRpcj5kaXJlY3Rpb248L3NwYW4+IGlzIGZvcndhcmRzIChyZXNwZWN0 aXZlbHkKK2JhY2t3YXJkcyksIGl0IG11c3QgcmV0dXJuIHRoZSB2YWx1ZSByZXR1cm5lZCBieSB0 aGUgPGNvZGUKK3RpdGxlPWRvbS1SYW5nZS1zdGFydENvbnRhaW5lcj5zdGFydENvbnRhaW5lcjwv Y29kZT4gKHJlc3BlY3RpdmVseSA8Y29kZQordGl0bGU9ZG9tLVJhbmdlLWVuZENvbnRhaW5lcj5l bmRDb250YWluZXI8L2NvZGU+KSBhdHRyaWJ1dGUgb2YgdGhlIGxhc3QKKzxjb2RlPlJhbmdlPC9j b2RlPiBvYmplY3QgaW4gdGhlIGxpc3QuCiAKIDxwPlRoZSA8ZGZuIHRpdGxlPWRvbS1TZWxlY3Rp b24tYW5jaG9yT2Zmc2V0Pjxjb2RlPmFuY2hvck9mZnNldDwvY29kZT48L2Rmbj4KLWF0dHJpYnV0 ZSBtdXN0IHJldHVybiB0aGUgdmFsdWUgcmV0dXJuZWQgYnkgdGhlCi08Y29kZSB0aXRsZT1kb20t UmFuZ2Utc3RhcnRPZmZzZXQ+c3RhcnRPZmZzZXQ8L2NvZGU+IGF0dHJpYnV0ZSBvZiB0aGUgbGFz dAotPGNvZGU+UmFuZ2U8L2NvZGU+IG9iamVjdCBpbiB0aGUgbGlzdCwgb3IgMCBpZiB0aGUgbGlz dCBpcyBlbXB0eS4KK2F0dHJpYnV0ZSBtdXN0IHJldHVybiAwIGlmIHRoZSBsaXN0IGlzIGVtcHR5 LiAgT3RoZXJ3aXNlLCBpZiB0aGUgPHNwYW4KK3RpdGxlPWNvbmNlcHQtc2VsZWN0aW9uPnNlbGVj dGlvbjwvc3Bhbj4ncyA8c3BhbgordGl0bGU9Y29uY2VwdC1zZWxlY3Rpb24tZGlyPmRpcmVjdGlv bjwvc3Bhbj4gaXMgZm9yd2FyZHMgKHJlc3BlY3RpdmVseQorYmFja3dhcmRzKSwgaXQgbXVzdCBy ZXR1cm4gdGhlIHZhbHVlIHJldHVybmVkIGJ5IHRoZSA8Y29kZQordGl0bGU9ZG9tLVJhbmdlLXN0 YXJ0T2Zmc2V0PnN0YXJ0T2Zmc2V0PC9jb2RlPiAocmVzcGVjdGl2ZWx5IDxjb2RlCit0aXRsZT1k b20tUmFuZ2UtZW5kT2Zmc2V0PmVuZE9mZnNldDwvY29kZT4pIGF0dHJpYnV0ZSBvZiB0aGUgbGFz dAorPGNvZGU+UmFuZ2U8L2NvZGU+IG9iamVjdCBpbiB0aGUgbGlzdC4KIAogPHA+VGhlIDxkZm4g dGl0bGU9ZG9tLVNlbGVjdGlvbi1mb2N1c05vZGU+PGNvZGU+Zm9jdXNOb2RlPC9jb2RlPjwvZGZu PgotYXR0cmlidXRlIG11c3QgcmV0dXJuIHRoZSB2YWx1ZSByZXR1cm5lZCBieSB0aGUKLTxjb2Rl IHRpdGxlPWRvbS1SYW5nZS1lbmRDb250YWluZXI+ZW5kQ29udGFpbmVyPC9jb2RlPiBhdHRyaWJ1 dGUgb2YgdGhlIGxhc3QKLTxjb2RlPlJhbmdlPC9jb2RlPiBvYmplY3QgaW4gdGhlIGxpc3QsIG9y IG51bGwgaWYgdGhlIGxpc3QgaXMgZW1wdHkuCithdHRyaWJ1dGUgbXVzdCByZXR1cm4gbnVsbCBp ZiB0aGUgbGlzdCBpcyBlbXB0eS4gIE90aGVyd2lzZSwgaWYgdGhlIDxzcGFuCit0aXRsZT1jb25j ZXB0LXNlbGVjdGlvbj5zZWxlY3Rpb248L3NwYW4+J3MgPHNwYW4KK3RpdGxlPWNvbmNlcHQtc2Vs ZWN0aW9uLWRpcj5kaXJlY3Rpb248L3NwYW4+IGlzIGZvcndhcmRzIChyZXNwZWN0aXZlbHkKK2Jh Y2t3YXJkcyksIGl0IG11c3QgcmV0dXJuIHRoZSB2YWx1ZSByZXR1cm5lZCBieSB0aGUgPGNvZGUK K3RpdGxlPWRvbS1SYW5nZS1lbmRDb250YWluZXI+ZW5kQ29udGFpbmVyPC9jb2RlPiAocmVzcGVj dGl2ZWx5IDxjb2RlCit0aXRsZT1kb20tUmFuZ2Utc3RhcnRDb250YWluZXI+c3RhcnRDb250YWlu ZXI8L2NvZGU+KSBhdHRyaWJ1dGUgb2YgdGhlIGxhc3QKKzxjb2RlPlJhbmdlPC9jb2RlPiBvYmpl Y3QgaW4gdGhlIGxpc3QuCiAKIDxwPlRoZSA8ZGZuIHRpdGxlPWRvbS1TZWxlY3Rpb24tZm9jdXNP ZmZzZXQ+PGNvZGU+Zm9jdXNPZmZzZXQ8L2NvZGU+PC9kZm4+Ci1hdHRyaWJ1dGUgbXVzdCByZXR1 cm4gdGhlIHZhbHVlIHJldHVybmVkIGJ5IHRoZQotPGNvZGUgdGl0bGU9ZG9tLVJhbmdlLWVuZE9m ZnNldD5lbmRPZmZzZXQ8L2NvZGU+IGF0dHJpYnV0ZSBvZiB0aGUgbGFzdAotPGNvZGU+UmFuZ2U8 L2NvZGU+IG9iamVjdCBpbiB0aGUgbGlzdCwgb3IgMCBpZiB0aGUgbGlzdCBpcyBlbXB0eS4KK2F0 dHJpYnV0ZSBtdXN0IHJldHVybiAwIGlmIHRoZSBsaXN0IGlzIGVtcHR5LiAgT3RoZXJ3aXNlLCBp ZiB0aGUgPHNwYW4KK3RpdGxlPWNvbmNlcHQtc2VsZWN0aW9uPnNlbGVjdGlvbjwvc3Bhbj4ncyA8 c3BhbgordGl0bGU9Y29uY2VwdC1zZWxlY3Rpb24tZGlyPmRpcmVjdGlvbjwvc3Bhbj4gaXMgZm9y d2FyZHMgKHJlc3BlY3RpdmVseQorYmFja3dhcmRzKSwgaXQgbXVzdCByZXR1cm4gdGhlIHZhbHVl IHJldHVybmVkIGJ5IHRoZSA8Y29kZQordGl0bGU9ZG9tLVJhbmdlLWVuZE9mZnNldD5lbmRPZmZz ZXQ8L2NvZGU+IChyZXNwZWN0aXZlbHkgPGNvZGUKK3RpdGxlPWRvbS1SYW5nZS1zdGFydE9mZnNl dD5zdGFydE9mZnNldDwvY29kZT4pIGF0dHJpYnV0ZSBvZiB0aGUgbGFzdAorPGNvZGU+UmFuZ2U8 L2NvZGU+IG9iamVjdCBpbiB0aGUgbGlzdC4KIDwvZGl2PgogCiA8aHI+CiAKIDxkbCBjbGFzcz1k b21pbnRybz4KICAgPGR0Pjx2YXIgdGl0bGU+Y29sbGFwc2VkPC92YXI+ID0gPHZhciB0aXRsZT5z ZWxlY3Rpb248L3Zhcj4gLiA8Y29kZSB0aXRsZT1kb20tU2VsZWN0aW9uLWlzQ29sbGFwc2VkPmlz Q29sbGFwc2VkPC9jb2RlPigpCiAgIDxkZD4KICAgICA8cD5SZXR1cm5zIHRydWUgaWYgdGhlcmUn cyBubyBzZWxlY3Rpb24gb3IgaWYgdGhlIHNlbGVjdGlvbiBpcyBlbXB0eS4KQEAgLTExMTEsMTcg KzExNDIsMTggQEAgdGl0bGU+cmFuZ2U8L3Zhcj4pPC9jb2RlPjwvZGZuPiBtZXRob2QgbQogCiA8 cD5UaGUKIDxkZm4gdGl0bGU9ZG9tLVNlbGVjdGlvbi1yZW1vdmVBbGxSYW5nZXM+PGNvZGU+cmVt b3ZlQWxsUmFuZ2VzKCk8L2NvZGU+PC9kZm4+CiBtZXRob2QgbXVzdCByZW1vdmUgYWxsIHRoZSA8 Y29kZT5SYW5nZTwvY29kZT5zIGZyb20gdGhlIGxpc3Qgb2YKIDxjb2RlPlJhbmdlPC9jb2RlPnMs IHN1Y2ggdGhhdCB0aGUKIDxjb2RlIHRpdGxlPWRvbS1TZWxlY3Rpb24tcmFuZ2VDb3VudD5yYW5n ZUNvdW50PC9jb2RlPiBhdHRyaWJ1dGUgcmV0dXJucyAwIGFmdGVyCiB0aGUgPGNvZGUgdGl0bGU9 ZG9tLVNlbGVjdGlvbi1yZW1vdmVBbGxSYW5nZXM+cmVtb3ZlQWxsUmFuZ2VzKCk8L2NvZGU+IG1l dGhvZCBpcwogaW52b2tlZCAoYW5kIHVudGlsIGEgbmV3IDxjb2RlPlJhbmdlPC9jb2RlPiBpcyBh ZGRlZCB0byB0aGUgbGlzdCwgZWl0aGVyIHRocm91Z2gKLXRoaXMgaW50ZXJmYWNlIG9yIHZpYSB1 c2VyIGludGVyYWN0aW9uKS4KK3RoaXMgaW50ZXJmYWNlIG9yIHZpYSB1c2VyIGludGVyYWN0aW9u KS4gIFRoZSA8c3BhbgordGl0bGU9Y29uY2VwdC1zZWxlY3Rpb24tZGlyPmRpcmVjdGlvbjwvc3Bh bj4gbXVzdCBiZSBzZXQgdG8gZm9yd2FyZHMuCiA8L2Rpdj4KIAogPGhyPgogCiA8ZGl2IGNsYXNz PWltcGw+CiA8cD5UaGUgPGRmbiB0aXRsZT1kb20tU2VsZWN0aW9uLXN0cmluZ2lmaWVyPnN0cmlu Z2lmaWVyPC9kZm4+IG11c3QgcmV0dXJuIHRoZQogY29uY2F0ZW5hdGlvbiBvZiB0aGUgcmVzdWx0 cyBvZgogPHNwYW4gdGl0bGU9ZG9tLVJhbmdlLXN0cmluZ2lmaWVyPnN0cmluZ2lmeWluZzwvc3Bh bj4gZWFjaCBvZiB0aGUK