44969 2010-08-31 11:57:19 -0700 Track the right gesture state during the asynchronous form submission. 2010-09-03 12:49:41 -0700 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED P2 Normal --- 0 jnd webkit-unassigned abarth cevans commit-queue enrica eric inferno mihaip scarybeasts webkit.review.bot oldest_to_newest 272255 0 jnd 2010-08-31 11:57:19 -0700 The following html can bypass chromium's popup blocker (You can also run the attached test case) <form id="frm1" action="http://www.google.com" target="_blank"> <input type="submit" value="Submit"/> </form> <script> var form1 = document.getElementById('frm1'); form1.submit(); </script> It's because WebKit can not provide correct gesture state during the asynchronous form submission. In WebKit, when submitting a form, the FrameLoader::submitForm can get right gesture state to allow or disallow the popup form submission according to setting's m_javaScriptCanOpenWindowsAutomatically (See DOMWindow::allowPopUp) before scheduling the submission. However, in chromium, we keep setting's m_javaScriptCanOpenWindowsAutomatically always true to always schedule any form submissions to allow the embedder (aka browser process) to make the decision by leveraging the chromium's popup blocker feature. In WebKit, the actual form submission is asynchronous and executed in ScheduledFormSubmission::fire, so during the real executing time, we lost the right context to get the right correct gesture state. In chromium, the RenderView::createView tried to call WebFrame::isProcessingUserGesture to get the gesture state when doing the real form submission, since we can not get the active(entered) frame in that time, the ScriptController::processingUserGesture returns true, so chromium thinks the popup submission is gesture-initiated, that is why the above test code bypasses chromium's popup blocker. To fix this issue, we need to express the following logic: if a submission was scheduled in response to a user gesture, set UserGestureIndicator's state to DefinitelyProcessingUserGesture when the submission timer fires; otherwise, set the state to DefinitelyNotProcessingUserGesture during the submission timer fires. (The solution actually is from Andy's comments in bug 34541). The patch will look like ScheduledFormSubmission::ScheduledFormSubmission(PassRefPtr<FormSubmission> submission, bool lockBackForwardList, bool duringLoad, bool wasUserGesture) : ScheduledNavigation(0, submission->lockHistory(), lockBackForwardList, duringLoad, true) , m_submission(submission) , m_haveToldClient(false) , m_wasUserGesture(wasUserGesture) virtual void ScheduledFormSubmission::fire(Frame* frame) { UserGestureIndicator gestureIndicator(m_wasUserGesture ? DefinitelyProcessingUserGesture : DefinitelyNotProcessingUserGesture); ... @Adam, what do you think? 272256 1 66081 jnd 2010-08-31 11:57:53 -0700 Created attachment 66081 test case 272260 2 abarth 2010-08-31 12:02:46 -0700 Yes. That's the right solution. We do something similar is a couple other cases where we need to track the user gesture state across async operations. That's actually why we created UserGestureIndicator in the first place. 272263 3 jnd 2010-08-31 12:05:50 -0700 (In reply to comment #2) > Yes. That's the right solution. We do something similar is a couple other cases where we need to track the user gesture state across async operations. That's actually why we created UserGestureIndicator in the first place. Thanks for super fast response:) Will give a patch after getting up. 272410 4 cevans 2010-08-31 14:55:05 -0700 @jnd, @abarth: we in fact had exactly this logic for exactly this case :) Adam and I added it a while ago in this CL: http://trac.webkit.org/changeset/57313/trunk/WebCore/loader/RedirectScheduler.cpp (plus follow-up fix): http://trac.webkit.org/changeset/59462/trunk/WebCore/loader/RedirectScheduler.cpp However, this subsequent CL seems to have backed part of our changes out: http://trac.webkit.org/changeset/65340/trunk/WebCore/loader/RedirectScheduler.cpp Adding Mihai - do you perhaps remember why the UserGestureIndicator part changed in 65340? 272416 5 mihaip 2010-08-31 15:01:00 -0700 (In reply to comment #4) > However, this subsequent CL seems to have backed part of our changes out: > http://trac.webkit.org/changeset/65340/trunk/WebCore/loader/RedirectScheduler.cpp > > Adding Mihai - do you perhaps remember why the UserGestureIndicator part changed in 65340? It looked like an unused local variable. Now I see that simply creating a UserGestureIndicator instance toggles a static member. I can put it back (perhaps with a comment). 272431 6 mihaip 2010-08-31 15:18:28 -0700 (In reply to comment #5) > It looked like an unused local variable. Now I see that simply creating a UserGestureIndicator instance toggles a static member. I can put it back (perhaps with a comment). It's also weird that fast/events/popup-blocked-to-post-blank.html still passes (based on http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fevents%2Fpopup-blocked-to-post-blank.html) even with my change. 272442 7 cevans 2010-08-31 15:37:42 -0700 @mihaip: unfortunately, the Chromium and Safari pop-up blockers work in totally different ways. Both were broken and I fixed both; but the test only tests the Safari blocker. I don't believe it's possible to test the Chromium blocker with a LayoutTest. I take blame here for not adding a Chromium UI test. Johnny, how bribe-able are you to add such a thing? Pop-up blocking keeps regressing; a Chromium UI test that checks all of the test cases we've been dealing with recently would be invaluable. 272622 8 jnd 2010-08-31 21:37:25 -0700 (In reply to comment #7) > @mihaip: unfortunately, the Chromium and Safari pop-up blockers work in totally different ways. Both were broken and I fixed both; but the test only tests the Safari blocker. I don't believe it's possible to test the Chromium blocker with a LayoutTest. > I take blame here for not adding a Chromium UI test. > Johnny, how bribe-able are you to add such a thing? Pop-up blocking keeps regressing; a Chromium UI test that checks all of the test cases we've been dealing with recently would be invaluable. Hi Chris, Yes, I am sorry I didn't find your original patch. and sure thing, I will add a chrome UI test to address this bug, also I will bring your fix back into WebKit with comments. Thanks! 272797 9 66211 jnd 2010-09-01 07:31:43 -0700 Created attachment 66211 fix patch Hi Adam, Chris, This patch is to bring the Chris's original fix (in r57313 and r594620) back. Since WebKit and Chromium implement popup blocker in different ways, the test fast/events/popup-blocked-to-post-blank.html can not cover this bug in chromium. I will add a browser_test to address this bug in chromium once this patch is landed and taken by chromium trunk. Thanks! 272912 10 66211 abarth 2010-09-01 11:33:45 -0700 Comment on attachment 66211 fix patch View in context: https://bugs.webkit.org/attachment.cgi?id=66211&action=prettypatch Mostly just questions. > WebCore/ChangeLog:9 > + fast/events/popup-blocked-to-post-blank.html can cover the test in WebKit. > + A UI test will be added in chromium to address chromium's bug. Is fast/events/popup-blocked-to-post-blank.html test currently failing? If so, do we need to remove it from the Skipped list? If not, then it doesn't seem to cover this change. > WebCore/loader/RedirectScheduler.cpp:188 > + // Please do not delete the following local variable gestureIndicator definition. > + // The variable gestureIndicator toggles a static gesture state to let WebKit correctly > + // track the user gesture state across async operations. This comment is not needed. Instead, we should have a test that breaks if you remove this line. > WebCore/loader/RedirectScheduler.cpp:324 > bool lockBackForwardList = mustLockBackForwardList(m_frame, UserGestureIndicator::processingUserGesture()) || (submission->state()->formSubmissionTrigger() == SubmittedByJavaScript && m_frame->tree()->parent()); > > - schedule(adoptPtr(new ScheduledFormSubmission(submission, lockBackForwardList, duringLoad))); > + schedule(adoptPtr(new ScheduledFormSubmission(submission, lockBackForwardList, duringLoad, m_frame->loader()->isProcessingUserGesture()))); Why do we use m_frame->loader()->isProcessingUserGesture() here but UserGestureIndicator::processingUserGesture() two lines above? 273372 11 jnd 2010-09-02 06:38:03 -0700 (In reply to comment #10) Thanks, Adam! Please see my inline comments. > Is fast/events/popup-blocked-to-post-blank.html test currently failing? If so, do we need to remove it from the Skipped list? If not, then it doesn't seem to cover this change. At now fast/events/popup-blocked-to-post-blank.html is not failed in WebKit layout test, and I think it does cover this issue, which is to check whether the form submission issued popup window can bypass popup blocker or not. AFAIK this test is not in any skip lists, we can still keep it. (Please correct me if I was wrong). But since Chromium's popup feature is implemented in another way (judgement in embedder), this test can not cover the same issue in Chromium. I will add a Chromium test once this patch is landed and taken by Chromium. Does that make sense? > This comment is not needed. Instead, we should have a test that breaks if you remove this line. Yes, you are right! The reason to add this comment is because the line looks like useless if someone is not familiar with the context. I want to remind him/her. However removing it does not break WebKit, but does break Chromium. so a chromium test case to address this issue is definitely necessary. Like I said in above. I will add that test in chromium. Of course, I will drop this comment in new patch. > Why do we use m_frame->loader()->isProcessingUserGesture() here but UserGestureIndicator::processingUserGesture() two lines above? The reason to use m_frame->loader()->isProcessingUserGesture() is because that call can cover all scenarios of user gesture, but UserGestureIndicator::processingUserGesture() does not. FrameLoader::isProcessingUserGesture() can handle right gesture state in the scenario of form submission when javascript is disabled, can handle right gesture state in the scenario of form submission via href="javascript:form.submit()", can handle right gesture state in the scenario of form submission inside gesture event or non-gesture event (See Event::fromUserGesture). Why the code in two lines above used serGestureIndicator::processingUserGesture(). To be honest, I don't know, but I 'd like to change it to use FrameLoader::isProcessingUserGesture(). Any comments? 273375 12 66365 jnd 2010-09-02 06:56:42 -0700 Created attachment 66365 new patch 273466 13 66365 abarth 2010-09-02 11:24:45 -0700 Comment on attachment 66365 new patch We need a test for this patch. Honestly, the test is more important than the fix in cases like this. Having a test in Chromium-land is nice, but we should have a LayoutTest too, otherwise we're only going to discover regressions after a merge, which is bad news bears. This is common code to all WebKit ports. We should be able to test it with a LayoutTest. 273533 14 cevans 2010-09-02 13:43:44 -0700 @abarth - let us know if you have a way to actually test this in WebKit. The Chromium port actually runs with WebKit's notification of a pop-up blocker _disabled_. Chromium instead relies on WebKit's UserGestureIndicator API returning the correct results at various times, such as in the asynchronous form submission context. (The original patch for this did add a LayoutTest for this with WebKit's pop-up blocker enabled). 273631 15 66365 abarth 2010-09-02 15:47:38 -0700 Comment on attachment 66365 new patch I see. Ok, we'll this is likely to cause us more pain in the future... 273635 16 cevans 2010-09-02 15:51:51 -0700 Thanks, Adam. Johnny - a good Chromium test in the area of pop-up blocking would go some way to lessening any future pain... 273759 17 jnd 2010-09-02 19:49:01 -0700 (In reply to comment #16) > Thanks, Adam. > Johnny - a good Chromium test in the area of pop-up blocking would go some way to lessening any future pain... Thanks Adam, Chris! The chromium test will be added after landing this patch. I will send the cl to you tomorrow.(ooo today) 274033 18 inferno 2010-09-03 10:57:23 -0700 Added commit queue flag so that this gets committed. 274052 19 66365 commit-queue 2010-09-03 11:21:53 -0700 Comment on attachment 66365 new patch Clearing flags on attachment: 66365 Committed r66742: <http://trac.webkit.org/changeset/66742> 274053 20 commit-queue 2010-09-03 11:21:59 -0700 All reviewed patches have been landed. Closing bug. 274134 21 webkit.review.bot 2010-09-03 12:49:41 -0700 http://trac.webkit.org/changeset/66742 might have broken Qt Linux Release The following changes are on the blame list: http://trac.webkit.org/changeset/66742 http://trac.webkit.org/changeset/66743 66081 2010-08-31 11:57:53 -0700 2010-08-31 11:57:53 -0700 test case frame_submission.html text/html 228 jnd PGh0bWw+IAo8Ym9keT4gCjxmb3JtIGlkPSJmcm0xIiBhY3Rpb249Imh0dHA6Ly93d3cuZ29vZ2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiAKPGlucHV0IHR5cGU9InN1Ym1pdCIgdmFsdWU9IlN1Ym1p dCIvPiAKPC9mb3JtPiAKPHNjcmlwdD4gCnZhciBmb3JtMSA9IGRvY3VtZW50LmdldEVsZW1lbnRC eUlkKCdmcm0xJyk7CmZvcm0xLnN1Ym1pdCgpOwo8L3NjcmlwdD4gCjwvYm9keT4gCjwvaHRtbD4g 66211 2010-09-01 07:31:43 -0700 2010-09-02 06:56:42 -0700 fix patch patch001.txt text/plain 3273 jnd SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA2NjYwMCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTggQEAKKzIwMTAtMDktMDEgIEpvaG5ueSBEaW5nICA8am5kQGNocm9taXVtLm9y Zz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBTYXZl IHRoZSBnZXN0dXJlIHN0YXRlIHRvIHRyYWNrIHRoZSB1c2VyIGdlc3R1cmUgc3RhdGUgYWNyb3Nz IGFzeW5jIGZvcm0gc3VibWlzc2lvbi4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcv c2hvd19idWcuY2dpP2lkPTQ0OTY5CisKKyAgICAgICAgZmFzdC9ldmVudHMvcG9wdXAtYmxvY2tl ZC10by1wb3N0LWJsYW5rLmh0bWwgY2FuIGNvdmVyIHRoZSB0ZXN0IGluIFdlYktpdC4KKyAgICAg ICAgQSBVSSB0ZXN0IHdpbGwgYmUgYWRkZWQgaW4gY2hyb21pdW0gdG8gYWRkcmVzcyBjaHJvbWl1 bSdzIGJ1Zy4KKworICAgICAgICAqIGxvYWRlci9SZWRpcmVjdFNjaGVkdWxlci5jcHA6CisgICAg ICAgIChXZWJDb3JlOjpTY2hlZHVsZWRGb3JtU3VibWlzc2lvbjo6U2NoZWR1bGVkRm9ybVN1Ym1p c3Npb24pOgorICAgICAgICAoV2ViQ29yZTo6U2NoZWR1bGVkRm9ybVN1Ym1pc3Npb246OmZpcmUp OgorICAgICAgICAoV2ViQ29yZTo6UmVkaXJlY3RTY2hlZHVsZXI6OnNjaGVkdWxlRm9ybVN1Ym1p c3Npb24pOgorCiAyMDEwLTA4LTI3ICBQaGlsaXBwZSBOb3JtYW5kICA8cG5vcm1hbmRAaWdhbGlh LmNvbT4KIAogICAgICAgICBSZXZpZXdlZCBieSBYYW4gTG9wZXouCkluZGV4OiBXZWJDb3JlL2xv YWRlci9SZWRpcmVjdFNjaGVkdWxlci5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9sb2FkZXIv UmVkaXJlY3RTY2hlZHVsZXIuY3BwCShyZXZpc2lvbiA2NjQ1OCkKKysrIFdlYkNvcmUvbG9hZGVy L1JlZGlyZWN0U2NoZWR1bGVyLmNwcAkod29ya2luZyBjb3B5KQpAQCAtMTcyLDE2ICsxNzIsMjIg QEAgcHJpdmF0ZToKIAogY2xhc3MgU2NoZWR1bGVkRm9ybVN1Ym1pc3Npb24gOiBwdWJsaWMgU2No ZWR1bGVkTmF2aWdhdGlvbiB7CiBwdWJsaWM6Ci0gICAgU2NoZWR1bGVkRm9ybVN1Ym1pc3Npb24o UGFzc1JlZlB0cjxGb3JtU3VibWlzc2lvbj4gc3VibWlzc2lvbiwgYm9vbCBsb2NrQmFja0Zvcndh cmRMaXN0LCBib29sIGR1cmluZ0xvYWQpCisgICAgU2NoZWR1bGVkRm9ybVN1Ym1pc3Npb24oUGFz c1JlZlB0cjxGb3JtU3VibWlzc2lvbj4gc3VibWlzc2lvbiwgYm9vbCBsb2NrQmFja0ZvcndhcmRM aXN0LCBib29sIGR1cmluZ0xvYWQsIGJvb2wgd2FzVXNlckdlc3R1cmUpCiAgICAgICAgIDogU2No ZWR1bGVkTmF2aWdhdGlvbigwLCBzdWJtaXNzaW9uLT5sb2NrSGlzdG9yeSgpLCBsb2NrQmFja0Zv cndhcmRMaXN0LCBkdXJpbmdMb2FkLCB0cnVlKQogICAgICAgICAsIG1fc3VibWlzc2lvbihzdWJt aXNzaW9uKQogICAgICAgICAsIG1faGF2ZVRvbGRDbGllbnQoZmFsc2UpCisgICAgICAgICwgbV93 YXNVc2VyR2VzdHVyZSh3YXNVc2VyR2VzdHVyZSkKICAgICB7CiAgICAgICAgIEFTU0VSVChtX3N1 Ym1pc3Npb24tPnN0YXRlKCkpOwogICAgIH0KIAogICAgIHZpcnR1YWwgdm9pZCBmaXJlKEZyYW1l KiBmcmFtZSkKICAgICB7CisgICAgICAgIC8vIFBsZWFzZSBkbyBub3QgZGVsZXRlIHRoZSBmb2xs b3dpbmcgbG9jYWwgdmFyaWFibGUgZ2VzdHVyZUluZGljYXRvciBkZWZpbml0aW9uLgorICAgICAg ICAvLyBUaGUgdmFyaWFibGUgZ2VzdHVyZUluZGljYXRvciB0b2dnbGVzIGEgc3RhdGljIGdlc3R1 cmUgc3RhdGUgdG8gbGV0IFdlYktpdCBjb3JyZWN0bHkKKyAgICAgICAgLy8gdHJhY2sgdGhlIHVz ZXIgZ2VzdHVyZSBzdGF0ZSBhY3Jvc3MgYXN5bmMgb3BlcmF0aW9ucy4KKyAgICAgICAgVXNlckdl c3R1cmVJbmRpY2F0b3IgZ2VzdHVyZUluZGljYXRvcihtX3dhc1VzZXJHZXN0dXJlID8gRGVmaW5p dGVseVByb2Nlc3NpbmdVc2VyR2VzdHVyZSA6IERlZmluaXRlbHlOb3RQcm9jZXNzaW5nVXNlckdl c3R1cmUpOworCiAgICAgICAgIC8vIFRoZSBzdWJtaXRGb3JtIGZ1bmN0aW9uIHdpbGwgZmluZCBh IHRhcmdldCBmcmFtZSBiZWZvcmUgdXNpbmcgdGhlIHJlZGlyZWN0aW9uIHRpbWVyLgogICAgICAg ICAvLyBOb3cgdGhhdCB0aGUgdGltZXIgaGFzIGZpcmVkLCB3ZSBuZWVkIHRvIHJlcGVhdCB0aGUg c2VjdXJpdHkgY2hlY2sgd2hpY2ggbm9ybWFsbHkgaXMgZG9uZSB3aGVuCiAgICAgICAgIC8vIHNl bGVjdGluZyBhIHRhcmdldCwgaW4gY2FzZSBjb25kaXRpb25zIGhhdmUgY2hhbmdlZC4gT3RoZXIg Y29kZSBwYXRocyBhdm9pZCB0aGlzIGJ5IHRhcmdldGluZwpAQCAtMjExLDYgKzIxNyw3IEBAIHB1 YmxpYzoKIHByaXZhdGU6CiAgICAgUmVmUHRyPEZvcm1TdWJtaXNzaW9uPiBtX3N1Ym1pc3Npb247 CiAgICAgYm9vbCBtX2hhdmVUb2xkQ2xpZW50OworICAgIGJvb2wgbV93YXNVc2VyR2VzdHVyZTsK IH07CiAKIFJlZGlyZWN0U2NoZWR1bGVyOjpSZWRpcmVjdFNjaGVkdWxlcihGcmFtZSogZnJhbWUp CkBAIC0zMTQsNyArMzIxLDcgQEAgdm9pZCBSZWRpcmVjdFNjaGVkdWxlcjo6c2NoZWR1bGVGb3Jt U3VibQogCiAgICAgYm9vbCBsb2NrQmFja0ZvcndhcmRMaXN0ID0gbXVzdExvY2tCYWNrRm9yd2Fy ZExpc3QobV9mcmFtZSwgVXNlckdlc3R1cmVJbmRpY2F0b3I6OnByb2Nlc3NpbmdVc2VyR2VzdHVy ZSgpKSB8fCAoc3VibWlzc2lvbi0+c3RhdGUoKS0+Zm9ybVN1Ym1pc3Npb25UcmlnZ2VyKCkgPT0g U3VibWl0dGVkQnlKYXZhU2NyaXB0ICYmIG1fZnJhbWUtPnRyZWUoKS0+cGFyZW50KCkpOwogCi0g ICAgc2NoZWR1bGUoYWRvcHRQdHIobmV3IFNjaGVkdWxlZEZvcm1TdWJtaXNzaW9uKHN1Ym1pc3Np b24sIGxvY2tCYWNrRm9yd2FyZExpc3QsIGR1cmluZ0xvYWQpKSk7CisgICAgc2NoZWR1bGUoYWRv cHRQdHIobmV3IFNjaGVkdWxlZEZvcm1TdWJtaXNzaW9uKHN1Ym1pc3Npb24sIGxvY2tCYWNrRm9y d2FyZExpc3QsIGR1cmluZ0xvYWQsIG1fZnJhbWUtPmxvYWRlcigpLT5pc1Byb2Nlc3NpbmdVc2Vy R2VzdHVyZSgpKSkpOwogfQogCiB2b2lkIFJlZGlyZWN0U2NoZWR1bGVyOjpzY2hlZHVsZVJlZnJl c2goYm9vbCB3YXNVc2VyR2VzdHVyZSkK 66365 2010-09-02 06:56:42 -0700 2010-09-03 11:21:53 -0700 new patch patch001.txt text/plain 3490 jnd SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA2NjYwMSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTggQEAKKzIwMTAtMDktMDEgIEpvaG5ueSBEaW5nICA8am5kQGNocm9taXVtLm9y Zz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBTYXZl IHRoZSBnZXN0dXJlIHN0YXRlIHRvIHRyYWNrIHRoZSB1c2VyIGdlc3R1cmUgc3RhdGUgYWNyb3Nz IGFzeW5jIGZvcm0gc3VibWlzc2lvbi4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcv c2hvd19idWcuY2dpP2lkPTQ0OTY5CisKKyAgICAgICAgZmFzdC9ldmVudHMvcG9wdXAtYmxvY2tl ZC10by1wb3N0LWJsYW5rLmh0bWwgY2FuIGNvdmVyIHRoZSB0ZXN0IGluIFdlYktpdC4KKyAgICAg ICAgQSBVSSB0ZXN0IHdpbGwgYmUgYWRkZWQgaW4gY2hyb21pdW0gdG8gYWRkcmVzcyBjaHJvbWl1 bSdzIGJ1Zy4KKworICAgICAgICAqIGxvYWRlci9SZWRpcmVjdFNjaGVkdWxlci5jcHA6CisgICAg ICAgIChXZWJDb3JlOjpTY2hlZHVsZWRGb3JtU3VibWlzc2lvbjo6U2NoZWR1bGVkRm9ybVN1Ym1p c3Npb24pOgorICAgICAgICAoV2ViQ29yZTo6U2NoZWR1bGVkRm9ybVN1Ym1pc3Npb246OmZpcmUp OgorICAgICAgICAoV2ViQ29yZTo6UmVkaXJlY3RTY2hlZHVsZXI6OnNjaGVkdWxlRm9ybVN1Ym1p c3Npb24pOgorCiAyMDEwLTA5LTAxICBBbmRyZXkgS29zeWFrb3YgIDxjYXNlcUBjaHJvbWl1bS5v cmc+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgWXVyeSBTZW1pa2hhdHNreS4KSW5kZXg6IFdlYkNv cmUvbG9hZGVyL1JlZGlyZWN0U2NoZWR1bGVyLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2xv YWRlci9SZWRpcmVjdFNjaGVkdWxlci5jcHAJKHJldmlzaW9uIDY2NjAxKQorKysgV2ViQ29yZS9s b2FkZXIvUmVkaXJlY3RTY2hlZHVsZXIuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0xNzIsMTYgKzE3 MiwxOSBAQCBwcml2YXRlOgogCiBjbGFzcyBTY2hlZHVsZWRGb3JtU3VibWlzc2lvbiA6IHB1Ymxp YyBTY2hlZHVsZWROYXZpZ2F0aW9uIHsKIHB1YmxpYzoKLSAgICBTY2hlZHVsZWRGb3JtU3VibWlz c2lvbihQYXNzUmVmUHRyPEZvcm1TdWJtaXNzaW9uPiBzdWJtaXNzaW9uLCBib29sIGxvY2tCYWNr Rm9yd2FyZExpc3QsIGJvb2wgZHVyaW5nTG9hZCkKKyAgICBTY2hlZHVsZWRGb3JtU3VibWlzc2lv bihQYXNzUmVmUHRyPEZvcm1TdWJtaXNzaW9uPiBzdWJtaXNzaW9uLCBib29sIGxvY2tCYWNrRm9y d2FyZExpc3QsIGJvb2wgZHVyaW5nTG9hZCwgYm9vbCB3YXNVc2VyR2VzdHVyZSkKICAgICAgICAg OiBTY2hlZHVsZWROYXZpZ2F0aW9uKDAsIHN1Ym1pc3Npb24tPmxvY2tIaXN0b3J5KCksIGxvY2tC YWNrRm9yd2FyZExpc3QsIGR1cmluZ0xvYWQsIHRydWUpCiAgICAgICAgICwgbV9zdWJtaXNzaW9u KHN1Ym1pc3Npb24pCiAgICAgICAgICwgbV9oYXZlVG9sZENsaWVudChmYWxzZSkKKyAgICAgICAg LCBtX3dhc1VzZXJHZXN0dXJlKHdhc1VzZXJHZXN0dXJlKQogICAgIHsKICAgICAgICAgQVNTRVJU KG1fc3VibWlzc2lvbi0+c3RhdGUoKSk7CiAgICAgfQogCiAgICAgdmlydHVhbCB2b2lkIGZpcmUo RnJhbWUqIGZyYW1lKQogICAgIHsKKyAgICAgICAgVXNlckdlc3R1cmVJbmRpY2F0b3IgZ2VzdHVy ZUluZGljYXRvcihtX3dhc1VzZXJHZXN0dXJlID8gRGVmaW5pdGVseVByb2Nlc3NpbmdVc2VyR2Vz dHVyZSA6IERlZmluaXRlbHlOb3RQcm9jZXNzaW5nVXNlckdlc3R1cmUpOworCiAgICAgICAgIC8v IFRoZSBzdWJtaXRGb3JtIGZ1bmN0aW9uIHdpbGwgZmluZCBhIHRhcmdldCBmcmFtZSBiZWZvcmUg dXNpbmcgdGhlIHJlZGlyZWN0aW9uIHRpbWVyLgogICAgICAgICAvLyBOb3cgdGhhdCB0aGUgdGlt ZXIgaGFzIGZpcmVkLCB3ZSBuZWVkIHRvIHJlcGVhdCB0aGUgc2VjdXJpdHkgY2hlY2sgd2hpY2gg bm9ybWFsbHkgaXMgZG9uZSB3aGVuCiAgICAgICAgIC8vIHNlbGVjdGluZyBhIHRhcmdldCwgaW4g Y2FzZSBjb25kaXRpb25zIGhhdmUgY2hhbmdlZC4gT3RoZXIgY29kZSBwYXRocyBhdm9pZCB0aGlz IGJ5IHRhcmdldGluZwpAQCAtMjExLDYgKzIxNCw3IEBAIHB1YmxpYzoKIHByaXZhdGU6CiAgICAg UmVmUHRyPEZvcm1TdWJtaXNzaW9uPiBtX3N1Ym1pc3Npb247CiAgICAgYm9vbCBtX2hhdmVUb2xk Q2xpZW50OworICAgIGJvb2wgbV93YXNVc2VyR2VzdHVyZTsKIH07CiAKIFJlZGlyZWN0U2NoZWR1 bGVyOjpSZWRpcmVjdFNjaGVkdWxlcihGcmFtZSogZnJhbWUpCkBAIC0zMTEsMTAgKzMxNSwxMCBA QCB2b2lkIFJlZGlyZWN0U2NoZWR1bGVyOjpzY2hlZHVsZUZvcm1TdWJtCiAgICAgLy8gSWYgdGhp cyBpcyBhIGNoaWxkIGZyYW1lIGFuZCB0aGUgZm9ybSBzdWJtaXNzaW9uIHdhcyB0cmlnZ2VyZWQg YnkgYSBzY3JpcHQsIGxvY2sgdGhlIGJhY2svZm9yd2FyZCBsaXN0CiAgICAgLy8gdG8gbWF0Y2gg SUUgYW5kIE9wZXJhLgogICAgIC8vIFNlZSBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1 Zy5jZ2k/aWQ9MzIzODMgZm9yIHRoZSBvcmlnaW5hbCBtb3RpdmF0aW9uIGZvciB0aGlzLgorICAg IGJvb2wgaXNVc2VyR2VzdHVyZSA9IG1fZnJhbWUtPmxvYWRlcigpLT5pc1Byb2Nlc3NpbmdVc2Vy R2VzdHVyZSgpOworICAgIGJvb2wgbG9ja0JhY2tGb3J3YXJkTGlzdCA9IG11c3RMb2NrQmFja0Zv cndhcmRMaXN0KG1fZnJhbWUsIGlzVXNlckdlc3R1cmUpIHx8IChzdWJtaXNzaW9uLT5zdGF0ZSgp LT5mb3JtU3VibWlzc2lvblRyaWdnZXIoKSA9PSBTdWJtaXR0ZWRCeUphdmFTY3JpcHQgJiYgbV9m cmFtZS0+dHJlZSgpLT5wYXJlbnQoKSk7CiAKLSAgICBib29sIGxvY2tCYWNrRm9yd2FyZExpc3Qg PSBtdXN0TG9ja0JhY2tGb3J3YXJkTGlzdChtX2ZyYW1lLCBVc2VyR2VzdHVyZUluZGljYXRvcjo6 cHJvY2Vzc2luZ1VzZXJHZXN0dXJlKCkpIHx8IChzdWJtaXNzaW9uLT5zdGF0ZSgpLT5mb3JtU3Vi bWlzc2lvblRyaWdnZXIoKSA9PSBTdWJtaXR0ZWRCeUphdmFTY3JpcHQgJiYgbV9mcmFtZS0+dHJl ZSgpLT5wYXJlbnQoKSk7Ci0KLSAgICBzY2hlZHVsZShhZG9wdFB0cihuZXcgU2NoZWR1bGVkRm9y bVN1Ym1pc3Npb24oc3VibWlzc2lvbiwgbG9ja0JhY2tGb3J3YXJkTGlzdCwgZHVyaW5nTG9hZCkp KTsKKyAgICBzY2hlZHVsZShhZG9wdFB0cihuZXcgU2NoZWR1bGVkRm9ybVN1Ym1pc3Npb24oc3Vi bWlzc2lvbiwgbG9ja0JhY2tGb3J3YXJkTGlzdCwgZHVyaW5nTG9hZCwgaXNVc2VyR2VzdHVyZSkp KTsKIH0KIAogdm9pZCBSZWRpcmVjdFNjaGVkdWxlcjo6c2NoZWR1bGVSZWZyZXNoKGJvb2wgd2Fz VXNlckdlc3R1cmUpCg==