62621 2011-06-13 22:10:59 -0700 Span ID duplicated when pressing enter at beginning of span 2011-06-15 10:06:37 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 sullivan webkit-unassigned adele darin enrica rniwa webkit.review.bot oldest_to_newest 420216 0 sullivan 2011-06-13 22:10:59 -0700 Put the following in a contenteditable div: <span id="dupe">a</span> Put the cursor before "a" and press enter. Result: <span id="dupe"><div><span id="dupe"><br></span></div>a</span> The id of the span should not be duplicated. 420780 1 sullivan 2011-06-14 15:38:44 -0700 Ryosuke, in comment #7 of bug 61594, you suggested that before fixing this issue, we should merge InsertParagraphSeparatorCommand::cloneHierarchyUnderNewBlock() with CompositeEditCommand::cloneParagraphUnderNewElement() since they are very similar functions. I started looking into this, but several differences in functionality tripped me up: 1. The InsertParagraphSeparator version actually operates as two functions paired together: getAncestorsInsideBlock() collects the ancestors and then cloneHierarchyUnderNewBlock() clones them. There doesn't appear to be much reason for this, so it should be okay to change. 2. For listing the ancestors, getAncestorsInsideBlock takes an insertion Node and an outer block Element. It excludes both these nodes from the list of ancestors, only appending the elements between them. By contrast, cloneParagraphUnderNewElement() takes a start Position and an outer Node, and includes the position.deprecatedNode() and the outer node in the list of ancestors. Swapping between using positions and using nodes, counting ancestors differently, and keeping lists of Nodes instead of Elements is a bigger change in behavior. We also end up with another dependency on deprecatedNode. 3. cloneParagraphUnderNewElement() has no return value. cloneHierarchyUnderNewBlock() returns the deepest Element in the ancestor list that was cloned. We'd need to add this functionality into cloneParagraphUnderNewElement(), but it seems like an arbitrary return value to add. Do you still think that merging these functions is the right thing to do? I am working on a patch to do this, but because of the differences in functionality I'm having a lot of trouble getting the arguments to cloneParagraphUnderNewElement correct. Each time I fix a layout test, a different layout test breaks with a slightly different problem. 420784 2 rniwa 2011-06-14 15:43:37 -0700 (In reply to comment #1) > 1. The InsertParagraphSeparator version actually operates as two functions paired together: getAncestorsInsideBlock() collects the ancestors and then cloneHierarchyUnderNewBlock() clones them. There doesn't appear to be much reason for this, so it should be okay to change. Just having one function that collects and clones ancestors should work. > 2. For listing the ancestors, getAncestorsInsideBlock takes an insertion Node and an outer block Element. It excludes both these nodes from the list of ancestors, only appending the elements between them. By contrast, cloneParagraphUnderNewElement() takes a start Position and an outer Node, and includes the position.deprecatedNode() and the outer node in the list of ancestors. Swapping between using positions and using nodes, counting ancestors differently, and keeping lists of Nodes instead of Elements is a bigger change in behavior. We also end up with another dependency on deprecatedNode. The merged function should take a starting Position and the outer block node. We may need to get rid of deprecatedNode dependency in a separate bug. > 3. cloneParagraphUnderNewElement() has no return value. cloneHierarchyUnderNewBlock() returns the deepest Element in the ancestor list that was cloned. We'd need to add this functionality into cloneParagraphUnderNewElement(), but it seems like an arbitrary return value to add. I agree. I'm curious why we'd need that. > Do you still think that merging these functions is the right thing to do? I am working on a patch to do this, but because of the differences in functionality I'm having a lot of trouble getting the arguments to cloneParagraphUnderNewElement correct. Each time I fix a layout test, a different layout test breaks with a slightly different problem. I think we should eventually merge these two functions, but that isn't really a requirement for you to fix other bugs. 420793 3 sullivan 2011-06-14 15:54:44 -0700 (In reply to comment #2) > > 2. For listing the ancestors, getAncestorsInsideBlock takes an insertion Node and an outer block Element. It excludes both these nodes from the list of ancestors, only appending the elements between them. By contrast, cloneParagraphUnderNewElement() takes a start Position and an outer Node, and includes the position.deprecatedNode() and the outer node in the list of ancestors. Swapping between using positions and using nodes, counting ancestors differently, and keeping lists of Nodes instead of > Elements is a bigger change in behavior. We also end up with another dependency on deprecatedNode. > > The merged function should take a starting Position and the outer block node. We may need to get rid of deprecatedNode dependency in a separate bug. CompositeEditCommand::cloneParagraphUnderNewElement() also takes an end position (in case there are also sibling nodes to clone) and a block element (to clone the paragraph under). I think both of these are needed as well. > > 3. cloneParagraphUnderNewElement() has no return value. cloneHierarchyUnderNewBlock() returns the deepest Element in the ancestor list that was cloned. We'd need to add this functionality into cloneParagraphUnderNewElement(), but it seems like an arbitrary return value to add. > > I agree. I'm curious why we'd need that. I think InsertParagraphSeparatorCommand is the only caller that would need it. The reason is that it inserts the actual line break by calling appendBlockPlaceholder() on that deepest cloned node. Maybe there is a better way to do this, like creating the block placeholder before cloning? > > Do you still think that merging these functions is the right thing to do? I am working on a patch to do this, but because of the differences in functionality I'm having a lot of trouble getting the arguments to cloneParagraphUnderNewElement correct. Each time I fix a layout test, a different layout test breaks with a slightly different problem. > > I think we should eventually merge these two functions, but that isn't really a requirement for you to fix other bugs. The whole thing seems pretty fragile; the existing code calls deprecatedNode() in both places and it seems like we'd want to get rid of those before we do a bigger refactor. But I think just getting rid of IDs when cloning can be done in a much simpler change that doesn't require any refactoring. 420843 4 97191 sullivan 2011-06-14 16:37:52 -0700 Created attachment 97191 Patch 420848 5 97191 rniwa 2011-06-14 16:42:37 -0700 Comment on attachment 97191 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=97191&action=review > Source/WebCore/editing/InsertParagraphSeparatorCommand.cpp:139 > + // Delete id attribute from the cloned child element because the same id cannot be used for more than one element I don't think this comment is necessary. It's self-evident. More interesting question to ask is whether if we'd ever delete the original element after cloning hierarchy, in which case we shouldn't be removing id attribute. > Source/WebCore/editing/InsertParagraphSeparatorCommand.cpp:141 > + child->removeAttribute(HTMLNames::idAttr, ec); Do you really need "HTMLNames::"? 420850 6 sullivan 2011-06-14 16:48:04 -0700 (In reply to comment #5) Will create a patch to address the rest of the comments soon, wanted to answer this one right away in case I'm missing something: > More interesting question to ask is whether if we'd ever delete the original element after cloning hierarchy, in which case we shouldn't be removing id attribute. This function is called from two places in InsertParagraphCommand, and they both look like this: appendBlockPlaceholder(cloneHierarchyUnderNewBlock(ancestors, blockToInsert)); // In this case, we need to set the new ending selection. setEndingSelection(VisibleSelection(insertionPosition, DOWNSTREAM)); return; Neither appendBlockPlaceholder nor setEndingSelection ever delete any nodes, so I think we're safe here. 420853 7 rniwa 2011-06-14 16:49:40 -0700 (In reply to comment #6) > > More interesting question to ask is whether if we'd ever delete the original element after cloning hierarchy, in which case we shouldn't be removing id attribute. > > This function is called from two places in InsertParagraphCommand, and they both look like this: > > appendBlockPlaceholder(cloneHierarchyUnderNewBlock(ancestors, blockToInsert)); > > // In this case, we need to set the new ending selection. > setEndingSelection(VisibleSelection(insertionPosition, DOWNSTREAM)); > return; > > Neither appendBlockPlaceholder nor setEndingSelection ever delete any nodes, so I think we're safe here. Right, and that'll be a useful comment to have. 420859 8 97197 sullivan 2011-06-14 17:05:31 -0700 Created attachment 97197 Patch 420873 9 97197 rniwa 2011-06-14 17:18:28 -0700 Comment on attachment 97197 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=97197&action=review > LayoutTests/editing/inserting/return-key-span-start-expected.txt:7 > +| <span> > +| id="dupe" > +| <div> > +| <span> > +| <br> Wow! Why are we nesting div inside span? Can we fix this? > Source/WebCore/editing/InsertParagraphSeparatorCommand.cpp:140 > + // It should always be okay to delete the id of cloned elements, because the codepaths that call this method > + // only call appendBlockPlaceholder and setEndingSelection afterward, which never delete the original node. I'm sad that there's no way to assert this. Also this comment might be too verbose. What matters is the fact we don't delete the cloned elements or the original elements, not the fact we call appendBlockPlaceholder and setEndingSelection. 420874 10 97197 rniwa 2011-06-14 17:18:29 -0700 Comment on attachment 97197 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=97197&action=review > LayoutTests/editing/inserting/return-key-span-start-expected.txt:7 > +| <span> > +| id="dupe" > +| <div> > +| <span> > +| <br> Wow! Why are we nesting div inside span? Can we fix this? > Source/WebCore/editing/InsertParagraphSeparatorCommand.cpp:140 > + // It should always be okay to delete the id of cloned elements, because the codepaths that call this method > + // only call appendBlockPlaceholder and setEndingSelection afterward, which never delete the original node. I'm sad that there's no way to assert this. Also this comment might be too verbose. What matters is the fact we don't delete the cloned elements or the original elements, not the fact we call appendBlockPlaceholder and setEndingSelection. 420905 11 sullivan 2011-06-14 17:56:46 -0700 (In reply to comment #10) > (From update of attachment 97197 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=97197&action=review > > > LayoutTests/editing/inserting/return-key-span-start-expected.txt:7 > > +| <span> > > +| id="dupe" > > +| <div> > > +| <span> > > +| <br> > > Wow! Why are we nesting div inside span? Can we fix this? This is the current behavior, and my change hasn't affected it. If you look at InsertParagraphSeparatorCommand::doApply(), we have started with the following tree: <div contenteditable> <span> hello startBlock gets set to the contenteditable div. The code falls into the "// Handle case when position is in the first visible position in its block.." block that starts on line 250 of my patch. That code looks for a refNode to insert the new div before: if (isFirstInBlock && !nestNewBlock) refNode = startBlock; else if (insertionPosition.deprecatedNode() == startBlock && nestNewBlock) { refNode = startBlock->childNode(insertionPosition.deprecatedEditingOffset()); ASSERT(refNode); // must be true or we'd be in the end of block case } else refNode = insertionPosition.deprecatedNode(); nestNewBlock is true and the insertion position is at the start of the text node (not the startBlock), so it falls through to the "refNode = insertionPosition.deprecatedNode();" line. So the div gets inserted right before the "hello" text, as a child of the span. We know that if we've fallen into this code path, and isFirstInBlock and nestNewBlock are true, that the insertion position is in the first visible position in the block. So I think we want to modify the code in that case to always insert the new div as this first child of startBlock. Does that sound right? In this case, we'd end up with: <div contenteditable> <div> <span> <br> <span> hello It seems like something that should be done in a separate patch. I know my layout test result looks strange, but other than that it doesn't seem to have much to do with this patch. So does that fix need to block this one? 420906 12 rniwa 2011-06-14 17:59:52 -0700 (In reply to comment #11) > (In reply to comment #10) > This is the current behavior, and my change hasn't affected it. If you look at InsertParagraphSeparatorCommand::doApply(), we have started with the following tree: Oh sure, I didn't meant that your patch broke it. > startBlock gets set to the contenteditable div. The code falls into the "// Handle case when position is in the first visible position in its block.." block that starts on line 250 of my patch. That code looks for a refNode to insert the new div before: > > if (isFirstInBlock && !nestNewBlock) > refNode = startBlock; > else if (insertionPosition.deprecatedNode() == startBlock && nestNewBlock) { > refNode = startBlock->childNode(insertionPosition.deprecatedEditingOffset()); > ASSERT(refNode); // must be true or we'd be in the end of block case > } else > refNode = insertionPosition.deprecatedNode(); > > nestNewBlock is true and the insertion position is at the start of the text node (not the startBlock), so it falls through to the "refNode = insertionPosition.deprecatedNode();" line. So the div gets inserted right before the "hello" text, as a child of the span. > > We know that if we've fallen into this code path, and isFirstInBlock and nestNewBlock are true, that the insertion position is in the first visible position in the block. So I think we want to modify the code in that case to always insert the new div as this first child of startBlock. Does that sound right? In this case, we'd end up with: I see. There's a code in ReplaceSelectionCommand enrica recently added and I subsequently modified that deals with similar situation. We may want to extract that up into CompositeEditCommand and share code if possible. > It seems like something that should be done in a separate patch. I know my layout test result looks strange, but other than that it doesn't seem to have much to do with this patch. So does that fix need to block this one? Fixing it in a separate patch sounds good to me. 420907 13 97197 rniwa 2011-06-14 18:00:43 -0700 Comment on attachment 97197 Patch I'd say r+ although you may want to consider revising the comment in cloneHierarchyUnderNewBlock. 420908 14 rniwa 2011-06-14 18:01:16 -0700 Let me know if you want to revise the comment or rather land the patch as is. I'm fine either way. 420911 15 97208 sullivan 2011-06-14 18:03:25 -0700 Created attachment 97208 Patch 420913 16 sullivan 2011-06-14 18:03:49 -0700 (In reply to comment #15) > Created an attachment (id=97208) [details] > Patch Added a shorter comment. 420914 17 97208 rniwa 2011-06-14 18:04:29 -0700 Comment on attachment 97208 Patch Thanks for revising the comment! 420915 18 rniwa 2011-06-14 18:06:39 -0700 (In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=97208) [details] [details] > > Patch > > Added a shorter comment. By the way, I think you can do webkit-patch --no-obsolete --commit-queue to leave r+ on old patch intact and ask for cq+ on new patch. 420945 19 97208 webkit.review.bot 2011-06-14 18:52:05 -0700 Comment on attachment 97208 Patch Clearing flags on attachment: 97208 Committed r88890: <http://trac.webkit.org/changeset/88890> 420946 20 webkit.review.bot 2011-06-14 18:52:10 -0700 All reviewed patches have been landed. Closing bug. 420992 21 rniwa 2011-06-14 20:46:22 -0700 Added the test to Mac WebKit2's skipped list in http://trac.webkit.org/changeset/88902 since TestRunner doesn't support eventSender.keyDown. 420995 22 rniwa 2011-06-14 20:52:20 -0700 Ugh... I should have realized this during the review but you should have done document.execCommand('InsertParagraph', false, null) instead of eventSender.keyDown('\n'). Then this test would have worked on all ports. Annie, could you post a patch to fix this? 421380 23 sullivan 2011-06-15 09:42:59 -0700 (In reply to comment #22) > Ugh... I should have realized this during the review but you should have done document.execCommand('InsertParagraph', false, null) instead of eventSender.keyDown('\n'). Then this test would have worked on all ports. > > Annie, could you post a patch to fix this? Sure. I'll try to fix editing/inserting/return-key-in-hidden-field.html as well, which is what I used as an example. Thanks for skipping the test in the meantime! 421404 24 rniwa 2011-06-15 10:06:37 -0700 (In reply to comment #23) > Sure. I'll try to fix editing/inserting/return-key-in-hidden-field.html as well, which is what I used as an example. Thanks for skipping the test in the meantime! Great! Thanks for the follow up. 97191 2011-06-14 16:37:52 -0700 2011-06-14 17:05:26 -0700 Patch bug-62621-20110614163751.patch text/plain 4068 sullivan U3VidmVyc2lvbiBSZXZpc2lvbjogODg4NjYKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5n ZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxvZwppbmRleCAyYjgwMzY2MDMxYTg5MzFkOWZkY2Yy Mzk2NzljOTNjMjg5OGJiMDNkLi5hMzEzMzA1ZjI5NTY1Y2JkNWIwOTNkMjg1NmE1YjRiNDJmMWYw OWU5IDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKKysrIGIvTGF5b3V0VGVzdHMv Q2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTEtMDYtMTQgIEFubmllIFN1bGxpdmFuICA8 c3VsbGl2YW5AY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q UyEpLgorCisgICAgICAgIFNwYW4gSUQgZHVwbGljYXRlZCB3aGVuIHByZXNzaW5nIGVudGVyIGF0 IGJlZ2lubmluZyBvZiBzcGFuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df YnVnLmNnaT9pZD02MjYyMQorCisgICAgICAgIEFkZGVkIHRlc3QgZm9yIHNwYW4gaWQgbm90IGdl dHRpbmcgZHVwbGljYXRlZCB3aGVuIHNwYW4gaXMgY2xvbmVkLgorCisgICAgICAgICogZWRpdGlu Zy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0LWV4cGVjdGVkLnR4dDogQWRkZWQuCisg ICAgICAgICogZWRpdGluZy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0Lmh0bWw6IEFk ZGVkLgorCiAyMDExLTA2LTE0ICBEaW1pdHJpIEdsYXprb3YgIDxkZ2xhemtvdkBjaHJvbWl1bS5v cmc+CiAKICAgICAgICAgW0Nocm9taXVtXSBUdXJucyBvdXQsIGluc3BlY3Rvci9jb29raWUtcGFy c2VyLmh0bWwgY2FuIHRpbWVvdXQgb3V0LgpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvZWRpdGlu Zy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0LWV4cGVjdGVkLnR4dCBiL0xheW91dFRl c3RzL2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXktc3Bhbi1zdGFydC1leHBlY3RlZC50eHQK bmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMC4uYjdmYmEwNjJkZTg3YWUwYTM1OWUxY2FjODE5YzQ3NTNjN2IxNzZjMQotLS0g L2Rldi9udWxsCisrKyBiL0xheW91dFRlc3RzL2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXkt c3Bhbi1zdGFydC1leHBlY3RlZC50eHQKQEAgLTAsMCArMSw4IEBACitUaGlzIHNldHMgdGhlIHNl bGVjdGlvbiB0byB0aGUgc3RhcnQgb2YgYSBzcGFuLCBhbmQgaGl0cyB0aGUgZW50ZXIga2V5Lgor RXhwZWN0ZWQgYmVoYXZpb3I6IHdoZW4gdGhlIHNwYW4gaXMgc3BsaXQsIGl0cyBJRCBzaG91bGQg bm90IGJlIGR1cGxpY2F0ZWQuIFNlZSBidWcgNjI2MjEuCit8IDxzcGFuPgorfCAgIGlkPSJkdXBl IgorfCAgIDxkaXY+Cit8ICAgICA8c3Bhbj4KK3wgICAgICAgPGJyPgorfCAgICI8I3NlbGVjdGlv bi1jYXJldD5oZWxsbyIKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2VkaXRpbmcvaW5zZXJ0aW5n L3JldHVybi1rZXktc3Bhbi1zdGFydC5odG1sIGIvTGF5b3V0VGVzdHMvZWRpdGluZy9pbnNlcnRp bmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0Lmh0bWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMC4uYTNkYTA4MWNhMTA5NTgy NjBlMDQzNTY4OTQwODU5NWNhZDU4MzM2YgotLS0gL2Rldi9udWxsCisrKyBiL0xheW91dFRlc3Rz L2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXktc3Bhbi1zdGFydC5odG1sCkBAIC0wLDAgKzEs MTUgQEAKKzwhRE9DVFlQRSBodG1sPgorPGh0bWw+Cis8Ym9keT4KKzxkaXYgY29udGVudGVkaXRh YmxlIGlkPSJyb290Ij48c3BhbiBpZD0iZHVwZSI+aGVsbG88L3NwYW4+PC9kaXY+Cis8c2NyaXB0 IHNyYz0iLi4vLi4vcmVzb3VyY2VzL2R1bXAtYXMtbWFya3VwLmpzIj48L3NjcmlwdD4KKzxzY3Jp cHQ+Cit2YXIgc2VsID0gd2luZG93LmdldFNlbGVjdGlvbigpOworc2VsLnNldFBvc2l0aW9uKGRv Y3VtZW50LmdldEVsZW1lbnRCeUlkKCJkdXBlIiksIDApOworZXZlbnRTZW5kZXIua2V5RG93bigi XG4iKTsKK01hcmt1cC5kZXNjcmlwdGlvbigiVGhpcyBzZXRzIHRoZSBzZWxlY3Rpb24gdG8gdGhl IHN0YXJ0IG9mIGEgc3BhbiwgYW5kIGhpdHMgdGhlIGVudGVyIGtleS5cbiIKKyAgICArICJFeHBl Y3RlZCBiZWhhdmlvcjogd2hlbiB0aGUgc3BhbiBpcyBzcGxpdCwgaXRzIElEIHNob3VsZCBub3Qg YmUgZHVwbGljYXRlZC4gU2VlIGJ1ZyA2MjYyMS4iKTsKK01hcmt1cC5kdW1wKHJvb3QpOworPC9z Y3JpcHQ+Cis8L2JvZHk+Cis8L2h0bWw+CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9DaGFu Z2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNWNlNzJiYzE2MDg2MzAzOTJj MDA3Y2UxNTM0NWJkYWY0MjhhYWRlNC4uN2UyOGM5MDlmOTU4Mzc2ZjQ3OTlhMDI0NTI1ZTIwZDVh ZGE4OTIxNCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDExLTA2LTE0ICBBbm5pZSBT dWxsaXZhbiAgPHN1bGxpdmFuQGNocm9taXVtLm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBO T0JPRFkgKE9PUFMhKS4KKworICAgICAgICBTcGFuIElEIGR1cGxpY2F0ZWQgd2hlbiBwcmVzc2lu ZyBlbnRlciBhdCBiZWdpbm5pbmcgb2Ygc3BhbgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0 Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NjI2MjEKKworICAgICAgICBTdHJpcCBpZCBmcm9tIGNsb25l ZCBzcGFuLCBzbyB0aGF0IGl0IGlzIG5vdCBkdXBsaWNhdGVkLgorCisgICAgICAgIFRlc3Q6IGVk aXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXktc3Bhbi1zdGFydC5odG1sCisKKyAgICAgICAgKiBl ZGl0aW5nL0luc2VydFBhcmFncmFwaFNlcGFyYXRvckNvbW1hbmQuY3BwOgorICAgICAgICAoV2Vi Q29yZTo6SW5zZXJ0UGFyYWdyYXBoU2VwYXJhdG9yQ29tbWFuZDo6Y2xvbmVIaWVyYXJjaHlVbmRl ck5ld0Jsb2NrKToKKwogMjAxMS0wNi0xNCAgSmVmZnJleSBQZmF1ICA8anBmYXVAYXBwbGUuY29t PgogCiAgICAgICAgIFJldmlld2VkIGJ5IERhdmlkIEh5YXR0LgpkaWZmIC0tZ2l0IGEvU291cmNl L1dlYkNvcmUvZWRpdGluZy9JbnNlcnRQYXJhZ3JhcGhTZXBhcmF0b3JDb21tYW5kLmNwcCBiL1Nv dXJjZS9XZWJDb3JlL2VkaXRpbmcvSW5zZXJ0UGFyYWdyYXBoU2VwYXJhdG9yQ29tbWFuZC5jcHAK aW5kZXggODM4NGYzMDY5MDY0NGI0OTA0NzU5NjJmNzNhYzVhMjRhZjZhMzFlOS4uZjg2MDk4NmRj MDA1YWIyMTI5NTUxZGRhMDg2NGQwNzBlZjIxM2FmYiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNv cmUvZWRpdGluZy9JbnNlcnRQYXJhZ3JhcGhTZXBhcmF0b3JDb21tYW5kLmNwcAorKysgYi9Tb3Vy Y2UvV2ViQ29yZS9lZGl0aW5nL0luc2VydFBhcmFncmFwaFNlcGFyYXRvckNvbW1hbmQuY3BwCkBA IC0xMzYsNiArMTM2LDEwIEBAIFBhc3NSZWZQdHI8RWxlbWVudD4gSW5zZXJ0UGFyYWdyYXBoU2Vw YXJhdG9yQ29tbWFuZDo6Y2xvbmVIaWVyYXJjaHlVbmRlck5ld0Jsb2NrCiAgICAgUmVmUHRyPEVs ZW1lbnQ+IHBhcmVudCA9IGJsb2NrVG9JbnNlcnQ7CiAgICAgZm9yIChzaXplX3QgaSA9IGFuY2Vz dG9ycy5zaXplKCk7IGkgIT0gMDsgLS1pKSB7CiAgICAgICAgIFJlZlB0cjxFbGVtZW50PiBjaGls ZCA9IGFuY2VzdG9yc1tpIC0gMV0tPmNsb25lRWxlbWVudFdpdGhvdXRDaGlsZHJlbigpOworICAg ICAgICAvLyBEZWxldGUgaWQgYXR0cmlidXRlIGZyb20gdGhlIGNsb25lZCBjaGlsZCBlbGVtZW50 IGJlY2F1c2UgdGhlIHNhbWUgaWQgY2Fubm90IGJlIHVzZWQgZm9yIG1vcmUgdGhhbiBvbmUgZWxl bWVudAorICAgICAgICBFeGNlcHRpb25Db2RlIGVjID0gMDsKKyAgICAgICAgY2hpbGQtPnJlbW92 ZUF0dHJpYnV0ZShIVE1MTmFtZXM6OmlkQXR0ciwgZWMpOworICAgICAgICBBU1NFUlQoIWVjKTsK ICAgICAgICAgYXBwZW5kTm9kZShjaGlsZCwgcGFyZW50KTsKICAgICAgICAgcGFyZW50ID0gY2hp bGQucmVsZWFzZSgpOwogICAgIH0K 97197 2011-06-14 17:05:31 -0700 2011-06-14 18:03:20 -0700 Patch bug-62621-20110614170530.patch text/plain 4201 sullivan U3VidmVyc2lvbiBSZXZpc2lvbjogODg4NzMKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5n ZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxvZwppbmRleCAyYjgwMzY2MDMxYTg5MzFkOWZkY2Yy Mzk2NzljOTNjMjg5OGJiMDNkLi44MGVlZGZiNGI3MTkwZmQ4NjQ0MzRiOWZhZjg4OTQ3MzRhZjMw MTdiIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKKysrIGIvTGF5b3V0VGVzdHMv Q2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTAtMDYtMTQgIEFubmllIFN1bGxpdmFuICA8 c3VsbGl2YW5AY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q UyEpLgorCisgICAgICAgIFNwYW4gSUQgZHVwbGljYXRlZCB3aGVuIHByZXNzaW5nIGVudGVyIGF0 IGJlZ2lubmluZyBvZiBzcGFuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df YnVnLmNnaT9pZD02MjYyMQorCisgICAgICAgIEFkZGVkIHRlc3QgZm9yIHNwYW4gaWQgbm90IGdl dHRpbmcgZHVwbGljYXRlZCB3aGVuIHNwYW4gaXMgY2xvbmVkLgorCisgICAgICAgICogZWRpdGlu Zy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0LWV4cGVjdGVkLnR4dDogQWRkZWQuCisg ICAgICAgICogZWRpdGluZy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0Lmh0bWw6IEFk ZGVkLgorCiAyMDExLTA2LTE0ICBEaW1pdHJpIEdsYXprb3YgIDxkZ2xhemtvdkBjaHJvbWl1bS5v cmc+CiAKICAgICAgICAgW0Nocm9taXVtXSBUdXJucyBvdXQsIGluc3BlY3Rvci9jb29raWUtcGFy c2VyLmh0bWwgY2FuIHRpbWVvdXQgb3V0LgpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvZWRpdGlu Zy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0LWV4cGVjdGVkLnR4dCBiL0xheW91dFRl c3RzL2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXktc3Bhbi1zdGFydC1leHBlY3RlZC50eHQK bmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMC4uYjdmYmEwNjJkZTg3YWUwYTM1OWUxY2FjODE5YzQ3NTNjN2IxNzZjMQotLS0g L2Rldi9udWxsCisrKyBiL0xheW91dFRlc3RzL2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXkt c3Bhbi1zdGFydC1leHBlY3RlZC50eHQKQEAgLTAsMCArMSw4IEBACitUaGlzIHNldHMgdGhlIHNl bGVjdGlvbiB0byB0aGUgc3RhcnQgb2YgYSBzcGFuLCBhbmQgaGl0cyB0aGUgZW50ZXIga2V5Lgor RXhwZWN0ZWQgYmVoYXZpb3I6IHdoZW4gdGhlIHNwYW4gaXMgc3BsaXQsIGl0cyBJRCBzaG91bGQg bm90IGJlIGR1cGxpY2F0ZWQuIFNlZSBidWcgNjI2MjEuCit8IDxzcGFuPgorfCAgIGlkPSJkdXBl IgorfCAgIDxkaXY+Cit8ICAgICA8c3Bhbj4KK3wgICAgICAgPGJyPgorfCAgICI8I3NlbGVjdGlv bi1jYXJldD5oZWxsbyIKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2VkaXRpbmcvaW5zZXJ0aW5n L3JldHVybi1rZXktc3Bhbi1zdGFydC5odG1sIGIvTGF5b3V0VGVzdHMvZWRpdGluZy9pbnNlcnRp bmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0Lmh0bWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMC4uYTNkYTA4MWNhMTA5NTgy NjBlMDQzNTY4OTQwODU5NWNhZDU4MzM2YgotLS0gL2Rldi9udWxsCisrKyBiL0xheW91dFRlc3Rz L2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXktc3Bhbi1zdGFydC5odG1sCkBAIC0wLDAgKzEs MTUgQEAKKzwhRE9DVFlQRSBodG1sPgorPGh0bWw+Cis8Ym9keT4KKzxkaXYgY29udGVudGVkaXRh YmxlIGlkPSJyb290Ij48c3BhbiBpZD0iZHVwZSI+aGVsbG88L3NwYW4+PC9kaXY+Cis8c2NyaXB0 IHNyYz0iLi4vLi4vcmVzb3VyY2VzL2R1bXAtYXMtbWFya3VwLmpzIj48L3NjcmlwdD4KKzxzY3Jp cHQ+Cit2YXIgc2VsID0gd2luZG93LmdldFNlbGVjdGlvbigpOworc2VsLnNldFBvc2l0aW9uKGRv Y3VtZW50LmdldEVsZW1lbnRCeUlkKCJkdXBlIiksIDApOworZXZlbnRTZW5kZXIua2V5RG93bigi XG4iKTsKK01hcmt1cC5kZXNjcmlwdGlvbigiVGhpcyBzZXRzIHRoZSBzZWxlY3Rpb24gdG8gdGhl IHN0YXJ0IG9mIGEgc3BhbiwgYW5kIGhpdHMgdGhlIGVudGVyIGtleS5cbiIKKyAgICArICJFeHBl Y3RlZCBiZWhhdmlvcjogd2hlbiB0aGUgc3BhbiBpcyBzcGxpdCwgaXRzIElEIHNob3VsZCBub3Qg YmUgZHVwbGljYXRlZC4gU2VlIGJ1ZyA2MjYyMS4iKTsKK01hcmt1cC5kdW1wKHJvb3QpOworPC9z Y3JpcHQ+Cis8L2JvZHk+Cis8L2h0bWw+CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9DaGFu Z2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNDU3NjNmMmI5NTI5MjViZmQ0 MGU5ZjFmNWFmMzMwN2I1ZDZmZGMwYy4uN2MwZWE5ZjMzMTg4NGViZDU0ZDE0OWE3YjliMTI5MDk3 OTJkMGE0NyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDExLTA2LTE0ICBBbm5pZSBT dWxsaXZhbiAgPHN1bGxpdmFuQGNocm9taXVtLm9yZz4KKyAgICAgICAgCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFNwYW4gSUQgZHVwbGljYXRlZCB3aGVu IHByZXNzaW5nIGVudGVyIGF0IGJlZ2lubmluZyBvZiBzcGFuCisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD02MjYyMQorCisgICAgICAgIFN0cmlwIGlkIGZy b20gY2xvbmVkIHNwYW4sIHNvIHRoYXQgaXQgaXMgbm90IGR1cGxpY2F0ZWQuCisgICAgICAgIAor ICAgICAgICBUZXN0OiBlZGl0aW5nL2luc2VydGluZy9yZXR1cm4ta2V5LXNwYW4tc3RhcnQuaHRt bAorICAgICAgICAKKyAgICAgICAgKiBlZGl0aW5nL0luc2VydFBhcmFncmFwaFNlcGFyYXRvckNv bW1hbmQuY3BwOgorICAgICAgICAoV2ViQ29yZTo6SW5zZXJ0UGFyYWdyYXBoU2VwYXJhdG9yQ29t bWFuZDo6Y2xvbmVIaWVyYXJjaHlVbmRlck5ld0Jsb2NrKToKKwogMjAxMS0wNi0xNCAgTWljaGFl bCBTYWJvZmYgIDxtc2Fib2ZmQGFwcGxlLmNvbT4KIAogICAgICAgICBSZXZpZXdlZCBieSBKb3Nl cGggUGVjb3Jhcm8uCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9lZGl0aW5nL0luc2VydFBh cmFncmFwaFNlcGFyYXRvckNvbW1hbmQuY3BwIGIvU291cmNlL1dlYkNvcmUvZWRpdGluZy9JbnNl cnRQYXJhZ3JhcGhTZXBhcmF0b3JDb21tYW5kLmNwcAppbmRleCA4Mzg0ZjMwNjkwNjQ0YjQ5MDQ3 NTk2MmY3M2FjNWEyNGFmNmEzMWU5Li5iODBjZTljN2MyMzIwNWQxMWJkMzhiYzEyZGMzNjNlOTlk MjY4NTZlIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9lZGl0aW5nL0luc2VydFBhcmFncmFw aFNlcGFyYXRvckNvbW1hbmQuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL2VkaXRpbmcvSW5zZXJ0 UGFyYWdyYXBoU2VwYXJhdG9yQ29tbWFuZC5jcHAKQEAgLTEzNiw2ICsxMzYsMTEgQEAgUGFzc1Jl ZlB0cjxFbGVtZW50PiBJbnNlcnRQYXJhZ3JhcGhTZXBhcmF0b3JDb21tYW5kOjpjbG9uZUhpZXJh cmNoeVVuZGVyTmV3QmxvY2sKICAgICBSZWZQdHI8RWxlbWVudD4gcGFyZW50ID0gYmxvY2tUb0lu c2VydDsKICAgICBmb3IgKHNpemVfdCBpID0gYW5jZXN0b3JzLnNpemUoKTsgaSAhPSAwOyAtLWkp IHsKICAgICAgICAgUmVmUHRyPEVsZW1lbnQ+IGNoaWxkID0gYW5jZXN0b3JzW2kgLSAxXS0+Y2xv bmVFbGVtZW50V2l0aG91dENoaWxkcmVuKCk7CisgICAgICAgIC8vIEl0IHNob3VsZCBhbHdheXMg YmUgb2theSB0byBkZWxldGUgdGhlIGlkIG9mIGNsb25lZCBlbGVtZW50cywgYmVjYXVzZSB0aGUg Y29kZXBhdGhzIHRoYXQgY2FsbCB0aGlzIG1ldGhvZAorICAgICAgICAvLyBvbmx5IGNhbGwgYXBw ZW5kQmxvY2tQbGFjZWhvbGRlciBhbmQgc2V0RW5kaW5nU2VsZWN0aW9uIGFmdGVyd2FyZCwgd2hp Y2ggbmV2ZXIgZGVsZXRlIHRoZSBvcmlnaW5hbCBub2RlLgorICAgICAgICBFeGNlcHRpb25Db2Rl IGVjID0gMDsKKyAgICAgICAgY2hpbGQtPnJlbW92ZUF0dHJpYnV0ZShpZEF0dHIsIGVjKTsKKyAg ICAgICAgQVNTRVJUKCFlYyk7CiAgICAgICAgIGFwcGVuZE5vZGUoY2hpbGQsIHBhcmVudCk7CiAg ICAgICAgIHBhcmVudCA9IGNoaWxkLnJlbGVhc2UoKTsKICAgICB9Cg== 97208 2011-06-14 18:03:25 -0700 2011-06-14 18:52:05 -0700 Patch bug-62621-20110614180324.patch text/plain 4079 sullivan U3VidmVyc2lvbiBSZXZpc2lvbjogODg4NzMKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5n ZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxvZwppbmRleCAyYjgwMzY2MDMxYTg5MzFkOWZkY2Yy Mzk2NzljOTNjMjg5OGJiMDNkLi44MGVlZGZiNGI3MTkwZmQ4NjQ0MzRiOWZhZjg4OTQ3MzRhZjMw MTdiIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VMb2cKKysrIGIvTGF5b3V0VGVzdHMv Q2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTAtMDYtMTQgIEFubmllIFN1bGxpdmFuICA8 c3VsbGl2YW5AY2hyb21pdW0ub3JnPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q UyEpLgorCisgICAgICAgIFNwYW4gSUQgZHVwbGljYXRlZCB3aGVuIHByZXNzaW5nIGVudGVyIGF0 IGJlZ2lubmluZyBvZiBzcGFuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df YnVnLmNnaT9pZD02MjYyMQorCisgICAgICAgIEFkZGVkIHRlc3QgZm9yIHNwYW4gaWQgbm90IGdl dHRpbmcgZHVwbGljYXRlZCB3aGVuIHNwYW4gaXMgY2xvbmVkLgorCisgICAgICAgICogZWRpdGlu Zy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0LWV4cGVjdGVkLnR4dDogQWRkZWQuCisg ICAgICAgICogZWRpdGluZy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0Lmh0bWw6IEFk ZGVkLgorCiAyMDExLTA2LTE0ICBEaW1pdHJpIEdsYXprb3YgIDxkZ2xhemtvdkBjaHJvbWl1bS5v cmc+CiAKICAgICAgICAgW0Nocm9taXVtXSBUdXJucyBvdXQsIGluc3BlY3Rvci9jb29raWUtcGFy c2VyLmh0bWwgY2FuIHRpbWVvdXQgb3V0LgpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvZWRpdGlu Zy9pbnNlcnRpbmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0LWV4cGVjdGVkLnR4dCBiL0xheW91dFRl c3RzL2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXktc3Bhbi1zdGFydC1leHBlY3RlZC50eHQK bmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMC4uYjdmYmEwNjJkZTg3YWUwYTM1OWUxY2FjODE5YzQ3NTNjN2IxNzZjMQotLS0g L2Rldi9udWxsCisrKyBiL0xheW91dFRlc3RzL2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXkt c3Bhbi1zdGFydC1leHBlY3RlZC50eHQKQEAgLTAsMCArMSw4IEBACitUaGlzIHNldHMgdGhlIHNl bGVjdGlvbiB0byB0aGUgc3RhcnQgb2YgYSBzcGFuLCBhbmQgaGl0cyB0aGUgZW50ZXIga2V5Lgor RXhwZWN0ZWQgYmVoYXZpb3I6IHdoZW4gdGhlIHNwYW4gaXMgc3BsaXQsIGl0cyBJRCBzaG91bGQg bm90IGJlIGR1cGxpY2F0ZWQuIFNlZSBidWcgNjI2MjEuCit8IDxzcGFuPgorfCAgIGlkPSJkdXBl IgorfCAgIDxkaXY+Cit8ICAgICA8c3Bhbj4KK3wgICAgICAgPGJyPgorfCAgICI8I3NlbGVjdGlv bi1jYXJldD5oZWxsbyIKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2VkaXRpbmcvaW5zZXJ0aW5n L3JldHVybi1rZXktc3Bhbi1zdGFydC5odG1sIGIvTGF5b3V0VGVzdHMvZWRpdGluZy9pbnNlcnRp bmcvcmV0dXJuLWtleS1zcGFuLXN0YXJ0Lmh0bWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMC4uYTNkYTA4MWNhMTA5NTgy NjBlMDQzNTY4OTQwODU5NWNhZDU4MzM2YgotLS0gL2Rldi9udWxsCisrKyBiL0xheW91dFRlc3Rz L2VkaXRpbmcvaW5zZXJ0aW5nL3JldHVybi1rZXktc3Bhbi1zdGFydC5odG1sCkBAIC0wLDAgKzEs MTUgQEAKKzwhRE9DVFlQRSBodG1sPgorPGh0bWw+Cis8Ym9keT4KKzxkaXYgY29udGVudGVkaXRh YmxlIGlkPSJyb290Ij48c3BhbiBpZD0iZHVwZSI+aGVsbG88L3NwYW4+PC9kaXY+Cis8c2NyaXB0 IHNyYz0iLi4vLi4vcmVzb3VyY2VzL2R1bXAtYXMtbWFya3VwLmpzIj48L3NjcmlwdD4KKzxzY3Jp cHQ+Cit2YXIgc2VsID0gd2luZG93LmdldFNlbGVjdGlvbigpOworc2VsLnNldFBvc2l0aW9uKGRv Y3VtZW50LmdldEVsZW1lbnRCeUlkKCJkdXBlIiksIDApOworZXZlbnRTZW5kZXIua2V5RG93bigi XG4iKTsKK01hcmt1cC5kZXNjcmlwdGlvbigiVGhpcyBzZXRzIHRoZSBzZWxlY3Rpb24gdG8gdGhl IHN0YXJ0IG9mIGEgc3BhbiwgYW5kIGhpdHMgdGhlIGVudGVyIGtleS5cbiIKKyAgICArICJFeHBl Y3RlZCBiZWhhdmlvcjogd2hlbiB0aGUgc3BhbiBpcyBzcGxpdCwgaXRzIElEIHNob3VsZCBub3Qg YmUgZHVwbGljYXRlZC4gU2VlIGJ1ZyA2MjYyMS4iKTsKK01hcmt1cC5kdW1wKHJvb3QpOworPC9z Y3JpcHQ+Cis8L2JvZHk+Cis8L2h0bWw+CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9DaGFu Z2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggNDU3NjNmMmI5NTI5MjViZmQ0 MGU5ZjFmNWFmMzMwN2I1ZDZmZGMwYy4uN2MwZWE5ZjMzMTg4NGViZDU0ZDE0OWE3YjliMTI5MDk3 OTJkMGE0NyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDExLTA2LTE0ICBBbm5pZSBT dWxsaXZhbiAgPHN1bGxpdmFuQGNocm9taXVtLm9yZz4KKyAgICAgICAgCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFNwYW4gSUQgZHVwbGljYXRlZCB3aGVu IHByZXNzaW5nIGVudGVyIGF0IGJlZ2lubmluZyBvZiBzcGFuCisgICAgICAgIGh0dHBzOi8vYnVn cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD02MjYyMQorCisgICAgICAgIFN0cmlwIGlkIGZy b20gY2xvbmVkIHNwYW4sIHNvIHRoYXQgaXQgaXMgbm90IGR1cGxpY2F0ZWQuCisgICAgICAgIAor ICAgICAgICBUZXN0OiBlZGl0aW5nL2luc2VydGluZy9yZXR1cm4ta2V5LXNwYW4tc3RhcnQuaHRt bAorICAgICAgICAKKyAgICAgICAgKiBlZGl0aW5nL0luc2VydFBhcmFncmFwaFNlcGFyYXRvckNv bW1hbmQuY3BwOgorICAgICAgICAoV2ViQ29yZTo6SW5zZXJ0UGFyYWdyYXBoU2VwYXJhdG9yQ29t bWFuZDo6Y2xvbmVIaWVyYXJjaHlVbmRlck5ld0Jsb2NrKToKKwogMjAxMS0wNi0xNCAgTWljaGFl bCBTYWJvZmYgIDxtc2Fib2ZmQGFwcGxlLmNvbT4KIAogICAgICAgICBSZXZpZXdlZCBieSBKb3Nl cGggUGVjb3Jhcm8uCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9lZGl0aW5nL0luc2VydFBh cmFncmFwaFNlcGFyYXRvckNvbW1hbmQuY3BwIGIvU291cmNlL1dlYkNvcmUvZWRpdGluZy9JbnNl cnRQYXJhZ3JhcGhTZXBhcmF0b3JDb21tYW5kLmNwcAppbmRleCA4Mzg0ZjMwNjkwNjQ0YjQ5MDQ3 NTk2MmY3M2FjNWEyNGFmNmEzMWU5Li5hM2I3NzYxYmZkZDgyY2NlNjAyMTY4NDk5NTUzZjJiNTYy MmE0YjY0IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9lZGl0aW5nL0luc2VydFBhcmFncmFw aFNlcGFyYXRvckNvbW1hbmQuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL2VkaXRpbmcvSW5zZXJ0 UGFyYWdyYXBoU2VwYXJhdG9yQ29tbWFuZC5jcHAKQEAgLTEzNiw2ICsxMzYsMTAgQEAgUGFzc1Jl ZlB0cjxFbGVtZW50PiBJbnNlcnRQYXJhZ3JhcGhTZXBhcmF0b3JDb21tYW5kOjpjbG9uZUhpZXJh cmNoeVVuZGVyTmV3QmxvY2sKICAgICBSZWZQdHI8RWxlbWVudD4gcGFyZW50ID0gYmxvY2tUb0lu c2VydDsKICAgICBmb3IgKHNpemVfdCBpID0gYW5jZXN0b3JzLnNpemUoKTsgaSAhPSAwOyAtLWkp IHsKICAgICAgICAgUmVmUHRyPEVsZW1lbnQ+IGNoaWxkID0gYW5jZXN0b3JzW2kgLSAxXS0+Y2xv bmVFbGVtZW50V2l0aG91dENoaWxkcmVuKCk7CisgICAgICAgIC8vIEl0IHNob3VsZCBhbHdheXMg YmUgb2theSB0byByZW1vdmUgaWQgZnJvbSB0aGUgY2xvbmVkIGVsZW1lbnRzLCBzaW5jZSB0aGUg b3JpZ2luYWxzIGFyZSBub3QgZGVsZXRlZC4KKyAgICAgICAgRXhjZXB0aW9uQ29kZSBlYyA9IDA7 CisgICAgICAgIGNoaWxkLT5yZW1vdmVBdHRyaWJ1dGUoaWRBdHRyLCBlYyk7CisgICAgICAgIEFT U0VSVCghZWMpOwogICAgICAgICBhcHBlbmROb2RlKGNoaWxkLCBwYXJlbnQpOwogICAgICAgICBw YXJlbnQgPSBjaGlsZC5yZWxlYXNlKCk7CiAgICAgfQo=