47428 2010-10-08 13:07:05 -0700 Redo in ReplaceNodeWithSpanCommand is broken 2010-10-09 17:38:21 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) All All RESOLVED FIXED P2 Normal --- 47424 1 rniwa webkit-unassigned darin enrica eric justin.garcia oldest_to_newest 291825 0 70277 rniwa 2010-10-08 13:07:05 -0700 Created attachment 70277 demo Redo in ReplaceNodeWithSpanCommand creates new element and as a result, subsequent redos that reply on the node added by ReplaceNodeWithSpanCommand fails. 291884 1 rniwa 2010-10-08 14:48:08 -0700 My previous analysis was (sort of) wrong. redo fails because ReplaceNodeWithSpanCommand inherits from CompositeEditCommand instead of SimpleEditCommand. 291887 2 darin 2010-10-08 14:55:35 -0700 We may never get around to this, but long ago I wanted to change SimpleEditCommand and CompositeEditCommand to be completely separate concepts. The SimpleEditCommand would be more of an UndoStep object, with the sole responsibility of being an undoable operation. The CompositeEditCommand objects would be created only during the original editing operation and would be responsible for the more complex process of deciding what to do the first time around, but would then be deallocated and would no longer be around doing the undo/redo process. 291924 3 rniwa 2010-10-08 15:58:22 -0700 (In reply to comment #2) > We may never get around to this, but long ago I wanted to change SimpleEditCommand and CompositeEditCommand to be completely separate concepts. The SimpleEditCommand would be more of an UndoStep object, with the sole responsibility of being an undoable operation. The CompositeEditCommand objects would be created only during the original editing operation and would be responsible for the more complex process of deciding what to do the first time around, but would then be deallocated and would no longer be around doing the undo/redo process. I think the current implementation works almost like that. Except CompositeEditCommand's doUnapply and doReapply of CompositeEditCommand still exist to as a stub / driver for SimpleEditCommands that compose the composite command. If we completely got rid of CompositeEditCommand, how do we determine which SimpleEditCommands correspond to which undo position? e.g. 1. user bolden text 2. user italicize text 3. user undo italicize In this case, each ApplyStyleCommand of step 1 and 2 will generate a bunch of SimpleEditCommands. But we need some way to group commands together so that we can undo only SimpleEditCommands added by step 2 in step 3. If we didn't have CompositeEditCommand at undo/redo, how do we determine that? 291943 4 70312 rniwa 2010-10-08 16:18:07 -0700 Created attachment 70312 fixes the bug 291983 5 darin 2010-10-08 17:41:57 -0700 (In reply to comment #3) > In this case, each ApplyStyleCommand of step 1 and 2 will generate a bunch of SimpleEditCommands. But we need some way to group commands together so that we can undo only SimpleEditCommands added by step 2 in step 3. If we didn't have CompositeEditCommand at undo/redo, how do we determine that? The chain of undo steps would have markers to say where an end user command started. This could be another type of UndoStep object. This marker could also contain the user-visible name of the command. 291984 6 70312 darin 2010-10-08 17:42:28 -0700 Comment on attachment 70312 fixes the bug Is there any way to prevent us from making this mistake in the future? Are there any other cases of this mistake? 291989 7 rniwa 2010-10-08 17:52:59 -0700 (In reply to comment #5) > The chain of undo steps would have markers to say where an end user command started. This could be another type of UndoStep object. This marker could also contain the user-visible name of the command. But that seems to make it hard to support Undo Manager as it's proposed today on whatwg. See http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#undo seem (In reply to comment #6) > (From update of attachment 70312 [details]) > Is there any way to prevent us from making this mistake in the future? Are there any other cases of this mistake? I remember the patch posted to the bug 35281 had a similar mistake. We can probably prevent the majority of similar mistakes if we can prevent sub classes of CompositeEditCommand to override doUnapply and doReapply. Can we make CompositeEditCommand's doUnapply and doReapply non-virtual? Will that prevent sub classes to override them? 291990 8 darin 2010-10-08 17:55:09 -0700 (In reply to comment #7) > (In reply to comment #5) > > The chain of undo steps would have markers to say where an end user command started. This could be another type of UndoStep object. This marker could also contain the user-visible name of the command. > > But that seems to make it hard to support Undo Manager as it's proposed today on whatwg. See > http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#undo seem I think it would be find to have the UndoStep objects grouped into UndoableOperation objects. I just don’t think those should be the same CompositeEditCommand objects we have today. CompositeEditCommand objects have two separate jobs: 1) Doing the edit the first time. 2) Managing the undo process. And the data needed to do the edit the first time has no reason to hang around. I think the code would be easier to read if there was a separation of concerns. 292063 9 rniwa 2010-10-08 23:36:26 -0700 (In reply to comment #8) > I think it would be find to have the UndoStep objects grouped into UndoableOperation objects. I just don’t think those should be the same CompositeEditCommand objects we have today. CompositeEditCommand objects have two separate jobs: 1) Doing the edit the first time. 2) Managing the undo process. And the data needed to do the edit the first time has no reason to hang around. I think the code would be easier to read if there was a separation of concerns. I think that makes a lot of sense. If we separate CompositeEditCommand into two classes as you suggest, then CompositeEditCommand doesn't have to derive from EditCommand any more, and we might be able to avoid making the same kind of mistakes in the future since there will be a clear distinction between CompositeEditCommand and SimpleEditCommand. In fact, CompositeEditCommand doesn't even need to be a class in that case (although it's probably best to keep things together as a class). 292162 10 rniwa 2010-10-09 12:41:43 -0700 I did spent some time looking into how to separate CompositeEditCommand and typing command seems to be the key. The way we implement right now reuses the last typing command if it's still "open," and we can't do that we if just replaced it with simple UndoStep. One way to resolve this problem is by making TypingCommand inherit from both UndoStep and CompositeEditCommand but that's a bit ugly, and it seems to defeat the whole point of separating CompositeEditCommand into two classes. On the other hand, typing command is a bit of mess right now, so maybe we can refactor it in such a way that we don't have to reuse it. One way to accomplish is to create some subclass of UndoStep for typing command that stores some extra information needed to resume typing, and add a new constructor for TypingCommand that takes this special UndoStep object from which it can resume the typing. 292164 11 rniwa 2010-10-09 12:50:04 -0700 Committed r69453: <http://trac.webkit.org/changeset/69453> 292178 12 rniwa 2010-10-09 13:27:26 -0700 (In reply to comment #11) > Committed r69453: <http://trac.webkit.org/changeset/69453> Reverted unintentional changes to platform/*/editing in http://trac.webkit.org/changeset/69456. 70277 2010-10-08 13:07:05 -0700 2010-10-08 13:07:05 -0700 demo replace-by-span-then-remove.html text/html 1402 rniwa PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8Ym9keT4KPGRpdiBpZD0idGVzdCIgY29udGVudGVkaXRh YmxlPmhlbGxvIDxiIHN0eWxlPSJmb250LXN0eWxlOml0YWxpYzsiPndvcmxkPC9iPiBXZWJLaXQ8 L2Rpdj4KPHByZSBpZD0iY29uc29sZSI+CjwvcHJlPgo8c2NyaXB0PgoKdmFyIHRlc3QgPSBkb2N1 bWVudC5nZXRFbGVtZW50QnlJZCgndGVzdCcpOwp3aW5kb3cuZ2V0U2VsZWN0aW9uKCkuc2V0UG9z aXRpb24odGVzdCwgMCk7CndpbmRvdy5nZXRTZWxlY3Rpb24oKS5tb2RpZnkoJ21vdmUnLCAnZm9y d2FyZCcsICd3b3JkJyk7CndpbmRvdy5nZXRTZWxlY3Rpb24oKS5tb2RpZnkoJ21vdmUnLCAnZm9y d2FyZCcsICd3b3JkJyk7CndpbmRvdy5nZXRTZWxlY3Rpb24oKS5tb2RpZnkoJ2V4dGVuZCcsICdi YWNrd2FyZCcsICd3b3JkJyk7Cgp2YXIgY29uc29sZSA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlk KCdjb25zb2xlJyk7CmNvbnNvbGUuYXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRlVGV4dE5vZGUo J2luaXRpYWw6JyArIHRlc3QuaW5uZXJIVE1MICsgJ1xuJykpOwpkb2N1bWVudC5leGVjQ29tbWFu ZCgnYm9sZCcsIGZhbHNlLCBudWxsKTsKY29uc29sZS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVh dGVUZXh0Tm9kZSgnYWZ0ZXIgcmVtb3ZpbmcgYm9sZDonICsgdGVzdC5pbm5lckhUTUwgKyAnXG4n KSk7CmRvY3VtZW50LmV4ZWNDb21tYW5kKCdpdGFsaWMnLCBmYWxzZSwgbnVsbCk7CmNvbnNvbGUu YXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRlVGV4dE5vZGUoJ2FmdGVyIHJlbW92aW5nIGl0YWxp YzonICsgdGVzdC5pbm5lckhUTUwgKyAnXG4nKSk7CmRvY3VtZW50LmV4ZWNDb21tYW5kKCd1bmRv JywgZmFsc2UsIG51bGwpOwpjb25zb2xlLmFwcGVuZENoaWxkKGRvY3VtZW50LmNyZWF0ZVRleHRO b2RlKCdhZnRlciB1bmRvaW5nIG9uY2U6JyArIHRlc3QuaW5uZXJIVE1MICsgJ1xuJykpOwpkb2N1 bWVudC5leGVjQ29tbWFuZCgndW5kbycsIGZhbHNlLCBudWxsKTsKY29uc29sZS5hcHBlbmRDaGls ZChkb2N1bWVudC5jcmVhdGVUZXh0Tm9kZSgnYWZ0ZXIgdW5kb2luZyB0d2ljZTonICsgdGVzdC5p bm5lckhUTUwgKyAnXG4nKSk7CmRvY3VtZW50LmV4ZWNDb21tYW5kKCdyZWRvJywgZmFsc2UsIG51 bGwpOwpjb25zb2xlLmFwcGVuZENoaWxkKGRvY3VtZW50LmNyZWF0ZVRleHROb2RlKCdhZnRlciBy ZWRvaW5nIG9uY2U6JyArIHRlc3QuaW5uZXJIVE1MICsgJ1xuJykpOwpkb2N1bWVudC5leGVjQ29t bWFuZCgncmVkbycsIGZhbHNlLCBudWxsKTsKY29uc29sZS5hcHBlbmRDaGlsZChkb2N1bWVudC5j cmVhdGVUZXh0Tm9kZSgnYWZ0ZXIgcmVkb2luZyB0d2ljZTonICsgdGVzdC5pbm5lckhUTUwgKyAn XG4nKSk7Cgo8L3NjcmlwdD4KPC9ib2R5Pgo8L2h0bWw+Cg== 70312 2010-10-08 16:18:07 -0700 2010-10-08 17:42:28 -0700 fixes the bug bug-47428-20101008161805.patch text/plain 5865 rniwa SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA2OTQyOCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMjYgQEAKKzIwMTAtMTAtMDggIFJ5b3N1a2UgTml3YSAgPHJuaXdhQHdlYmtpdC5v cmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgUmVk byBpbiBSZXBsYWNlTm9kZVdpdGhTcGFuQ29tbWFuZCBpcyBicm9rZW4KKyAgICAgICAgaHR0cHM6 Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTQ3NDI4CisKKyAgICAgICAgVGhlIGJ1 ZyB3YXMgY2F1c2VkIGJ5IFJlcGxhY2VOb2RlV2l0aFNwYW5Db21tYW5kJ3MgaW5oZXJpdGluZyBm cm9tIENvbXBvc2l0ZUVkaXRDb21tYW5kLAorICAgICAgICBhbmQgUmVwbGFjZU5vZGVXaXRoU3Bh bkNvbW1hbmQncyBub3QgaW1wbGVtZW50aW5nIGRvUmVhcHBseS4gQmVjYXVzZSBSZXBsYWNlTm9k ZVdpdGhTcGFuQ29tbWFuZCdzIGRvQXBwbHkKKyAgICAgICAgZGlyZWN0bHkgbW9kaWZpZXMgRE9N IGFuZCBkb2VzIG5vdCB1c2Ugc2ltcGxlIGVkaXQgY29tbWFuZCB3aGlsZSBDb21wb3NpdGVFZGl0 Q29tbWFuZCdzIGRvUmVhcHBseQorICAgICAgICBvbmx5IGNhbGxzIHJlYXBwbHkgb2YgY29tcG9z dGluZyBzaW1wbGUgZWRpdCBjb21tYW5kLCBSZXBsYWNlTm9kZVdpdGhTcGFuQ29tbWFuZCdzIGRv UmVhcHBseSB3YXMgbm8tb3AuCisKKyAgICAgICAgRml4ZWQgdGhlIGJ1ZyBieSBjaGFuZ2luZyB0 aGUgYmFzZSBjbGFzcyBvZiBSZXBsYWNlTm9kZVdpdGhTcGFuQ29tbWFuZCB0byBTaW1wbGVFZGl0 Q29tbWFuZC4KKyAgICAgICAgVGhpcyBhbGxvd3MgUmVwbGFjZU5vZGVXaXRoU3BhbkNvbW1hbmQn cyBkb1JlYXBwbHkgdG8gY2FsbCBpdHMgZG9BcHBseSwgd2hpY2ggYWxyZWFkeSBzdXBwb3J0cyBy ZWRvIG9wZXJhdGlvbi4KKworICAgICAgICBUZXN0OiBlZGl0aW5nL3VuZG8vcmVwbGFjZS1ieS1z cGFuLXRoZW4tcmVtb3ZlLmh0bWwKKworICAgICAgICAqIGVkaXRpbmcvQXBwbHlTdHlsZUNvbW1h bmQuaDoKKyAgICAgICAgKFdlYkNvcmU6OkFwcGx5U3R5bGVDb21tYW5kOjpwcmludFN0eWxlKToK KyAgICAgICAgKiBlZGl0aW5nL1JlcGxhY2VOb2RlV2l0aFNwYW5Db21tYW5kLmNwcDoKKyAgICAg ICAgKFdlYkNvcmU6OlJlcGxhY2VOb2RlV2l0aFNwYW5Db21tYW5kOjpSZXBsYWNlTm9kZVdpdGhT cGFuQ29tbWFuZCk6CisgICAgICAgICogZWRpdGluZy9SZXBsYWNlTm9kZVdpdGhTcGFuQ29tbWFu ZC5oOgorCiAyMDEwLTEwLTA4ICBTaGVyaWZmIEJvdCAgPHdlYmtpdC5yZXZpZXcuYm90QGdtYWls LmNvbT4KIAogICAgICAgICBVbnJldmlld2VkLCByb2xsaW5nIG91dCByNjg1NzQuCkluZGV4OiBX ZWJDb3JlL2VkaXRpbmcvUmVwbGFjZU5vZGVXaXRoU3BhbkNvbW1hbmQuY3BwCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIFdlYkNvcmUvZWRpdGluZy9SZXBsYWNlTm9kZVdpdGhTcGFuQ29tbWFuZC5jcHAJKHJldmlz aW9uIDY5MzQ2KQorKysgV2ViQ29yZS9lZGl0aW5nL1JlcGxhY2VOb2RlV2l0aFNwYW5Db21tYW5k LmNwcAkod29ya2luZyBjb3B5KQpAQCAtNDIsNyArNDIsNyBAQCBuYW1lc3BhY2UgV2ViQ29yZSB7 CiB1c2luZyBuYW1lc3BhY2UgSFRNTE5hbWVzOwogCiBSZXBsYWNlTm9kZVdpdGhTcGFuQ29tbWFu ZDo6UmVwbGFjZU5vZGVXaXRoU3BhbkNvbW1hbmQoUGFzc1JlZlB0cjxOb2RlPiBub2RlKQotICAg IDogQ29tcG9zaXRlRWRpdENvbW1hbmQobm9kZS0+ZG9jdW1lbnQoKSkKKyAgICA6IFNpbXBsZUVk aXRDb21tYW5kKG5vZGUtPmRvY3VtZW50KCkpCiAgICAgLCBtX25vZGUobm9kZSkKIHsKICAgICBB U1NFUlQobV9ub2RlKTsKSW5kZXg6IFdlYkNvcmUvZWRpdGluZy9SZXBsYWNlTm9kZVdpdGhTcGFu Q29tbWFuZC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvZWRpdGluZy9SZXBsYWNlTm9kZVdpdGhT cGFuQ29tbWFuZC5oCShyZXZpc2lvbiA2OTM0NikKKysrIFdlYkNvcmUvZWRpdGluZy9SZXBsYWNl Tm9kZVdpdGhTcGFuQ29tbWFuZC5oCSh3b3JraW5nIGNvcHkpCkBAIC0zOCw3ICszOCw3IEBAIG5h bWVzcGFjZSBXZWJDb3JlIHsKIGNsYXNzIEhUTUxFbGVtZW50OwogCiAvLyBNb3JlIGFjY3VyYXRl bHksIHRoaXMgaXMgUmVwbGFjZU5vZGVXaXRoU3BhblByZXNlcnZpbmdDaGlsZHJlbkFuZEF0dHJp YnV0ZXNDb21tYW5kCi1jbGFzcyBSZXBsYWNlTm9kZVdpdGhTcGFuQ29tbWFuZCA6IHB1YmxpYyBD b21wb3NpdGVFZGl0Q29tbWFuZCB7CitjbGFzcyBSZXBsYWNlTm9kZVdpdGhTcGFuQ29tbWFuZCA6 IHB1YmxpYyBTaW1wbGVFZGl0Q29tbWFuZCB7CiBwdWJsaWM6CiAgICAgc3RhdGljIFBhc3NSZWZQ dHI8UmVwbGFjZU5vZGVXaXRoU3BhbkNvbW1hbmQ+IGNyZWF0ZShQYXNzUmVmUHRyPE5vZGU+IG5v ZGUpCiAgICAgewpJbmRleDogTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExh eW91dFRlc3RzL0NoYW5nZUxvZwkocmV2aXNpb24gNjk0MjgpCisrKyBMYXlvdXRUZXN0cy9DaGFu Z2VMb2cJKHdvcmtpbmcgY29weSkKQEAgLTEsMyArMSwxNiBAQAorMjAxMC0xMC0wOCAgUnlvc3Vr ZSBOaXdhICA8cm5pd2FAd2Via2l0Lm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkg KE9PUFMhKS4KKworICAgICAgICBSZWRvIGluIFJlcGxhY2VOb2RlV2l0aFNwYW5Db21tYW5kIGlz IGJyb2tlbgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9 NDc0MjgKKworICAgICAgICBBZGRlZCBhIHRlc3QgdG8gZW5zdXJlIHJlcGxhY2luZyBhIG5vZGUg d2l0aCBzcGFuIGNhbiBiZSByZWRvbmUsCisgICAgICAgIGFuZCBkb2luZyBzbyBkb2VzIG5vdCBk aXNydXB0IHN1YnNlcXVlbnQgcmVkbydzLgorCisgICAgICAgICogZWRpdGluZy91bmRvL3JlcGxh Y2UtYnktc3Bhbi10aGVuLXJlbW92ZS1leHBlY3RlZC50eHQ6IEFkZGVkLgorICAgICAgICAqIGVk aXRpbmcvdW5kby9yZXBsYWNlLWJ5LXNwYW4tdGhlbi1yZW1vdmUuaHRtbDogQWRkZWQuCisKIDIw MTAtMTAtMDggIEFsYmVydCBKLiBXb25nICA8YWp3b25nQGNocm9taXVtLm9yZz4KIAogICAgICAg ICBbVW5yZXZpZXdlZF0gQ2hyb21pdW0gYnVpbGQgZml4LgpJbmRleDogTGF5b3V0VGVzdHMvZWRp dGluZy91bmRvL3JlcGxhY2UtYnktc3Bhbi10aGVuLXJlbW92ZS1leHBlY3RlZC50eHQKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gTGF5b3V0VGVzdHMvZWRpdGluZy91bmRvL3JlcGxhY2UtYnktc3Bhbi10aGVuLXJl bW92ZS1leHBlY3RlZC50eHQJKHJldmlzaW9uIDApCisrKyBMYXlvdXRUZXN0cy9lZGl0aW5nL3Vu ZG8vcmVwbGFjZS1ieS1zcGFuLXRoZW4tcmVtb3ZlLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gMCkK QEAgLTAsMCArMSw3IEBACitpbml0aWFsOjxiIHN0eWxlPSJmb250LXN0eWxlOiBpdGFsaWM7ICI+ d29ybGQ8L2I+CithZnRlciByZW1vdmluZyBib2xkOjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBp dGFsaWM7ICI+d29ybGQ8L3NwYW4+CithZnRlciByZW1vdmluZyBpdGFsaWM6d29ybGQKK2FmdGVy IHVuZG86PGIgc3R5bGU9ImZvbnQtc3R5bGU6IGl0YWxpYzsgIj53b3JsZDwvYj4KK2FmdGVyIHJl ZG86d29ybGQKK1BBU1MKKwpJbmRleDogTGF5b3V0VGVzdHMvZWRpdGluZy91bmRvL3JlcGxhY2Ut Ynktc3Bhbi10aGVuLXJlbW92ZS5odG1sCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2VkaXRp bmcvdW5kby9yZXBsYWNlLWJ5LXNwYW4tdGhlbi1yZW1vdmUuaHRtbAkocmV2aXNpb24gMCkKKysr IExheW91dFRlc3RzL2VkaXRpbmcvdW5kby9yZXBsYWNlLWJ5LXNwYW4tdGhlbi1yZW1vdmUuaHRt bAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw0NiBAQAorPCFET0NUWVBFIGh0bWw+Cis8aHRtbD4K Kzxib2R5PgorPGRpdiBpZD0idGVzdCIgY29udGVudGVkaXRhYmxlPjxiIHN0eWxlPSJmb250LXN0 eWxlOiBpdGFsaWM7ICI+d29ybGQ8L2I+PC9kaXY+Cis8cHJlIGlkPSJjb25zb2xlIj4KKzwvcHJl PgorPHNjcmlwdD4KKworaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikKKyAgICBsYXlv dXRUZXN0Q29udHJvbGxlci5kdW1wQXNUZXh0KCk7CisKK3ZhciB0ZXN0ID0gZG9jdW1lbnQuZ2V0 RWxlbWVudEJ5SWQoJ3Rlc3QnKTsKK3dpbmRvdy5nZXRTZWxlY3Rpb24oKS5zZWxlY3RBbGxDaGls ZHJlbih0ZXN0KTsKKwordmFyIGNvbnNvbGUgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnY29u c29sZScpOwordmFyIGluaXRpYWxWYWx1ZSA9IHRlc3QuaW5uZXJIVE1MOwordmFyIGZhaWxlZCA9 IGZhbHNlOworY29uc29sZS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVUZXh0Tm9kZSgnaW5p dGlhbDonICsgdGVzdC5pbm5lckhUTUwgKyAnXG4nKSk7Citkb2N1bWVudC5leGVjQ29tbWFuZCgn Ym9sZCcsIGZhbHNlLCBudWxsKTsKK2NvbnNvbGUuYXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRl VGV4dE5vZGUoJ2FmdGVyIHJlbW92aW5nIGJvbGQ6JyArIHRlc3QuaW5uZXJIVE1MICsgJ1xuJykp OworZG9jdW1lbnQuZXhlY0NvbW1hbmQoJ2l0YWxpYycsIGZhbHNlLCBudWxsKTsKK2NvbnNvbGUu YXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRlVGV4dE5vZGUoJ2FmdGVyIHJlbW92aW5nIGl0YWxp YzonICsgdGVzdC5pbm5lckhUTUwgKyAnXG4nKSk7Cit2YXIgZmluYWxWYWx1ZSA9IHRlc3QuaW5u ZXJIVE1MOworCitkb2N1bWVudC5leGVjQ29tbWFuZCgndW5kbycsIGZhbHNlLCBudWxsKTsKK2Rv Y3VtZW50LmV4ZWNDb21tYW5kKCd1bmRvJywgZmFsc2UsIG51bGwpOworY29uc29sZS5hcHBlbmRD aGlsZChkb2N1bWVudC5jcmVhdGVUZXh0Tm9kZSgnYWZ0ZXIgdW5kbzonICsgdGVzdC5pbm5lckhU TUwgKyAnXG4nKSk7CitpZiAodGVzdC5pbm5lckhUTUwgIT0gaW5pdGlhbFZhbHVlKSB7CisgICAg Y29uc29sZS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVUZXh0Tm9kZSgnYnV0IGV4cGVjdGVk ICcgKyBpbml0aWFsVmFsdWUgKyAnXG4nKSk7CisgICAgZmFpbGVkID0gdHJ1ZTsKK30KK2RvY3Vt ZW50LmV4ZWNDb21tYW5kKCdyZWRvJywgZmFsc2UsIG51bGwpOworZG9jdW1lbnQuZXhlY0NvbW1h bmQoJ3JlZG8nLCBmYWxzZSwgbnVsbCk7Citjb25zb2xlLmFwcGVuZENoaWxkKGRvY3VtZW50LmNy ZWF0ZVRleHROb2RlKCdhZnRlciByZWRvOicgKyB0ZXN0LmlubmVySFRNTCArICdcbicpKTsKK2lm ICh0ZXN0LmlubmVySFRNTCAhPSBmaW5hbFZhbHVlKSB7CisgICAgY29uc29sZS5hcHBlbmRDaGls ZChkb2N1bWVudC5jcmVhdGVUZXh0Tm9kZSgnYnV0IGV4cGVjdGVkICcgKyBmaW5hbFZhbHVlICsg J1xuJykpOworICAgIGZhaWxlZCA9IHRydWU7Cit9CisKK3Rlc3QuaW5uZXJIVE1MID0gJyc7CisK K2NvbnNvbGUuYXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRlVGV4dE5vZGUoZmFpbGVkID8gJ0ZB SUxcbicgOiAnUEFTU1xuJykpOworCis8L3NjcmlwdD4KKzwvYm9keT4KKzwvaHRtbD4K