33538 2010-01-12 10:49:49 -0800 history.back() for same-document history traversals isn't synchronous as the spec. states. 2010-01-21 23:30:02 -0800 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) All All RESOLVED FIXED InRadar P2 Normal --- 1 beidson beidson brettw fishd ian oliver oldest_to_newest 179884 0 46382 beidson 2010-01-12 10:49:49 -0800 Created attachment 46382 Test case push/replaceState() during load followed by a history.back() doesn't work as expected. According to 10.5.3 of the spec (http://dev.w3.org/html5/spec/Overview.html#activating-state-object-entries), if a state object is popped before the document has loaded, that popped state object becomes the "pending" state object and the event is to-be-fired after the load event fires. I thought I had this working originally when working on the ajaxy history stuff, but apparently missed it in the end. See the attached test case. The output is: Pushing state - document.readyState is loading Popping state - document.readyState is loading State popped - null (type object) - document.readyState is complete And I'd expect it to be: Pushing state - document.readyState is loading Popping state - document.readyState is loading Load event fired - document.readyState is complete State popped - New state (type string) - document.readyState is complete 179972 1 beidson 2010-01-12 14:03:47 -0800 <rdar://problem/7535011> 180025 2 beidson 2010-01-12 16:31:34 -0800 The history.back() scheduling cancels the current load, putting the document into the complete state but never firing the load event. Either we need to do the history.back() synchronously or somehow remember to fire the load event along with it. 180036 3 beidson 2010-01-12 16:52:18 -0800 In the case of following a fragment scroll link, the load is performed synchronously via the "loadInSameDocument" call. I bet that this works in the "before the document has loaded" case just the same as what we're trying to achieve here with the history navigation to a state entry. It should be pretty easy to bottleneck this new interesting case in HistoryController. 180263 4 fishd 2010-01-13 09:50:48 -0800 > Either we need to do the history.back() synchronously or somehow remember to > fire the load event along with it. It is important that history.back() be performed asynchronously. 180489 5 beidson 2010-01-13 17:36:24 -0800 (In reply to comment #4) > > Either we need to do the history.back() synchronously or somehow remember to > > fire the load event along with it. > > It is important that history.back() be performed asynchronously. I'm curious why you say this. 6.10.2's description of history.go() makes no mention of queueing any part of the operation or making it be asynchronous. Step's 1-5 choose the specified entry then step 6 hands it off to 6.11.9. 6.11.9's description of history traversal makes no mention of queueing any of the operations (except for 6.11.9.4.5 which is only about queueing the pageshow event) or making it be asynchronous. What am I missing? 181730 6 beidson 2010-01-17 21:45:30 -0800 Since Darin (Fisher) hasn't elaborated on why he thinks this history.back() needs to be asynchronous and there's already a pretty solid example of a synchronous back/forward navigation that we already do (back/forward amongst fragment scrolls), I'm going to start on a patch that does this type of history.go() synchronously similar to how fragment scrolls work. 181751 7 46793 beidson 2010-01-17 23:43:15 -0800 Created attachment 46793 Slightly updated test case 181752 8 46794 beidson 2010-01-17 23:45:36 -0800 Created attachment 46794 WIP patch Current WIP. This turned out to be surprisingly easy to get ALMOST right. This patch makes the above test case work as well as others that are a mix of fragment navs and fragment/state object combinations. The only think this patch obviously gets wrong is the back-forward cursor is not set to the right place after the history.back(). Weeding out why might be easy. 181753 9 beidson 2010-01-17 23:46:16 -0800 Gosh I hope the try-bots don't actually try to run on this patch, I sure don't want them to waste their time. 182104 10 fishd 2010-01-18 19:40:29 -0800 Sorry for the slow response. I missed the bugmail. Please see https://bugs.webkit.org/show_bug.cgi?id=25570 for reference. For compat with IE, FF and Chrome, I changed WebKit to make history.{back,forward,go} work asynchronously. It turns out that Chrome has to perform these asynchronously since the back forward list is stored in another process. In general, I also believe we should favor making DOM methods that trigger DOM events function asynchronously whenever possible. It helps reduce complexity by avoiding re-entrancy issues. Stepping back, please note that history.back cannot complete synchronously in all cases. Often, it requires loading data from the network or from a disk cache, which happens asynchronously. In the page cache case or in the fragment scroll case, you could perform history.back() synchronously, but I'd argue that it is a bad idea to make the behavior differ from a normal back navigation. 182105 11 fishd 2010-01-18 19:42:27 -0800 I think we need to get clarity from the working groups to understand what is supposed to happen in this case. Since history.back() cancels the page load, and prevents the load event from firing, it is not possible for the "pending" state object to-be-fired after the load event fires. Maybe the spec should be amended to say that it can also fire after a load error? 182120 12 beidson 2010-01-18 20:34:30 -0800 Let me preface my reply by saying that I'm not trying to have an academic discussion about whether this should or should not be synchronous. What I am attempting to bring together is: 1 - How WebKit actually behaves today in some cases. 2 - How other browsers actually behave today in the same cases. 3 - Exactly what the specified behavior is. (In reply to comment #10) > Sorry for the slow response. I missed the bugmail. > Please see https://bugs.webkit.org/show_bug.cgi?id=25570 for reference. > For compat with IE, FF and Chrome, I changed WebKit to make > history.{back,forward,go} work asynchronously In your first comment in 25570, you say: "None of the other browsers behave this way. They always dispatch history.{back,forward,go} asynchronously." Are you sure they dispatch the back/forward asynchronously, or is it simply possible that they fired the scroll event asynchronously? > In general, I also believe we should favor making DOM methods that trigger DOM > events function asynchronously whenever possible. It helps reduce complexity > by avoiding re-entrancy issues. In general I agree with this philosophy. But there's also something to be said for not changing long-since-implemented, well-tested behavior for idealistic reasons. In this context I'm referring to fragment scroll, both in the sense of a fragment navigation (which is often/always synchronous in WebKit) as well as fragment history traversals. That the state object navigation/traversal model matches so well with the one for fragment navigation/traversal is no accident. The spec seems to quite purposefully treat them similarly or even identically. > Stepping back, please note that history.back cannot complete synchronously in > all cases. > Often, it requires loading data from the network or from a disk > cache, which happens asynchronously. Well of course! This is why the spec is so very explicit about what is synchronous and what is not. According to 6.11.9.1, if the specified entry has no document then the traversal algorithm is aborted and the navigation algorithm (6.11.1) is invoked. And at 6.11.1.12, the navigation algorithm specifically calls out converting to asynchronous operation. But just-as-explicitly in the spec is traversals and navigations that *do* happen synchronously. 6.11.1, for example, points out that navigations to about:blank or to certain types of inline content *must* be synchronous. And back in 6.11.9.1, if the specific entry has a Document object then 6.11.1 is skipped altogether. Cases where the target entry might have a document are if it represents a fragment difference from the current document's URL, if it represents a state object entry for the current document, or if its document is suspended in a page cache. For these cases, the entire remainder of 6.11.9 completes synchronously. > In the page cache case or in the fragment scroll case, you could perform > history.back() synchronously, but I'd argue that it is a bad idea to make the > behavior differ from a normal back navigation. You were quite prescient in calling out those two cases, as I just did above, and as the spec already has. :) (In reply to comment #11) > I think we need to get clarity from the working groups to understand what is > supposed to happen in this case. I think raising the conversation with the working groups is needed at this point in the discussion. But my understanding of 6.11.9 leading into 6.11.1 involves little ambiguity - I'm pretty sure the expected behavior I've laid out *is* what is specified, even if it wasn't necessarily the intentions of the editors. > Since history.back() cancels the page load, and prevents the load event from > firing, it is not possible for the "pending" state object to-be-fired after the > load event fires. This might be the difference in our understandings that is causing the confusion. history.back() does not actually cancel the page load. history.back() simply finds the target item from the session history then hands it off to the History traversal algorithm (6.11.9). If the specified item fails the check in 6.11.9.1 and is handed off to the Navigation algorithm (6.11.1), then yes - 6.11.1.5 or 6.11.1.7 might cause the current load to be stopped. Please note that even the Navigation algorithm can be aborted *without* the current load being stopped (e.g., 6.11.1.4). In the interesting cases being discussed - state objects entries and fragment scroll entries - the current load is not necessarily stopped. 182129 13 ian 2010-01-18 21:18:50 -0800 As far as I can tell, Brady is right. In my testing, I found IE to be synchronous in the same way the spec describes. If you think this should change, I recommend creating a tiny test case demonstrating the difference between the spec and what you think should happen, and e-mailing the WG with the URL to that test case. 182130 14 fishd 2010-01-18 21:27:11 -0800 (In reply to comment #12) > Let me preface my reply by saying that I'm not trying to have an academic > discussion about whether this should or should not be synchronous. > > What I am attempting to bring together is: > 1 - How WebKit actually behaves today in some cases. > 2 - How other browsers actually behave today in the same cases. > 3 - Exactly what the specified behavior is. That's good, but I think we should also consider how things should be, especially at this stage of the game where the spec for pushState is still in flux. > (In reply to comment #10) > > Sorry for the slow response. I missed the bugmail. > > Please see https://bugs.webkit.org/show_bug.cgi?id=25570 for reference. > > For compat with IE, FF and Chrome, I changed WebKit to make > > history.{back,forward,go} work asynchronously > > In your first comment in 25570, you say: > "None of the other browsers behave this way. They always dispatch > history.{back,forward,go} asynchronously." > > Are you sure they dispatch the back/forward asynchronously, or is it simply > possible that they fired the scroll event asynchronously? I think I observed the scroll event in my testing, so it could be either. Digging through the Mozilla code, I believe it is indeed the latter. (Perhaps we should consider dispatching the scroll event asynchronously as well.) > > In general, I also believe we should favor making DOM methods that trigger DOM > > events function asynchronously whenever possible. It helps reduce complexity > > by avoiding re-entrancy issues. > > In general I agree with this philosophy. But there's also something to be said > for not changing long-since-implemented, well-tested behavior for idealistic > reasons. In this context I'm referring to fragment scroll, both in the sense > of a fragment navigation (which is often/always synchronous in WebKit) as well > as fragment history traversals. > > That the state object navigation/traversal model matches so well with the one > for fragment navigation/traversal is no accident. The spec seems to quite > purposefully treat them similarly or even identically. Yeah, that makes sense. > > Since history.back() cancels the page load, and prevents the load event from > > firing, it is not possible for the "pending" state object to-be-fired after the > > load event fires. > > This might be the difference in our understandings that is causing the > confusion. history.back() does not actually cancel the page load. > > history.back() simply finds the target item from the session history then hands > it off to the History traversal algorithm (6.11.9). > > If the specified item fails the check in 6.11.9.1 and is handed off to the > Navigation algorithm (6.11.1), then yes - 6.11.1.5 or 6.11.1.7 might cause the > current load to be stopped. Please note that even the Navigation algorithm can > be aborted *without* the current load being stopped (e.g., 6.11.1.4). > > In the interesting cases being discussed - state objects entries and fragment > scroll entries - the current load is not necessarily stopped. This indeed clears up some confusion on my part. Now, I'm confused about why history.back() scheduling cancels the load. Perhaps that is not necessary, and if we fix that, we'll have fixed this bug? I'm also a bit confounded by what it *should* mean to call pushState during page load. replaceState makes sense. Navigating to a reference fragment during page load is a lot like replaceState. It seems a bit strange and potentially problematic to be changing the current HistoryItem during page load without also stopping page load. Just imagine what happens if the BODY includes an IFRAME after some inline script has called pushState. Do we have to go back to the previous HistoryItem and append a HistoryItem for the IFRAME? 182143 15 beidson 2010-01-18 23:00:24 -0800 > > > (In reply to comment #10) > > > Sorry for the slow response. I missed the bugmail. > > > Please see https://bugs.webkit.org/show_bug.cgi?id=25570 for reference. > > > For compat with IE, FF and Chrome, I changed WebKit to make > > > history.{back,forward,go} work asynchronously > > > > In your first comment in 25570, you say: > > "None of the other browsers behave this way. They always dispatch > > history.{back,forward,go} asynchronously." > > > > Are you sure they dispatch the back/forward asynchronously, or is it simply > > possible that they fired the scroll event asynchronously? > > I think I observed the scroll event in my testing, so it could be either. > Digging through the Mozilla code, I believe it is indeed the latter. > > (Perhaps we should consider dispatching the scroll event asynchronously as > well.) I scoured the text of the spec' to see how dispatching the scroll event is defined, but came up short. Is it in there at all? > This indeed clears up some confusion on my part. > > > Now, I'm confused about why history.back() scheduling cancels the load. > Perhaps that is not necessary, and if we fix that, we'll have fixed this bug? We simply don't match the spec yet. The idea of creating a cohesive spec of navigation and history traversal by looking at all the major browsers had never been done before HTML5 and it seems highly unlikely we would've already matched it without fixing some bugs. :) That said, this bug isn't so much about fixing this one specific test case in any particular manner. Rather it's about changing us to match the spec in a way this test case uncovered. If we pushed back canceling the load until the scheduled redirect occurred, but still kept the history.back() asynchronous, then yes that would fix the symptom in this bug. But in exploring this I think we've uncovered an understanding that this test case is meant to involve a synchronous history traversal. > I'm also a bit confounded by what it *should* mean to call pushState during > page load. replaceState makes sense. Navigating to a reference fragment > during page load is a lot like replaceState. It seems a bit strange and > potentially problematic to be changing the current HistoryItem during page load > without also stopping page load. Just imagine what happens if the BODY > includes an IFRAME after some inline script has called pushState. Do we have > to go back to the previous HistoryItem and append a HistoryItem for the IFRAME? I don't see why you would. As long as the document is live and shared between the two history entries, then returning to the original HistoryItem in your scenario would simply be an inter-document history traversal and not depend on knowing anything about the frame tree. Additionally, if the document was navigated away from and cleared from the history entries, then the URLs in those HistoryItems are the one true representation of their state - frames or no frames, state objects or no state objects. 183043 16 beidson 2010-01-20 19:39:07 -0800 Updating the title to reflect the final understanding of what needs to be changed. 183048 17 47095 beidson 2010-01-20 19:54:10 -0800 Created attachment 47095 Patch and layout test updates After a few back and forths here and with Hixie's guidance, I think we're all in agreement with what the spec says. That said, I think there's still disagreement on what the spec *should* be. Personally, I don't see any problem with the spec as-is and we've even analyzed how the synchronicity here might affect WebKit in a multi-process future, and we're pretty convinced it's not a huge problem. This same consensus was reached by at least one non-WebKit contributor who works on the spec. If there are changes to be made to the spec in the future, that's fine - the process will work its magic and we'll make WebKit compliant. Until then, this patch brings WebKit inline with the spec we have. 183049 18 47095 oliver 2010-01-20 20:04:19 -0800 Comment on attachment 47095 Patch and layout test updates What happens if i now do: history.back(); // going to a different document, so it's asynchronous history.forward(); // going to the same document which will be synchronous My reading say that the history.back() call will make an asynchronous load going back 1 step, history.forward will now happen synchronously so will be done before the back load starts. When back starts there has now been an additional state put into history, so stepping back 1 entry will take us back to the original point. This seems odd to me. 183053 19 47095 mjs 2010-01-20 20:11:00 -0800 Comment on attachment 47095 Patch and layout test updates r=me 183114 20 fishd 2010-01-21 01:01:45 -0800 Please hold the presses! This behavior change is not something we can easily support in Chrome, so by making this change, you are introducing a compatibility difference between Chrome and Safari. At the very least, this change is going to break Chrome in a serious way until I have a chance to compensate for it. I think that warrants further discussion (or at least some temporary #ifdefs if you are going to land it now). > If we pushed back canceling the load until the scheduled redirect occurred, but > still kept the history.back() asynchronous, then yes that would fix the symptom > in this bug. But in exploring this I think we've uncovered an understanding > that this test case is meant to involve a synchronous history traversal. I think we should explore this solution further. I understand your desire to match the spec, but I also think that the spec can and should change without breaking anything. It is clear that IE does not implement history.back() in a synchronous manner, so we should not need to make it synchronous for web compat reasons. 183458 21 beidson 2010-01-21 20:23:08 -0800 Landed in http://trac.webkit.org/changeset/53672 with the new behavior disabled for Chromium. 183511 22 fishd 2010-01-21 23:30:02 -0800 (In reply to comment #18) > (From update of attachment 47095 [details]) > What happens if i now do: > history.back(); // going to a different document, so it's asynchronous > history.forward(); // going to the same document which will be synchronous > > My reading say that the history.back() call will make an asynchronous load > going back 1 step, history.forward will now happen synchronously so will be > done before the back load starts. When back starts there has now been an > additional state put into history, so stepping back 1 entry will take us back > to the original point. > > This seems odd to me. This is a good question. Brady, did you and Oliver discuss this issue? Would either of you mind sharing the resolution? Thank you for the ENABLE(HISTORY_ALWAYS_ASYNC) define! (I still hope to convince you that all WebKit ports should enable that flag.) 46382 2010-01-12 10:49:49 -0800 2010-01-17 23:43:15 -0800 Test case pushstate-then-popstate-before-load.html text/html 945 beidson PGh0bWw+CjxoZWFkPgo8c2NyaXB0PgoKaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikg ewogICAgbGF5b3V0VGVzdENvbnRyb2xsZXIuY2xlYXJCYWNrRm9yd2FyZExpc3QoKTsKICAgIGxh eW91dFRlc3RDb250cm9sbGVyLmR1bXBBc1RleHQoKTsKICAgIGxheW91dFRlc3RDb250cm9sbGVy LndhaXRVbnRpbERvbmUoKTsKfQoKZnVuY3Rpb24gbG9nKHR4dCkKewogICAgZG9jdW1lbnQuZ2V0 RWxlbWVudEJ5SWQoImxvZ2dlciIpLmlubmVyVGV4dCArPSB0eHQgKyAiXG4iOwp9CiAgICAKZnVu Y3Rpb24gbG9hZGVkKCkKewogICAgbG9nKCJMb2FkIGV2ZW50IGZpcmVkIC0gZG9jdW1lbnQucmVh ZHlTdGF0ZSBpcyAiICsgZG9jdW1lbnQucmVhZHlTdGF0ZSk7Cn0KCmZ1bmN0aW9uIHN0YXRlUG9w cGVkKCkKewogICAgbG9nKCJTdGF0ZSBwb3BwZWQgLSAiICsgZXZlbnQuc3RhdGUgKyAiICh0eXBl ICIgKyB0eXBlb2YgZXZlbnQuc3RhdGUgKyAiKSAtIGRvY3VtZW50LnJlYWR5U3RhdGUgaXMgIiAr IGRvY3VtZW50LnJlYWR5U3RhdGUpOwogICAgaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxl cikKICAgICAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5ub3RpZnlEb25lKCk7Cn0KCjwvc2NyaXB0 Pgo8Ym9keSBvbmxvYWQ9ImxvYWRlZCgpOyIgb25wb3BzdGF0ZT0ic3RhdGVQb3BwZWQoKTsiPgo8 cHJlIGlkPSJsb2dnZXIiPjwvcHJlPgo8c2NyaXB0PgoKbG9nKCJQdXNoaW5nIHN0YXRlIC0gZG9j dW1lbnQucmVhZHlTdGF0ZSBpcyAiICsgZG9jdW1lbnQucmVhZHlTdGF0ZSk7Cmhpc3RvcnkucHVz aFN0YXRlKCJOZXcgc3RhdGUiLCAiTmV3IHRpdGxlIik7CmxvZygiUG9wcGluZyBzdGF0ZSAtIGRv Y3VtZW50LnJlYWR5U3RhdGUgaXMgIiArIGRvY3VtZW50LnJlYWR5U3RhdGUpOwpoaXN0b3J5LmJh Y2soKTsKCjwvc2NyaXB0Pgo8L2JvZHk+CjwvaHRtbD4K 46793 2010-01-17 23:43:15 -0800 2010-01-17 23:43:15 -0800 Slightly updated test case test.html text/html 1077 beidson PGh0bWw+CjxoZWFkPgo8c2NyaXB0PgoKaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxlcikg ewogICAgbGF5b3V0VGVzdENvbnRyb2xsZXIuY2xlYXJCYWNrRm9yd2FyZExpc3QoKTsKICAgIGxh eW91dFRlc3RDb250cm9sbGVyLmR1bXBBc1RleHQoKTsKICAgIGxheW91dFRlc3RDb250cm9sbGVy LndhaXRVbnRpbERvbmUoKTsKfQoKZnVuY3Rpb24gbG9nKHR4dCkKewogICAgZG9jdW1lbnQuZ2V0 RWxlbWVudEJ5SWQoImxvZ2dlciIpLmlubmVyVGV4dCArPSB0eHQgKyAiXG4iOwp9CiAgICAKZnVu Y3Rpb24gbG9hZGVkKCkKewogICAgbG9nKCJMb2FkIGV2ZW50IGZpcmVkIC0gZG9jdW1lbnQucmVh ZHlTdGF0ZSBpcyAiICsgZG9jdW1lbnQucmVhZHlTdGF0ZSk7Cn0KCmZ1bmN0aW9uIHN0YXRlUG9w cGVkKCkKewogICAgbG9nKCJTdGF0ZSBwb3BwZWQgLSAiICsgZXZlbnQuc3RhdGUgKyAiICh0eXBl ICIgKyB0eXBlb2YgZXZlbnQuc3RhdGUgKyAiKSAtIGRvY3VtZW50LnJlYWR5U3RhdGUgaXMgIiAr IGRvY3VtZW50LnJlYWR5U3RhdGUpOwogICAgaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJvbGxl cikKICAgICAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5ub3RpZnlEb25lKCk7Cn0KCjwvc2NyaXB0 Pgo8Ym9keSBvbmxvYWQ9ImxvYWRlZCgpOyIgb25wb3BzdGF0ZT0ic3RhdGVQb3BwZWQoKTsiPgo8 cHJlIGlkPSJsb2dnZXIiPjwvcHJlPgo8c2NyaXB0PgoKbG9nKCJTZXR0aW5nIHVwIHN0YXRlIC0g ZG9jdW1lbnQucmVhZHlTdGF0ZSBpcyAiICsgZG9jdW1lbnQucmVhZHlTdGF0ZSk7Cmhpc3Rvcnku cmVwbGFjZVN0YXRlKCJGaXJzdCBzdGF0ZSIsICJGaXJzdCB0aXRsZSIpOwpoaXN0b3J5LnB1c2hT dGF0ZSgiU2Vjb25kIHN0YXRlIiwgIlNlY29uZCB0aXRsZSIpOwpsb2coImhpc3RvcnkubGVuZ3Ro IGlzIG5vdyAiICsgaGlzdG9yeS5sZW5ndGgpOwpsb2coIkFib3V0IHRvIHBvcCBzdGF0ZSB2aWEg aGlzdG9yeS5iYWNrKCkgLSBkb2N1bWVudC5yZWFkeVN0YXRlIGlzICIgKyBkb2N1bWVudC5yZWFk eVN0YXRlKTsKaGlzdG9yeS5iYWNrKCk7Cgo8L3NjcmlwdD4KPC9ib2R5Pgo8L2h0bWw+ 46794 2010-01-17 23:45:36 -0800 2010-01-20 19:54:10 -0800 WIP patch currentpatch.txt text/plain 1814 beidson SW5kZXg6IFdlYkNvcmUvbG9hZGVyL1JlZGlyZWN0U2NoZWR1bGVyLmNwcAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBXZWJDb3JlL2xvYWRlci9SZWRpcmVjdFNjaGVkdWxlci5jcHAJKHJldmlzaW9uIDUzMzkwKQor KysgV2ViQ29yZS9sb2FkZXIvUmVkaXJlY3RTY2hlZHVsZXIuY3BwCSh3b3JraW5nIGNvcHkpCkBA IC0zMiwxMiArMzIsMTQgQEAKICNpbmNsdWRlICJjb25maWcuaCIKICNpbmNsdWRlICJSZWRpcmVj dFNjaGVkdWxlci5oIgogCisjaW5jbHVkZSAiQmFja0ZvcndhcmRMaXN0LmgiCiAjaW5jbHVkZSAi RG9jdW1lbnRMb2FkZXIuaCIKICNpbmNsdWRlICJFdmVudC5oIgogI2luY2x1ZGUgIkZvcm1TdGF0 ZS5oIgogI2luY2x1ZGUgIkZyYW1lLmgiCiAjaW5jbHVkZSAiRnJhbWVMb2FkUmVxdWVzdC5oIgog I2luY2x1ZGUgIkZyYW1lTG9hZGVyLmgiCisjaW5jbHVkZSAiSGlzdG9yeUl0ZW0uaCIKICNpbmNs dWRlICJIVE1MRm9ybUVsZW1lbnQuaCIKICNpbmNsdWRlICJIVE1MRnJhbWVPd25lckVsZW1lbnQu aCIKICNpbmNsdWRlICJQYWdlLmgiCkBAIC0yNjUsMTEgKzI2NywyMSBAQCB2b2lkIFJlZGlyZWN0 U2NoZWR1bGVyOjpzY2hlZHVsZUhpc3RvcnlOCiAKICAgICAvLyBJbnZhbGlkIGhpc3RvcnkgbmF2 aWdhdGlvbnMgKHN1Y2ggYXMgaGlzdG9yeS5mb3J3YXJkKCkgZHVyaW5nIGEgbmV3IGxvYWQpIGhh dmUgdGhlIHNpZGUgZWZmZWN0IG9mIGNhbmNlbGxpbmcgYW55IHNjaGVkdWxlZAogICAgIC8vIHJl ZGlyZWN0cy4gV2UgYWxzbyBhdm9pZCB0aGUgcG9zc2liaWxpdHkgb2YgY2FuY2VsbGluZyB0aGUg Y3VycmVudCBsb2FkIGJ5IGF2b2lkaW5nIHRoZSBzY2hlZHVsZWQgcmVkaXJlY3Rpb24gYWx0b2dl dGhlci4KLSAgICBpZiAoIW1fZnJhbWUtPnBhZ2UoKS0+Y2FuR29CYWNrT3JGb3J3YXJkKHN0ZXBz KSkgeyAKLSAgICAgICAgY2FuY2VsKCk7IAotICAgICAgICByZXR1cm47IAotICAgIH0gCisgICAg SGlzdG9yeUl0ZW0qIHNwZWNpZmllZEVudHJ5ID0gbV9mcmFtZS0+cGFnZSgpLT5iYWNrRm9yd2Fy ZExpc3QoKS0+aXRlbUF0SW5kZXgoc3RlcHMpOworICAgIGlmICghc3BlY2lmaWVkRW50cnkpIHsK KyAgICAgICAgY2FuY2VsKCk7CisgICAgICAgIHJldHVybjsKKyAgICB9CiAKKyAgICAvLyBJZiB0 aGUgc3BlY2lmaWVkIGVudHJ5IGFuZCB0aGUgY3VycmVudCBlbnRyeSBoYXZlIHRoZSBzYW1lIGRv Y3VtZW50LCB0aGlzIGlzIGVpdGhlciBhIHN0YXRlIG9iamVjdCB0cmF2ZXJzYWwgb3IgYSBmcmFn bWVudCAKKyAgICAvLyB0cmF2ZXJzYWwgKG9yIGJvdGgpIGFuZCBjYW4gYmUgcGVyZm9ybWVkIHN5 bmNocm9ub3VzbHkuCisgICAgSGlzdG9yeUl0ZW0qIGN1cnJlbnRFbnRyeSA9IG1fZnJhbWUtPmxv YWRlcigpLT5oaXN0b3J5KCktPmN1cnJlbnRJdGVtKCk7CisgICAgaWYgKGN1cnJlbnRFbnRyeSAh PSBzcGVjaWZpZWRFbnRyeSAmJiBjdXJyZW50RW50cnktPmRvY3VtZW50KCkgPT0gc3BlY2lmaWVk RW50cnktPmRvY3VtZW50KCkpIHsKKyAgICAgICAgbV9mcmFtZS0+bG9hZGVyKCktPmxvYWRJdGVt KHNwZWNpZmllZEVudHJ5LCBGcmFtZUxvYWRUeXBlSW5kZXhlZEJhY2tGb3J3YXJkKTsKKyAgICAg ICAgcmV0dXJuOworICAgIH0KKyAgICAKKyAgICAvLyBJbiBhbGwgb3RoZXIgY2FzZXMsIHNjaGVk dWxlIHRoZSBoaXN0b3J5IHRyYXZlcnNhbCB0byBvY2N1ciBhc3luY2hyb25vdXNseS4KICAgICBz Y2hlZHVsZShuZXcgU2NoZWR1bGVkUmVkaXJlY3Rpb24oc3RlcHMpKTsKIH0KIAo= 47095 2010-01-20 19:54:10 -0800 2010-01-20 20:10:59 -0800 Patch and layout test updates patch.txt text/plain 11549 beidson SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA1MzU5NCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMjEgQEAKKzIwMTAtMDEtMjAgIEJyYWR5IEVpZHNvbiAgPGJlaWRzb25AYXBwbGUu Y29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIGhp c3RvcnkuYmFjaygpIGZvciBzYW1lLWRvY3VtZW50IGhpc3RvcnkgdHJhdmVyc2FscyBpc24ndCBz eW5jaHJvbm91cyBhcyB0aGUgc3BlY2lmaWNhdGlvbiBzdGF0ZXMuCisgICAgICAgIDxyZGFyOi8v cHJvYmxlbS83NTM1MDExPiBhbmQgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp P2lkPTMzNTM4CisKKyAgICAgICAgSW4gcmVzb2x2aW5nIGh0dHBzOi8vYnVncy53ZWJraXQub3Jn L3Nob3dfYnVnLmNnaT9pZD0yNTU3MCwgYWxsIGhpc3RvcnkuYmFjaygpL2ZvcndhcmQoKS9nbygp IG5hdmlnYXRpb25zCisgICAgICAgIHdlcmUgbWFkZSBhc3luY2hyb25vdXMuIFRoYXQgZG9lc24n dCBhZ3JlZSB3aXRoIHRoZSBIVE1MNSBzcGVjIGFuZCBtaWdodCBoYXZlIGJlZW4gb3ZlcnJlYWNo aW5nIGZvciBmaXhpbmcKKyAgICAgICAgdGhhdCBwYXJ0aWN1bGFyIGJ1Zy4gSW4gd29ya2luZyB3 aXRoIHRoZSBuZXcgaGlzdG9yeSBzdGF0ZSBBUElzIEkgbm90aWNlZCBzb21lIHRoaW5ncyB0aGF0 IHNob3VsZCd2ZSBiZWVuCisgICAgICAgIHBvc3NpYmxlIHdlcmUgbm90IHBvc3NpYmxlIGJlY2F1 c2Ugb2YgdGhpcyBjaGFuZ2UuCisKKyAgICAgICAgVGhlIGNoYW5nZSBpbiBsb2FkaW5nIGJlaGF2 aW9yIGlzIHdlbGwgY292ZXJlZCB2aWEgbW9kaWZpY2F0aW9ucyB0byBwcmV2aW91cyB0ZXN0cy4K KworICAgICAgICAqIGxvYWRlci9SZWRpcmVjdFNjaGVkdWxlci5jcHA6CisgICAgICAgIChXZWJD b3JlOjpSZWRpcmVjdFNjaGVkdWxlcjo6c2NoZWR1bGVIaXN0b3J5TmF2aWdhdGlvbik6IERldGVy bWluZSBiZWZvcmVoYW5kIGlmIHRoZSB0cmF2ZXJzYWwgaXMKKyAgICAgICAgICBhIHNhbWUtZG9j dW1lbnQgbmF2aWdhdGlvbi4gSWYgaXQgaXMsIHBlcmZvcm0gdGhlIGxvYWQgZGlyZWN0bHkgaW5z dGVhZCBvZiBzY2hlZHVsaW5nIGl0LgorCiAyMDEwLTAxLTIwICBGdW1pdG9zaGkgVWthaSAgPHVr YWlAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFJldmlld2VkIGJ5IEFsZXhleSBQcm9za3VyeWFr b3YuCkluZGV4OiBXZWJDb3JlL2xvYWRlci9SZWRpcmVjdFNjaGVkdWxlci5jcHAKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gV2ViQ29yZS9sb2FkZXIvUmVkaXJlY3RTY2hlZHVsZXIuY3BwCShyZXZpc2lvbiA1MzU5 MikKKysrIFdlYkNvcmUvbG9hZGVyL1JlZGlyZWN0U2NoZWR1bGVyLmNwcAkod29ya2luZyBjb3B5 KQpAQCAtMzIsMTIgKzMyLDE0IEBACiAjaW5jbHVkZSAiY29uZmlnLmgiCiAjaW5jbHVkZSAiUmVk aXJlY3RTY2hlZHVsZXIuaCIKIAorI2luY2x1ZGUgIkJhY2tGb3J3YXJkTGlzdC5oIgogI2luY2x1 ZGUgIkRvY3VtZW50TG9hZGVyLmgiCiAjaW5jbHVkZSAiRXZlbnQuaCIKICNpbmNsdWRlICJGb3Jt U3RhdGUuaCIKICNpbmNsdWRlICJGcmFtZS5oIgogI2luY2x1ZGUgIkZyYW1lTG9hZFJlcXVlc3Qu aCIKICNpbmNsdWRlICJGcmFtZUxvYWRlci5oIgorI2luY2x1ZGUgIkhpc3RvcnlJdGVtLmgiCiAj aW5jbHVkZSAiSFRNTEZvcm1FbGVtZW50LmgiCiAjaW5jbHVkZSAiSFRNTEZyYW1lT3duZXJFbGVt ZW50LmgiCiAjaW5jbHVkZSAiUGFnZS5oIgpAQCAtMjY1LDExICsyNjcsMjEgQEAgdm9pZCBSZWRp cmVjdFNjaGVkdWxlcjo6c2NoZWR1bGVIaXN0b3J5TgogCiAgICAgLy8gSW52YWxpZCBoaXN0b3J5 IG5hdmlnYXRpb25zIChzdWNoIGFzIGhpc3RvcnkuZm9yd2FyZCgpIGR1cmluZyBhIG5ldyBsb2Fk KSBoYXZlIHRoZSBzaWRlIGVmZmVjdCBvZiBjYW5jZWxsaW5nIGFueSBzY2hlZHVsZWQKICAgICAv LyByZWRpcmVjdHMuIFdlIGFsc28gYXZvaWQgdGhlIHBvc3NpYmlsaXR5IG9mIGNhbmNlbGxpbmcg dGhlIGN1cnJlbnQgbG9hZCBieSBhdm9pZGluZyB0aGUgc2NoZWR1bGVkIHJlZGlyZWN0aW9uIGFs dG9nZXRoZXIuCi0gICAgaWYgKCFtX2ZyYW1lLT5wYWdlKCktPmNhbkdvQmFja09yRm9yd2FyZChz dGVwcykpIHsgCi0gICAgICAgIGNhbmNlbCgpOyAKLSAgICAgICAgcmV0dXJuOyAKLSAgICB9IAor ICAgIEhpc3RvcnlJdGVtKiBzcGVjaWZpZWRFbnRyeSA9IG1fZnJhbWUtPnBhZ2UoKS0+YmFja0Zv cndhcmRMaXN0KCktPml0ZW1BdEluZGV4KHN0ZXBzKTsKKyAgICBpZiAoIXNwZWNpZmllZEVudHJ5 KSB7CisgICAgICAgIGNhbmNlbCgpOworICAgICAgICByZXR1cm47CisgICAgfQogCisgICAgLy8g SWYgdGhlIHNwZWNpZmllZCBlbnRyeSBhbmQgdGhlIGN1cnJlbnQgZW50cnkgaGF2ZSB0aGUgc2Ft ZSBkb2N1bWVudCwgdGhpcyBpcyBlaXRoZXIgYSBzdGF0ZSBvYmplY3QgdHJhdmVyc2FsIG9yIGEg ZnJhZ21lbnQgCisgICAgLy8gdHJhdmVyc2FsIChvciBib3RoKSBhbmQgc2hvdWxkIGJlIHBlcmZv cm1lZCBzeW5jaHJvbm91c2x5LgorICAgIEhpc3RvcnlJdGVtKiBjdXJyZW50RW50cnkgPSBtX2Zy YW1lLT5sb2FkZXIoKS0+aGlzdG9yeSgpLT5jdXJyZW50SXRlbSgpOworICAgIGlmIChjdXJyZW50 RW50cnkgIT0gc3BlY2lmaWVkRW50cnkgJiYgc3BlY2lmaWVkRW50cnktPmRvY3VtZW50KCkgJiYg Y3VycmVudEVudHJ5LT5kb2N1bWVudCgpID09IHNwZWNpZmllZEVudHJ5LT5kb2N1bWVudCgpKSB7 CisgICAgICAgIG1fZnJhbWUtPmxvYWRlcigpLT5oaXN0b3J5KCktPmdvVG9JdGVtKHNwZWNpZmll ZEVudHJ5LCBGcmFtZUxvYWRUeXBlSW5kZXhlZEJhY2tGb3J3YXJkKTsKKyAgICAgICAgcmV0dXJu OworICAgIH0KKyAgICAKKyAgICAvLyBJbiBhbGwgb3RoZXIgY2FzZXMsIHNjaGVkdWxlIHRoZSBo aXN0b3J5IHRyYXZlcnNhbCB0byBvY2N1ciBhc3luY2hyb25vdXNseS4KICAgICBzY2hlZHVsZShu ZXcgU2NoZWR1bGVkUmVkaXJlY3Rpb24oc3RlcHMpKTsKIH0KIApJbmRleDogTGF5b3V0VGVzdHMv Q2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL0NoYW5nZUxvZwkocmV2aXNpb24g NTM1OTQpCisrKyBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHdvcmtpbmcgY29weSkKQEAgLTEsMyAr MSwxOCBAQAorMjAxMC0wMS0yMCAgQnJhZHkgRWlkc29uICA8YmVpZHNvbkBhcHBsZS5jb20+CisK KyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgaGlzdG9yeS5i YWNrKCkgZm9yIHNhbWUtZG9jdW1lbnQgaGlzdG9yeSB0cmF2ZXJzYWxzIGlzbid0IHN5bmNocm9u b3VzIGFzIHRoZSBzcGVjaWZpY2F0aW9uIHN0YXRlcy4KKyAgICAgICAgPHJkYXI6Ly9wcm9ibGVt Lzc1MzUwMTE+IGFuZCBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MzM1 MzgKKworICAgICAgICBUaGUgY2hhbmdlIGluIGxvYWRpbmcgYmVoYXZpb3IgaXMgd2VsbCBjb3Zl cmVkIHZpYSBtb2RpZmljYXRpb25zIHRvIHRoZXNlIHByZXZpb3VzIHRlc3RzOgorCisgICAgICAg ICogZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL2RvY3VtZW50LWRlc3Ryb3llZC1uYXZpZ2F0ZS1i YWNrLXdpdGgtZnJhZ21lbnQtc2Nyb2xsLmh0bWw6CisgICAgICAgICogZmFzdC9sb2FkZXIvc3Rh dGVvYmplY3RzL3B1c2hzdGF0ZS13aXRoLWZyYWdtZW50LXVybHMtYW5kLWhhc2hjaGFuZ2UtZXhw ZWN0ZWQudHh0OgorICAgICAgICAqIGZhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9wdXNoc3RhdGUt d2l0aC1mcmFnbWVudC11cmxzLWFuZC1oYXNoY2hhbmdlLmh0bWw6CisgICAgICAgICogZmFzdC9s b2FkZXIvc3RhdGVvYmplY3RzL3N0YXRlLWFwaS1vbi1kZXRhY2hlZC1mcmFtZS1jcmFzaC1leHBl Y3RlZC50eHQ6CisgICAgICAgICogZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL3N0YXRlLWFwaS1v bi1kZXRhY2hlZC1mcmFtZS1jcmFzaC5odG1sOgorCiAyMDEwLTAxLTIwICBEYW5pZWwgQmF0ZXMg IDxkYmF0ZXNAd2Via2l0Lm9yZz4KIAogICAgICAgICBVbnJldmlld2VkLiBBZGQgZmFpbGluZyB0 ZXN0IGZhc3QvY3NzL2J1dHRvbi1oZWlnaHQuaHRtbApJbmRleDogTGF5b3V0VGVzdHMvZmFzdC9s b2FkZXIvc3RhdGVvYmplY3RzL2RvY3VtZW50LWRlc3Ryb3llZC1uYXZpZ2F0ZS1iYWNrLXdpdGgt ZnJhZ21lbnQtc2Nyb2xsLmh0bWwKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTGF5b3V0VGVzdHMvZmFzdC9sb2Fk ZXIvc3RhdGVvYmplY3RzL2RvY3VtZW50LWRlc3Ryb3llZC1uYXZpZ2F0ZS1iYWNrLXdpdGgtZnJh Z21lbnQtc2Nyb2xsLmh0bWwJKHJldmlzaW9uIDUzNTkyKQorKysgTGF5b3V0VGVzdHMvZmFzdC9s b2FkZXIvc3RhdGVvYmplY3RzL2RvY3VtZW50LWRlc3Ryb3llZC1uYXZpZ2F0ZS1iYWNrLXdpdGgt ZnJhZ21lbnQtc2Nyb2xsLmh0bWwJKHdvcmtpbmcgY29weSkKQEAgLTI0LDcgKzI0LDcgQEAgZnVu Y3Rpb24gcnVuRmlyc3RTdGFnZU9mVGVzdCgpCiBmdW5jdGlvbiBydW5TZWNvbmRTdGFnZU9mVGVz dCgpCiB7CiAgICAgYWxlcnQoIkxhc3QgcGF0aCBjb21wb25lbnQgb2YgbG9jYXRpb24gaXMgIiAr IGxhc3RQYXRoQ29tcG9uZW50KCkpOwotICAgIGhpc3RvcnkuYmFjaygpOworICAgIHNldFRpbWVv dXQoImhpc3RvcnkuYmFjaygpOyIsIDApOwogfQogCiBmdW5jdGlvbiBydW5UaGlyZFN0YWdlT2ZU ZXN0KCkKQEAgLTQ4LDcgKzQ4LDcgQEAgZnVuY3Rpb24gc3RhdGVQb3BwZWQoKQogICAgIGFsZXJ0 KCJTdGF0ZSBwb3BwZWQgLSAiICsgZXZlbnQuc3RhdGUgKyAiICh0eXBlICIgKyB0eXBlb2YgZXZl bnQuc3RhdGUgKyAiKSIpOwogICAgIGlmIChldmVudC5zdGF0ZSA9PSAiRmlyc3RFbnRyeSIpIHsK ICAgICAgICAgaGlzdG9yeS5yZXBsYWNlU3RhdGUoIkZpcnN0RW50cnlXaWxsTGF0ZXJCZVJlYWN0 aXZhdGVkIiwgbnVsbCwgIiNGaXJzdEVudHJ5V2lsbExhdGVyQmVSZWFjdGl2YXRlZCIpOwotICAg ICAgICBoaXN0b3J5LmZvcndhcmQoKTsKKyAgICAgICAgc2V0VGltZW91dCgiaGlzdG9yeS5mb3J3 YXJkKCk7IiwgMCk7CiAgICAgfSBlbHNlIGlmIChldmVudC5zdGF0ZSA9PSAiU2Vjb25kRW50cnki KSB7CiAgICAgICAgIGhpc3RvcnkucmVwbGFjZVN0YXRlKCJTZWNvbmRFbnRyeVdpbGxMYXRlckJl UmVhY3RpdmF0ZWQiLCBudWxsLCAiI1NlY29uZEVudHJ5V2lsbExhdGVyQmVSZWFjdGl2YXRlZCIp OwogICAgICAgICB3aW5kb3cubG9jYXRpb24gPSAicmVzb3VyY2VzL25hdmlnYXRlLWJhY2suaHRt bCI7CkluZGV4OiBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvcHVzaHN0YXRl LXdpdGgtZnJhZ21lbnQtdXJscy1hbmQtaGFzaGNoYW5nZS1leHBlY3RlZC50eHQKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gTGF5b3V0VGVzdHMvZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL3B1c2hzdGF0ZS13aXRo LWZyYWdtZW50LXVybHMtYW5kLWhhc2hjaGFuZ2UtZXhwZWN0ZWQudHh0CShyZXZpc2lvbiA1MzU5 MikKKysrIExheW91dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9wdXNoc3RhdGUtd2l0 aC1mcmFnbWVudC11cmxzLWFuZC1oYXNoY2hhbmdlLWV4cGVjdGVkLnR4dAkod29ya2luZyBjb3B5 KQpAQCAtMiwzMyArMiwzMyBAQCBUaGlzIHRlc3QgcHVzaGVzIGEgc2VyaWVzIG9mIHN0YXRlIG9i amVjCiAKIFN0YXRlIHBvcHBlZCB3aXRoIGV2ZW50IG51bGwgKHR5cGUgb2JqZWN0KSBhbmQgbGFz dCBwYXRoIGNvbXBvbmVudCBzb21lLW90aGVyLmh0bWw/d2l0aHNvbWVvdGhlcnF1ZXJ5CiBTdGF0 ZSBwb3BwZWQgd2l0aCBldmVudCBudWxsICh0eXBlIG9iamVjdCkgYW5kIGxhc3QgcGF0aCBjb21w b25lbnQgc29tZS1vdGhlci5odG1sP3dpdGhzb21lb3RoZXJxdWVyeSMKLUhhc2ggY2hhbmdlIGZp cmVkCitIYXNoIGNoYW5nZSBmaXJlZCBhbmQgbGFzdCBwYXRoIGNvbXBvbmVudCBpcyBzb21lLW90 aGVyLmh0bWw/d2l0aHNvbWVvdGhlcnF1ZXJ5IwogU3RhdGUgcG9wcGVkIHdpdGggZXZlbnQgbnVs bCAodHlwZSBvYmplY3QpIGFuZCBsYXN0IHBhdGggY29tcG9uZW50IHNvbWUtb3RoZXIuaHRtbD93 aXRoc29tZW90aGVycXVlcnkKLUhhc2ggY2hhbmdlIGZpcmVkCitIYXNoIGNoYW5nZSBmaXJlZCBh bmQgbGFzdCBwYXRoIGNvbXBvbmVudCBpcyBzb21lLW90aGVyLmh0bWw/d2l0aHNvbWVvdGhlcnF1 ZXJ5CiBTdGF0ZSBwb3BwZWQgd2l0aCBldmVudCBudWxsICh0eXBlIG9iamVjdCkgYW5kIGxhc3Qg cGF0aCBjb21wb25lbnQgc29tZS1vdGhlci5odG1sP3dpdGhzb21lb3RoZXJxdWVyeSNzb21laGFz aAotSGFzaCBjaGFuZ2UgZmlyZWQKK0hhc2ggY2hhbmdlIGZpcmVkIGFuZCBsYXN0IHBhdGggY29t cG9uZW50IGlzIHNvbWUtb3RoZXIuaHRtbD93aXRoc29tZW90aGVycXVlcnkjc29tZWhhc2gKIFN0 YXRlIHBvcHBlZCB3aXRoIGV2ZW50IG51bGwgKHR5cGUgb2JqZWN0KSBhbmQgbGFzdCBwYXRoIGNv bXBvbmVudCBzb21lLW90aGVyLmh0bWw/d2l0aHNvbWVvdGhlcnF1ZXJ5I3NvbWVvdGhlcmhhc2gK LUhhc2ggY2hhbmdlIGZpcmVkCitIYXNoIGNoYW5nZSBmaXJlZCBhbmQgbGFzdCBwYXRoIGNvbXBv bmVudCBpcyBzb21lLW90aGVyLmh0bWw/d2l0aHNvbWVvdGhlcnF1ZXJ5I3NvbWVvdGhlcmhhc2gK IFN0YXRlIHBvcHBlZCB3aXRoIGV2ZW50IG51bGwgKHR5cGUgb2JqZWN0KSBhbmQgbGFzdCBwYXRo IGNvbXBvbmVudCBzb21lLW90aGVyLmh0bWw/d2l0aHF1ZXJ5I3NvbWVvdGhlcmhhc2gKIFN0YXRl IHBvcHBlZCB3aXRoIGV2ZW50IG51bGwgKHR5cGUgb2JqZWN0KSBhbmQgbGFzdCBwYXRoIGNvbXBv bmVudCBzb21lLW90aGVyLmh0bWw/d2l0aHF1ZXJ5IwotSGFzaCBjaGFuZ2UgZmlyZWQKK0hhc2gg Y2hhbmdlIGZpcmVkIGFuZCBsYXN0IHBhdGggY29tcG9uZW50IGlzIHNvbWUtb3RoZXIuaHRtbD93 aXRocXVlcnkjCiBTdGF0ZSBwb3BwZWQgd2l0aCBldmVudCBudWxsICh0eXBlIG9iamVjdCkgYW5k IGxhc3QgcGF0aCBjb21wb25lbnQgc29tZS1vdGhlci5odG1sP3dpdGhxdWVyeSNzb21laGFzaAot SGFzaCBjaGFuZ2UgZmlyZWQKK0hhc2ggY2hhbmdlIGZpcmVkIGFuZCBsYXN0IHBhdGggY29tcG9u ZW50IGlzIHNvbWUtb3RoZXIuaHRtbD93aXRocXVlcnkjc29tZWhhc2gKIFN0YXRlIHBvcHBlZCB3 aXRoIGV2ZW50IG51bGwgKHR5cGUgb2JqZWN0KSBhbmQgbGFzdCBwYXRoIGNvbXBvbmVudCBzb21l LW90aGVyLmh0bWw/d2l0aHF1ZXJ5Ci1IYXNoIGNoYW5nZSBmaXJlZAorSGFzaCBjaGFuZ2UgZmly ZWQgYW5kIGxhc3QgcGF0aCBjb21wb25lbnQgaXMgc29tZS1vdGhlci5odG1sP3dpdGhxdWVyeQog U3RhdGUgcG9wcGVkIHdpdGggZXZlbnQgbnVsbCAodHlwZSBvYmplY3QpIGFuZCBsYXN0IHBhdGgg Y29tcG9uZW50IHNvbWUtb3RoZXIuaHRtbD93aXRocXVlcnkjCi1IYXNoIGNoYW5nZSBmaXJlZAor SGFzaCBjaGFuZ2UgZmlyZWQgYW5kIGxhc3QgcGF0aCBjb21wb25lbnQgaXMgc29tZS1vdGhlci5o dG1sP3dpdGhxdWVyeSMKIFN0YXRlIHBvcHBlZCB3aXRoIGV2ZW50IG51bGwgKHR5cGUgb2JqZWN0 KSBhbmQgbGFzdCBwYXRoIGNvbXBvbmVudCBzb21lLW90aGVyLmh0bWw/d2l0aHF1ZXJ5Ci1IYXNo IGNoYW5nZSBmaXJlZAorSGFzaCBjaGFuZ2UgZmlyZWQgYW5kIGxhc3QgcGF0aCBjb21wb25lbnQg aXMgc29tZS1vdGhlci5odG1sP3dpdGhxdWVyeQogU3RhdGUgcG9wcGVkIHdpdGggZXZlbnQgbnVs bCAodHlwZSBvYmplY3QpIGFuZCBsYXN0IHBhdGggY29tcG9uZW50IHNvbWUtb3RoZXIuaHRtbAog U3RhdGUgcG9wcGVkIHdpdGggZXZlbnQgbnVsbCAodHlwZSBvYmplY3QpIGFuZCBsYXN0IHBhdGgg Y29tcG9uZW50IHB1c2hzdGF0ZS13aXRoLWZyYWdtZW50LXVybHMtYW5kLWhhc2hjaGFuZ2UuaHRt bCMKIFN0YXRlIHBvcHBlZCB3aXRoIGV2ZW50IG51bGwgKHR5cGUgb2JqZWN0KSBhbmQgbGFzdCBw YXRoIGNvbXBvbmVudCBwdXNoc3RhdGUtd2l0aC1mcmFnbWVudC11cmxzLWFuZC1oYXNoY2hhbmdl Lmh0bWwjCiBTdGF0ZSBwb3BwZWQgd2l0aCBldmVudCBudWxsICh0eXBlIG9iamVjdCkgYW5kIGxh c3QgcGF0aCBjb21wb25lbnQgcHVzaHN0YXRlLXdpdGgtZnJhZ21lbnQtdXJscy1hbmQtaGFzaGNo YW5nZS5odG1sI290aGVyaGFzaAotSGFzaCBjaGFuZ2UgZmlyZWQKK0hhc2ggY2hhbmdlIGZpcmVk IGFuZCBsYXN0IHBhdGggY29tcG9uZW50IGlzIHB1c2hzdGF0ZS13aXRoLWZyYWdtZW50LXVybHMt YW5kLWhhc2hjaGFuZ2UuaHRtbCNvdGhlcmhhc2gKIFN0YXRlIHBvcHBlZCB3aXRoIGV2ZW50IG51 bGwgKHR5cGUgb2JqZWN0KSBhbmQgbGFzdCBwYXRoIGNvbXBvbmVudCBwdXNoc3RhdGUtd2l0aC1m cmFnbWVudC11cmxzLWFuZC1oYXNoY2hhbmdlLmh0bWwjaGFzaAotSGFzaCBjaGFuZ2UgZmlyZWQK K0hhc2ggY2hhbmdlIGZpcmVkIGFuZCBsYXN0IHBhdGggY29tcG9uZW50IGlzIHB1c2hzdGF0ZS13 aXRoLWZyYWdtZW50LXVybHMtYW5kLWhhc2hjaGFuZ2UuaHRtbCNoYXNoCiBTdGF0ZSBwb3BwZWQg d2l0aCBldmVudCBudWxsICh0eXBlIG9iamVjdCkgYW5kIGxhc3QgcGF0aCBjb21wb25lbnQgcHVz aHN0YXRlLXdpdGgtZnJhZ21lbnQtdXJscy1hbmQtaGFzaGNoYW5nZS5odG1sIwotSGFzaCBjaGFu Z2UgZmlyZWQKK0hhc2ggY2hhbmdlIGZpcmVkIGFuZCBsYXN0IHBhdGggY29tcG9uZW50IGlzIHB1 c2hzdGF0ZS13aXRoLWZyYWdtZW50LXVybHMtYW5kLWhhc2hjaGFuZ2UuaHRtbCMKIFN0YXRlIHBv cHBlZCB3aXRoIGV2ZW50IG51bGwgKHR5cGUgb2JqZWN0KSBhbmQgbGFzdCBwYXRoIGNvbXBvbmVu dCBwdXNoc3RhdGUtd2l0aC1mcmFnbWVudC11cmxzLWFuZC1oYXNoY2hhbmdlLmh0bWwjCiBTdGF0 ZSBwb3BwZWQgd2l0aCBldmVudCBPcmlnaW5hbEVudHJ5ICh0eXBlIHN0cmluZykgYW5kIGxhc3Qg cGF0aCBjb21wb25lbnQgcHVzaHN0YXRlLXdpdGgtZnJhZ21lbnQtdXJscy1hbmQtaGFzaGNoYW5n ZS5odG1sCiAKSW5kZXg6IExheW91dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9wdXNo c3RhdGUtd2l0aC1mcmFnbWVudC11cmxzLWFuZC1oYXNoY2hhbmdlLmh0bWwKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gTGF5b3V0VGVzdHMvZmFzdC9sb2FkZXIvc3RhdGVvYmplY3RzL3B1c2hzdGF0ZS13aXRoLWZy YWdtZW50LXVybHMtYW5kLWhhc2hjaGFuZ2UuaHRtbAkocmV2aXNpb24gNTM1OTIpCisrKyBMYXlv dXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvcHVzaHN0YXRlLXdpdGgtZnJhZ21lbnQt dXJscy1hbmQtaGFzaGNoYW5nZS5odG1sCSh3b3JraW5nIGNvcHkpCkBAIC00OCwxNCArNDgsMTQg QEAgZnVuY3Rpb24gc3RhdGVQb3BwZWQoKQogewogICAgIGxvZygiU3RhdGUgcG9wcGVkIHdpdGgg ZXZlbnQgIiArIGV2ZW50LnN0YXRlICsgIiAodHlwZSAiICsgdHlwZW9mIGV2ZW50LnN0YXRlICsg IikgYW5kIGxhc3QgcGF0aCBjb21wb25lbnQgIiArIGxhc3RQYXRoQ29tcG9uZW50KCkpOwogICAg IGlmIChldmVudC5zdGF0ZSAhPSAiT3JpZ2luYWxFbnRyeSIpCi0gICAgICAgIGhpc3RvcnkuYmFj aygpOworICAgICAgICBzZXRUaW1lb3V0KCJoaXN0b3J5LmJhY2soKTsiLCAwKTsKICAgICBlbHNl IGlmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIpCiAgICAgICAgIGxheW91dFRlc3RDb250 cm9sbGVyLm5vdGlmeURvbmUoKTsKIH0KIAogZnVuY3Rpb24gaGFzaENoYW5nZWQoKQogewotICAg IGxvZygiSGFzaCBjaGFuZ2UgZmlyZWQiKTsKKyAgICBsb2coIkhhc2ggY2hhbmdlIGZpcmVkIGFu ZCBsYXN0IHBhdGggY29tcG9uZW50IGlzICIgKyBsYXN0UGF0aENvbXBvbmVudCgpKTsKIH0KIAog PC9zY3JpcHQ+CkluZGV4OiBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvc3Rh dGUtYXBpLW9uLWRldGFjaGVkLWZyYW1lLWNyYXNoLWV4cGVjdGVkLnR4dAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBMYXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvc3RhdGUtYXBpLW9uLWRldGFj aGVkLWZyYW1lLWNyYXNoLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gNTM1OTIpCisrKyBMYXlvdXRU ZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvc3RhdGUtYXBpLW9uLWRldGFjaGVkLWZyYW1l LWNyYXNoLWV4cGVjdGVkLnR4dAkod29ya2luZyBjb3B5KQpAQCAtMSArMSBAQAotSWYgdGhpcyB0 ZXN0IGRvZXNuJ3QgY3Jhc2gsIGl0IHBhc3NlZC4KKwpJbmRleDogTGF5b3V0VGVzdHMvZmFzdC9s b2FkZXIvc3RhdGVvYmplY3RzL3N0YXRlLWFwaS1vbi1kZXRhY2hlZC1mcmFtZS1jcmFzaC5odG1s Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2Zhc3QvbG9hZGVyL3N0YXRlb2JqZWN0cy9zdGF0 ZS1hcGktb24tZGV0YWNoZWQtZnJhbWUtY3Jhc2guaHRtbAkocmV2aXNpb24gNTM1OTIpCisrKyBM YXlvdXRUZXN0cy9mYXN0L2xvYWRlci9zdGF0ZW9iamVjdHMvc3RhdGUtYXBpLW9uLWRldGFjaGVk LWZyYW1lLWNyYXNoLmh0bWwJKHdvcmtpbmcgY29weSkKQEAgLTgsMjEgKzgsMTIgQEAgZnVuY3Rp b24gcnVuVGVzdCgpCiB7CiAgICAgdmFyIGlmciA9IGZyYW1lc1swXTsKICAgICBkb2N1bWVudC5i b2R5LnJlbW92ZUNoaWxkKGRvY3VtZW50LmdldEVsZW1lbnRzQnlUYWdOYW1lKCJpZnJhbWUiKVsw XSkKLSAgICB0cnkgewotICAgICAgICBpZnIuaGlzdG9yeS5yZXBsYWNlU3RhdGUoImZvbyIsICJi YXIiKTsKLSAgICB9IGNhdGNoKGUpIHsKLSAgICAgICAgYWxlcnQoZSk7Ci0gICAgfQotICAgIHRy eSB7Ci0gICAgICAgIGlmci5oaXN0b3J5LnB1c2hTdGF0ZSgiZnUiLCAiYmFycmVkIik7Ci0gICAg fSBjYXRjaChlKSB7Ci0gICAgICAgIGFsZXJ0KGUpOwotICAgIH0gICAKKyAgICBpZnIuaGlzdG9y eS5yZXBsYWNlU3RhdGUoImZvbyIsICJiYXIiKTsKKyAgICBpZnIuaGlzdG9yeS5wdXNoU3RhdGUo ImZ1IiwgImJhcnJlZCIpOwogfQogCiA8L3NjcmlwdD4KIDxib2R5IG9ubG9hZD0icnVuVGVzdCgp OyI+Ci1JZiB0aGlzIHRlc3QgZG9lc24ndCBjcmFzaCwgaXQgcGFzc2VkLgogPGlmcmFtZSBzcmM9 ImFib3V0OmJsYW5rIj4KIDwvaWZyYW1lPgogPC9ib2R5Pgo=