89114 2012-06-14 11:56:56 -0700 REGRESSION (r112919): Setting scrollTop after setting display from none to block fails 2012-07-25 18:15:37 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) All All RESOLVED FIXED InRadar P1 Normal --- 1 simon.fraser bdakin bdakin eric jchaffraix rakeshchaitan simon.fraser thorton tkent webkit-bug-importer webkit.review.bot oldest_to_newest 649355 0 simon.fraser 2012-06-14 11:56:56 -0700 The attached testcase shows a bug in setting scrollTop after toggling display: from 'none' to 'block'. This regressed in http://trac.webkit.org/changeset/112919, bug 72852. 649357 1 simon.fraser 2012-06-14 11:57:25 -0700 <rdar://problem/11656050> 649405 2 jchaffraix 2012-06-14 13:04:13 -0700 Simon, it looks like the test case didn't make it to the bug. 649416 3 147637 simon.fraser 2012-06-14 13:17:00 -0700 Created attachment 147637 Testcase 649432 4 jchaffraix 2012-06-14 13:31:47 -0700 I wonder if this is a regression from bug 72852. Testing on a Chromium build from last week (WebKit revision 119830), I don't see the bug. Yet on today's Canary (WebKit r120277), I do. 649435 5 thorton 2012-06-14 13:33:45 -0700 (In reply to comment #4) > I wonder if this is a regression from bug 72852. > > Testing on a Chromium build from last week (WebKit revision 119830), I don't see the bug. Yet on today's Canary (WebKit r120277), I do. I believe that has already been confirmed. 650049 6 rakeshchaitan 2012-06-15 02:56:17 -0700 I could not reproduce this issue on r120414. 652611 7 simon.fraser 2012-06-19 11:03:10 -0700 I can still reproduce in a TOT Mac build (the testcase should say "after: 0" at the end. 657654 8 jchaffraix 2012-06-26 09:37:41 -0700 (In reply to comment #7) > I can still reproduce in a TOT Mac build (the testcase should say "after: 0" at the end. There seems to be some platform differences playing here. I couldn't reproduce the issue on Linux (using Qt or Chromium) but I saw it on Snow-Leopard (Chromium or Mac). 677508 9 bdakin 2012-07-24 19:00:47 -0700 I think I understand what's going on here, and I have an idea for a fix. Taking the bug. 677606 10 154247 bdakin 2012-07-24 21:55:02 -0700 Created attachment 154247 Patch 678147 11 154247 mitz 2012-07-25 09:21:33 -0700 Comment on attachment 154247 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=154247&action=review > Source/WebCore/ChangeLog:11 > + ScrollAnimatorMac::immediateScrollTo() and ScrollAnimatorMac::immediateScrollTo() Did you mean a different function the second time? 678153 12 154247 jchaffraix 2012-07-25 09:30:55 -0700 Comment on attachment 154247 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=154247&action=review Good catch! > Source/WebCore/rendering/RenderLayer.cpp:200 > m_scrollOffset = element->savedLayerScrollOffset(); > + if (!m_scrollOffset.isZero()) > + scrollAnimator()->setCurrentPosition(FloatPoint(m_scrollOffset.width(), m_scrollOffset.height())); I think those lines should just be: scrollToOffset(element->savedLayerScrollOffset()); The rationale being that we need to dispatch a 'scroll' event so that JS can also update its position. On top of that, it integrates more nicely in the existing code. > LayoutTests/fast/overflow/setting-scrollTop-after-hide-show-expected.txt:1 > +before: 20 Could it be possible to dump more information about what is expected? The current result is difficult to read for people not familiar with this bug. > LayoutTests/fast/overflow/setting-scrollTop-after-hide-show-expected.txt:3 > +after: 0 before / after don't really speak to me, especially since they refer to the final setting. Writting the following would be more readable: * scrollTop after restoring it * scrollTop after setting it back to 0 > LayoutTests/fast/overflow/setting-scrollTop-after-hide-show.html:23 > + log('before: ' + a.scrollTop + '\n'); I think using our JS testing framework would make the expected output better (shouldBe("a.scrollTop", "20")) as it would document what you expect. 678235 13 bdakin 2012-07-25 10:53:38 -0700 (In reply to comment #11) > (From update of attachment 154247 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=154247&action=review > > > Source/WebCore/ChangeLog:11 > > + ScrollAnimatorMac::immediateScrollTo() and ScrollAnimatorMac::immediateScrollTo() > > Did you mean a different function the second time? Oops! Yes, I meant immediateScrollBy for the second one. Will fix. 678242 14 bdakin 2012-07-25 11:03:15 -0700 (In reply to comment #12) > (From update of attachment 154247 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=154247&action=review > > Good catch! > > > Source/WebCore/rendering/RenderLayer.cpp:200 > > m_scrollOffset = element->savedLayerScrollOffset(); > > + if (!m_scrollOffset.isZero()) > > + scrollAnimator()->setCurrentPosition(FloatPoint(m_scrollOffset.width(), m_scrollOffset.height())); > > I think those lines should just be: > > scrollToOffset(element->savedLayerScrollOffset()); > > The rationale being that we need to dispatch a 'scroll' event so that JS can also update its position. On top of that, it integrates more nicely in the existing code. > We definitely do NOT want to get rid of the if-statement. Otherwise will create ScrollAnimators for all layers with Element nodes. This has been a memory footprint issue that we have worked to control and reduce in the past. In terms of the JS argument…is there really a JS bug left here? I think my test case demonstrates that there is not a JS bug because when JS asks for the scrollTop, it will update layout, and everything will be right. I am happy to go with scrollToOffset() instead of setCurrentPosition() if there is actually a bug that would be fixed by that, but otherwise, scrollToOffset does a lot of work that does not seem necessary at this time. > > LayoutTests/fast/overflow/setting-scrollTop-after-hide-show-expected.txt:1 > > +before: 20 > > Could it be possible to dump more information about what is expected? The current result is difficult to read for people not familiar with this bug. > > > LayoutTests/fast/overflow/setting-scrollTop-after-hide-show-expected.txt:3 > > +after: 0 > > before / after don't really speak to me, especially since they refer to the final setting. Writting the following would be more readable: > * scrollTop after restoring it > * scrollTop after setting it back to 0 > > > LayoutTests/fast/overflow/setting-scrollTop-after-hide-show.html:23 > > + log('before: ' + a.scrollTop + '\n'); > Yes, your suggestion is definitely better. Will fix. 678264 15 bdakin 2012-07-25 11:16:32 -0700 Committed with http://trac.webkit.org/changeset/123637 I will definitely change that setCurrentPosition() call to a scrollToOffset() if there is a bug leftover there. But I haven't found one yet. 678273 16 154247 jchaffraix 2012-07-25 11:21:29 -0700 Comment on attachment 154247 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=154247&action=review >>> Source/WebCore/rendering/RenderLayer.cpp:200 >>> + scrollAnimator()->setCurrentPosition(FloatPoint(m_scrollOffset.width(), m_scrollOffset.height())); >> >> I think those lines should just be: >> >> scrollToOffset(element->savedLayerScrollOffset()); >> >> The rationale being that we need to dispatch a 'scroll' event so that JS can also update its position. On top of that, it integrates more nicely in the existing code. > > We definitely do NOT want to get rid of the if-statement. Otherwise will create ScrollAnimators for all layers with Element nodes. This has been a memory footprint issue that we have worked to control and reduce in the past. > > In terms of the JS argument…is there really a JS bug left here? I think my test case demonstrates that there is not a JS bug because when JS asks for the scrollTop, it will update layout, and everything will be right. I am happy to go with scrollToOffset() instead of setCurrentPosition() if there is actually a bug that would be fixed by that, but otherwise, scrollToOffset does a lot of work that does not seem necessary at this time. You are totally right we don't want to create a ScrollAnimator for every layers. I would have expected the check in RenderLayer::scrollToOffset to catch the no-offset case and not calling into the ScrollableArea but I may have missed something. The issue is not with the use case in this bug (ie changing the scrollOffset from JS). It's more about making the restore logic visible from JS through the 'scroll' event. Currently we don't dispatch a 'scroll' event when restoring the scrollOffset but I believe we should so that JS can update whatever representation it uses. 678295 17 bdakin 2012-07-25 11:37:53 -0700 (In reply to comment #16) > > You are totally right we don't want to create a ScrollAnimator for every layers. I would have expected the check in RenderLayer::scrollToOffset to catch the no-offset case and not calling into the ScrollableArea but I may have missed something. > Oh, you are right. scrollToOffset is smart about that. My bad! > The issue is not with the use case in this bug (ie changing the scrollOffset from JS). It's more about making the restore logic visible from JS through the 'scroll' event. Currently we don't dispatch a 'scroll' event when restoring the scrollOffset but I believe we should so that JS can update whatever representation it uses. I see. Hmm. But is this really necessary? It's kind of the JS's fault if it chose to change any of its internal scroll information. Because wasn't the whole point of the original change that caused this regression to make sure that that scroll information isn't lost so that it can be restored as it was? That implies to me that sites would have been broken BEFORE the original change, not NOW after these changes. I don't think it makes sense to send a scroll event here unless other browsers do or unless we find content that is actually broken by not sending it. I would rather not make guesses about what JavaScript implementations may or may not be doing here, because without actual broken sites, it seems just as likely that they would assume that that scroll position had never changed. 678338 18 jchaffraix 2012-07-25 12:26:40 -0700 (In reply to comment #17) > (In reply to comment #16) > > > I see. Hmm. But is this really necessary? It's kind of the JS's fault if it chose to change any of its internal scroll information. Because wasn't the whole point of the original change that caused this regression to make sure that that scroll information isn't lost so that it can be restored as it was? That implies to me that sites would have been broken BEFORE the original change, not NOW after these changes. > > I don't think it makes sense to send a scroll event here unless other browsers do or unless we find content that is actually broken by not sending it. I would rather not make guesses about what JavaScript implementations may or may not be doing here, because without actual broken sites, it seems just as likely that they would assume that that scroll position had never changed. It can be interpreted both ways. In order for us to restore the scroll offset you need to make the element non-scrollable at some point - which means that scrollOffset is (0, 0) at that time. AFAICT we don't send the 'scroll' event when killing the layer and since we restore it automatically when we are again scrollable, it may be fine to not to dispatch it in this case. Deferring until we get more reports from the wild seems better indeed, sorry for the noise. 678700 19 tkent 2012-07-25 18:15:37 -0700 *** Bug 92239 has been marked as a duplicate of this bug. *** 147637 2012-06-14 13:17:00 -0700 2012-06-14 13:17:00 -0700 Testcase scrollTop-test.html text/html 573 simon.fraser PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8Ym9keT4KICAgIDxkaXYgaWQ9InNjcm9sbGVyIiBzdHls ZT0iaGVpZ2h0OiAyMHB4OyBvdmVyZmxvdzogc2Nyb2xsOyI+CiAgICAgICAgPGRpdiBzdHlsZT0i aGVpZ2h0OiA2MHB4OyI+UmlnaHQ8YnIvPldyb25nPC9kaXY+CiAgICA8L2Rpdj4KICAgIDx0ZXh0 YXJlYSBpZD0iY29uc29sZSIgcm93cz0iNCIgY29scz0iMTAiPjwvdGV4dGFyZWE+CiAgICA8c2Ny aXB0PgogICAgYSA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdzY3JvbGxlcicpOwogICAgYyA9 IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdjb25zb2xlJyk7CiAgICBhLnNjcm9sbFRvcCA9IDIw OwogICAgYS5zdHlsZS5kaXNwbGF5ID0gJ25vbmUnOwogICAgYS5zY3JvbGxUb3AgPSAyMDsKICAg IGEuc3R5bGUuZGlzcGxheSA9ICdibG9jayc7CiAgICBjLnZhbHVlICs9ICdiZWZvcmU6ICcgKyBh LnNjcm9sbFRvcCArICdcbic7CiAgICBhLnNjcm9sbFRvcCA9IDA7CiAgICBjLnZhbHVlICs9ICdh ZnRlcjogJyArIGEuc2Nyb2xsVG9wICsgJ1xuJzsKICAgIDwvc2NyaXB0Pgo8L2JvZHk+CjwvaHRt bD4K 154247 2012-07-24 21:55:02 -0700 2012-07-25 11:21:29 -0700 Patch for-review.txt text/plain 4739 bdakin SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDEyMzU2OSkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDI2IEBACisyMDEyLTA3LTI0ICBCZXRoIERh a2luICA8YmRha2luQGFwcGxlLmNvbT4KKworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9y Zy9zaG93X2J1Zy5jZ2k/aWQ9ODkxMTQKKyAgICAgICAgUkVHUkVTU0lPTiAocjExMjkxOSk6IFNl dHRpbmcgc2Nyb2xsVG9wIGFmdGVyIHNldHRpbmcgZGlzcGxheSBmcm9tIG5vbmUgdG8gYmxvY2sg CisgICAgICAgIGZhaWxzCisgICAgICAgIC1hbmQgY29ycmVzcG9uZGluZy0KKyAgICAgICAgPHJk YXI6Ly9wcm9ibGVtLzExNjU2MDUwPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q UyEpLgorCisgICAgICAgIFNjcm9sbEFuaW1hdG9yTWFjOjppbW1lZGlhdGVTY3JvbGxUbygpIGFu ZCBTY3JvbGxBbmltYXRvck1hYzo6aW1tZWRpYXRlU2Nyb2xsVG8oKSAKKyAgICAgICAgYm90aCBo YXZlIGFuIG9wdGltaXphdGlvbiBpbiBwbGFjZSBzbyB0aGF0IHRoZXkgZG8gbm90IGNhbGwgCisg ICAgICAgIG5vdGlmeVBvc2l0aW9uQ2hhbmdlZCgpIGlmIHRoZSBuZXcgc2Nyb2xsIG9mZnNldCBt YXRjaGVzIHRoZSBTY3JvbGxBbmltYXRvcidzIAorICAgICAgICBjYWNoZWQgbV9jdXJyZW50UG9z WCBhbmQgbV9jdXJyZW50UG9zWS4gU28gcmV2aXNpb24gMTEyOTE5IGNhdXNlZCB0cm91YmxlZCB3 aXRoIAorICAgICAgICB0aGlzIG9wdGltaXphdGlvbiBiZWNhdXNlIGl0IGFsbG93ZWQgUmVuZGVy TGF5ZXJzIHRvIHJlc3RvcmUgYSBzY3JvbGxPZmZzZXQgZnJvbSAKKyAgICAgICAgdGhlIEVsZW1l bnQgaWYgdGhlcmUgaXMgb25lIGNhY2hlZCB0aGVyZS4gVGhpcyBjYXVzZWQgdGhlIFJlbmRlckxh eWVyIHRvIGhhdmUgYSAKKyAgICAgICAgc2Nyb2xsT2Zmc2V0IHRoYXQgaXMgaW1wcm9wZXJseSBv dXQtb2Ytc3luY2ggd2l0aCB0aGUgU2Nyb2xsQW5pbWF0b3IncyAKKyAgICAgICAgY3VycmVudFBv c2l0aW9uICh3aGljaCB3aWxsIGp1c3QgYmUgMCwwIHNpbmNlIGl0IGlzIGJlaW5nIHJlLWNyZWF0 ZWQgbGlrZSB0aGUgCisgICAgICAgIFJlbmRlckxheWVyKS4gVGhpcyBmaXggbWFrZXMgc3VyZSB0 aGV5IGFyZSBpbiBzeW5jaCBieSBjYWxsaW5nIAorICAgICAgICBzZXRDdXJyZW50UG9zaXRpb24o KSBvbiB0aGUgU2Nyb2xsQW5pbWF0b3Igd2hlbiB0aGUgY2FjaGVkIHBvc2l0aW9uIGlzIG5vbi16 ZXJvLgorICAgICAgICAqIHJlbmRlcmluZy9SZW5kZXJMYXllci5jcHA6CisgICAgICAgIChXZWJD b3JlOjpSZW5kZXJMYXllcjo6UmVuZGVyTGF5ZXIpOgorCiAyMDEyLTA3LTI0ICBBbGVjIEZsZXR0 ICA8YWxlY2ZsZXR0QGNocm9taXVtLm9yZz4KIAogICAgICAgICBJbmRleGVkREI6IGZpeCAjaW5j bHVkZSBkZXBlbmRlbmNpZXMgc28gSURCUmVxdWVzdCBpc24ndCBhbiBpbmNsdWRlIHJvb3QKSW5k ZXg6IFNvdXJjZS9XZWJDb3JlL3JlbmRlcmluZy9SZW5kZXJMYXllci5jcHAKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gU291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL1JlbmRlckxheWVyLmNwcAkocmV2aXNpb24gMTIz NDAyKQorKysgU291cmNlL1dlYkNvcmUvcmVuZGVyaW5nL1JlbmRlckxheWVyLmNwcAkod29ya2lu ZyBjb3B5KQpAQCAtODYsNiArODYsNyBAQAogI2luY2x1ZGUgIlJlbmRlclRyZWVBc1RleHQuaCIK ICNpbmNsdWRlICJSZW5kZXJWaWV3LmgiCiAjaW5jbHVkZSAiU2NhbGVUcmFuc2Zvcm1PcGVyYXRp b24uaCIKKyNpbmNsdWRlICJTY3JvbGxBbmltYXRvci5oIgogI2luY2x1ZGUgIlNjcm9sbGJhci5o IgogI2luY2x1ZGUgIlNjcm9sbGJhclRoZW1lLmgiCiAjaW5jbHVkZSAiU2V0dGluZ3MuaCIKQEAg LTE5NSw2ICsxOTYsOCBAQCBSZW5kZXJMYXllcjo6UmVuZGVyTGF5ZXIoUmVuZGVyQm94TW9kZWxP CiAgICAgICAgIC8vIFdlIHNhdmUgYW5kIHJlc3RvcmUgb25seSB0aGUgc2Nyb2xsT2Zmc2V0IGFz IHRoZSBvdGhlciBzY3JvbGwgdmFsdWVzIGFyZSByZWNhbGN1bGF0ZWQuCiAgICAgICAgIEVsZW1l bnQqIGVsZW1lbnQgPSB0b0VsZW1lbnQobm9kZSk7CiAgICAgICAgIG1fc2Nyb2xsT2Zmc2V0ID0g ZWxlbWVudC0+c2F2ZWRMYXllclNjcm9sbE9mZnNldCgpOworICAgICAgICBpZiAoIW1fc2Nyb2xs T2Zmc2V0LmlzWmVybygpKQorICAgICAgICAgICAgc2Nyb2xsQW5pbWF0b3IoKS0+c2V0Q3VycmVu dFBvc2l0aW9uKEZsb2F0UG9pbnQobV9zY3JvbGxPZmZzZXQud2lkdGgoKSwgbV9zY3JvbGxPZmZz ZXQuaGVpZ2h0KCkpKTsKICAgICAgICAgZWxlbWVudC0+c2V0U2F2ZWRMYXllclNjcm9sbE9mZnNl dChJbnRTaXplKCkpOwogICAgIH0KIH0KSW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHJldmlzaW9uIDEyMzU3MCkKKysrIExh eW91dFRlc3RzL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEy LTA3LTI0ICBCZXRoIERha2luICA8YmRha2luQGFwcGxlLmNvbT4KKworICAgICAgICBodHRwczov L2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9ODkxMTQKKyAgICAgICAgUkVHUkVTU0lP TiAocjExMjkxOSk6IFNldHRpbmcgc2Nyb2xsVG9wIGFmdGVyIHNldHRpbmcgZGlzcGxheSBmcm9t IG5vbmUgdG8gYmxvY2sgCisgICAgICAgIGZhaWxzCisgICAgICAgIC1hbmQgY29ycmVzcG9uZGlu Zy0KKyAgICAgICAgPHJkYXI6Ly9wcm9ibGVtLzExNjU2MDUwPgorCisgICAgICAgIFJldmlld2Vk IGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogZmFzdC9vdmVyZmxvdy9zZXR0aW5nLXNj cm9sbFRvcC1hZnRlci1oaWRlLXNob3ctZXhwZWN0ZWQudHh0OiBBZGRlZC4KKyAgICAgICAgKiBm YXN0L292ZXJmbG93L3NldHRpbmctc2Nyb2xsVG9wLWFmdGVyLWhpZGUtc2hvdy5odG1sOiBBZGRl ZC4KKwogMjAxMi0wNy0yNCAgTU9SSVRBIEhhamltZSAgPG1vcnJpdGFAZ29vZ2xlLmNvbT4KIAog ICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9ODkxNzkKSW5k ZXg6IExheW91dFRlc3RzL2Zhc3Qvb3ZlcmZsb3cvc2V0dGluZy1zY3JvbGxUb3AtYWZ0ZXItaGlk ZS1zaG93LWV4cGVjdGVkLnR4dAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9mYXN0L292ZXJm bG93L3NldHRpbmctc2Nyb2xsVG9wLWFmdGVyLWhpZGUtc2hvdy1leHBlY3RlZC50eHQJKHJldmlz aW9uIDApCisrKyBMYXlvdXRUZXN0cy9mYXN0L292ZXJmbG93L3NldHRpbmctc2Nyb2xsVG9wLWFm dGVyLWhpZGUtc2hvdy1leHBlY3RlZC50eHQJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNSBAQAor YmVmb3JlOiAyMAorCithZnRlcjogMAorCisKSW5kZXg6IExheW91dFRlc3RzL2Zhc3Qvb3ZlcmZs b3cvc2V0dGluZy1zY3JvbGxUb3AtYWZ0ZXItaGlkZS1zaG93Lmh0bWwKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g TGF5b3V0VGVzdHMvZmFzdC9vdmVyZmxvdy9zZXR0aW5nLXNjcm9sbFRvcC1hZnRlci1oaWRlLXNo b3cuaHRtbAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2Zhc3Qvb3ZlcmZsb3cvc2V0dGlu Zy1zY3JvbGxUb3AtYWZ0ZXItaGlkZS1zaG93Lmh0bWwJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEs MjggQEAKKzwhRE9DVFlQRSBodG1sPgorPGh0bWw+Cis8c2NyaXB0PgorICAgIGlmICh3aW5kb3cu bGF5b3V0VGVzdENvbnRyb2xsZXIpCisgICAgICAgIGxheW91dFRlc3RDb250cm9sbGVyLmR1bXBB c1RleHQoKTsKKyAgICAKKyAgICBmdW5jdGlvbiBsb2cobWVzc2FnZSkKKyAgICAgeworICAgICAg ICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoImNvbnNvbGUiKS5hcHBlbmRDaGlsZChkb2N1bWVu dC5jcmVhdGVUZXh0Tm9kZShtZXNzYWdlICsgIlxuIikpOworICAgICB9Cis8L3NjcmlwdD4KKzxi b2R5PgorICAgIDxkaXYgaWQ9InNjcm9sbGVyIiBzdHlsZT0iaGVpZ2h0OiAyMHB4OyBvdmVyZmxv dzogc2Nyb2xsOyI+CisgICAgICAgIDxkaXYgc3R5bGU9ImhlaWdodDogNjBweDsiPjwvZGl2Pgor ICAgIDwvZGl2PgorICAgIDxwcmUgaWQ9ImNvbnNvbGUiPjwvcHJlPgorICAgIDxzY3JpcHQ+Cisg ICAgYSA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdzY3JvbGxlcicpOworICAgIGEuc2Nyb2xs VG9wID0gMjA7CisgICAgYS5zdHlsZS5kaXNwbGF5ID0gJ25vbmUnOworICAgIGEuc2Nyb2xsVG9w ID0gMjA7CisgICAgYS5zdHlsZS5kaXNwbGF5ID0gJ2Jsb2NrJzsKKyAgICBsb2coJ2JlZm9yZTog JyArIGEuc2Nyb2xsVG9wICsgJ1xuJyk7CisgICAgYS5zY3JvbGxUb3AgPSAwOworICAgIGxvZygn YWZ0ZXI6ICcgKyBhLnNjcm9sbFRvcCArICdcbicpOworICAgIDwvc2NyaXB0PgorPC9ib2R5Pgor PC9odG1sPgo=