<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>32047</bug_id>
          
          <creation_ts>2009-12-01 18:25:26 -0800</creation_ts>
          <short_desc>Make appcache layouttests top-frame-*.html more robust for async checking event</short_desc>
          <delta_ts>2010-03-11 15:14:59 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>Tools / Tests</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>All</rep_platform>
          <op_sys>OS X 10.5</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Jenn Braithwaite">jennb</reporter>
          <assigned_to name="Michael Nordman">michaeln</assigned_to>
          <cc>ap</cc>
    
    <cc>dimich</cc>
    
    <cc>jennb</cc>
    
    <cc>levin</cc>
    
    <cc>michaeln</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>167830</commentid>
    <comment_count>0</comment_count>
    <who name="Jenn Braithwaite">jennb</who>
    <bug_when>2009-12-01 18:25:26 -0800</bug_when>
    <thetext>top-frame-2.html fails in chromium&apos;s appcache implementation because the checking event is asynchronous and may arrive after the iframe has posted the message back to its parent.  The test ends as soon as it gets the message from the iframe, causing the checking event to be missed.

Change the test to check for both a checking event and the receipt of the iframe&apos;s message before ending to ensure that both events are processed before calling the test a success.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>167895</commentid>
    <comment_count>1</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2009-12-01 23:57:16 -0800</bug_when>
    <thetext>The checking event is always asynchronous, not just in the Chromium implementation. 

Are you saying that the order in which the checking event and the message event arrive is undefined in Chromium? Would it be just a bug?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168199</commentid>
    <comment_count>2</comment_count>
    <who name="Jenn Braithwaite">jennb</who>
    <bug_when>2009-12-02 15:53:20 -0800</bug_when>
    <thetext>In chromium, the appcache update process runs in the IO thread.

Sequence of events for this test is as follows (on windows):
UI thread adds iframe (subframe-2.html), triggering appcache update on IO thread.
Update process on IO thread posts checking event to UI thread.

Meanwhile, on UI thread, subframe-2.html finishes loading and executes the script. The XMLHttpRequest synchronously fails and calls parent.postMessage.

postMessage uses startTimer(0) to post the message. The timer fires before the UI thread has a chance to process any messages in the thread queue.  Thus, the message event listener in the parent(top-frame-2.html) invokes notifyDone() before the UI thread has a chance to process the checking event.

Dimich tells me that depending on the platform, the firing of a timer event may or may not have priority over queued messages for a thread.  So, the test should not depend on a particular ordering of the checking event over the message event.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168202</commentid>
    <comment_count>3</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2009-12-02 16:04:22 -0800</bug_when>
    <thetext>The fact that postMessage() uses a timer is an implementation detail. How events are delivered is actually specified in HTML5 - we&apos;ll need to check if the test is correct per the spec to determine if it&apos;s the test or Chromium that needs to be fixed.

It is also possible that HTML5 will need to be changed due to Chromium implementation experience.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168210</commentid>
    <comment_count>4</comment_count>
      <attachid>44193</attachid>
    <who name="Jenn Braithwaite">jennb</who>
    <bug_when>2009-12-02 16:31:57 -0800</bug_when>
    <thetext>Created attachment 44193
Proposed fix

The spec says to &quot;queue a task&quot; to fire the checking event. The definition of &quot;queue a task&quot; in the spec does not impose an ordering on script events vs appcache update events.

Attached patch makes the test robust against ordering of these events.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168213</commentid>
    <comment_count>5</comment_count>
      <attachid>44193</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2009-12-02 16:39:45 -0800</bug_when>
    <thetext>Comment on attachment 44193
Proposed fix

(In reply to comment #4)
&gt; The spec says to &quot;queue a task&quot; to fire the checking event. The definition of
&gt; &quot;queue a task&quot; in the spec does not impose an ordering on script events vs
&gt; appcache update events.

Application cache update events are fired in exactly the same way (&quot;queue a task to fire a simple event named checking&quot;), which means that they go into the same FIFO queue, and must be delivered sequentially.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168226</commentid>
    <comment_count>6</comment_count>
    <who name="Michael Nordman">michaeln</who>
    <bug_when>2009-12-02 17:50:37 -0800</bug_when>
    <thetext>(In reply to comment #5)
&gt; (From update of attachment 44193 [details])
&gt; (In reply to comment #4)
&gt; &gt; The spec says to &quot;queue a task&quot; to fire the checking event. The definition of
&gt; &gt; &quot;queue a task&quot; in the spec does not impose an ordering on script events vs
&gt; &gt; appcache update events.
&gt; 
&gt; Application cache update events are fired in exactly the same way (&quot;queue a
&gt; task to fire a simple event named checking&quot;), which means that they go into the
&gt; same FIFO queue, and must be delivered sequentially.

If I&apos;m understanding this properly, the difference is that in Chrome the CHECKING event is queued and eventually raised some time after the frame load has made progress, whereas in Safari the CHECKING event is queued prior to the frame load getting past the &lt;html&gt; tag parsing and is guaranteed to be raised prior to any events queued after that point in time. And the layout test depends on that synchronous queueing guarantee.

Here&apos;s the relavant part of the HTML5 spec...

&lt;snip&gt;
The application cache download process steps are as follows:

1) Optionally, wait until the permission to start the application cache download process has been obtained from the user and until the user agent is confident that the network is available. This could include doing nothing until the user explicitly opts-in to caching the site, or could involve prompting the user for permission. The algorithm might never get past this point. (This step is particularly intended to be used by user agents running on severely space-constrained devices or in highly privacy-sensitive environments).

2) Atomically, so as to avoid race conditions, perform the following substeps

  blah, blah, queue a CHECKING event, blah
&lt;/snip&gt;


Step 1 implies that the entire UpdateAlgorithm (including the raising of the CHECKING event) can be deferred for an arbitrarily long period of time, presumably without preventing a frame load from continuing.

Chrome respects the &quot;Atomically, so as to avoid race conditions&quot; part of this steps to be sure. But my reading of this is that &quot;Atomically&quot; should not be interpreted as &quot;Synchronously&quot;.

So, I think Chrome&apos;s more async behavior in this area is valid per the spec today.

Also, if the spec did not allow some async&apos;ness here... i&apos;d be looking to change that in the spec. Sure, we *could* force things to be synchronous, but that would only slow page loading (which we generally have an aversion to).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168308</commentid>
    <comment_count>7</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2009-12-02 23:49:53 -0800</bug_when>
    <thetext>Interesting! This step 1 didn&apos;t exist when I was making this test. I&apos;ll need to think about consequences some more - as you noticed, it&apos;s quite close to being in contradiction with atomicity from step 2.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168467</commentid>
    <comment_count>8</comment_count>
    <who name="Michael Nordman">michaeln</who>
    <bug_when>2009-12-03 11:08:23 -0800</bug_when>
    <thetext>(In reply to comment #7)
&gt; Interesting! This step 1 didn&apos;t exist when I was making this test. I&apos;ll need to
&gt; think about consequences some more - as you noticed, it&apos;s quite close to being
&gt; in contradiction with atomicity from step 2.

Step 1 allows for an async user prompt while the page continues to load. I think that&apos;s probably a good things since it gives user agents some wiggle room on how to present this form of persistence to the user. Chrome doesn&apos;t have any UI yet, but you can imagine an &quot;info bar&quot; that appears when a particular manifest file is first referred to and the update algorithm waits until the DOIT button is pressed (maybe).

UI deliberations aside, accommodating async&apos;ness here is good for other reasons as well. These steps are being invoked in the act of &lt;html&gt; tag parsing (in the act of cache-selection). The cache selection part of may involves disk IO. We all generally prefer to decouple the UI thread from disk IO.

As mentioned before, my reading of the spec is that async&apos;ness here is permitted. I&apos;m not at all keen on making our impl sync here for the reasons mentioned above (and other performance related reasons not mentioned above).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168920</commentid>
    <comment_count>9</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2009-12-04 14:05:54 -0800</bug_when>
    <thetext>I agree for the most part. The spec doesn&apos;t look fully updated for this change - right after step 2, there&apos;s &quot;The remainder of the steps run asynchronously.&quot; I was worried about behavioral changes caused by this that can affect existing content, but I can&apos;t find any.

I sent e-mail to WhatWG, asking to clarify whether the text after step 2 is a mistake.

It this really the only test affected by this spec change? I&apos;d like to avoid having to fix them one by one. Could you perhaps add a sleep for one second to the beginning of cache update algorithm in Chromium implementation to see if that breaks more tests?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>168923</commentid>
    <comment_count>10</comment_count>
    <who name="Jenn Braithwaite">jennb</who>
    <bug_when>2009-12-04 14:12:56 -0800</bug_when>
    <thetext>top-frame-3.html and top-frame-4.html are both affected as well, but will usually pass as they run longer and the checking events usually arrive before the test ends.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>198425</commentid>
    <comment_count>11</comment_count>
    <who name="Dmitry Titov">dimich</who>
    <bug_when>2010-03-10 17:01:36 -0800</bug_when>
    <thetext>The top-frame2.html was already modified as proposed here in the patch for bug 35943.

So the remaining work is to verify/update top-frame3 and top-frame4</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>198775</commentid>
    <comment_count>12</comment_count>
    <who name="Dmitry Titov">dimich</who>
    <bug_when>2010-03-11 14:29:23 -0800</bug_when>
    <thetext>In fact, more tests in http/tests/appcache folder are using a combination of appcache events and postMessage to determine the termination time and success of the test. Take fro example the remove-cache.html. It actually registers appcache event handlers that *should not* fire and considers it a failure if they fire. However, it uses postMessage from included iframe as a termination signal. If the appcache actually fires those &apos;wrong&apos; events but onmessage terminates the test right before this, we might miss a bug.

Apparently the spec, as indicated in the discussion in bug 35943, assumes no ordering of events between different event sources. That could make tests dependin gon the particular ordering always pass on one implementation (or port) and fail on another, or, worse, be flaky.

I&apos;d like to try to make top-frame-*.html tests at least be consistent with each other and test for all conditions before termination. The patch for that is coming. 

Also, I think we need a separate bug for the appcache folder, to review and perhaps update all the affected tests. Apparently, some of them are disabled for Chromium port specifically because of the event ordering mismatch.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>198783</commentid>
    <comment_count>13</comment_count>
      <attachid>50542</attachid>
    <who name="Dmitry Titov">dimich</who>
    <bug_when>2010-03-11 14:36:11 -0800</bug_when>
    <thetext>Created attachment 50542
Patch.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>198790</commentid>
    <comment_count>14</comment_count>
      <attachid>50542</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2010-03-11 14:49:49 -0800</bug_when>
    <thetext>Comment on attachment 50542
Patch.

&gt;         Also added check for &quot;noupdate&quot; event.

I&apos;m not sure if I understand this change. What you are doing here is replacing a handler that calls test() with one that logs and checks whether the test is done. The counter doesn&apos;t match the number of events received, because the original handler doesn&apos;t increment it.

applicationCache.onnoupdate = function() { test() }
applicationCache.oncached = function() { test() }

Do the tests still pass in browser both on first try (with empty appcache), and on reload?

r=me though.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>198801</commentid>
    <comment_count>15</comment_count>
    <who name="Dmitry Titov">dimich</who>
    <bug_when>2010-03-11 15:11:23 -0800</bug_when>
    <thetext>(In reply to comment #14)
&gt; (From update of attachment 50542 [details])
&gt; &gt;         Also added check for &quot;noupdate&quot; event.
&gt; 
&gt; I&apos;m not sure if I understand this change. What you are doing here is replacing
&gt; a handler that calls test() with one that logs and checks whether the test is
&gt; done. The counter doesn&apos;t match the number of events received, because the
&gt; original handler doesn&apos;t increment it.
&gt; 
&gt; applicationCache.onnoupdate = function() { test() }
&gt; applicationCache.oncached = function() { test() }
&gt; 
&gt; Do the tests still pass in browser both on first try (with empty appcache), and
&gt; on reload?

Yes, they pass in both conditions. There are 3 opportunities for those events to fire - first time, when the page itself loads, then both of those tests attach 2 iframes. So the first time onnoupdate fires as a result of the page and calls test(), after that it fires twice for each iframe. The test counts up to 2.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>198802</commentid>
    <comment_count>16</comment_count>
    <who name="Dmitry Titov">dimich</who>
    <bug_when>2010-03-11 15:14:59 -0800</bug_when>
    <thetext>Landed: http://trac.webkit.org/changeset/55858</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>44193</attachid>
            <date>2009-12-02 16:31:57 -0800</date>
            <delta_ts>2010-03-11 14:36:11 -0800</delta_ts>
            <desc>Proposed fix</desc>
            <filename>topframe2patch.txt</filename>
            <type>text/plain</type>
            <size>2372</size>
            <attacher name="Jenn Braithwaite">jennb</attacher>
            
              <data encoding="base64">SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9D
aGFuZ2VMb2cJKHJldmlzaW9uIDUxNTc2KQorKysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3Jr
aW5nIGNvcHkpCkBAIC0xLDMgKzEsMTIgQEAKKzIwMDktMTItMDEgIEplbm4gQnJhaXRod2FpdGUg
IDxqZW5uYkBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BT
ISkuCisKKyAgICAgICAgTWFrZSBodHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS0yLmh0bWwg
bW9yZSByb2J1c3QuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn
aT9pZD0zMjA0NworCisgICAgICAgICogaHR0cC90ZXN0cy9hcHBjYWNoZS90b3AtZnJhbWUtMi5o
dG1sOgorCiAyMDA5LTEyLTAxICBDaHJpcyBGbGVpemFjaCAgPGNmbGVpemFjaEBhcHBsZS5jb20+
CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgRGF2aWQgS2lsemVyLgpJbmRleDogTGF5b3V0VGVzdHMv
aHR0cC90ZXN0cy9hcHBjYWNoZS90b3AtZnJhbWUtMi5odG1sCj09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91
dFRlc3RzL2h0dHAvdGVzdHMvYXBwY2FjaGUvdG9wLWZyYW1lLTIuaHRtbAkocmV2aXNpb24gNTE1
NzApCisrKyBMYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS0yLmh0bWwJ
KHdvcmtpbmcgY29weSkKQEAgLTExLDYgKzExLDkgQEAgaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29u
dHJvbGxlcikgewogICAgIGxheW91dFRlc3RDb250cm9sbGVyLndhaXRVbnRpbERvbmUoKTsKIH0K
IAordmFyIGdvdENoZWNraW5nID0gZmFsc2U7Cit2YXIgZ290TWVzc2FnZSA9IGZhbHNlOworCiBm
dW5jdGlvbiBsb2cobWVzc2FnZSkKIHsKICAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgicmVz
dWx0IikuaW5uZXJIVE1MICs9IG1lc3NhZ2UgKyAiPGJyPiI7CkBAIC0yMiwyMCArMjUsMzAgQEAg
ZnVuY3Rpb24gdGVzdCgpCiAgICAgYXBwbGljYXRpb25DYWNoZS5vbmNhY2hlZCA9IG51bGw7CiAK
ICAgICAvLyBXaGVuIGEgbmV3IG1haW4gcmVzb3VyY2UgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBj
YWNoZSwgYW4gdXBkYXRlIHNob3VsZCBiZSBzdGFydGVkLgotICAgIGFwcGxpY2F0aW9uQ2FjaGUu
b25jaGVja2luZyA9IGZ1bmN0aW9uKCkgeyBsb2coImNoZWNraW5nIikgfQorICAgIGFwcGxpY2F0
aW9uQ2FjaGUub25jaGVja2luZyA9IGZ1bmN0aW9uKCkgeyBsb2coImNoZWNraW5nIik7IGdvdENo
ZWNraW5nID0gdHJ1ZTsgY2hlY2tEb25lKCkgfQogCiAgICAgdmFyIGlmciA9IGRvY3VtZW50LmNy
ZWF0ZUVsZW1lbnQoImlmcmFtZSIpOwogICAgIGlmci5zZXRBdHRyaWJ1dGUoInNyYyIsICJyZXNv
dXJjZXMvc3ViZnJhbWUtMi5odG1sIik7CiAgICAgZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChp
ZnIpOwogfQogCitmdW5jdGlvbiBjaGVja0RvbmUoKQoreworICAgIC8vIFdhaXQgZm9yIGJvdGgg
Y2hlY2tpbmcgZXZlbnQgYW5kIG1lc3NhZ2UgZnJvbSBpZnJhbWUgYmVmb3JlIGVuZGluZyB0ZXN0
LgorICAgIGlmIChnb3RDaGVja2luZyAmJiBnb3RNZXNzYWdlKSB7CisgICAgICAgIGxvZygiU1VD
Q0VTUyIpOworICAgICAgICBpZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVyKQorICAgICAg
ICAgICAgbGF5b3V0VGVzdENvbnRyb2xsZXIubm90aWZ5RG9uZSgpOworICAgIH0KK30KKwogYXBw
bGljYXRpb25DYWNoZS5vbm5vdXBkYXRlID0gZnVuY3Rpb24oKSB7IHRlc3QoKSB9CiBhcHBsaWNh
dGlvbkNhY2hlLm9uY2FjaGVkID0gZnVuY3Rpb24oKSB7IHRlc3QoKSB9CiAKIGFwcGxpY2F0aW9u
Q2FjaGUub251cGRhdGVyZWFkeSA9IGZ1bmN0aW9uKCkgeyBsb2coIkZBSUw6IHJlY2VpdmVkIHVu
ZXhwZWN0ZWQgdXBkYXRlcmVhZHkgZXZlbnQiKSB9CiBhcHBsaWNhdGlvbkNhY2hlLm9uZXJyb3Ig
PSBmdW5jdGlvbigpIHsgbG9nKCJGQUlMOiByZWNlaXZlZCB1bmV4cGVjdGVkIGVycm9yIGV2ZW50
IikgfQogCi13aW5kb3cuYWRkRXZlbnRMaXN0ZW5lcigibWVzc2FnZSIsIGZ1bmN0aW9uKCkgeyBs
b2coIlNVQ0NFU1MiKTsgaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikgbGF5b3V0VGVz
dENvbnRyb2xsZXIubm90aWZ5RG9uZSgpIH0sIGZhbHNlKTsKK3dpbmRvdy5hZGRFdmVudExpc3Rl
bmVyKCJtZXNzYWdlIiwgZnVuY3Rpb24oKSB7IGdvdE1lc3NhZ2UgPSB0cnVlOyBjaGVja0RvbmUo
KSB9LCBmYWxzZSk7CiAKIDwvc2NyaXB0PgogPC9ib2R5Pgo=
</data>
<flag name="review"
          id="25991"
          type_id="1"
          status="-"
          setter="ap"
    />
          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>50542</attachid>
            <date>2010-03-11 14:36:11 -0800</date>
            <delta_ts>2010-03-11 14:49:49 -0800</delta_ts>
            <desc>Patch.</desc>
            <filename>patch.txt</filename>
            <type>text/plain</type>
            <size>6719</size>
            <attacher name="Dmitry Titov">dimich</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv
ZwppbmRleCA3ZTFmZDAwLi5iYzk5ZGM3IDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM
b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjAgQEAKKzIwMTAtMDMt
MTEgIERtaXRyeSBUaXRvdiAgPGRpbWljaEBjaHJvbWl1bS5vcmc+CisKKyAgICAgICAgUmV2aWV3
ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgTWFrZSBhcHBjYWNoZSBsYXlvdXR0ZXN0
cyB0b3AtZnJhbWUtKi5odG1sIG1vcmUgcm9idXN0IGZvciBhc3luYyBjaGVja2luZyBldmVudAor
ICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzIwNDcKKwor
ICAgICAgICBNb2RpZmllZCB0aGUgdGVzdHMgdG8gd2F0Y2ggZm9yIGFsbCB0ZXJtaW5hdGlvbiBj
b25kaXRpb25zLCBlbGltaW5hdGluZyB0aGUgaGFyZGNvZGVkCisgICAgICAgIGFzc3VtZWQgb3Jk
ZXIgb2YgdGhlIGV2ZW50cyBmcm9tIHNlcGFyYXRlIGFzeW5jIGV2ZW50IHNvdXJjZXMuCisgICAg
ICAgIEFsc28gYWRkZWQgY2hlY2sgZm9yICJub3VwZGF0ZSIgZXZlbnQuCisKKyAgICAgICAgKiBo
dHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS0yLmh0bWw6IE1vZGlmaWVkIHRvIGJlIGNvbnNp
c3RlbnQgd2l0aCB0aGUgb3RoZXIgMiB0ZXN0cy4KKyAgICAgICAgKiBodHRwL3Rlc3RzL2FwcGNh
Y2hlL3RvcC1mcmFtZS0zLWV4cGVjdGVkLnR4dDoKKyAgICAgICAgKiBodHRwL3Rlc3RzL2FwcGNh
Y2hlL3RvcC1mcmFtZS0zLmh0bWw6IFVzZWQgbG9naWMgc2ltaWxhciB0byB0b3AtZnJhbWUtMi5o
dG1sIHRvIGF2b2lkIGFzc3VtcHRpb24gb2YgdGhlIGV2ZW50cyBvcmRlci4KKyAgICAgICAgKiBo
dHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS00LWV4cGVjdGVkLnR4dDoKKyAgICAgICAgKiBo
dHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS00Lmh0bWw6IERpdHRvLgorCiAyMDEwLTAzLTEw
ICBDaHJpcyBGbGVpemFjaCAgPGNmbGVpemFjaEBhcHBsZS5jb20+CiAKICAgICAgICAgU2tpcHBp
bmcgdGVzdCBvbiBHVEsgYW5kIFdJTi4gTm8gUmV2aWV3LgpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVz
dHMvaHR0cC90ZXN0cy9hcHBjYWNoZS90b3AtZnJhbWUtMi5odG1sIGIvTGF5b3V0VGVzdHMvaHR0
cC90ZXN0cy9hcHBjYWNoZS90b3AtZnJhbWUtMi5odG1sCmluZGV4IGVkZGU4YzIuLjcxYmQ0Njgg
MTAwNjQ0Ci0tLSBhL0xheW91dFRlc3RzL2h0dHAvdGVzdHMvYXBwY2FjaGUvdG9wLWZyYW1lLTIu
aHRtbAorKysgYi9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS0yLmh0
bWwKQEAgLTI3LDYgKzI3LDE1IEBAIHZhciByZWNlaXZlZEV4cGVjdGVkTWVzc2FnZSA9IGZhbHNl
OwogdmFyIHJlY2VpdmVkQ2hlY2tpbmdFdmVudCA9IGZhbHNlOwogdmFyIHJlY2VpdmVkTm91cGRh
dGVFdmVudCA9IGZhbHNlOwogCitmdW5jdGlvbiBjaGVja0RvbmUoKQoreworICAgIGlmIChyZWNl
aXZlZEV4cGVjdGVkTWVzc2FnZSAmJiByZWNlaXZlZENoZWNraW5nRXZlbnQgJiYgcmVjZWl2ZWRO
b3VwZGF0ZUV2ZW50KSB7CisgICAgICAgIGxvZygiU1VDQ0VTUyIpOworICAgICAgICBpZiAod2lu
ZG93LmxheW91dFRlc3RDb250cm9sbGVyKQorICAgICAgICAgICAgbGF5b3V0VGVzdENvbnRyb2xs
ZXIubm90aWZ5RG9uZSgpOworICAgIH0KK30KKwogZnVuY3Rpb24gdGVzdCgpCiB7CiAgICAgYXBw
bGljYXRpb25DYWNoZS5vbm5vdXBkYXRlID0gbnVsbDsKQEAgLTQxLDE1ICs1MCw2IEBAIGZ1bmN0
aW9uIHRlc3QoKQogICAgIGRvY3VtZW50LmJvZHkuYXBwZW5kQ2hpbGQoaWZyKTsKIH0KIAotZnVu
Y3Rpb24gY2hlY2tEb25lKCkKLXsKLSAgICBpZiAocmVjZWl2ZWRFeHBlY3RlZE1lc3NhZ2UgJiYg
cmVjZWl2ZWRDaGVja2luZ0V2ZW50ICYmIHJlY2VpdmVkTm91cGRhdGVFdmVudCkgewotICAgICAg
ICBsb2coIlNVQ0NFU1MiKTsKLSAgICAgICAgaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxl
cikKLSAgICAgICAgICAgIGxheW91dFRlc3RDb250cm9sbGVyLm5vdGlmeURvbmUoKTsKLSAgICB9
Ci19Ci0KIGFwcGxpY2F0aW9uQ2FjaGUub25ub3VwZGF0ZSA9IGZ1bmN0aW9uKCkgeyB0ZXN0KCkg
fQogYXBwbGljYXRpb25DYWNoZS5vbmNhY2hlZCA9IGZ1bmN0aW9uKCkgeyB0ZXN0KCkgfQogCmRp
ZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS0zLWV4
cGVjdGVkLnR4dCBiL0xheW91dFRlc3RzL2h0dHAvdGVzdHMvYXBwY2FjaGUvdG9wLWZyYW1lLTMt
ZXhwZWN0ZWQudHh0CmluZGV4IGExMGRiZWUuLmExMjQ1Y2IgMTAwNjQ0Ci0tLSBhL0xheW91dFRl
c3RzL2h0dHAvdGVzdHMvYXBwY2FjaGUvdG9wLWZyYW1lLTMtZXhwZWN0ZWQudHh0CisrKyBiL0xh
eW91dFRlc3RzL2h0dHAvdGVzdHMvYXBwY2FjaGUvdG9wLWZyYW1lLTMtZXhwZWN0ZWQudHh0CkBA
IC00LDcgKzQsNSBAQCBJbiB0aGlzIGNhc2UsIHRoZSBzdWJmcmFtZSByZXNvdXJjZSBpcyBOT1Qg
bGlzdGVkIGluIG1hbmlmZXN0IGV4cGxpY2l0bHkuCiAKIFNob3VsZCBzYXkgU1VDQ0VTUzoKIAot
Y2hlY2tpbmcKLWNoZWNraW5nCiBTVUNDRVNTCiAKZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2h0
dHAvdGVzdHMvYXBwY2FjaGUvdG9wLWZyYW1lLTMuaHRtbCBiL0xheW91dFRlc3RzL2h0dHAvdGVz
dHMvYXBwY2FjaGUvdG9wLWZyYW1lLTMuaHRtbAppbmRleCA5ZmM5ZGRlLi5hMmQyY2M2IDEwMDY0
NAotLS0gYS9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS0zLmh0bWwK
KysrIGIvTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9hcHBjYWNoZS90b3AtZnJhbWUtMy5odG1sCkBA
IC0xNiwxMyArMTYsMzQgQEAgZnVuY3Rpb24gbG9nKG1lc3NhZ2UpCiAgICAgZG9jdW1lbnQuZ2V0
RWxlbWVudEJ5SWQoInJlc3VsdCIpLmlubmVySFRNTCArPSBtZXNzYWdlICsgIjxicj4iOwogfQog
CitmdW5jdGlvbiBkZWJ1ZyhtZXNzYWdlKQoreworICAgIC8vIElmIHJ1bm5pbmcgbWFudWFsbHkg
aW4gdGhlIGJyb3dzZXIsIHByaW50IHRoZSBzZXF1ZW5jZSBvZiBldmVudHMuCisgICAgaWYgKCF3
aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpCisgICAgICAgIGxvZyhtZXNzYWdlKTsKK30KKwor
dmFyIHJlY2VpdmVkRXhwZWN0ZWRNZXNzYWdlID0gZmFsc2U7Cit2YXIgcmVjZWl2ZWRDaGVja2lu
Z0V2ZW50c0NvdW50ZXIgPSAwOwordmFyIHJlY2VpdmVkTm91cGRhdGVFdmVudHNDb3VudGVyID0g
MDsKKworZnVuY3Rpb24gY2hlY2tEb25lKCkKK3sKKyAgICBpZiAocmVjZWl2ZWRFeHBlY3RlZE1l
c3NhZ2UgJiYgcmVjZWl2ZWRDaGVja2luZ0V2ZW50c0NvdW50ZXIgPT0gMiAmJiByZWNlaXZlZE5v
dXBkYXRlRXZlbnRzQ291bnRlciA9PSAyKSB7CisgICAgICAgIGxvZygiU1VDQ0VTUyIpOworICAg
ICAgICBpZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVyKQorICAgICAgICAgICAgbGF5b3V0
VGVzdENvbnRyb2xsZXIubm90aWZ5RG9uZSgpOworICAgIH0KK30KKwogZnVuY3Rpb24gdGVzdCgp
CiB7CiAgICAgYXBwbGljYXRpb25DYWNoZS5vbm5vdXBkYXRlID0gbnVsbDsKICAgICBhcHBsaWNh
dGlvbkNhY2hlLm9uY2FjaGVkID0gbnVsbDsKIAogICAgIC8vIFdoZW4gYSBuZXcgbWFpbiByZXNv
dXJjZSBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIGNhY2hlLCBhbiB1cGRhdGUgc2hvdWxkIGJlIHN0
YXJ0ZWQuCi0gICAgYXBwbGljYXRpb25DYWNoZS5vbmNoZWNraW5nID0gZnVuY3Rpb24oKSB7IGxv
ZygiY2hlY2tpbmciKSB9CisgICAgYXBwbGljYXRpb25DYWNoZS5vbmNoZWNraW5nID0gZnVuY3Rp
b24oKSB7IGRlYnVnKCJjaGVja2luZyIpOyByZWNlaXZlZENoZWNraW5nRXZlbnRzQ291bnRlcisr
OyBjaGVja0RvbmUoKSB9CisgICAgYXBwbGljYXRpb25DYWNoZS5vbm5vdXBkYXRlID0gZnVuY3Rp
b24oKSB7IGRlYnVnKCJub3VwZGF0ZSIpOyByZWNlaXZlZE5vdXBkYXRlRXZlbnRzQ291bnRlcisr
OyBjaGVja0RvbmUoKTsgIH0KIAogICAgIHZhciBpZnIgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50
KCJpZnJhbWUiKTsKICAgICBpZnIuc2V0QXR0cmlidXRlKCJzcmMiLCAicmVzb3VyY2VzL3N1YmZy
YW1lLTMuaHRtbCIpOwpAQCAtNDIsOSArNjMsOSBAQCBmdW5jdGlvbiB0ZXN0MigpCiAKIGZ1bmN0
aW9uIHRlc3QzKCkKIHsKLSAgICBsb2coIlNVQ0NFU1MiKTsKLSAgICBpZiAod2luZG93LmxheW91
dFRlc3RDb250cm9sbGVyKQotICAgICAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5ub3RpZnlEb25l
KCk7CisgICAgZGVidWcoIm1lc3NhZ2UiKTsKKyAgICByZWNlaXZlZEV4cGVjdGVkTWVzc2FnZSA9
IHRydWU7CisgICAgY2hlY2tEb25lKCk7CiB9CiAKIGFwcGxpY2F0aW9uQ2FjaGUub25ub3VwZGF0
ZSA9IGZ1bmN0aW9uKCkgeyB0ZXN0KCkgfQpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvaHR0cC90
ZXN0cy9hcHBjYWNoZS90b3AtZnJhbWUtNC1leHBlY3RlZC50eHQgYi9MYXlvdXRUZXN0cy9odHRw
L3Rlc3RzL2FwcGNhY2hlL3RvcC1mcmFtZS00LWV4cGVjdGVkLnR4dAppbmRleCA0M2JmZDQzLi5l
NzQ4MTYwIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2FwcGNhY2hlL3RvcC1m
cmFtZS00LWV4cGVjdGVkLnR4dAorKysgYi9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2FwcGNhY2hl
L3RvcC1mcmFtZS00LWV4cGVjdGVkLnR4dApAQCAtNCw3ICs0LDUgQEAgSW4gdGhpcyBjYXNlLCB0
aGUgc3ViZnJhbWUgcmVzb3VyY2UgaXMgbGlzdGVkIGluIG1hbmlmZXN0IGV4cGxpY2l0bHkuCiAK
IFNob3VsZCBzYXkgU1VDQ0VTUzoKIAotY2hlY2tpbmcKLWNoZWNraW5nCiBTVUNDRVNTCiAKZGlm
ZiAtLWdpdCBhL0xheW91dFRlc3RzL2h0dHAvdGVzdHMvYXBwY2FjaGUvdG9wLWZyYW1lLTQuaHRt
bCBiL0xheW91dFRlc3RzL2h0dHAvdGVzdHMvYXBwY2FjaGUvdG9wLWZyYW1lLTQuaHRtbAppbmRl
eCAzOTc0M2I5Li5jMzZlMGEzIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9odHRwL3Rlc3RzL2Fw
cGNhY2hlL3RvcC1mcmFtZS00Lmh0bWwKKysrIGIvTGF5b3V0VGVzdHMvaHR0cC90ZXN0cy9hcHBj
YWNoZS90b3AtZnJhbWUtNC5odG1sCkBAIC0xNiwxMyArMTYsMzQgQEAgZnVuY3Rpb24gbG9nKG1l
c3NhZ2UpCiAgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoInJlc3VsdCIpLmlubmVySFRNTCAr
PSBtZXNzYWdlICsgIjxicj4iOwogfQogCitmdW5jdGlvbiBkZWJ1ZyhtZXNzYWdlKQoreworICAg
IC8vIElmIHJ1bm5pbmcgbWFudWFsbHkgaW4gdGhlIGJyb3dzZXIsIHByaW50IHRoZSBzZXF1ZW5j
ZSBvZiBldmVudHMuCisgICAgaWYgKCF3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpCisgICAg
ICAgIGxvZyhtZXNzYWdlKTsKK30KKwordmFyIHJlY2VpdmVkRXhwZWN0ZWRNZXNzYWdlID0gZmFs
c2U7Cit2YXIgcmVjZWl2ZWRDaGVja2luZ0V2ZW50c0NvdW50ZXIgPSAwOwordmFyIHJlY2VpdmVk
Tm91cGRhdGVFdmVudHNDb3VudGVyID0gMDsKKworZnVuY3Rpb24gY2hlY2tEb25lKCkKK3sKKyAg
ICBpZiAocmVjZWl2ZWRFeHBlY3RlZE1lc3NhZ2UgJiYgcmVjZWl2ZWRDaGVja2luZ0V2ZW50c0Nv
dW50ZXIgPT0gMiAmJiByZWNlaXZlZE5vdXBkYXRlRXZlbnRzQ291bnRlciA9PSAyKSB7CisgICAg
ICAgIGxvZygiU1VDQ0VTUyIpOworICAgICAgICBpZiAod2luZG93LmxheW91dFRlc3RDb250cm9s
bGVyKQorICAgICAgICAgICAgbGF5b3V0VGVzdENvbnRyb2xsZXIubm90aWZ5RG9uZSgpOworICAg
IH0KK30KKwogZnVuY3Rpb24gdGVzdCgpCiB7CiAgICAgYXBwbGljYXRpb25DYWNoZS5vbm5vdXBk
YXRlID0gbnVsbDsKICAgICBhcHBsaWNhdGlvbkNhY2hlLm9uY2FjaGVkID0gbnVsbDsKIAogICAg
IC8vIFdoZW4gYSBuZXcgbWFpbiByZXNvdXJjZSBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIGNhY2hl
LCBhbiB1cGRhdGUgc2hvdWxkIGJlIHN0YXJ0ZWQuCi0gICAgYXBwbGljYXRpb25DYWNoZS5vbmNo
ZWNraW5nID0gZnVuY3Rpb24oKSB7IGxvZygiY2hlY2tpbmciKSB9CisgICAgYXBwbGljYXRpb25D
YWNoZS5vbmNoZWNraW5nID0gZnVuY3Rpb24oKSB7IGRlYnVnKCJjaGVja2luZyIpOyByZWNlaXZl
ZENoZWNraW5nRXZlbnRzQ291bnRlcisrOyBjaGVja0RvbmUoKSB9CisgICAgYXBwbGljYXRpb25D
YWNoZS5vbm5vdXBkYXRlID0gZnVuY3Rpb24oKSB7IGRlYnVnKCJub3VwZGF0ZSIpOyByZWNlaXZl
ZE5vdXBkYXRlRXZlbnRzQ291bnRlcisrOyBjaGVja0RvbmUoKTsgIH0KIAogICAgIHZhciBpZnIg
PSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJpZnJhbWUiKTsKICAgICBpZnIuc2V0QXR0cmlidXRl
KCJzcmMiLCAicmVzb3VyY2VzL3N1YmZyYW1lLTQuaHRtbCIpOwpAQCAtNDIsOSArNjMsOSBAQCBm
dW5jdGlvbiB0ZXN0MigpCiAKIGZ1bmN0aW9uIHRlc3QzKCkKIHsKLSAgICBsb2coIlNVQ0NFU1Mi
KTsKLSAgICBpZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVyKQotICAgICAgICBsYXlvdXRU
ZXN0Q29udHJvbGxlci5ub3RpZnlEb25lKCk7CisgICAgZGVidWcoIm1lc3NhZ2UiKTsKKyAgICBy
ZWNlaXZlZEV4cGVjdGVkTWVzc2FnZSA9IHRydWU7CisgICAgY2hlY2tEb25lKCk7CiB9CiAKIGFw
cGxpY2F0aW9uQ2FjaGUub25ub3VwZGF0ZSA9IGZ1bmN0aW9uKCkgeyB0ZXN0KCkgfQo=
</data>
<flag name="review"
          id="33709"
          type_id="1"
          status="+"
          setter="ap"
    />
    <flag name="commit-queue"
          id="33710"
          type_id="3"
          status="-"
          setter="dimich"
    />
          </attachment>
      

    </bug>

</bugzilla>