60010 2011-05-02 22:22:58 -0700 [Chromium]Add clear_autofill flag to hide autofill popup without clear field. 2012-01-31 09:54:55 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) Other OS X 10.5 RESOLVED WONTFIX P2 Normal --- 0 honten webkit-unassigned dcheng dglazkov eric fishd honten isherman jamesr mjs tkent tony oldest_to_newest 396964 0 honten 2011-05-02 22:22:58 -0700 [Chromium]Add clear_autofill flag to hide autofill popup without clear field. 396966 1 92047 honten 2011-05-02 22:33:16 -0700 Created attachment 92047 Patch 396971 2 isherman 2011-05-02 22:42:49 -0700 This doesn't seem like the right approach to me, because we never want to have suggested values in the form fields when the popup is closed. A drag action should accept the suggested values. Once the suggested values are accepted, closing the popup should work normally, without any further changes. 396978 3 honten 2011-05-02 23:04:51 -0700 Ilya, Thank you for your comment. I want to make sure what "Accept" status. As you know, when user changes the selection, didAcceptAutoFillSuggestion() is called. I guess this is the already "Accept" status for the field, right? But after the "Accept" status, user select all string in the field while showing popup window, then starts dragging. In that situation, even if the field is after "Accept", the field string is gone. That is a problem. Or do you mean different "Accept"? Thanks, (In reply to comment #2) > This doesn't seem like the right approach to me, because we never want to have suggested values in the form fields when the popup is closed. A drag action should accept the suggested values. Once the suggested values are accepted, closing the popup should work normally, without any further changes. 396982 4 honten 2011-05-02 23:32:31 -0700 If you say "Accept" means choosing item in autofill popup with keyboard, for example, the following function is called. 1061 void PopupListBox::acceptIndex(int index) 1062 { 1063 // Clear m_acceptedIndexOnAbandon once user accepts the selected index. 1064 if (m_acceptedIndexOnAbandon >= 0) 1065 m_acceptedIndexOnAbandon = -1; 1066 1067 if (index >= numItems()) 1068 return; 1069 1070 if (index < 0) { 1071 if (m_popupClient) { 1072 // Enter pressed with no selection, just close the popup. 1073 hidePopup(); 1074 } 1075 return; 1076 } 1077 1078 if (isSelectableItem(index)) { 1079 RefPtr<PopupListBox> keepAlive(this); 1080 1081 // Hide ourselves first since valueChanged may have numerous side-effects. 1082 hidePopup(); 1083 1084 // Tell the <select> PopupMenuClient what index was selected. 1085 m_popupClient->valueChanged(index); 1086 } 1087 } But, as you know, hidePopup() is the same function which I try to call from startDragging and then the function calls m_popupClient->valueChanged(index); here. Actually valueChange() calls didAcceptAutoFillSuggestion() internally, if we follow the same way as this, we have to call didAcceptAutoFillSuggestion(). But didAcceptAutoFillSuggestion() needs webnode information which is difficult to access outside of m_popupClient. Maybe we can make a special function to accept current index, but it it very long path to access from WebView... What do you think? Thanks, (In reply to comment #3) > Ilya, > > Thank you for your comment. > > I want to make sure what "Accept" status. > > As you know, when user changes the selection, didAcceptAutoFillSuggestion() is called. I guess this is the already "Accept" status for the field, right? > > But after the "Accept" status, user select all string in the field while showing popup window, then starts dragging. > > In that situation, even if the field is after "Accept", the field string is gone. > > That is a problem. > > Or do you mean different "Accept"? > > Thanks, > > > (In reply to comment #2) > > This doesn't seem like the right approach to me, because we never want to have suggested values in the form fields when the popup is closed. A drag action should accept the suggested values. Once the suggested values are accepted, closing the popup should work normally, without any further changes. 397005 5 isherman 2011-05-03 01:25:51 -0700 (In reply to comment #3) > Ilya, > > Thank you for your comment. > > I want to make sure what "Accept" status. > > As you know, when user changes the selection, didAcceptAutoFillSuggestion() is called. I guess this is the already "Accept" status for the field, right? This is the right method to call into. If this is called prior to the drag, then there shouldn't be a need to do anything extra to make sure that the text remains. When I tested locally, I did not see this method being called. However, I did notice that clicking&dragging within the field while the popup is open causes us to switch from Autofill suggestions to single-field Autocomplete suggestions. The form remains in the previewed state -- with all of the autofillable fields showing a preview of what would be filled into them -- but there is no way to accept this Autofill suggestion. This is a bug, and something we should probably fix before tackling http://code.google.com/p/chromium/issues/detail?id=80817 397006 6 isherman 2011-05-03 01:30:16 -0700 (In reply to comment #4) > If you say "Accept" means choosing item in autofill popup with keyboard, for example, the following function is called. > > 1061 void PopupListBox::acceptIndex(int index) > 1062 { > 1063 // Clear m_acceptedIndexOnAbandon once user accepts the selected index. > 1064 if (m_acceptedIndexOnAbandon >= 0) > 1065 m_acceptedIndexOnAbandon = -1; > 1066 > 1067 if (index >= numItems()) > 1068 return; > 1069 > 1070 if (index < 0) { > 1071 if (m_popupClient) { > 1072 // Enter pressed with no selection, just close the popup. > 1073 hidePopup(); > 1074 } > 1075 return; > 1076 } > 1077 > 1078 if (isSelectableItem(index)) { > 1079 RefPtr<PopupListBox> keepAlive(this); > 1080 > 1081 // Hide ourselves first since valueChanged may have numerous side-effects. > 1082 hidePopup(); > 1083 > 1084 // Tell the <select> PopupMenuClient what index was selected. > 1085 m_popupClient->valueChanged(index); > 1086 } > 1087 } > > But, as you know, hidePopup() is the same function which I try to call from startDragging and then the function calls m_popupClient->valueChanged(index); here. > > Actually valueChange() calls didAcceptAutoFillSuggestion() internally, if we follow the same way as this, we have to call didAcceptAutoFillSuggestion(). > > But didAcceptAutoFillSuggestion() needs webnode information which is difficult to access outside of m_popupClient. > > Maybe we can make a special function to accept current index, but it it very long path to access from WebView... This (accepting the current index when a drag is initiated) is probably the right solution -- at least in terms of the functionality it implies. I'm not sure if there is perhaps an easier way to write the code. 397276 7 honten 2011-05-03 12:49:04 -0700 (In reply to comment #5) > When I tested locally, I did not see this method being called. However, I did notice that clicking&dragging within the field while the popup is open causes us to switch from Autofill suggestions to single-field Autocomplete suggestions. The form remains in the previewed state -- with all of the autofillable fields showing a preview of what would be filled into them -- but there is no way to accept this Autofill suggestion. This is a bug, and something we should probably fix before tackling http://code.google.com/p/chromium/issues/detail?id=80817 So you fixed it at http://codereview.chromium.org/6915003/ did you? 397285 8 honten 2011-05-03 12:59:11 -0700 (In reply to comment #6) > This (accepting the current index when a drag is initiated) is probably the right solution -- at least in terms of the functionality it implies. I'm not sure if there is perhaps an easier way to write the code. Hmmm... As you know the function is not exposed to WebView, and the autofill popup window is abstracted as just a popup window like HTML select element popup. Of course, I can add an extra function like acceptCurrectAutoFilled(), but it is too specific to expose the method as a popup menu interface, right? The fundamental problem is autofill popup is mixed up with other popup windows. We should split it apart from the implementation;-( Anyway I'm looking around the source code again if there is a much easier solution or not... 397470 9 isherman 2011-05-03 15:44:58 -0700 (In reply to comment #7) > (In reply to comment #5) > > > When I tested locally, I did not see this method being called. However, I did notice that clicking&dragging within the field while the popup is open causes us to switch from Autofill suggestions to single-field Autocomplete suggestions. The form remains in the previewed state -- with all of the autofillable fields showing a preview of what would be filled into them -- but there is no way to accept this Autofill suggestion. This is a bug, and something we should probably fix before tackling http://code.google.com/p/chromium/issues/detail?id=80817 > > So you fixed it at > http://codereview.chromium.org/6915003/ > did you? Yes indeed. It turned out to be a rather straightforward fix. (In reply to comment #8) > (In reply to comment #6) > > This (accepting the current index when a drag is initiated) is probably the right solution -- at least in terms of the functionality it implies. I'm not sure if there is perhaps an easier way to write the code. > Hmmm... > > As you know the function is not exposed to WebView, and the autofill popup window is abstracted as just a popup window like HTML select element popup. > > Of course, I can add an extra function like acceptCurrectAutoFilled(), but it is too specific to expose the method as a popup menu interface, right? Would something go wrong if we were to add a more general method: acceptSelectedPopupItem() ? 397476 10 honten 2011-05-03 15:54:26 -0700 > (In reply to comment #8) > > (In reply to comment #6) > > > This (accepting the current index when a drag is initiated) is probably the right solution -- at least in terms of the functionality it implies. I'm not sure if there is perhaps an easier way to write the code. > > Hmmm... > > > > As you know the function is not exposed to WebView, and the autofill popup window is abstracted as just a popup window like HTML select element popup. > > > > Of course, I can add an extra function like acceptCurrectAutoFilled(), but it is too specific to expose the method as a popup menu interface, right? > > Would something go wrong if we were to add a more general method: acceptSelectedPopupItem() ? I see. Still I don't know how I should do for <select> popup window though, I'll look into that. Thanks, 400006 11 92677 honten 2011-05-06 19:15:40 -0700 Created attachment 92677 Patch 400007 12 92677 honten 2011-05-06 19:17:11 -0700 Comment on attachment 92677 Patch According to Ilya's suggestion, I added the function to accept autofilled field. Please review. 400053 13 92677 isherman 2011-05-07 02:05:15 -0700 Comment on attachment 92677 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=92677&action=review This looks ok to me, but should definitely get looked at by one of the WebKit API guardians. > Source/WebCore/ChangeLog:5 > + [Chromium]Add clear_autofill flag to hide autofill popup without clear field. nit: This description is out of sync with the code changes. > Source/WebKit/chromium/public/WebView.h:301 > + virtual void acceptCurrectAutoFilled() = 0; nit: Is there any reason not to name this more generally, e.g. """ acceptSelectedPopupItem() """ ? 400336 14 honten 2011-05-08 20:36:16 -0700 Ilya, Thank you for your review. But, as I wrote in Chromium LC, there might have some problem. So the current flow is 1, Autofill overwrap the field and show the completion. Here the node color is yellow. 2, The user selects the range in the yellow field. 3, The user start dragging. 4, Accept the completion and the yellow field is gone. 5, The user drops the text to another field. 6, But the original field stays the accepted text. (Is this Ok???) The reason why I ask you about 6 is this dragged text should be gone from the original filed. But still it stays as is. Maybe when staring dragging, we have to replace the dragged node from original yellow field to white accepted field, don't we? If so, we have to do more tweaking when starting dragging... Thanks, (In reply to comment #13) > (From update of attachment 92677 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=92677&action=review > > This looks ok to me, but should definitely get looked at by one of the WebKit API guardians. > > > Source/WebCore/ChangeLog:5 > > + [Chromium]Add clear_autofill flag to hide autofill popup without clear field. > > nit: This description is out of sync with the code changes. > > > Source/WebKit/chromium/public/WebView.h:301 > > + virtual void acceptCurrectAutoFilled() = 0; > > nit: Is there any reason not to name this more generally, e.g. """ acceptSelectedPopupItem() """ ? 400375 15 isherman 2011-05-09 00:36:37 -0700 (In reply to comment #14) > So the current flow is > 1, Autofill overwrap the field and show the completion. Here the node color is yellow. > 2, The user selects the range in the yellow field. > 3, The user start dragging. > 4, Accept the completion and the yellow field is gone. > 5, The user drops the text to another field. > 6, But the original field stays the accepted text. (Is this Ok???) > > The reason why I ask you about 6 is this dragged text should be gone from the original filed. But still it stays as is. > > Maybe when staring dragging, we have to replace the dragged node from original yellow field to white accepted field, don't we? We should try to make this work exactly the same way it would if the user were to first autofill the form, then drag the filled text. Could you please clarify why this code coupled with the Chromium change does not result in this desired behavior? 403268 16 isherman 2011-05-12 17:20:53 -0700 Maciej, the code revision history tells me you might be familiar with the drag&drop code. Could you weigh in on this patch and the related Chromium one, http://codereview.chromium.org/6902196/ ? Here's a quick summary of the problem, as I understand it: (1) We initiate a drag event for "suggested" (uncommitted) Autofill text in a text field. (2) This drag should cause the text to be committed. (3) When the text is committed, the "suggested" text is cleared; but it is still referenced in the drag state. (4) When the corresponding drop event occurs, we hit an assertion because the referenced selection is orphaned. Do you have any suggestions on how to handle this somewhat unusual situation? 404141 17 honten 2011-05-14 21:40:34 -0700 Maciej, Could you give us your comment or thought? Thanks, (In reply to comment #16) > Maciej, the code revision history tells me you might be familiar with the drag&drop code. Could you weigh in on this patch and the related Chromium one, http://codereview.chromium.org/6902196/ ? > > Here's a quick summary of the problem, as I understand it: > (1) We initiate a drag event for "suggested" (uncommitted) Autofill text in a text field. > (2) This drag should cause the text to be committed. > (3) When the text is committed, the "suggested" text is cleared; but it is still referenced in the drag state. > (4) When the corresponding drop event occurs, we hit an assertion because the referenced selection is orphaned. > > Do you have any suggestions on how to handle this somewhat unusual situation? 404611 18 honten 2011-05-16 11:11:46 -0700 Is there anybody who can comment this problem? (In reply to comment #17) > Maciej, > > Could you give us your comment or thought? > > Thanks, > > (In reply to comment #16) > > Maciej, the code revision history tells me you might be familiar with the drag&drop code. Could you weigh in on this patch and the related Chromium one, http://codereview.chromium.org/6902196/ ? > > > > Here's a quick summary of the problem, as I understand it: > > (1) We initiate a drag event for "suggested" (uncommitted) Autofill text in a text field. > > (2) This drag should cause the text to be committed. > > (3) When the text is committed, the "suggested" text is cleared; but it is still referenced in the drag state. > > (4) When the corresponding drop event occurs, we hit an assertion because the referenced selection is orphaned. > > > > Do you have any suggestions on how to handle this somewhat unusual situation? 404614 19 dglazkov 2011-05-16 11:15:03 -0700 Maciej is probably the completely wrong guy for this question. Daniel perhaps? 404618 20 dcheng 2011-05-16 11:19:11 -0700 Sorry, this is out of my area of knowledge. 404628 21 honten 2011-05-16 11:32:49 -0700 Hmmm.... Is there any other person in mind? (In reply to comment #20) > Sorry, this is out of my area of knowledge. 404645 22 tony 2011-05-16 11:57:39 -0700 (In reply to comment #16) > Maciej, the code revision history tells me you might be familiar with the drag&drop code. Could you weigh in on this patch and the related Chromium one, http://codereview.chromium.org/6902196/ ? > > Here's a quick summary of the problem, as I understand it: > (1) We initiate a drag event for "suggested" (uncommitted) Autofill text in a text field. > (2) This drag should cause the text to be committed. > (3) When the text is committed, the "suggested" text is cleared; but it is still referenced in the drag state. > (4) When the corresponding drop event occurs, we hit an assertion because the referenced selection is orphaned. > > Do you have any suggestions on how to handle this somewhat unusual situation? Is this problem specific to Autofill? For example, if I select and drag text and a dom event fires (e.g., ondragenter) and removes the text I'm dragging, do we hit the same assertion? If so, this might be a bug that needs to be fixed separately. 404650 23 honten 2011-05-16 12:07:39 -0700 Ok, I'll make sure with some test code... (In reply to comment #22) > (In reply to comment #16) > > Maciej, the code revision history tells me you might be familiar with the drag&drop code. Could you weigh in on this patch and the related Chromium one, http://codereview.chromium.org/6902196/ ? > > > > Here's a quick summary of the problem, as I understand it: > > (1) We initiate a drag event for "suggested" (uncommitted) Autofill text in a text field. > > (2) This drag should cause the text to be committed. > > (3) When the text is committed, the "suggested" text is cleared; but it is still referenced in the drag state. > > (4) When the corresponding drop event occurs, we hit an assertion because the referenced selection is orphaned. > > > > Do you have any suggestions on how to handle this somewhat unusual situation? > > Is this problem specific to Autofill? For example, if I select and drag text and a dom event fires (e.g., ondragenter) and removes the text I'm dragging, do we hit the same assertion? > > If so, this might be a bug that needs to be fixed separately. 404936 24 honten 2011-05-16 22:14:00 -0700 Tony, this is not autofill specific problem. It happens with your suggested test pattern. Should I make another bug entry? Thanks, (In reply to comment #23) > Ok, I'll make sure with some test code... > > (In reply to comment #22) > > (In reply to comment #16) > > > Maciej, the code revision history tells me you might be familiar with the drag&drop code. Could you weigh in on this patch and the related Chromium one, http://codereview.chromium.org/6902196/ ? > > > > > > Here's a quick summary of the problem, as I understand it: > > > (1) We initiate a drag event for "suggested" (uncommitted) Autofill text in a text field. > > > (2) This drag should cause the text to be committed. > > > (3) When the text is committed, the "suggested" text is cleared; but it is still referenced in the drag state. > > > (4) When the corresponding drop event occurs, we hit an assertion because the referenced selection is orphaned. > > > > > > Do you have any suggestions on how to handle this somewhat unusual situation? > > > > Is this problem specific to Autofill? For example, if I select and drag text and a dom event fires (e.g., ondragenter) and removes the text I'm dragging, do we hit the same assertion? > > > > If so, this might be a bug that needs to be fixed separately. 405101 25 tony 2011-05-17 09:48:30 -0700 (In reply to comment #24) > Tony, this is not autofill specific problem. It happens with your suggested test pattern. > > Should I make another bug entry? Yes, a new bug for the drag assert would be good. Do we crash in release builds? I think it's fine to get this patch reviewed and landed since the bug you describe is not specific to this patch. 405433 26 honten 2011-05-17 18:15:22 -0700 I filed the issue as https://bugs.webkit.org/show_bug.cgi?id=61008 (In reply to comment #25) > (In reply to comment #24) > > Tony, this is not autofill specific problem. It happens with your suggested test pattern. > > > > Should I make another bug entry? > > Yes, a new bug for the drag assert would be good. Do we crash in release builds? > > I think it's fine to get this patch reviewed and landed since the bug you describe is not specific to this patch. 545461 27 eric 2012-01-30 15:13:29 -0800 It's been 8 months since this was posted. Do we really need this fix? 545505 28 isherman 2012-01-30 15:42:35 -0800 (In reply to comment #27) > It's been 8 months since this was posted. Do we really need this fix? We're currently working to move this UI out of WebKit, so this change should not be necessary within WebKit. 545513 29 92677 eric 2012-01-30 15:50:08 -0800 Comment on attachment 92677 Patch Cleared review? from attachment 92677 so that this bug does not appear in http://webkit.org/pending-review. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again). 546179 30 92677 fishd 2012-01-31 09:54:55 -0800 Comment on attachment 92677 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=92677&action=review >> Source/WebKit/chromium/public/WebView.h:301 >> + virtual void acceptCurrectAutoFilled() = 0; > > nit: Is there any reason not to name this more generally, e.g. """ acceptSelectedPopupItem() """ ? Agreed, the name is wrong. At the very least, it seems like you probably meant to write "Current" instead of "Currect", but I like Ilya's suggestion. 92047 2011-05-02 22:33:16 -0700 2011-05-06 19:15:35 -0700 Patch bug-60010-20110502223314.patch text/plain 4910 honten U3VidmVyc2lvbiBSZXZpc2lvbjogODUzNjkKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvY2hy b21pdW0vQ2hhbmdlTG9nIGIvU291cmNlL1dlYktpdC9jaHJvbWl1bS9DaGFuZ2VMb2cKaW5kZXgg M2Q1NDBlZTQ0MTY0ODRiZjNlMmM0ZjI5M2U5NTNiNTdmNTZkMWQ4Zi4uN2I0NDdjM2YzMDgyMTA3 Yzk2YjY0OWIzMTEzOTQ2ZTA0NGIzNjRjNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9jaHJv bWl1bS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYktpdC9jaHJvbWl1bS9DaGFuZ2VMb2cKQEAg LTEsMyArMSwyMCBAQAorMjAxMS0wNS0wMiAgTmFva2kgVGFrYW5vICA8dGFrYW5vLm5hb2tpQGdt YWlsLmNvbT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAg ICBbQ2hyb21pdW1dQWRkIGNsZWFyX2F1dG9maWxsIGZsYWcgdG8gaGlkZSBhdXRvZmlsbCBwb3B1 cCB3aXRob3V0IGNsZWFyIGZpZWxkLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9z aG93X2J1Zy5jZ2k/aWQ9NjAwMTAKKworICAgICAgICBObyB0ZXN0IGJlY2F1c2UgQXV0b2ZpbGwg Y2Fubm90IGhhdmUgYW55IHRlc3QgZnJhbWV3b3JrIG9uIFdlYktpdC4KKworICAgICAgICAqIHB1 YmxpYy9XZWJBdXRvRmlsbENsaWVudC5oOgorICAgICAgICAoV2ViS2l0OjpXZWJBdXRvRmlsbENs aWVudDo6c2V0Q2xlYXJBdXRvRmlsbCk6IEFkZGVkIHRvIHN3aXRjaCB0byBjbGVhciBhdXRvZmls bGVkIGZpbGVkIG9yIG5vdC4KKyAgICAgICAgKiBwdWJsaWMvV2ViVmlldy5oOiBBZGQgY2xlYXJB dXRvRmlsbCBpbnB1dCBwYXJhbWV0ZXIgZm9yIGhpZGVQb3B1cHMoKS4KKyAgICAgICAgKiBzcmMv V2ViVmlld0ltcGwuY3BwOgorICAgICAgICAoV2ViS2l0OjpXZWJWaWV3SW1wbDo6aGlkZUF1dG9G aWxsUG9wdXApOiBQYXNzIGNsZWFyQXV0b0ZpbGwgcGFyYW1ldGVyIHRvIHNldENsZWFyQXV0b0Zp bGwoKSB0byBjaG9vc2UgY2xlYXIgb3Igbm90LgorICAgICAgICAoV2ViS2l0OjpXZWJWaWV3SW1w bDo6aGlkZVBvcHVwcyk6IFBhc3MgY2xlYXJBdXRvRmlsbCB0byBoaWRlQXV0b0ZpbGxQb3B1cCgp LgorICAgICAgICAqIHNyYy9XZWJWaWV3SW1wbC5oOiBBZGQgY2xlYXJBdXRvRmlsbCBpbnB1dCBw YXJhbWV0ZXIgZm9yIGhpZGVQb3B1cHMoKSBhbmQgaGlkZUF1dG9GaWxsUG9wdXAoKS4KKwogMjAx MS0wNC0yOSAgS2VubmV0aCBSdXNzZWxsICA8a2JyQGdvb2dsZS5jb20+CiAKICAgICAgICAgVW5y ZXZpZXdlZCBidWlsZCBmaXguIFNraXAgV2ViUGFnZU5ld1NlcmlhbGl6ZXJUZXN0LmNwcCBpbiBX aW5kb3dzIG11bHRpLURMTCBidWlsZC4KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvY2hyb21p dW0vcHVibGljL1dlYkF1dG9GaWxsQ2xpZW50LmggYi9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL3B1 YmxpYy9XZWJBdXRvRmlsbENsaWVudC5oCmluZGV4IDYzYjM5YTg2ZWU1NWI2MGY2NjQ2YTIwNDg0 OWY4ZDJkMDFmY2ZkOWQuLmFjNzExYTBlNjdkMmFmZjZmNTg2YzIxNjNjOWViYmIyMGVlMTUyZjUg MTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvY2hyb21pdW0vcHVibGljL1dlYkF1dG9GaWxsQ2xp ZW50LmgKKysrIGIvU291cmNlL1dlYktpdC9jaHJvbWl1bS9wdWJsaWMvV2ViQXV0b0ZpbGxDbGll bnQuaApAQCAtNzYsNiArNzYsOCBAQCBwdWJsaWM6CiAgICAgdmlydHVhbCB2b2lkIHRleHRGaWVs ZERpZENoYW5nZShjb25zdCBXZWJJbnB1dEVsZW1lbnQmKSB7IH0KICAgICB2aXJ0dWFsIHZvaWQg dGV4dEZpZWxkRGlkUmVjZWl2ZUtleURvd24oY29uc3QgV2ViSW5wdXRFbGVtZW50JiwgY29uc3Qg V2ViS2V5Ym9hcmRFdmVudCYpIHsgfQogCisgICAgdmlydHVhbCB2b2lkIHNldENsZWFyQXV0b0Zp bGwoYm9vbCkgeyB9CisKIHByb3RlY3RlZDoKICAgICB+V2ViQXV0b0ZpbGxDbGllbnQoKSB7IH0K IH07CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL3B1YmxpYy9XZWJWaWV3Lmgg Yi9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL3B1YmxpYy9XZWJWaWV3LmgKaW5kZXggM2U5YjNkNmYz YzQ5MjIzNzViNmU3N2JmYjY2ZTQxMTg1ZGMwYjBkYy4uNzE2NjQ5ZWZjNDhiOWMzYWQzYjc2Yjk1 NDBmMmNiZTc4ZmU0ODBjZiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9jaHJvbWl1bS9wdWJs aWMvV2ViVmlldy5oCisrKyBiL1NvdXJjZS9XZWJLaXQvY2hyb21pdW0vcHVibGljL1dlYlZpZXcu aApAQCAtMjk0LDcgKzI5NCw3IEBAIHB1YmxpYzoKICAgICAgICAgaW50IHNlcGFyYXRvckluZGV4 KSA9IDA7CiAKICAgICAvLyBIaWRlcyBhbnkgcG9wdXAgKHN1Z2dlc3Rpb25zLCBzZWxlY3RzLi4u KSB0aGF0IG1pZ2h0IGJlIHNob3dpbmcuCi0gICAgdmlydHVhbCB2b2lkIGhpZGVQb3B1cHMoKSA9 IDA7CisgICAgdmlydHVhbCB2b2lkIGhpZGVQb3B1cHMoYm9vbCBjbGVhckF1dG9GaWxsID0gdHJ1 ZSkgPSAwOwogCiAKICAgICAvLyBDb250ZXh0IG1lbnUgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJL aXQvY2hyb21pdW0vc3JjL1dlYlZpZXdJbXBsLmNwcCBiL1NvdXJjZS9XZWJLaXQvY2hyb21pdW0v c3JjL1dlYlZpZXdJbXBsLmNwcAppbmRleCBiNGFmN2MxNTQzZDY4N2VmYTAyNTkyYjUxYzY1MTFj NThhOTlmNmViLi5lMDcwOTZmOWFiZjUyZjgxMjRjNDUyMTQ0ZmZkNDUxNjRhZTI3NTNiIDEwMDY0 NAotLS0gYS9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL3NyYy9XZWJWaWV3SW1wbC5jcHAKKysrIGIv U291cmNlL1dlYktpdC9jaHJvbWl1bS9zcmMvV2ViVmlld0ltcGwuY3BwCkBAIC05MjAsMTAgKzky MCwxNCBAQCB2b2lkICBXZWJWaWV3SW1wbDo6cG9wdXBDbG9zZWQoV2ViQ29yZTo6UG9wdXBDb250 YWluZXIqIHBvcHVwQ29udGFpbmVyKQogICAgIH0KIH0KIAotdm9pZCBXZWJWaWV3SW1wbDo6aGlk ZUF1dG9GaWxsUG9wdXAoKQordm9pZCBXZWJWaWV3SW1wbDo6aGlkZUF1dG9GaWxsUG9wdXAoYm9v bCBjbGVhckF1dG9GaWxsKQogewogICAgIGlmIChtX2F1dG9GaWxsUG9wdXBTaG93aW5nKSB7Cisg ICAgICAgIC8vIE9ubHkgaWYgY2xlYXJBdXRvRmlsbCBpcyBub3Qgc2V0LCB3ZSBkb24ndCB3YW50 IHRvIGNsZWFyIGF1dG9maWxsZWQgZmllbGQuCisgICAgICAgIC8vIEZvciBleGFtcGxlLCB3aGVu IGRyYWdnaW5nIHN0YXJ0cywgd2Ugd2FudCB0byBjbG9zZSBhdXRvZmlsbCBwb3B1cCB3aW5kb3cg YnV0IGRvbid0IGNsZWFyIHRoZSBmaWVsZC4KKyAgICAgICAgYXV0b0ZpbGxDbGllbnQoKS0+c2V0 Q2xlYXJBdXRvRmlsbChjbGVhckF1dG9GaWxsKTsKICAgICAgICAgbV9hdXRvRmlsbFBvcHVwLT5o aWRlUG9wdXAoKTsKKyAgICAgICAgYXV0b0ZpbGxDbGllbnQoKS0+c2V0Q2xlYXJBdXRvRmlsbCh0 cnVlKTsKICAgICAgICAgbV9hdXRvRmlsbFBvcHVwU2hvd2luZyA9IGZhbHNlOwogICAgIH0KIH0K QEAgLTIwODcsMTAgKzIwOTEsMTAgQEAgdm9pZCBXZWJWaWV3SW1wbDo6YXBwbHlBdXRvRmlsbFN1 Z2dlc3Rpb25zKAogICAgIH0KIH0KIAotdm9pZCBXZWJWaWV3SW1wbDo6aGlkZVBvcHVwcygpCit2 b2lkIFdlYlZpZXdJbXBsOjpoaWRlUG9wdXBzKGJvb2wgY2xlYXJBdXRvRmlsbCkKIHsKICAgICBo aWRlU2VsZWN0UG9wdXAoKTsKLSAgICBoaWRlQXV0b0ZpbGxQb3B1cCgpOworICAgIGhpZGVBdXRv RmlsbFBvcHVwKGNsZWFyQXV0b0ZpbGwpOwogfQogCiB2b2lkIFdlYlZpZXdJbXBsOjpwZXJmb3Jt Q3VzdG9tQ29udGV4dE1lbnVBY3Rpb24odW5zaWduZWQgYWN0aW9uKQpkaWZmIC0tZ2l0IGEvU291 cmNlL1dlYktpdC9jaHJvbWl1bS9zcmMvV2ViVmlld0ltcGwuaCBiL1NvdXJjZS9XZWJLaXQvY2hy b21pdW0vc3JjL1dlYlZpZXdJbXBsLmgKaW5kZXggNTlhY2UzNzkyMmFkNTFmNzgwYWU0Zjg1ZmYy MDBjYmM1ZTFhMzY5YS4uOTQ2MGM4NjFiOTcwNDFhNWNhZDE3NjIzZmNlN2E2MjIwMTZkMjU2NCAx MDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9jaHJvbWl1bS9zcmMvV2ViVmlld0ltcGwuaAorKysg Yi9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL3NyYy9XZWJWaWV3SW1wbC5oCkBAIC0xODksNyArMTg5 LDcgQEAgcHVibGljOgogICAgICAgICBjb25zdCBXZWJWZWN0b3I8V2ViU3RyaW5nPiYgaWNvbnMs CiAgICAgICAgIGNvbnN0IFdlYlZlY3RvcjxpbnQ+JiB1bmlxdWVJRHMsCiAgICAgICAgIGludCBz ZXBhcmF0b3JJbmRleCk7Ci0gICAgdmlydHVhbCB2b2lkIGhpZGVQb3B1cHMoKTsKKyAgICB2aXJ0 dWFsIHZvaWQgaGlkZVBvcHVwcyhib29sIGNsZWFyQXV0b0ZpbGwgPSB0cnVlKTsKICAgICB2aXJ0 dWFsIHZvaWQgc2V0U2Nyb2xsYmFyQ29sb3JzKHVuc2lnbmVkIGluYWN0aXZlQ29sb3IsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBhY3RpdmVDb2xvciwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIHRyYWNrQ29sb3IpOwpA QCAtMzMxLDcgKzMzMSw3IEBAIHB1YmxpYzoKICAgICB2b2lkIHBvcHVwT3BlbmVkKFdlYkNvcmU6 OlBvcHVwQ29udGFpbmVyKiBwb3B1cENvbnRhaW5lcik7CiAgICAgdm9pZCBwb3B1cENsb3NlZChX ZWJDb3JlOjpQb3B1cENvbnRhaW5lciogcG9wdXBDb250YWluZXIpOwogCi0gICAgdm9pZCBoaWRl QXV0b0ZpbGxQb3B1cCgpOworICAgIHZvaWQgaGlkZUF1dG9GaWxsUG9wdXAoYm9vbCBjbGVhckF1 dG9GaWxsID0gdHJ1ZSk7CiAKICAgICAvLyBSZXR1cm5zIHRoZSBpbnB1dCBldmVudCB3ZSdyZSBj dXJyZW50bHkgcHJvY2Vzc2luZy4gVGhpcyBpcyB1c2VkIGluIHNvbWUKICAgICAvLyBjYXNlcyB3 aGVyZSB0aGUgV2ViQ29yZSBET00gZXZlbnQgZG9lc24ndCBoYXZlIHRoZSBpbmZvcm1hdGlvbiB3 ZSBuZWVkLgo= 92677 2011-05-06 19:15:40 -0700 2012-01-31 09:54:55 -0800 Patch bug-60010-20110506191539.patch text/plain 4958 honten U3VidmVyc2lvbiBSZXZpc2lvbjogODU5NTQKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCBjNzMwNjMzOGI0Y2Q4NzEy Y2RjYWU5ZDZkYmZiMmNlOWM3MTg5MmJmLi5lOGY5NmQwYjQxNTg5YjQ5YzM0NjAyNTAzZWQzODY4 MTAzMmFjZGMzIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTYgQEAKKzIwMTEtMDUtMDYgIE5hb2tp IFRha2FubyAgPHRha2Fuby5uYW9raUBnbWFpbC5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkg Tk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgW0Nocm9taXVtXUFkZCBjbGVhcl9hdXRvZmlsbCBm bGFnIHRvIGhpZGUgYXV0b2ZpbGwgcG9wdXAgd2l0aG91dCBjbGVhciBmaWVsZC4KKyAgICAgICAg aHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTYwMDEwCisKKyAgICAgICAg Tm8gbmV3IHRlc3QgYmVjYXVzZSB3ZSBkb24ndCBoYXZlIGFueSBwb3B1cCBtZW51IHRlc3QgZnJh bWV3b3JrLgorCisgICAgICAgICogcGxhdGZvcm0vY2hyb21pdW0vUG9wdXBNZW51Q2hyb21pdW0u Y3BwOgorICAgICAgICAoV2ViQ29yZTo6UG9wdXBDb250YWluZXI6OmFjY2VwdEN1cnJlbnQpOiBB ZGRlZCB0byBhY2NlcHQgdGhlIGN1cnJlbnQgc2VsZWN0ZWQgbV9saXN0Qm94IGl0ZW0uCisgICAg ICAgICogcGxhdGZvcm0vY2hyb21pdW0vUG9wdXBNZW51Q2hyb21pdW0uaDogQWRkZWQgYWNjZXB0 Q3VycmVudCgpIGRlY2xhcmF0aW9uLgorCiAyMDExLTA1LTA2ICBFcmljIENhcmxzb24gIDxlcmlj LmNhcmxzb25AYXBwbGUuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IERhcmluIEFkbGVyLgpk aWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vY2hyb21pdW0vUG9wdXBNZW51Q2hy b21pdW0uY3BwIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vY2hyb21pdW0vUG9wdXBNZW51Q2hy b21pdW0uY3BwCmluZGV4IDk2NWNjZDU4YjFkNTY1ZmRlY2I5MWY3YjI0OWVlZTA3NWU0NDY2Nzgu LjA0MDE5ZjkwODBjNzJmNDU1ZmNiNWRlZDVmMTgzOTA2OTYxOGFlMWUgMTAwNjQ0Ci0tLSBhL1Nv dXJjZS9XZWJDb3JlL3BsYXRmb3JtL2Nocm9taXVtL1BvcHVwTWVudUNocm9taXVtLmNwcAorKysg Yi9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9jaHJvbWl1bS9Qb3B1cE1lbnVDaHJvbWl1bS5jcHAK QEAgLTYwMSw2ICs2MDEsMTEgQEAgUG9wdXBNZW51U3R5bGUgUG9wdXBDb250YWluZXI6Om1lbnVT dHlsZSgpIGNvbnN0CiAgICAgcmV0dXJuIG1fbGlzdEJveC0+bV9wb3B1cENsaWVudC0+bWVudVN0 eWxlKCk7CiB9CiAKK3ZvaWQgUG9wdXBDb250YWluZXI6OmFjY2VwdEN1cnJlbnQoKQoreworICAg IHJldHVybiBtX2xpc3RCb3gtPmFjY2VwdEluZGV4KG1fbGlzdEJveC0+bV9zZWxlY3RlZEluZGV4 KTsKK30KKwogY29uc3QgV1RGOjpWZWN0b3I8UG9wdXBJdGVtKj4mIFBvcHVwQ29udGFpbmVyOjog cG9wdXBEYXRhKCkgY29uc3QKIHsKICAgICByZXR1cm4gbV9saXN0Qm94LT5pdGVtcygpOwpkaWZm IC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vY2hyb21pdW0vUG9wdXBNZW51Q2hyb21p dW0uaCBiL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL2Nocm9taXVtL1BvcHVwTWVudUNocm9taXVt LmgKaW5kZXggMzQzNjY1MDAxZDk3YTMyZTFlNmFlNmQ0YjM5NTBhOGMwM2NhNDI5ZC4uNzVmMjUz NjM0MDQ1MGUwMTc1N2I4YmU2ODgzYzdkYzc5NDkxYzJkMCAxMDA2NDQKLS0tIGEvU291cmNlL1dl YkNvcmUvcGxhdGZvcm0vY2hyb21pdW0vUG9wdXBNZW51Q2hyb21pdW0uaAorKysgYi9Tb3VyY2Uv V2ViQ29yZS9wbGF0Zm9ybS9jaHJvbWl1bS9Qb3B1cE1lbnVDaHJvbWl1bS5oCkBAIC0xNjcsNiAr MTY3LDkgQEAgcHVibGljOgogCiAgICAgUG9wdXBUeXBlIHBvcHVwVHlwZSgpIGNvbnN0IHsgcmV0 dXJuIG1fcG9wdXBUeXBlOyB9CiAKKyAgICAvLyBBY2NlcHQgY3VycmVudCBzZWxlY3RlZCBpdGVt LgorICAgIHZvaWQgYWNjZXB0Q3VycmVudCgpOworCiBwcml2YXRlOgogICAgIGZyaWVuZCBjbGFz cyBXVEY6OlJlZkNvdW50ZWQ8UG9wdXBDb250YWluZXI+OwogCmRpZmYgLS1naXQgYS9Tb3VyY2Uv V2ViS2l0L2Nocm9taXVtL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvY2hyb21pdW0vQ2hhbmdl TG9nCmluZGV4IDNmODk2NTdlZjQzZjhiZmE2YzhjOTRkMzIzZjM3OThjYmIzYzBlZWMuLjFmZjZh NzExZjRmODg3YzdkMmUyNzEwYTNjNzFjNWY1YmJmZmIyNjUgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9X ZWJLaXQvY2hyb21pdW0vQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XZWJLaXQvY2hyb21pdW0vQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTEtMDUtMDYgIE5hb2tpIFRha2FubyAgPHRha2Fu by5uYW9raUBnbWFpbC5jb20+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISku CisKKyAgICAgICAgW0Nocm9taXVtXUFkZCBjbGVhcl9hdXRvZmlsbCBmbGFnIHRvIGhpZGUgYXV0 b2ZpbGwgcG9wdXAgd2l0aG91dCBjbGVhciBmaWVsZC4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTYwMDEwCisKKyAgICAgICAgKiBwdWJsaWMvV2ViVmll dy5oOiBBZGRlZCBkZWNsYXJhdGlvbiBvZiBhY2NlcHRDdXJyZWN0QXV0b0ZpbGxlZCgpLgorICAg ICAgICAqIHNyYy9XZWJWaWV3SW1wbC5jcHA6CisgICAgICAgIChXZWJLaXQ6OldlYlZpZXdJbXBs OjphY2NlcHRDdXJyZWN0QXV0b0ZpbGxlZCk6IEFkZGVkIHRoZSBmdW5jdGlvbiB0byBhY2NlcHQg dGhlIGN1cnJlbnQgYXV0b2ZpbGxlZCBmaWVsZCBpdGVtLgorICAgICAgICAqIHNyYy9XZWJWaWV3 SW1wbC5oOiBBZGRlZCBkZWNsYXJhdGlvbiBvZiBhY2NlcHRDdXJyZWN0QXV0b0ZpbGxlZCgpLgor CiAyMDExLTA1LTA2ICBTaGVyaWZmIEJvdCAgPHdlYmtpdC5yZXZpZXcuYm90QGdtYWlsLmNvbT4K IAogICAgICAgICBVbnJldmlld2VkLCByb2xsaW5nIG91dCByODU5MTkuCmRpZmYgLS1naXQgYS9T b3VyY2UvV2ViS2l0L2Nocm9taXVtL3B1YmxpYy9XZWJWaWV3LmggYi9Tb3VyY2UvV2ViS2l0L2No cm9taXVtL3B1YmxpYy9XZWJWaWV3LmgKaW5kZXggM2U5YjNkNmYzYzQ5MjIzNzViNmU3N2JmYjY2 ZTQxMTg1ZGMwYjBkYy4uODFkNzg0YmMxZDliMTVhMjFmNmQ4ZWJhMjA4N2ZhMzdkM2Q3YmIyYiAx MDA2NDQKLS0tIGEvU291cmNlL1dlYktpdC9jaHJvbWl1bS9wdWJsaWMvV2ViVmlldy5oCisrKyBi L1NvdXJjZS9XZWJLaXQvY2hyb21pdW0vcHVibGljL1dlYlZpZXcuaApAQCAtMjk2LDYgKzI5Niw5 IEBAIHB1YmxpYzoKICAgICAvLyBIaWRlcyBhbnkgcG9wdXAgKHN1Z2dlc3Rpb25zLCBzZWxlY3Rz Li4uKSB0aGF0IG1pZ2h0IGJlIHNob3dpbmcuCiAgICAgdmlydHVhbCB2b2lkIGhpZGVQb3B1cHMo KSA9IDA7CiAKKyAgICAvLyBBY2NlcHQgY3VycmVudCBhdXRvZmlsbGVkIGZpZWxkLiBUaGUgZnVu Y3Rpb24gaXMgdXNlZCB0byBjbG9zZSBhdXRvZmlsbAorICAgIC8vIHBvcHVwIHdpbmRvdyBhbmQg bm90IHRvIGNsZWFyIHRoZSBmaWVsZC4KKyAgICB2aXJ0dWFsIHZvaWQgYWNjZXB0Q3VycmVjdEF1 dG9GaWxsZWQoKSA9IDA7CiAKICAgICAvLyBDb250ZXh0IG1lbnUgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIApkaWZmIC0tZ2l0IGEvU291 cmNlL1dlYktpdC9jaHJvbWl1bS9zcmMvV2ViVmlld0ltcGwuY3BwIGIvU291cmNlL1dlYktpdC9j aHJvbWl1bS9zcmMvV2ViVmlld0ltcGwuY3BwCmluZGV4IDY2ZTkyMDk4MTkwYzY3ZDY3YTg4NDJk YzlhYWI4NzEwODM3ZDUxZmEuLmI3ZjQ2MWY4ZTYxZTVkNjM2NDdiZmI2ODE2NTk3Mzc4ZTViZjU1 ZTkgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvY2hyb21pdW0vc3JjL1dlYlZpZXdJbXBsLmNw cAorKysgYi9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL3NyYy9XZWJWaWV3SW1wbC5jcHAKQEAgLTkx OCw2ICs5MTgsMTEgQEAgdm9pZCAgV2ViVmlld0ltcGw6OnBvcHVwQ2xvc2VkKFdlYkNvcmU6OlBv cHVwQ29udGFpbmVyKiBwb3B1cENvbnRhaW5lcikKICAgICB9CiB9CiAKK3ZvaWQgV2ViVmlld0lt cGw6OmFjY2VwdEN1cnJlY3RBdXRvRmlsbGVkKCkKK3sKKyAgICBtX2F1dG9GaWxsUG9wdXAtPmFj Y2VwdEN1cnJlbnQoKTsKK30KKwogdm9pZCBXZWJWaWV3SW1wbDo6aGlkZUF1dG9GaWxsUG9wdXAo KQogewogICAgIGlmIChtX2F1dG9GaWxsUG9wdXBTaG93aW5nKSB7CmRpZmYgLS1naXQgYS9Tb3Vy Y2UvV2ViS2l0L2Nocm9taXVtL3NyYy9XZWJWaWV3SW1wbC5oIGIvU291cmNlL1dlYktpdC9jaHJv bWl1bS9zcmMvV2ViVmlld0ltcGwuaAppbmRleCBkOGQ5MmE4ZWQ3ZDI1YmM4MmFlMTgxMGU4ZWY1 YzM5NTYxNTNkODY3Li5kYWFmOTRiYTM4OTcyNTU4ZTU3ZjBlMTRiNDQwYTU1Y2VkNjM3YjdkIDEw MDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0L2Nocm9taXVtL3NyYy9XZWJWaWV3SW1wbC5oCisrKyBi L1NvdXJjZS9XZWJLaXQvY2hyb21pdW0vc3JjL1dlYlZpZXdJbXBsLmgKQEAgLTE5MCw2ICsxOTAs NyBAQCBwdWJsaWM6CiAgICAgICAgIGNvbnN0IFdlYlZlY3RvcjxpbnQ+JiB1bmlxdWVJRHMsCiAg ICAgICAgIGludCBzZXBhcmF0b3JJbmRleCk7CiAgICAgdmlydHVhbCB2b2lkIGhpZGVQb3B1cHMo KTsKKyAgICB2aXJ0dWFsIHZvaWQgYWNjZXB0Q3VycmVjdEF1dG9GaWxsZWQoKTsKICAgICB2aXJ0 dWFsIHZvaWQgc2V0U2Nyb2xsYmFyQ29sb3JzKHVuc2lnbmVkIGluYWN0aXZlQ29sb3IsCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBhY3RpdmVDb2xvciwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIHRyYWNrQ29sb3IpOwo=