23226 2013-09-12 18:51:22 +0000 Need for Virtual MutationRecords 2014-02-13 10:20:05 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED WONTFIX P2 normal --- 1 bradley.meck annevk bugs bzbarsky mike rafaelw www-dom public-webapps-bugzilla oldest_to_newest 93301 0 1395 bradley.meck 2013-09-12 18:51:22 +0000 Created attachment 1395 IRC Discussion About Topic I am still a bit new to writing to standards groups so please forgive any faux pas I make in this report. Right now various state changes are not observable using MutationObservers, in particular: <input>, <textarea>, and <select> states/values. These are visible if we listen to "change" events, but do not provide a clear abstraction for: * the name of the host object property that represents the state * the old value * the new value After some time and discussion on the mailing list, it was shown that we cannot fix the getter/setter specification for these various host properties. So, as a counter proposal an opt-in way to notify observers of host object state changes seems the best way to bring back what I consider a base use case of MutationObservers. After more discussion some points came up as important: * A full event dispatch appears to be overkill because propagation, prevention, bubbling, etc. are not necessary when compiling a list of MutationRecords for MutationObservers. * There should be a clear distinction of host object properties/getters/setters and DOM Node attributes. There appears to be some tooling for web inspection of various browsers allowing enumeration of MutationObservers viewing a Node (when in privileged code), but this sounds a little extreme to me especially considering the lack of ability for people to see what EventListeners are on a Node. Therefore, I propose something like smaug mentioned in the #whatwg IRC: * node.notifyMutationObservers({property: "value"}); Which would create something like: {property:"value", target: node, type: "virtual"} If it is determined that old/new values and or arbitrary data are relevant to this, I would think that to be amenable. This would create a mutation record with a specified type such as "virtual" that would be propagated to any MutationObservers watching a Node. By doing this, we add an addendum to elements that use "change" events so that they fire these virtual records without affecting older code. This also may become relevant with WebComponents needing to announce state transitions, that are not directly observable in the DOM. As always I am completely open to alternatives that would cover these use cases. Cheers, Bradley Related History: http://w3-org.9356.n7.nabble.com/MutationObserver-does-not-observe-state-changes-tt260972.html#none https://code.google.com/p/chromium/issues/detail?id=260881&can=1&q=reporter%3Abradley.meck&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified 93302 1 bugs 2013-09-12 19:00:38 +0000 > Therefore, I propose something like smaug mentioned in the #whatwg IRC: > > * node.notifyMutationObservers({property: "value"}); I assume you don't mean here that there is automatic notification when value property has changed, since observing properties would be really hard and slow. > > Which would create something like: > > {property:"value", target: node, type: "virtual"} So MutationRecord would have to be extended to have also attribute 'property'? 93304 2 bradley.meck 2013-09-12 19:10:57 +0000 (In reply to Olli Pettay from comment #1) > > Therefore, I propose something like smaug mentioned in the #whatwg IRC: > > > > * node.notifyMutationObservers({property: "value"}); > I assume you don't mean here that there is automatic > notification when value property has changed, since observing properties > would be really hard and slow. > Correct, the process would be manual, not automatic. This is opt-in and default notification would only occur for things that currently have state that is not observable with only the DOM attributes, such as <input>, <select>, and <textarea>. There was talk of using something like Object.observe for automatic notification, but as you said, this would most likely be slow. And may cause confusion when storing symbol keyed values or private data on Nodes. > > > > > Which would create something like: > > > > {property:"value", target: node, type: "virtual"} > > So MutationRecord would have to be extended to have also attribute > 'property'? I think that would be the best course of action. We could overload attributeName, but I would be hesitant of having the same name for very different concepts (name of HTML attribute vs scripting property name). 93305 3 rafaelw 2013-09-12 19:26:38 +0000 Object.observe seems like the right solution for this problem. http://wiki.ecmascript.org/doku.php?id=harmony:observe It already has exactly this mechanism, e.g. Object.getNotifier(node).notify({ type: "myCustomChangeRecordType", data: ..., otherData: ... }); This mechanism already has built into it a notion of observers 'accepting' a specific set of change record types, so that observing code isn't at risk of breaking if observed nodes suddenly update to emit new change record types. 93307 4 bradley.meck 2013-09-12 19:59:36 +0000 (In reply to Rafael Weinstein from comment #3) > Object.observe seems like the right solution for this problem. > > http://wiki.ecmascript.org/doku.php?id=harmony:observe > > It already has exactly this mechanism, e.g. > Object.getNotifier(node).notify({ type: "myCustomChangeRecordType", data: > ..., otherData: ... }); > > This mechanism already has built into it a notion of observers 'accepting' a > specific set of change record types, so that observing code isn't at risk of > breaking if observed nodes suddenly update to emit new change record types. Object.observe poses some problems we should look at with relation to notification creation / subtree observation: * It would need a way to propagate up the DOM subtree * we iterate up node.parentNode if we add observers / notifiers to all Nodes and chaining appropriately * The properties that make up the base case for this are getter/setters which are not covered using Object.observe / getNotifier [1][2][3] * We can work around this by adding node.notify(...) to the getter / setter algorithms * These notifications would be propagated to MutationObservers The key problem for me with using *only* Object.observe is the disconnect of purposes. MutationObservers is a means of monitoring the state of a DOM subtree. Object.observe does not have the concept of a tree structure. For subtree observation present in MutationObservers it would be very odd to deal with during Object.observe because other notification callbacks could change the DOM tree while notifications are being passed down the tree to an observer of a DOM subtree. We could cache the list of parentNodes on first notification, but only if we can reliably cause the notification to create this cache before any DOM mutation occurs again. [1] http://www.w3.org/TR/WebIDL/#es-attributes [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element [3] https://code.google.com/p/chromium/issues/detail?id=260881#c6 93317 5 rafaelw 2013-09-12 20:54:33 +0000 It's not clear to me why observing a subtree is necessary. Can you please explain this? AFACT, The original complaint is that state changes of input elements (input.value, select.selectedIndex, etc...) are not directly observable (other than by registering event listeners). The original thread you created seemed to resolve in fairly good agreement that those elements should emit changeRecords via notifier.notify() when their value changes. Why is that not sufficient? 93325 6 bradley.meck 2013-09-13 01:54:42 +0000 (In reply to Rafael Weinstein from comment #5) > It's not clear to me why observing a subtree is necessary. Can you please > explain this? > The original use case problems was that MutationObservers could not view host object property changes. This came up during a workflow of watching a <form>'s subtree. > > AFACT, The original complaint is that state changes of input elements > (input.value, select.selectedIndex, etc...) are not directly observable > (other than by registering event listeners). > This is true, but came up when using MutationObservers, if I wanted to merely listen for these change events on those specific properties I can use a "change" event handler. > > The original thread you created seemed to resolve in fairly good agreement > that those elements should emit changeRecords via notifier.notify() when > their value changes. > > Why is that not sufficient? Resolve might be a poor word choice here. It was agreed that Object.observe was a possible solution. However, this is not going to fix the start of the discussion in which MutationObservers did not watch for state mutation that was clearly observable. If we are merely going for sufficient, we could add "change" event handlers on any DOM insertion/removal of any element that *may* have "change" events and propagate them to a WeakMap that contains any observers listening to changes, and iterate up the element that dispatched the "change" event's parent Node chain and checking against the WeakMap. Then we can detect the type of Node and what should have changed during a "change" even. Then if we setImmediate and it looks like the change was not prevented; we can do our work assuming we know the type of element and it is not something custom. There is no need to bring notifier.notify() into this if we are ok with the above; and it would have a similar workflow using notifier.notify() except for that last 2 steps since we can tell what property changed and it is not preventable. This workflow may be simplified with delegating the event listener to the top of the document, but may cause problems if the observed Node changes documents that it is in, because then the next document would need to have a "change" delegating handler on it as well. This workflow sounds terrible. I abandoned the original thread due to talking an many people asking "why" without listening to the original case. This is my attempt to reassess the problems I was having, and have seen no progress on. I have spent some time, not only thinking about the problem but also about the question "why". Instead of "why" as the question of workflow, "what" may be pertinent to assess first. --- "what" is the use case --- My use case comes from MutationObservers being unable to see state changes that are clearly available from screen readers, scripting languages, and visible renders of a page. The cause of this is host objects *for Nodes* containing internal state. This is likely to become more pressing as custom elements/document.register begin to standardize more. --- "why" should we care --- First of all, this can be done in the way mentioned above. Right now Polymer, Angular, etc. are implementing it in somewhat similar manners to above. As we mentioned in the "what" section though, this is going to get increasingly complex if custom elements start to have "change" events. Now I like words, and although it may not be the best place to start; a "MutationObserver" not being able to observe mutation, even if that mutation notification must be opt-in, seems a little suspect. An immediate use case, and how I stumbled across this, is when you want to tell when form data has changed. This gets more convoluted if we have essentially nested forms with the "form" attribute and no true <form> parent Node. As we have discussed above, it is possible to just have "change" event handlers on Nodes / Documents. But having "change" and "mutation" of a Node be entirely different concepts, that would make me argue for a nomenclature clarification rather than keeping the word mutation. Lets delve a little deeper though. These data binding layers are emulating behavior similar to MutationObservers using events. One of the problems with events is that they are cancelable, and can make other events queue for dispatch during their handler. From my previous reading that is part of the problem of DOMMutationEvent. Enter Object.observe / notify. These do not suffer the recursive dispatch problems of an event handler. However, they also do not come with a propagation up the parent Node chain like events. So doing behavior like watching a <form> relies on similar tactics of manually firing .notify() up the parent Node chain. MutationObservers already fire up the parent Node chain *and* do not suffer the problems of recursive dispatch and cancellation. Any future custom element may desire to pass down notifications that match both of these criteria (any input widget for example that tries to follow what <input>, <select>, and <textarea> did with .defaultValue for example). --- "who" has experience with this problem --- Data binding library authors. I will try to see if some want to loop into this discussion. People just learning about MutationObservers; this is quite a shock to most web developers I have told about MutationObservers. 93535 7 bradley.meck 2013-09-18 20:40:40 +0000 I have attempted to contact multiple developer communities to comment on this, with only Mozilla providing a response so far with concerns about DOM tree representation vs host state. I have opened issues on several projects seeking developer comments/concerns on this as well. Based upon personal investigation this is what I have learned so far: # Dugg through some Angular code: All the directives for state changes on native controls gather the value/checked/selectedIndex/selectedIndices in the change event to propagate changes to their view. They then propagate these values to JS only listeners (not on the dom) in order to state the nature of mutation in a uniform way. For <input type=text> - https://github.com/angular/angular.js/blob/master/src/ng/directive/select.js#L337 For <input type=radio> - https://github.com/angular/angular.js/blob/master/src/ng/directive/input.js#L630 For <input type=checkbox> - https://github.com/angular/angular.js/blob/master/src/ng/directive/input.js#L652 For <select> - https://github.com/angular/angular.js/blob/master/src/ng/directive/select.js#L263 For <select multiple> - https://github.com/angular/angular.js/blob/master/src/ng/directive/select.js#L294 Event Propagation - https://github.com/angular/angular.js/blob/master/src/ng/directive/input.js#L1075 There is not current use of MutationObservers. # Dugg through some Polymer code: This does "change" event propagation directly onto objects rather than through listeners by use of node.bind (https://github.com/Polymer/NodeBind/blob/master/src/NodeBind.js). Custom elements must implement their own "bind" function and defer to the parent as necessary. It is unclear on what to do when custom elements inherit from custom elements unless you hard code the parent "bind" function. After changes Object observers in JS propagate the state as needed. This allows models to be bound to Nodes directly does not need subtree observation for models that are split across DOM subtrees; however, this approach leads to more observers and reminds me of why people us jQuery.delegate rather than attaching event listeners to every Node. Event binding - https://github.com/Polymer/NodeBind/blob/master/src/NodeBind.js Custom Element binding - http://www.polymer-project.org/platform/node_bind.html#custom-element-bindings Object observation - https://github.com/Polymer/observe-js All of these are independent of the use of MutationObservers. # Dugg through some Knockout code: All data binding for native controls go through an expression engine, with two way data bindings such as those from native forms requiring a bit more effort to figure out what changed. Had a bit of trouble reading through the actual data flow on this one. Data binding propagation - https://github.com/knockout/knockout/blob/master/src/binding/defaultBindings/checked.js - https://github.com/knockout/knockout/blob/master/src/binding/defaultBindings/selectedOptions.js - https://github.com/knockout/knockout/blob/master/src/binding/defaultBindings/value.js Interesting comments - https://github.com/knockout/knockout/blob/b173d028cc044c48ef8bcc570dfa2e414d73c41f/src/binding/expressionRewriting.js#L103 - https://github.com/knockout/knockout/blob/b173d028cc044c48ef8bcc570dfa2e414d73c41f/src/binding/expressionRewriting.js#L188 # Summary I did not find any reference to needing to make attribute based state special snowflake code such as the "open" attribute on <details> (http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element), although this is not fully supported in these libraries. These frameworks are not using attempts to unify MutationObservers with "change" events, but each are creating specific code for monitoring non-DOM state changes on Nodes. Angular provides custom directives to handle changes on native controls. Polymer is explicitly creating a means to propagate changes with the DOM with "bind" but I do not have the experience to comment on how the two-way binding works in practice. Knockout uses expressionRewriting and explicitly has to declare values as "two way", several comments suggest these as special cased situations. # Conclusion A DOM Node based approach using MutationObservers is still lacking data from developers of these libraries. However, there is a need for unification of what state changes occur on Nodes. Whether this should be on the DOM Tree, or DOM host objects is still undetermined. The unification should most likely include custom elements in the future given the Shadow DOM and Custom Elements specifications. Polymer has an existing idea of this with "bind", but would certainly need deeper investigation. "bind" can suffer from a recursive dispatch style situation currently, but this needs further investigation as well. 100487 8 annevk 2014-02-13 10:20:05 +0000 Bradley, I think the idea is that the unification will come with Object.observe() for those type of changes. Given that this is mostly brainstorming I'm going to close this bug. I'd prefer brainstorming to happen on whatwg@whatwg.org, es-discuss@mozilla.org, or public-webapps@w3.org. 1395 2013-09-12 18:51:22 +0000 2013-09-12 18:51:22 +0000 IRC Discussion About Topic irc-whatwg-12-8-2013.log application/octet-stream 6193 bradley.meck WzExOjQ5YW1dIGJyYWRsZXltZWNrOiBvaywgc28sIHdobyBkbyBJIHRhbGsgdG8gYWJvdXQgaG9z dCBvYmplY3RzIGhhdmluZyBnZXR0ZXJzL3NldHRlcnMvcHJvcGVydGllcyBhbmQgRE9NIGF0dHJp YnV0ZXMgbm90IG1hdGNoaW5nIHVwIGZvciB2YXJpb3VzIGZ1biBzdHVmZiBsaWtlIE11dGF0aW9u T2JzZXJ2ZXJzIGFuZCB0YWJJbmRleC4gc3BlbnQgc29tZSB0aW1lIGEgY291cGxlIG1vbnRocyBi YWNrIHdyaXRpbmcgdG8gdGhlIG1haWxpbmcgbGlzdCBhbmQgYmFzaWNhbGx5IGdvdCBhYmFjayBh ICAidGhhdHMgdGhlIHdheSBpdCB3b3JrcyIgc28sIG9udG8gcm91bmQgMgpbMTE6NTBhbV0gbWFy Y29zYyBsZWZ0IHRoZSBjaGF0IHJvb20uIChSZW1vdGUgaG9zdCBjbG9zZWQgdGhlIGNvbm5lY3Rp b24pClsxMTo1MGFtXSBzbWF1Z19fX186IGJyYWRsZXltZWNrOiB5b3UgbWVhbiBzdHVmZiBsaWtl IGlucHV0ZWxlbWVudC52YWx1ZSB2cy4gPGlucHV0IHZhbHVlPSIiPiA/ClsxMTo1MWFtXSBicmFk bGV5bWVjazogdGhlIGNvbnRyb2xzIG5vdCBtYXRjaGluZyB1cCB3aXRoIGNoYW5nZSBldmVudHMg aXMgYSBiaWcgb25lLCB5ZXMKWzExOjUxYW1dIGpyZWFkaW5nIGxlZnQgdGhlIGNoYXQgcm9vbS4g KFBpbmcgdGltZW91dDogMjQ1IHNlY29uZHMpClsxMTo1MmFtXSBqcmVhZGluZyBqb2luZWQgdGhl IGNoYXQgcm9vbS4KWzExOjUyYW1dIHNtYXVnX19fXzogd2VsbCwgLnZhbHVlIGhhbmRsaW5nIGNh bid0IGJlIGNoYW5nZWQsIGFuZCBNdXRhdGlvbk9ic2VydmVyIGlzIGFib3V0IGNoYW5nZXMgdG8g RE9NLi4uc28gSSdtIG5vdCBzdXJlIHRoZXJlIGlzIG11Y2ggdG8gZGlzY3VzcyB0aGVyZSwgdW5s ZXNzIHlvdSBoYXZlIHNvbWUgZ3JlYXQgcHJvcG9zYWwgClsxMTo1M2FtXSBEb21lbmljXzogYnJh ZGxleW1lY2s6IHRoZSBwcm9ibGVtIGlzICJkb24ndCBicmVhayB0aGUgd2ViIjsgd2UgY2FuJ3Qg Y2hhbmdlIHRoZSB2YWx1ZSBhdHRyaWJ1dGUgdG8gc3VkZGVubHkgbm90IGJlIHJldGFyZGVkLgpb MTE6NTNhbV0gc2NvciBsZWZ0IHRoZSBjaGF0IHJvb20uIChRdWl0OiBzY29yKQpbMTE6NTNhbV0g YWRhY3RpbyBsZWZ0IHRoZSBjaGF0IHJvb20uClsxMTo1M2FtXSBEb21lbmljXzogYnJhZGxleW1l Y2s6IGJ1dCBtb3N0IG5ldyBhdHRyaWJ1dGVzIHNlZW0gdG8gd29yayBmaW5lLCBlLmcuIDxkZXRh aWxzPiBvcGVuIGF0dHJpYnV0ZSBhbmQgLm9wZW4gcHJvcGVydHkgc3RheSBpbiBzeW5jLgpbMTE6 NTRhbV0gRG9tZW5pY186IHRoaXMga2luZCBvZiBzdWNrcyB0aG91Z2ggc2luY2UgeW91IGNhbiB1 c2UgTXV0YXRpb25PYnNlcnZlciBvbiA8ZGV0YWlscz4gYnV0IG5vdCBvbiA8aW5wdXQ+IApbMTE6 NTVhbV0gdG9iaWVfIGxlZnQgdGhlIGNoYXQgcm9vbS4gKFBpbmcgdGltZW91dDogMjQ4IHNlY29u ZHMpClsxMTo1OGFtXSBicmlvbiBqb2luZWQgdGhlIGNoYXQgcm9vbS4KWzExOjU5YW1dIGJyYWRs ZXltZWNrOiB3ZWxsIEkgZG9uJ3Qgd2FudCB0byBjaGFuZ2UgaXQgZnJvbSBhIGdldHRlciwgYnV0 IHNldHRpbmcgZG9lcyBhbHJlYWR5IHRpZSBpbnRvIGEgY2hhbmdlIGV2ZW50LCBzbyBJIGFtIGxv b2tpbmcgbW9yZSB0b3dhcmRzIGhhdmluZyBhIHdheSBmb3IgZXZlbnRzIGhvb2sgaW50byBtdXRh dGlvbiBvYnNlcnZlcnMKWzEyOjAwcG1dIG15YWt1cmEgam9pbmVkIHRoZSBjaGF0IHJvb20uClsx MjowMHBtXSBicmFkbGV5bWVjazogY2F1c2UgdGhlIEpTIHNpZGUgbm90aWZ5aW5nIHRoZSBET00g dHJlZSB0aGF0IHNvbWV0aGluZyBpbXBvcnRhbnQgaGFzIGhhcHBlbmVkIHNlZW1zIGFuIG9rIHVz ZSBjYXNlClsxMjowMHBtXSBkcm9sbHdpdCBqb2luZWQgdGhlIGNoYXQgcm9vbS4KWzEyOjAxcG1d IERvbWVuaWNfOiBpIGFtIG5vdCBzdXJlIGkgZ2V0IGl0Li4uIHlvdSdyZSB0YWxraW5nIGFib3V0 IGZpcmluZyBzeW50aGV0aWMgZXZlbnRzIG9uIERPTSBlbGVtZW50cz8KWzEyOjAxcG1dIGpvcmdl cGVkcmV0IGpvaW5lZCB0aGUgY2hhdCByb29tLgpbMTI6MDJwbV0gdGFudGVrIGpvaW5lZCB0aGUg Y2hhdCByb29tLgpbMTI6MDJwbV0gbWl0ZW1pdHJlc2tpIGxlZnQgdGhlIGNoYXQgcm9vbS4gKFJl YWQgZXJyb3I6IENvbm5lY3Rpb24gcmVzZXQgYnkgcGVlcikKWzEyOjAycG1dIG5ld3Ryb24gbGVm dCB0aGUgY2hhdCByb29tLiAoUGluZyB0aW1lb3V0OiAyNzYgc2Vjb25kcykKWzEyOjAzcG1dIG5p bWJ1IGxlZnQgdGhlIGNoYXQgcm9vbS4gKFF1aXQ6IExlYXZpbmcuKQpbMTI6MDNwbV0gYnJhZGxl eW1lY2s6IERvbWVuaWNfOiBpIGd1ZXNzIHlvdSBjb3VsZCBzYXkgaXQgdGhhdCB3YXksIG5vdGlm aWNhdGlvbiBmb3IgTXV0YXRpb25PYnNlcnZlcnMgb25seSwgbm90IHF1aXRlIGZ1bGwgZXZlbnRz ClsxMjowNHBtXSBEb21lbmljXzogb2ggaSB0aGluayBpIHNlZSwgc28sIGFydGlmaWNpYWxseSB0 cmlnZ2VyIGEgbXV0YXRpb24gb2JzZXJ2ZXIgY2FsbGJhY2s/ClsxMjowNHBtXSBicmFkbGV5bWVj azogeWVzClsxMjowNHBtXSBzbWF1Z19fX186IHdlbGwsIGZvciBub3cgeW91IGNvdWxkIGp1c3Qg Y2FsbCB0aGUgY2FsbGJhY2sgbWFudWFsbHkKWzEyOjA0cG1dIHNtYXVnX19fXzogYnV0IHdlIGNv dWxkIGFkZCBhIGdldHRlciBmb3IgdGhlIGNhbGxiYWNrClsxMjowNHBtXSBicmFkbGV5bWVjazog YnV0IGRldGVjdGluZyB3aGljaCBtdXRhdGlvbiBvYnNlcnZlcnMgYXJlIG9ic2VydmluZyBhIG5v ZGU/ClsxMjowNXBtXSBzbWF1Z19fX186IGJyYWRsZXltZWNrOiB5b3Ugd2FudCBzb21ldGhpbmcg bGlrZSBodHRwczovL2J1Z3ppbGxhLm1vemlsbGEub3JnL3Nob3dfYnVnLmNnaT9pZD05MTI4NzQg PwpbMTI6MDZwbV0gc21hdWdfX19fOiAoaW4gR2Vja28gdGhhdCBpcyBhdmFpbGFibGUgZm9yIGNo cm9tZSBjb2RlIG9ubHksIG5vdCBmb3Igd2ViIHBhZ2VzKQpbMTI6MDdwbV0gc21hdWdfX19fOiAo dGhlIEFQSSBpbiBidWcgOTEyODc0IGlzbid0IHN1cGVyIHByZXR0eSBidXQgZ2l2ZXMgd2hhdCBk ZXZ0b29scyBuZWVkZWQpClsxMjowOHBtXSBicmFkbGV5bWVjazogeW91IGNvdWxkIHBlcmZvcm0g dGhpcyB1c2luZyBNdXRhdGlvbk9ic2VydmVyIGVudW1lcmF0aW9uLCBidXQgSSBhbSBoZXNpdGFu dCBhYm91dCBleHBvc2luZyB3aGF0IG11dGF0aW9uIG9ic2VydmVycyBhcmUgbG9va2luZyBhdCBh IG5vZGUsIGp1c3Qgc2VuZGluZyBhIG5ldyBNdXRhdGlvblJlY29yZCB0byBhbnkgb2JzZXJ2ZXIg bGlzdGVuaW5nIHRvIGEgbm9kZSB3b3VsZCBzZWVtIGxlc3Mgc2NvcGUgY3JlZXAKWzEyOjA4cG1d IHNtYXVnX19fXzogYnJhZGxleW1lY2s6IHRoZSBhZGRpdGlvbnMgdG8gTXV0YXRpb25PYnNlcnZl ciBsZXQncyBvbmUgdG8gZ2V0IHRoZSBjYWxsYmFjawpbMTI6MDlwbV0gbmltYnUgam9pbmVkIHRo ZSBjaGF0IHJvb20uClsxMjowOXBtXSBzbWF1Z19fX186IHlvdSBjYW4gc2tpcCB0aGUgY2hhbmdl IHRvIE5vZGUgClsxMjowOXBtXSBvZGluaG8gbGVmdCB0aGUgY2hhdCByb29tLiAoUGluZyB0aW1l b3V0OiAyNjQgc2Vjb25kcykKWzEyOjA5cG1dIGJyYWRsZXltZWNrOiBzb21ldGhpbmcgYWtpbiB0 byBFdmVudFRhcmdldC5kaXNwYXRjaEV2ZW50KFZpcnR1YWxNdXRhdGlvbkV2ZW50KSB3YXMgd2hh dCBJIHdhcyB0aGlua2luZwpbMTI6MTBwbV0gc21hdWdfX19fOiBvaCwgeW91IHdhbnQgdmlydHVh bCBNdXRhdGlvblJlY29yZHMKWzEyOjEwcG1dIGJyYWRsZXltZWNrOiBjYXVzZSB0ZWxsaW5nIHBl b3BsZSB0byBpdGVyYXRlIHdoZW4gYSBzY3JpcHRpbmcgcHJvcGVydHkgaXMgdGhlIGF1dGhvcml0 eSBmb3IgbXV0YXRpb24gbWlnaHQgYmUgdWdseQpbMTI6MTBwbV0gc2F5MmpvZSBqb2luZWQgdGhl IGNoYXQgcm9vbS4KWzEyOjEwcG1dIHNheTJqb2UgbGVmdCB0aGUgY2hhdCByb29tLgpbMTI6MTJw bV0gYnJhZGxleW1lY2s6IGl0IGRvZXMgbm90IG5lZWQgdG8gaGF2ZSBidWJibGUgLyBwcm9wYWdh dGlvbiAvIGV0Yywgc28gSSBhbSB1bnN1cmUgaXQgc2hvdWxkIGJlIGFuIGV2ZW50IGV2ZW4KWzEy OjEycG1dIHNtYXVnX19fXzogYnJhZGxleW1lY2s6IHNvbWV0aGluZyBsaWtlIHNvbWVub2RlLm5v dGlmeU11dGF0aW9uT2JzZXJ2ZXJzKG5ldyBNdXRhdGlvblJlY29yZCh7dHlwZTogImF0dHJpYnV0 ZXMiLCB0YXJnZXQ6IHNvbWVub2RlLCBhdHRyaWJ1dGVOYW1lOiAidmFsdWUifSkpClsxMjoxMnBt XSBicmFkbGV5bWVjazogeWVzClsxMjoxMnBtXSBuaW1idSBsZWZ0IHRoZSBjaGF0IHJvb20uIChD bGllbnQgUXVpdCkKWzEyOjEycG1dIHNtYXVnX19fXzogb3IsIHBlcmhhcHMgbm8gbmVlZCBmb3Ig TXV0YXRpb25SZWNvcmQgY3RvciwgZGljdGlvbmFyeSB3b3VsZCBiZSBlbm91Z2gKWzEyOjEzcG1d IGJyYWRsZXltZWNrOiBidXQgc2luY2UgaXQgaXMgdmlydHVhbCBJIHdvdWxkIGNvbnN0cmFpbiB0 eXBlLCB0aGlzIHNob3VsZCBvbmx5IGJlIHRhbGtpbmcgYWJvdXQgdGhlIGhvc3Qgb2JqZWN0IG5v dCB0aGUgRE9NIHNpZGUKWzEyOjEzcG1dIGJyYWRsZXltZWNrOiB0aGVuIHdlIGRvbid0IGhhdmUg dG8gY29uZnVzZSBhdHRyaWJ1dGVzIG9uIGhvc3QgdnMgYXR0cmlidXRlcyBvbiBkb20gaXRzZWxm ClsxMjoxNXBtXSBicmFkbGV5bWVjazogYW5kIHdlIG9ubHkgcmVhbGx5IG5lZWQgdGhpcyBzaW5j ZSBoaXN0b3J5IGFib3V0IGNoYW5nZSBldmVudHMgYW5kIHZhbHVlIGF0dHJpYnV0ZXMgc2lnaApb MTI6MTZwbV0gRG9tZW5pY186IGJyYWRsZXltZWNrOiByaWdodCwgc291bmRzIGxpa2UgeW91ciB1 c2UgY2FzZSBpcyBmaXJpbmcgYXJ0aWZpY2lhbCBjaGFuZ2VzIGZvciBgYXR0cmlidXRlTmFtZTog InZhbHVlImAgZnJvbSB0aGUgYCJpbnB1dCJgIGV2ZW50LCBzbyB0aGF0IHZhbHVlIGJlaGF2ZXMg bGlrZSBldmVyeXRoaW5nIGVsc2UuIG9wdC1pbiBmaXhpbmcgb2YgYHZhbHVlYCB3aXRoIHJlc3Bl Y3QgdG8gTXV0YXRpb25PYnNlcnZlci4KWzEyOjE3cG1dIGJyYWRsZXltZWNrOiB0aGF0cyB0aGUg YmFzaWMgaWRlYQpbMTI6MTlwbV0gRG9tZW5pY186IHNlZW1zIGdyZWF0LCBub3cgd2UganVzdCBu ZWVkIHRvIGdldCB0aGUgYXR0ZW50aW9uIG9mIHdob2V2ZXIncyBpbiBjaGFyZ2Ugb2YgbXV0YXRp b25vYnNlcnZlcnMuIEkgdGhpbmsgdGhleSdyZSBpbiBET00gbm93LCBzbyBtYXliZSBhbm5ldms/ ClsxMjoxOXBtXSBEb21lbmljXzogKGd0ZywgcmVqZWN0anMgYWZ0ZXJwYXJ0eS4pClsxMjoyMXBt XSB6a2lzIGpvaW5lZCB0aGUgY2hhdCByb29tLgpbMTI6MjRwbV0gYnJpb24gbGVmdCB0aGUgY2hh dCByb29tLiAoUGluZyB0aW1lb3V0OiAyNTYgc2Vjb25kcykKWzEyOjI1cG1dIGJyaW9uIGpvaW5l ZCB0aGUgY2hhdCByb29tLgpbMTI6MjlwbV0gU3BlZGF4IGpvaW5lZCB0aGUgY2hhdCByb29tLgpb MTI6MzNwbV0gY2FiYW5pZXIgam9pbmVkIHRoZSBjaGF0IHJvb20uClsxMjozM3BtXSBzY29yIGpv aW5lZCB0aGUgY2hhdCByb29tLgpbMTI6MzNwbV0gU3BlZGF4IGxlZnQgdGhlIGNoYXQgcm9vbS4g KFBpbmcgdGltZW91dDogMjY0IHNlY29uZHMpClsxMjozOHBtXSBhbm5ldms6IERvbWVuaWNfOiB0 aGV5J3ZlIGFsd2F5cyBiZWVuIGluIERPTSwgSSB0aG91Z2h0IHdlIHdlcmUgZ29pbmcgdG8gd2Fp dCBmb3IgT2JqZWN0Lm9ic2VydmUoKT8KWzEyOjM5cG1dIGJyYWRsZXltZWNrOiBhbm5ldms6IGFy ZSB5b3UgdGFsa2luZyBhYm91dCBtdXRhdGlvbiBvYnNlcnZlcnM/ClsxMjo0MHBtXSBhbm5ldms6 IGJyYWRsZXltZWNrOiB5ZWFoClsxMjo0MXBtXSBhbm5ldms6IGJyYWRsZXltZWNrOiBqdXN0IHJl YWQgc2Nyb2xsYmFjaywgSSBzdXBwb3NlIHdlIGNvdWxkIGNvbnNpZGVyIHN5bnRoZXRpYyBjaGFu Z2VzLCBub3Qgc3VyZSBleGFjdGx5IHdoYXQgdGhlIGJlc3Qgd2F5IGZvcndhcmQgaXMKWzEyOjQx cG1dIGFubmV2azogYnJhZGxleW1lY2s6IHdvdWxkIHlvdSBtaW5kIGZpbGluZyBhIGJ1ZyBhZ2Fp bnN0IGh0dHA6Ly9kb20uc3BlYy53aGF0d2cub3JnLyAobGluayBhdCB0aGUgdG9wKSB3aXRoIHNv bWUgbW9yZSBkZXRhaWw/IEVtYWlsaW5nIGlzIGZpbmUgdG9vClsxMjo0M3BtXSBqYWNvYm9sdXMg am9pbmVkIHRoZSBjaGF0IHJvb20uClsxMjo0NHBtXSBicmFkbGV5bWVjazogSSBjYW4gd3JpdGUg dXAgdGhlIGhpc3RvcnkgcmVhc29uaW5nIGV0Yy4gdG9uaWdodA==