52846 2011-01-20 14:39:18 -0800 InsertUnorderedList breaks up paragraphs when they contain non-editable elements. 2022-07-27 19:09:48 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) PC All NEW P2 Normal --- 1 alberthilbert webkit-unassigned ahmad.saleem792 ap ayg bfulgham eric jparent kalman megan_gardner rniwa wenson_hsieh oldest_to_newest 337613 0 79652 alberthilbert 2011-01-20 14:39:18 -0800 Created attachment 79652 Html file showing the reported issue Let's suppose the text caret is into a paragraph within an editable environment and that paragraph contains non-editable elements. If 'insertunorderedlist' is executed the paragraph breaks up and just the portion containing the caret and bounded by the nearest non-editable elements is moved inside the list. Obviously that isn't the intended behavior: the whole paragraph, non-editable elements included, must be moved inside the list. 342066 1 80557 alberthilbert 2011-01-29 02:41:39 -0800 Created attachment 80557 Proposed patch 342067 2 alberthilbert 2011-01-29 02:46:39 -0800 I will be happy to follow your advices to make the patch accepted. Thank you... Raffaele 342359 3 ojan 2011-01-30 12:56:23 -0800 The old behavior is clearly wrong and the new behavior is clearly correct. rniwa is probably best to confirm whether the code change is the best one. 342403 4 kalman 2011-01-30 17:02:36 -0800 View in context: https://bugs.webkit.org/attachment.cgi?id=80557&action=review > LayoutTests/editing/execCommand/insert-list-inside-editable-paragraph-containing-noneditable-elements.html:3 > +<div id="test2" contenteditable="true"><p id="test2-p">This is another editable paragraph that contains a <span contenteditable="false">non-editable</span> span.</p></div> Why the extra ps, rather than just using the containing div? Anyway, rather than repeating the same test case, it would be nice to test some different cases, such as - non-editable span at the start of the paragraph - non-editable span at the end of the paragraph - non-editable span in the middle somewhere (as you have) - multiple lines (with non-editable spans), no selection - multiple lines (with non-editable spans), with the selection across multiple lines (i.e. use getSelection().modify("extend", "forward", "line") or something) > LayoutTests/editing/execCommand/insert-list-inside-editable-paragraph-containing-noneditable-elements.html:15 > +Markup.dump("test1", "The whole paragraph - non-editable part included - must become a list item"); I'd pull this common logic into a function. Also, if there is a way to just print "PASS ..." or "FAIL ..." then that would be more concise than using Markup and easier to understand regressions. 342404 5 kalman 2011-01-30 17:04:07 -0800 Hmm, I don't actually have permission to comment on the patch so I did it in a roundabout way, and it didn't seem to work in context. 342437 6 kalman 2011-01-30 19:55:51 -0800 Here is a similar bug: https://bugs.webkit.org/show_bug.cgi?id=53409 342442 7 80557 rniwa 2011-01-30 20:17:59 -0800 Comment on attachment 80557 Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=80557&action=review > Source/WebCore/editing/InsertListCommand.cpp:331 > - VisiblePosition start = startOfParagraph(originalStart); > - VisiblePosition end = endOfParagraph(start); > + VisiblePosition start = startOfParagraph(originalStart, CanCrossEditingBoundary); > + VisiblePosition end = endOfParagraph(start, CanCrossEditingBoundary); How do we ensure that the entire paragraph is editable if we allow start/end to cross editing boundary? For example, if we had <div contenteditable="false">hello <span contenteditable="true">world</span></div>, and the caret is inside the span, we shouldn't be listifying "hello world". Because of deep equivalent positions, I don't think we're ready to fix this kind of bugs properly yet. Also, please don't just fix InsertUnorderedList. At least InsertOrderedList must also be fixed. And I'm sure the same bug exists for IndentOutdentCommand and FormatBlockCommand. If you're interested in working on InsertListCommand, please fix crash/hang bugs we have as they have a higher priority. 342863 8 alberthilbert 2011-01-31 15:42:16 -0800 > How do we ensure that the entire paragraph is editable if we allow start/end to cross editing boundary? > For example, if we had <div contenteditable="false">hello <span contenteditable="true">world</span></div>, > and the caret is inside the span, we shouldn't be listifying "hello world". I'm aware of this kind of problem but I consider it largely independent of this bug. Even now (without my patch), in a situation like the one you described, the behavior of 'insertList' is wrong. If you put an editable span inside a non-editable paragraph, you clearly want the user allowed to modify the content of the span, not the nature of the paragraph (from plain paragraph to list item) nor the nature of the span itself (from span to list item or worst inserting a list inside it where only phrasing content is allowed). In such a situation "insertList" command should not be available at all (queryCommandEnabled should return false). I think when 'insertList' is invoked we must look for the nearest non-phrasing content ancestor of the element containing the caret. That is the element 'insertList' will be acting on. Now, if its parent element is editable the execution can go on, otherwise it stops without making changes to the document. To realize the above project we must have a way to determine if an element is of phrasing content category*. For that reason, within the discussion relative to another WebKit bug (https://bugs.webkit.org/show_bug.cgi?id=45866), I proposed to add a new method to the HTMLElemet class: isPhrasingContent(). Unfortunately I have got virtually no feedback on my idea. > Also, please don't just fix InsertUnorderedList. At least InsertOrderedList must also be fixed. My patch already fixes either 'InsertUnorderedList' or 'InsertOrderedList'. * At the moment the paragraph element which 'insertList' will be acting on is determined by looking for the nearest ancestor with css style property 'display' set to 'block'. That is not correct because there can be elements with 'display' property set to 'block' that are in fact children of a paragraph. For example display math equations are displayed as block but they don't break the paragraph where they lie in. Raffaele 342876 9 rniwa 2011-01-31 15:54:07 -0800 (In reply to comment #8) > I'm aware of this kind of problem but I consider it largely independent of this bug. What I'm saying that your patch would have reproduced a regression or that it would have made the situation worse. > Even now (without my patch), in a situation like the one you described, the behavior of 'insertList' is wrong. > If you put an editable span inside a non-editable paragraph, you clearly want the user allowed to modify the content of the span, not the nature of the paragraph (from plain paragraph to list item) nor the nature of the span itself (from span to list item or worst inserting a list inside it where only phrasing content is allowed). > In such a situation "insertList" command should not be available at all (queryCommandEnabled should return false). I agree and we should take care of that instead of ignoring it. In fact, there seems to be a dependency that we need to fix the said bug before being able to fix this one. > I think when 'insertList' is invoked we must look for the nearest non-phrasing content ancestor of the element containing the caret. That is the element 'insertList' will be acting on. This isn't sufficient nor necessary condition. For example, non-phrasing element may be inline (display: inline;) and it may not make sense for us to indent against such an element from user's perspective. > To realize the above project we must have a way to determine if an element is of phrasing content category*. > For that reason, within the discussion relative to another WebKit bug (https://bugs.webkit.org/show_bug.cgi?id=45866), I proposed to add a new method to the HTMLElemet class: isPhrasingContent(). > Unfortunately I have got virtually no feedback on my idea. Yes, I'm aware of that bug and I gave you the feedback that we must be careful when we're adding a function to Node. And Adam pointed out that the parser may know which element is a phrasing element. I'm more than happy to give you more feedback if you can tell us what kind of feedback you'd like to receive. > > Also, please don't just fix InsertUnorderedList. At least InsertOrderedList must also be fixed. > > My patch already fixes either 'InsertUnorderedList' or 'InsertOrderedList'. But your patch didn't have any tests. How can we know that the bug is fixed? 454064 10 ayg 2011-08-19 14:01:56 -0700 I can't reproduce in Chrome 15.0.849.0 dev. The testcase from comment #0 works as expected: everything gets made into a list. 1886909 11 ahmad.saleem792 2022-07-26 14:48:47 -0700 I am able to observe following behavior: *** Safari 15.5 on macOS 12.5 *** Placing caret in any place except non-editable make it "list" upon clicking button, non-editable span does not do anything. Upon listified, the caret remain at the same position and <div contenteditable> remain focused (like you can continue typing etc. and how rich text formatting behave). *** Firefox Nightly 104 *** Placing caret in any place except non-editable make it "list" upon clicking button, non-editable span does not do anything. Upon listified, the focus is lost from <div contenteditable> and it is more like one click magic and now poof. (NOT Ideal for Rich text formatting) *** Chrome Canary 106 *** Placing caret in any place except non-editable make it "list" upon clicking button, non-editable span does not do anything. Upon listified, the caret jumps to start of text line or paragraph and <div contenteditable> remain focused (like you can continue typing etc. and how rich text formatting behave). Although jumping of caret is not ideal for editing document. __________ I think Safari behavior is the most ideal one here and there is no issue of content being moved as mentioned in Comment 0. I think this can be marked as "RESOLVED WONTFIX" or "RESOLVED CONFIGURATION CHANGED". Thanks! 79652 2011-01-20 14:39:18 -0800 2011-01-20 14:39:18 -0800 Html file showing the reported issue test.html text/html 409 alberthilbert PGh0bWw+CjxoZWFkPgo8dGl0bGU+VGVzdDwvdGl0bGU+IAo8L2hlYWQ+Cjxib2R5Pgo8cD5QdXQg dGhlIHRleHQgY2FyZXQgaW5zaWRlIHRoZSBwYXJhZ3JhcGggYmVsb3cgYW5kIGNsaWNrIHRoZSBi dXR0b24gIkxpc3RpZnkiITwvcD4KPGRpdiBjb250ZW50ZWRpdGFibGU9InRydWUiPgo8cD5FZGl0 YWJsZSBwYXJhZ3JhcGggY29udGFpbmluZyBhIDxzcGFuIGNvbnRlbnRlZGl0YWJsZT0iZmFsc2Ui IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiBMaWdodEdyYXk7Ij5ub24tZWRpdGFibGU8L3NwYW4+ IHNwYW4uPC9wPgo8L2Rpdj4KPGJ1dHRvbiBvbmNsaWNrPSJkb2N1bWVudC5leGVjQ29tbWFuZCgn aW5zZXJ0dW5vcmRlcmVkbGlzdCcsIGZhbHNlLCAnJyk7Ij5MaXN0aWZ5PC9idXR0b24+CjwvYm9k eT4KPC9odG1sPg== 80557 2011-01-29 02:41:39 -0800 2011-01-30 20:17:59 -0800 Proposed patch insert-list-inside-editable-paragraph-containing-noneditable-elements.patch text/plain 5011 alberthilbert SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDc3MDYwKQorKysgU291cmNlL1dlYkNvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTcgQEAKKzIwMTEtMDEtMjkgIFJhZmZhZWxl IERlIEZlbyAgPGFsYmVydGhpbGJlcnRAZ21haWwuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5 IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFdoZW4gdGhlIGNhcmV0IGlzIGluc2lkZSBhbiBl ZGl0YWJsZSBwYXJhZ3JhcGggYW5kIHRoZSAnaW5zZXJ0bGlzdCcgY29tbWFuZAorICAgICAgICBp cyBleGVjdXRlZCwgdGhlIHdob2xlIHBhcmFncmFwaCBtdXN0IGJlIG1vdmVkIHdpdGhpbiB0aGUg bGlzdCwgbm90IG9ubHkgCisgICAgICAgIHRoZSBwb3J0aW9uIGJvdW5kZWQgYnkgdGhlIG5lYXJl c3Qgbm90LWVkaXRhYmxlIGVsZW1lbnRzLiAKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5v cmcvc2hvd19idWcuY2dpP2lkPTUyODQ2CisKKyAgICAgICAgVGVzdDogZWRpdGluZy9leGVjQ29t bWFuZC9pbnNlcnQtbGlzdC1pbnNpZGUtZWRpdGFibGUtcGFyYWdyYXBoLWNvbnRhaW5pbmctbm9u ZWRpdGFibGUtZWxlbWVudHMuaHRtbAorCisgICAgICAgICogZWRpdGluZy9JbnNlcnRMaXN0Q29t bWFuZC5jcHA6CisgICAgICAgIChXZWJDb3JlOjpJbnNlcnRMaXN0Q29tbWFuZDo6bGlzdGlmeVBh cmFncmFwaCk6CisKIDIwMTEtMDEtMjkgIEFkYW0gQmFydGggIDxhYmFydGhAd2Via2l0Lm9yZz4K IAogICAgICAgICBSZXZpZXdlZCBieSBEYW5pZWwgQmF0ZXMuCkluZGV4OiBTb3VyY2UvV2ViQ29y ZS9lZGl0aW5nL0luc2VydExpc3RDb21tYW5kLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9lZGl0aW5nL0luc2VydExpc3RDb21tYW5kLmNwcAkocmV2aXNpb24gNzY4MTIpCisrKyBT b3VyY2UvV2ViQ29yZS9lZGl0aW5nL0luc2VydExpc3RDb21tYW5kLmNwcAkod29ya2luZyBjb3B5 KQpAQCAtMzI3LDggKzMyNyw4IEBAIHN0YXRpYyBFbGVtZW50KiBhZGphY2VudEVuY2xvc2luZ0xp c3QoY28KIAogUGFzc1JlZlB0cjxIVE1MRWxlbWVudD4gSW5zZXJ0TGlzdENvbW1hbmQ6Omxpc3Rp ZnlQYXJhZ3JhcGgoY29uc3QgVmlzaWJsZVBvc2l0aW9uJiBvcmlnaW5hbFN0YXJ0LCBjb25zdCBR dWFsaWZpZWROYW1lJiBsaXN0VGFnKQogewotICAgIFZpc2libGVQb3NpdGlvbiBzdGFydCA9IHN0 YXJ0T2ZQYXJhZ3JhcGgob3JpZ2luYWxTdGFydCk7Ci0gICAgVmlzaWJsZVBvc2l0aW9uIGVuZCA9 IGVuZE9mUGFyYWdyYXBoKHN0YXJ0KTsKKyAgICBWaXNpYmxlUG9zaXRpb24gc3RhcnQgPSBzdGFy dE9mUGFyYWdyYXBoKG9yaWdpbmFsU3RhcnQsIENhbkNyb3NzRWRpdGluZ0JvdW5kYXJ5KTsKKyAg ICBWaXNpYmxlUG9zaXRpb24gZW5kID0gZW5kT2ZQYXJhZ3JhcGgoc3RhcnQsIENhbkNyb3NzRWRp dGluZ0JvdW5kYXJ5KTsKICAgICAKICAgICBpZiAoc3RhcnQuaXNOdWxsKCkgfHwgZW5kLmlzTnVs bCgpKQogICAgICAgICByZXR1cm4gMDsKSW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHJldmlzaW9uIDc3MDYwKQorKysgTGF5 b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTEt MDEtMjkgIFJhZmZhZWxlIERlIEZlbyAgPGFsYmVydGhpbGJlcnRAZ21haWwuY29tPgorCisgICAg ICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFdoZW4gdGhlIGNhcmV0 IGlzIGluc2lkZSBhbiBlZGl0YWJsZSBwYXJhZ3JhcGggYW5kIHRoZSAnaW5zZXJ0bGlzdCcgY29t bWFuZAorICAgICAgICBpcyBleGVjdXRlZCwgdGhlIHdob2xlIHBhcmFncmFwaCBtdXN0IGJlIG1v dmVkIHdpdGhpbiB0aGUgbGlzdCwgbm90IG9ubHkKKyAgICAgICAgdGhlIHBvcnRpb24gYm91bmRl ZCBieSB0aGUgbmVhcmVzdCBub3QtZWRpdGFibGUgZWxlbWVudHMuCisgICAgICAgIGh0dHBzOi8v YnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD01Mjg0NgorCisgICAgICAgICogZWRpdGlu Zy9leGVjQ29tbWFuZC9pbnNlcnQtbGlzdC1pbnNpZGUtZWRpdGFibGUtcGFyYWdyYXBoLWNvbnRh aW5pbmctbm9uZWRpdGFibGUtZWxlbWVudHMtZXhwZWN0ZWQudHh0OiBBZGRlZC4KKyAgICAgICAg KiBlZGl0aW5nL2V4ZWNDb21tYW5kL2luc2VydC1saXN0LWluc2lkZS1lZGl0YWJsZS1wYXJhZ3Jh cGgtY29udGFpbmluZy1ub25lZGl0YWJsZS1lbGVtZW50cy5odG1sOiBBZGRlZC4KKwogMjAxMS0w MS0yOSAgUnlvc3VrZSBOaXdhICA8cm5pd2FAd2Via2l0Lm9yZz4KIAogICAgICAgICBVbnJldmll d2VkIENocm9taXVtIHRlc3QgZXhwZWN0YXRpb24gdXBkYXRlLgpJbmRleDogTGF5b3V0VGVzdHMv ZWRpdGluZy9leGVjQ29tbWFuZC9pbnNlcnQtbGlzdC1pbnNpZGUtZWRpdGFibGUtcGFyYWdyYXBo LWNvbnRhaW5pbmctbm9uZWRpdGFibGUtZWxlbWVudHMtZXhwZWN0ZWQudHh0Cj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIExheW91dFRlc3RzL2VkaXRpbmcvZXhlY0NvbW1hbmQvaW5zZXJ0LWxpc3QtaW5zaWRlLWVk aXRhYmxlLXBhcmFncmFwaC1jb250YWluaW5nLW5vbmVkaXRhYmxlLWVsZW1lbnRzLWV4cGVjdGVk LnR4dAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2VkaXRpbmcvZXhlY0NvbW1hbmQvaW5z ZXJ0LWxpc3QtaW5zaWRlLWVkaXRhYmxlLXBhcmFncmFwaC1jb250YWluaW5nLW5vbmVkaXRhYmxl LWVsZW1lbnRzLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwyMiBAQAorCitU aGUgd2hvbGUgcGFyYWdyYXBoIC0gbm9uLWVkaXRhYmxlIHBhcnQgaW5jbHVkZWQgLSBtdXN0IGJl Y29tZSBhIGxpc3QgaXRlbToKK3wgPHA+Cit8ICAgaWQ9InRlc3QxLXAiCit8ICAgPHVsPgorfCAg ICAgPGxpPgorfCAgICAgICAiVGhpPCNzZWxlY3Rpb24tY2FyZXQ+cyBpcyBhbiBlZGl0YWJsZSBw YXJhZ3JhcGggdGhhdCBjb250YWlucyBhICIKK3wgICAgICAgPHNwYW4+Cit8ICAgICAgICAgY29u dGVudGVkaXRhYmxlPSJmYWxzZSIKK3wgICAgICAgICAibm9uLWVkaXRhYmxlIgorfCAgICAgICAi IHNwYW4uIgorCitUaGUgd2hvbGUgcGFyYWdyYXBoIC0gbm9uLWVkaXRhYmxlIHBhcnQgaW5jbHVk ZWQgLSBtdXN0IGJlY29tZSBhIGxpc3QgaXRlbToKK3wgPHA+Cit8ICAgaWQ9InRlc3QxLXAiCit8 ICAgPHVsPgorfCAgICAgPGxpPgorfCAgICAgICAiVGhpcyBpcyBhbiBlZGl0YWJsZSBwYXJhZ3Jh cGggdGhhdCBjb250YWlucyBhICIKK3wgICAgICAgPHNwYW4+Cit8ICAgICAgICAgY29udGVudGVk aXRhYmxlPSJmYWxzZSIKK3wgICAgICAgICAibm9uLWVkaXRhYmxlIgorfCAgICAgICAiIHNwYW4u IgpJbmRleDogTGF5b3V0VGVzdHMvZWRpdGluZy9leGVjQ29tbWFuZC9pbnNlcnQtbGlzdC1pbnNp ZGUtZWRpdGFibGUtcGFyYWdyYXBoLWNvbnRhaW5pbmctbm9uZWRpdGFibGUtZWxlbWVudHMuaHRt bAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9lZGl0aW5nL2V4ZWNDb21tYW5kL2luc2VydC1s aXN0LWluc2lkZS1lZGl0YWJsZS1wYXJhZ3JhcGgtY29udGFpbmluZy1ub25lZGl0YWJsZS1lbGVt ZW50cy5odG1sCShyZXZpc2lvbiAwKQorKysgTGF5b3V0VGVzdHMvZWRpdGluZy9leGVjQ29tbWFu ZC9pbnNlcnQtbGlzdC1pbnNpZGUtZWRpdGFibGUtcGFyYWdyYXBoLWNvbnRhaW5pbmctbm9uZWRp dGFibGUtZWxlbWVudHMuaHRtbAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwxNyBAQAorPHNjcmlw dCBzcmM9Ii4uLy4uL3Jlc291cmNlcy9kdW1wLWFzLW1hcmt1cC5qcyI+PC9zY3JpcHQ+Cis8ZGl2 IGlkPSJ0ZXN0MSIgY29udGVudGVkaXRhYmxlPSJ0cnVlIj48cCBpZD0idGVzdDEtcCI+VGhpcyBp cyBhbiBlZGl0YWJsZSBwYXJhZ3JhcGggdGhhdCBjb250YWlucyBhIDxzcGFuIGNvbnRlbnRlZGl0 YWJsZT0iZmFsc2UiPm5vbi1lZGl0YWJsZTwvc3Bhbj4gc3Bhbi48L3A+PC9kaXY+Cis8ZGl2IGlk PSJ0ZXN0MiIgY29udGVudGVkaXRhYmxlPSJ0cnVlIj48cCBpZD0idGVzdDItcCI+VGhpcyBpcyBh bm90aGVyIGVkaXRhYmxlIHBhcmFncmFwaCB0aGF0IGNvbnRhaW5zIGEgPHNwYW4gY29udGVudGVk aXRhYmxlPSJmYWxzZSI+bm9uLWVkaXRhYmxlPC9zcGFuPiBzcGFuLjwvcD48L2Rpdj4KKzxzY3Jp cHQ+Cit2YXIgc2VsID0gd2luZG93LmdldFNlbGVjdGlvbigpOworCit2YXIgcCA9IGRvY3VtZW50 LmdldEVsZW1lbnRCeUlkKCJ0ZXN0MS1wIik7CitzZWwuc2V0UG9zaXRpb24ocC5maXJzdENoaWxk LCAzKTsKK2RvY3VtZW50LmV4ZWNDb21tYW5kKCJJbnNlcnRVbm9yZGVyZWRMaXN0Iik7CitNYXJr dXAuZHVtcCgidGVzdDEiLCAiVGhlIHdob2xlIHBhcmFncmFwaCAtIG5vbi1lZGl0YWJsZSBwYXJ0 IGluY2x1ZGVkIC0gbXVzdCBiZWNvbWUgYSBsaXN0IGl0ZW0iKTsKKwordmFyIHAgPSBkb2N1bWVu dC5nZXRFbGVtZW50QnlJZCgidGVzdDItcCIpOworc2VsLnNldFBvc2l0aW9uKHAubGFzdENoaWxk LCAzKTsKK2RvY3VtZW50LmV4ZWNDb21tYW5kKCJJbnNlcnRVbm9yZGVyZWRMaXN0Iik7CitNYXJr dXAuZHVtcCgidGVzdDEiLCAiVGhlIHdob2xlIHBhcmFncmFwaCAtIG5vbi1lZGl0YWJsZSBwYXJ0 IGluY2x1ZGVkIC0gbXVzdCBiZWNvbWUgYSBsaXN0IGl0ZW0iKTsKKworPC9zY3JpcHQ+Cg==