14547 2007-07-07 04:44:21 -0700 typeof document.body.childNodes=="function" ("object" expected) 2022-06-14 17:44:25 -0700 1 1 1 Unclassified WebKit DOM 523.x (Safari 3) Mac (PowerPC) OS X 10.4 RESOLVED FIXED javascript:alert(typeof document.body.childNodes()) HasReduction, InRadar P2 Normal --- 1 doekman webkit-unassigned abarth ahmad.saleem792 ap arv bugs+webkit eric ggaren heycam ian Meanjeanaco m.goleb+bugzilla mrowe oliver sam xk1t ysuzuki yurys oldest_to_newest 5294 0 doekman 2007-07-07 04:44:21 -0700 Javascript's type of an NodeList is "function", where "object" is expected. testcase: typeof document.body.childNodes expected result: "object" actual result: "function" This also goes for the XML DOM, though I don't have a testcase. I encountered the same behaviour with XMLHttpRequest.responseXML Rationale: Firefox 2, IE6 and Opera9 all report "object" 5204 1 ddkilzer 2007-07-07 13:45:10 -0700 Confirmed with a local debug build of WebKit r24089 on Safari 3.0 (522.12) using Mac OS X 10.4.10 (8R218). 1398 2 mitz 2007-08-27 02:44:42 -0700 *** Bug 15089 has been marked as a duplicate of this bug. *** 1399 3 mrowe 2007-08-27 02:56:10 -0700 <rdar://problem/5439389> 1150 4 sullivan 2007-08-30 14:49:25 -0700 Do we know of any real-world sites that this affects? Do we know if it's a regression from earlier WebKit behavior? 1152 5 mrowe 2007-08-30 15:02:01 -0700 This affects the jQuery JavaScript library which is widly used, though they currently have a workaround in place. 1126 6 ddkilzer 2007-08-30 21:31:24 -0700 (In reply to comment #4) > Do we know of any real-world sites that this affects? Do we know if it's a > regression from earlier WebKit behavior? It is not a regression since Safari 2.0.4 (419.3) with original WebKit also returns "function" for the test URL. 1119 7 sam 2007-08-30 23:32:19 -0700 The reason NodeLists report there type as function is that they implement call() and the implementation of typeof checks to see if implementsCall() returns true (which it does). (see http://trac.webkit.org/projects/webkit/browser/trunk/JavaScriptCore/kjs/nodes.cpp#L977). 1120 8 mrowe 2007-08-30 23:44:58 -0700 Why does it implement call? document.body.childNodes() throws an exception in Firefox (Error: document.body.childNodes is not a function) while we return undefined. 1122 9 mrowe 2007-08-30 23:51:30 -0700 Sam informs me that it does so because Internet Explorer does so. document.body.childNodes(1) is the same as document.body.childNodes[1]. Ugh. 1117 10 sam 2007-08-31 00:33:32 -0700 This also is true for HTMLCollections. For instance, typeof document.images == "function". 58267 11 xk1t 2007-10-10 17:23:34 -0700 Objects that do not support call or construct are not functions. typeof window.constructor == "function" Typeof should return something other than function. This makes it harder to typecheck. 58268 12 xk1t 2007-10-10 17:29:56 -0700 A workaround: var isFunction = function( fn ) { return typeof fn == "function" && typeof fn.hasOwnProperty == "function" && fn.hasOwnProperty('prototype'); }; More on this: http://dhtmlkitchen.com/?category=/JavaScript/&date=2007/10/10/&entry=How-to-Tell-if-an-Object-is-a-Function#safari-anwser 58277 13 xk1t 2007-10-10 20:29:51 -0700 The error I get is: "TypeError: Value undefined (result of expression document.body.childNodes.call) is not object. undefined http://trac.webkit.org/projects/webkit/browser/trunk/JavaScriptCore/kjs/nodes.cpp#L636 636 if (!v->isObject()) { 637 return throwError(exec, TypeError, "Value %s (result of expression %s) is not object.", v, expr.get()); 638 } The jQuery patch will return incorrect results under several obvious conditions that I have posted on my blog entry. 58425 14 xk1t 2007-10-13 13:34:33 -0700 Updated test case. Try & break it. http://dhtmlkitchen.com/jstest/isFunctionTest.html I noticed several problems: 1) constructor property missing: "constructor" in document.getElementsByTagName("div"); // false 2) toString reflects the [[class]] as NodeList: document.getElementsByTagName("div").toString();// [object NodeList] document.getElementsByTagName("div").__proto__ === null; // true "NodeList" in window; // false 3) prototype property is missing from built-in functions. Function.prototype.prototype // undefined, should be an object. parseInt.prototype; // undefined, should be an object. 58436 15 Richard 2007-10-13 18:41:09 -0700 (In reply to comment #14) Updated test case. Try & break it. http://dhtmlkitchen.com/jstest/isFunctionTest.html > I noticed several problems: > 1) constructor property missing: > "constructor" in document.getElementsByTagName("div"); // false In ECMAScript terms the object retuned from a call to - getElementsByTagName - is a host object, and host objects are not required to have a - constructor - property. The W3C DOM specification for the NodeList interface also does not define a - constructor - property. So there is no technical justification for anyone to expect the object returned from a call to - getElementsByTagName - to have a - constructor - property. Thus the absence of such a property cannot be regarded as in any way erroneous. Instead any error would be in the thinking of anyone who expected/demanded it. > 2) > toString reflects the [[class]] as NodeList: Why would that be a problem? There is nothing that says it should not. > document.getElementsByTagName("div").toString();// [object NodeList] Why would that be a problem? There is nothing that says it should not. > document.getElementsByTagName("div").__proto__ === null; // true Why would that be a problem? There is nothing that says it should not. > "NodeList" in window; // false Why would that be a problem? There is nothing that says it should not. > 3) > prototype property is missing from built-in functions. Not all of them, and ECMA 262 3rd Ed, Section 15 paragraph 9 says:- "None of the built-in functions described in this section shall implement the internal [[Construct]] method unless otherwise specified in the description of a particular function. None of the built-in functions described in this section shall initially have a prototype property unless otherwise specified in the description of a particular function." - so where not "otherwise specified" no prototype property should be expected. > Function.prototype.prototype // undefined, should be an object. That actually would be a bug, but an utterly insignificant one as nobody is likely to be interested in Function.prototype.prototype. > parseInt.prototype; // undefined, should be an object. No it should not as for - parseInt - there is nothing to 'otherwise specify' and so section 15 paragraph 9 applies. Generally this entire 'bug report' is bogus. The W3C specifies NodeList, HTMLCollection, etc., as interfaces. For ECMAScript the implications of this are not that there should be a NodeList class in the environment but instead that when you get an object that "is a NodeList" what you actually get is an object that implements the NodeList interface (nothing more than an object that has all of the methods and properties defined in the ECMAScript binding for the interface), and that can be any object so long as it implements the interface correctly. In ECMAScript/javascript functions are objects, so there is no reason for the object implementing the NodeList interface not being a function object. That may not be required but it certainly is not excluded, or particularly unexpected by anyone with any experience of scripting web browsers. Historically the typeof operator would return 'function' for all objects implanting NodeList, NamedNodeMap, HTMLCollection and even all pre-DOM collections in Mac IE, Konqueror, Opera versions up 7, IceBrowser versions up to 5 and probably at least some others. And in all cases these object were callable. 58440 16 xk1t 2007-10-13 20:09:25 -0700 (In reply to comment #15) > (In reply to comment #14) > > Updated test case. Try & break it. > http://dhtmlkitchen.com/jstest/isFunctionTest.html > > > I noticed several problems: > > > 1) constructor property missing: > > > "constructor" in document.getElementsByTagName("div"); // false > > In ECMAScript terms the object retuned from a call to - getElementsByTagName - > is a host object, and host objects are not required to have a - constructor - > property. The constructor property would be on the object's [[Prototype]] The W3C DOM specification for the NodeList interface also does not > define a - constructor - property. So there is no technical justification for > anyone to expect the object returned from a call to - getElementsByTagName - to > have a - constructor - property. Thus the absence of such a property cannot be > regarded as in any way erroneous. Instead any error would be in the thinking of > anyone who expected/demanded it. > A NodeList is an object. Error in thinking, huh? > > 2) > > toString reflects the [[class]] as NodeList: > > Why would that be a problem? There is nothing that says it should not. > The fact that constructor is null. [[class]] comes from the constructor. So it sounds like you're trying to say that an object's [[class]] doesn't imply that an object's has the same constructor. If that's what you're trying to say, that is technically correct. The class doesn't imply the constructor, it's the other way around. Ab object (nodeList in this case) COULD get its [[class]] from an internal private function, where private is implementation defined. If the class property is NodeList, the object should be a NodeList. > > document.getElementsByTagName("div").toString();// [object NodeList] > > Why would that be a problem? There is nothing that says it should not. > > > document.getElementsByTagName("div").__proto__ === null; // true > > Why would that be a problem? There is nothing that says it should not. > javascript:alert(document.body.childNodes[1].toString === Object.prototype.toString) We got Object.prototype.toString and all the other methods off Object.prototype. What happened to the constructor? The [[Prototype]] was not set, but all the methods are there. To me, that seems strange. > > "NodeList" in window; // false > > Why would that be a problem? There is nothing that says it should not. > That's true. > > 3) > > prototype property is missing from built-in functions. > > Not all of them, and ECMA 262 3rd Ed, Section 15 paragraph 9 says:- > > "None of the built-in functions described in this section shall implement the > internal [[Construct]] method unless otherwise specified in the description of > a particular function. None of the built-in functions described in this section > shall initially have a prototype property unless otherwise specified in the > description of a particular function." > You're right. > > Generally this entire 'bug report' is bogus. THAT is not true. This bug is valid. document.body.childNodes IS NOT a function. The W3C specifies NodeList, > HTMLCollection, etc., as interfaces. For ECMAScript the implications of this > are not that there should be a NodeList class in the environment but instead > that when you get an object that "is a NodeList" what you actually get is an > object that implements the NodeList interface (nothing more than an object that > has all of the methods and properties defined in the ECMAScript binding for the > interface), and that can be any object so long as it implements the interface > correctly. In ECMAScript/javascript functions are objects, so there is no > reason for the object implementing the NodeList interface not being a function > object. That may not be required but it certainly is not excluded, or > particularly unexpected by anyone with any experience of scripting web > browsers. Historically the typeof operator would return 'function' for all > objects implanting NodeList, NamedNodeMap, HTMLCollection and even all pre-DOM > collections in Mac IE, Konqueror, Opera versions up 7, IceBrowser versions up > to 5 and probably at least some others. And in all cases these object were > callable. > Do you meant objects implementing NodeList? document.body.childNodes does not implement NodeList. It's constructor, however, does. document.body.childNodes is an instance of a NodeList. Thanks for bringing relevant javascript knowledge here to straighten out the prototype property. You seem to have the manual clearly implanted in your brain. > 58443 17 mjs 2007-10-13 21:17:12 -0700 Please, ladies & gentlemen, let's try to remain courteous in these discussions. It's probably true that many of the issues noted by the test are not required by the relevant specs. However, we may have to implement some of those things for compatibility. The best thing to do with this bug report would be to split off a separate bug for each individual issue, rather than making this a master bug for dozens of DOM binding quirks. For each individual issue, it would be great to know: 1) Do the relevant specs require this behavior? (Probably the answer is no in most cases, since the ECMAScript spec has pretty loose rules for host objects, and the DOM specs are not very detailed in specifying how JS bindings should work.) 2) Do the relevant specs forbid this behavior? We're somewhat hesitant to outright violate specs, even in cases where there might be some effect on compatibility. 3) Is the behavior required for compatibility, or just a minor corner case? In the case of the original function vs. object thing for NodeLists, it's clear that neither the ECMA-262 spec or the DOM spec require typeof to return "object". It's also clear that this is not forbidden - the ECMAScript spec allows host objects to return anything whatsoever from "typeof". And it's clear that returning "object" matters to web compatibility. Therefore we should give a typeof result of object. This may require objects to gain an isFunction() method in addition to implementsCall(), which can default to calling implementsCall() but which is overridable. I'm not sure what the answer is for the many other issues mentioned in this bug. They deserve separate bug reports and someone should do the analogous research. 58445 18 xk1t 2007-10-13 22:50:29 -0700 (In reply to comment #17) > Please, ladies & gentlemen, let's try to remain courteous in these discussions. > Point taken. My post sounded sarcastic. Richard did correctly correct me on Function.prototype.prototype point, clearing up confusion that I caused. > It's probably true that many of the issues noted by the test are not required > by the relevant specs. However, we may have to implement some of those things > for compatibility. The best thing to do with this bug report would be to split > off a separate bug for each individual issue, rather than making this a master > bug for dozens of DOM binding quirks. For each individual issue, it would be > great to know: > > 1) Do the relevant specs require this behavior? (Probably the answer is no in > most cases, since the ECMAScript spec has pretty loose rules for host objects, > and the DOM specs are not very detailed in specifying how JS bindings should > work.) > document.images is not a function, it is a NodeList instance. > 2) Do the relevant specs forbid this behavior? We're somewhat hesitant to > outright violate specs, even in cases where there might be some effect on > compatibility. > ECMA and W3 do not forbid any custom behavior, AFAIK. > 3) Is the behavior required for compatibility, or just a minor corner case? > Minor case, AFAIK. most uses of nodelist/collection won't try to invoke them with arguments. Please correct this if it is not right. > In the case of the original function vs. object thing for NodeLists, it's clear > that neither the ECMA-262 spec or the DOM spec require typeof to return > "object". It's also clear that this is not forbidden - the ECMAScript spec > allows host objects to return anything whatsoever from "typeof". And it's clear > that returning "object" matters to web compatibility. Therefore we should give > a typeof result of object. This may require objects to gain an isFunction() > method in addition to implementsCall(), which can default to calling > implementsCall() but which is overridable. > I don't think it's a good idea to implement conflicting interfaces. typeof it == "function" should mean that I can use the call method or any other methods on Function.prototype. If it's a function, I expect it to be one, completely. Function.prototype.constructor is Function. What is the constructor of such an object? If typeof it == "function", I expect that. How do you resolve document.images.length? 1) function.length 2) collection length Implementing Function for a Collection/NodeList conflicts with NodeList interface. Partially implementing Function makes for a confusing interface. It is not desirable to implement Function for document.images. Collection, not Function. Can this feature removed? Is it being heavily relied on? > I'm not sure what the answer is for the many other issues mentioned in this > bug. They deserve separate bug reports and someone should do the analogous > research. > 58451 19 mrowe 2007-10-13 23:04:45 -0700 document.images behaves as both a NodeList and a function for compatibility with Internet Explorer. It is unlikely that this dual behaviour could be removed without causing compatibility issues with real-world websites. See <http://msdn2.microsoft.com/en-us/library/ms537461.aspx> for Microsoft's documentation of their bizarre behaviour of document.images. 58513 20 Richard 2007-10-14 10:48:29 -0700 > Please, ladies & gentlemen, let's try to remain courteous in these > discussions. > > It's probably true that many of the issues noted by the test are not > required by the relevant specs. However, we may have to implement > some of those things for compatibility. By which you mean compatibility with IE, because, as I have mentioned, historically many browsers had collections that could be called and would report 'function' when tested with - typeof -, so the status quo is already computable with all of those. A pragmatic acceptance of the real world would tend to indicate that compatibility with IE has a lot to be said for it. > The best thing to do with > this bug report would be to split off a separate bug for each > individual issue, rather than making this a master bug for dozens > of DOM binding quirks. For each individual issue, it would be great > to know: > > 1) Do the relevant specs require this behavior? (Probably the answer > is no in most cases, since the ECMAScript spec has pretty loose > rules for host objects, and the DOM specs are not very detailed in > specifying how JS bindings should work.) The relevant specs nether require that a 'collection' (taken as shorthand for NodeList, HTMLCollection, NamedNodeMap etc and anything outside DOM such as window.frames) be callable, nor do they preclude the possibility (at least in ECMAScript/javascript contexts (and Java itself is the limiting factor in the Java context, not the DOM bindings)). These 'collections' are all host objects so ECMA 262 allows them to report anything they like from a - typeof - operation. Though historically almost no host objects have stepped outside of the limited set of - typeof - responses defined in ECMA 262 (the only notable exceptions being methods of ActiveX objects which often report 'unknown'). > 2) Do the relevant specs forbid this behavior? Nothing described in this bug report is forbidden by any pertinent specification. > We're somewhat > hesitant to outright violate specs, even in cases where there > might be some effect on compatibility. That is not an issue here. All of:- 1. Callable collections that report 'object' with typeof. 2. Non-callable collections that report 'object' with typeof 3. Callable collections that report 'function' with typoeof 4. Non-callable collections that report 'function' with typeof - are allowed by the pertinent specifications. Though 1 and 4 are of questionable rationality. 4 would be absolutely stupid, but it is still worth noting that when the team creating Mac IE looked at what the Windows IE team had done even they perceived option 1 as wrong and chose option 3 in its place. > 3) Is the behavior required for compatibility, or just a minor > corner case? Microsoft's own documentation is littered with JScript examples which call collections, to the exclusion of using property accessors for the task. Virtually anyone coming into browser scripting via IE only scripting and Microsoft documentation will have been exposed to these bad examples. The result will be that if you don't allow collections to be called probably about 50% of the sites that are "best viewed with IE" will be non-functional with Safari. The situation will be worse with "IE only" intranets and it may extend to .NET components. So the question of whether the collections should be callable comes down to; do you care about that? And the pragmatic answer is probably 'yes'. > In the case of the original function vs. object thing for NodeLists, > it's clear that neither the ECMA-262 spec or the DOM spec require > typeof to return "object". It's also clear that this is not > forbidden - the ECMAScript spec allows host objects to return > anything whatsoever from "typeof". And it's clear that returning > "object" matters to web compatibility. That last is not clear. If you are aiming for 'like for like' compatibility with Windows IE then the implications go well beyond the 'collections'. On Windows IE all of (or at least most of) the DOM methods also report "object" from - typeof -, as do other callable objects such as - alert -, - setTimeout - and - attachEvent -. And perversely the - item - method of 'collections' reports "string" from - typeof -, of all things (at least up to version 6. I have not checked to see if that insanity was carried through to version 7 yet). All of that is allowed, but it certainly is not a good idea and should not be reproduced lightly. The issue here is not one of compatibility but rather one of expectations. From the first description: "Javascript's type of an NodeList is "function", where "object" is expected." But why is that expected when there is no standard that asserts that anything specific should be expected? Anyone who had any experience stretching back a couple of versions with Opera, or included Konqueror or Mac IE would have no such expectation as it would have been disappointed years ago. It is an expectation that comes from looking at a couple of recent browsers and assuming that what they do should be definitive (despite the evidence that even recent browsers are a long way from being consistent). The problem with pandering to such uniformed expectations is that while you can give in to the expectations of the first individual who presents them the next individual's expectations stand a very good chance of being different, and sooner or later there will be expectations that are incompatible with earlier ones. Indeed the situation here stems from people having uniformed and incompatible expectations. The W3C DOM specifications gives a solid justification for an expected outcome from:- document.images.item(1); The ECMAScript bindings, by asserting that the bracket notation is to be mapped to the - item - method, justifies the same expected outcome for:- document.image[1]; While there is nothing in the world to suggest that:- document.images(1); - should do anything but throw an exception, beyond Microsoft's documentation and the fact that it does not throw an exception in most actual web browsers but instead produces the same outcome as the previous two. The only way out of that is to totally give in to creating a like-for-like imitation of one (and only one) of the browsers that are producing these expectations, and so in your case reproducing all of the features of IE, regardless of how perverse and irrational they may be (That would not be exclusive; there is no reason for not providing things that do not feature in IE at all in addition, and handling them in any why seen as desirable). > Therefore we should give a > typeof result of object. This may require objects to gain an > isFunction() method in addition to implementsCall(), which can > default to calling implementsCall() but which is overridable. Just remember that you will have to generate a list of all of the object/function properties available in Safari and then test Windows IE to see precisely what it does return from - typeof - for its equivalents. Otherwise the problem is not solved, only moved a little more out of sight. 74404 21 ap 2008-03-19 00:20:45 -0700 *** Bug 10647 has been marked as a duplicate of this bug. *** 105458 22 ian 2009-01-13 00:31:23 -0800 HTML5 now requires HTMLCollection objects to be callable. 137783 23 eric 2009-08-06 21:26:12 -0700 It seems this should be a "relatively simple" fix. We can use TypeInfo like we do for Strings which masquerade as undefined. JSValue jsTypeStringForValue(CallFrame* callFrame, JSValue v) is the function where this check is made: if (v.isObject()) { // Return "undefined" for objects that should be treated // as null when doing comparisons. if (asObject(v)->structure()->typeInfo().masqueradesAsUndefined()) return jsNontrivialString(callFrame, "undefined"); CallData callData; if (asObject(v)->getCallData(callData) != CallTypeNone) return jsNontrivialString(callFrame, "function"); } return jsNontrivialString(callFrame, "object"); we just add a callableObject() accessor to typeInfo or some such. And we add a special property to the IDL files. The idls already have a CustomCall for these cases. We can change it to be UndetectableCustomCall or something. Sam, Oliver? Sound like a good plan to you? 181363 24 ap 2010-01-15 13:41:47 -0800 *** Bug 33716 has been marked as a duplicate of this bug. *** 292035 25 abarth 2010-10-08 20:41:51 -0700 Sadly, there does not appear to be any space left in JSC::TypeInfo. 292040 26 70337 abarth 2010-10-08 21:28:25 -0700 Created attachment 70337 approach 292052 27 70341 abarth 2010-10-08 22:13:07 -0700 Created attachment 70341 Patch 292055 28 sam 2010-10-08 22:25:17 -0700 (In reply to comment #25) > Sadly, there does not appear to be any space left in JSC::TypeInfo. I am not sure that is strictly true. The way TypeInfo is used in Structure, there is quite a bit of padding after it, so expanding its size should ok, though it may require some JIT changes. 292057 29 abarth 2010-10-08 22:39:20 -0700 (In reply to comment #28) > (In reply to comment #25) > > Sadly, there does not appear to be any space left in JSC::TypeInfo. > > I am not sure that is strictly true. The way TypeInfo is used in Structure, there is quite a bit of padding after it, so expanding its size should ok, though it may require some JIT changes. Do you think that's better than the approach in this patch? I tried changing the field from a char to a short, but then I ran into some ASSERTs about the inline capacity of objects. Given that the typeof operator isn't called that often, it seemed better to add a virtual function call than to add a byte to the structure, but I'm not nearly an expert on the tradeoffs here. (Part of the fun of working on these ancient bugs is to learn about this kind of thing.) 292060 30 xk1t 2010-10-08 23:20:15 -0700 (wincing at my previous comments) ECMA 5 requires callable host object to result "function" when supplied to typeof operator. And so if document.images is remain callable then typeof document.images is required to result "function". See also comment 20. 292069 31 70341 ap 2010-10-09 00:49:45 -0700 Comment on attachment 70341 Patch Eric, Adam, Sam - I don't understand why everyone is discussing how to fix this. Isn't the bug clearly INVALID at this point? r-, because there is no explanation of why this is even being changed. 292110 32 abarth 2010-10-09 08:17:20 -0700 > Eric, Adam, Sam - I don't understand why everyone is discussing how to fix this. Isn't the bug clearly INVALID at this point? 4 of 5 browsers agree that the typeof these objects is "object". > ECMA 5 requires callable host object to result "function" when supplied to typeof operator. And so if document.images is remain callable then typeof document.images is required to result "function". Then the spec is wrong and should be fixed. The folks in the working group must not have considered this case because their operating rule was that if 4 of 5 browsers agree, then that's what the spec should say. 292113 33 70341 abarth 2010-10-09 08:18:10 -0700 Comment on attachment 70341 Patch IMHO, Safari being the only browser that fails this test is a good reason to converge to the consensus behavior. 292159 34 70341 ap 2010-10-09 12:35:43 -0700 Comment on attachment 70341 Patch Please bring this up for discussion on relevant working groups. 292241 35 abarth 2010-10-09 19:44:31 -0700 > Please bring this up for discussion on relevant working groups. That seems overly conservative. Why wouldn't we want to match every other browser? 292247 36 ap 2010-10-09 20:59:19 -0700 It doesn't seem that there is any urgency now - we lived with this behavior before, why rush to change it when all the specs reportedly agree with us? ECMAScript is a complicated spec with many interdependencies. If we're going to violate a requirement saying that typeof of a callable object must be "function", we should at least consult experts who can tell us what else needs to change in accordance. 292262 37 abarth 2010-10-09 23:46:32 -0700 @oliver: Thoughts on what we should do here? 292513 38 arv 2010-10-11 10:00:22 -0700 With my TC39 hat on... The ES5 spec is clear (11.4.3) that any object that has a [[Call]] should return "function" for typeof. The problem comes from our willingness to follow the IE VBS-ism where collections are callable. In ES3 this was fine since ES3 did not mandate that [[Call]] implied typeof obj === "function". I think there are 2 possible paths here. 1. Make collections non callable, at least not in standards mode. Other browsers do not do this (IE9 stoppee supporting it). 2. Keep them callable but hack typeof to return "object" like this patch does. This is no worse than the document.all hack and just like that one this is a win for compatibility. 292537 39 abarth 2010-10-11 10:24:41 -0700 > 1. Make collections non callable, at least not in standards mode. Other browsers do not do this (IE9 stopped supporting it). Oh, I didn't know IE9 stopped making these callable. Unfortunately, IE9 has tons of compatibility modes, which makes it difficult to know whether following suit will work for us. I suspect it would cost noticeable compatibility. 292577 40 oliver 2010-10-11 11:28:07 -0700 I would rather not jump through hoops to make things that are callable claim not to be functions, as it would seem likely to lead to interesting bugs. For instance JSON serialisation skips 'functions' it does this by skipping things that are callable, yet this means it would need to be updated to check for these special cases, ditto for postMessage serialisation. Special casing these so that typeof returns "object" would lead (i think) to many subtle differences in behaviour. If we want to stop these from claiming to be "function"s they should stop being callable. 292588 41 abarth 2010-10-11 11:44:07 -0700 > I would rather not jump through hoops to make things that are callable claim not to be functions, as it would seem likely to lead to interesting bugs. For instance JSON serialisation skips 'functions' it does this by skipping things that are callable, yet this means it would need to be updated to check for these special cases, ditto for postMessage serialisation. Special casing these so that typeof returns "object" would lead (i think) to many subtle differences in behaviour. How do these cases interoperate across browsers now? It seems that we'll need to make sure these cases behave properly regardless of what string we return from this function. > If we want to stop these from claiming to be "function"s they should stop being callable. I suspect we'll have compatibility problems removing their callability. 292610 42 xk1t 2010-10-11 12:20:20 -0700 (In reply to comment #38) > With my TC39 hat on... > > The ES5 spec is clear (11.4.3) that any object that has a [[Call]] should return "function" for typeof. > > The problem comes from our willingness to follow the IE VBS-ism where collections are callable. > > In ES3 this was fine since ES3 did not mandate that [[Call]] implied typeof obj === "function". > > I think there are 2 possible paths here. > > 1. Make collections non callable, at least not in standards mode. Other browsers do not do this (IE9 stoppee supporting it). That's a fair proposal, though you've supported it with false information :-(. In Gecko, collections aren't callable in any mode. Never have been. If collections aren't callable in Gecko then all of those pages are erring in Gecko. How many pages that is might be hard to determine because many "IE only" sites are internal applications. Probably Mozilla developers would have more insight into this (Boris comes to mind). Collections are callable in Opera 10.6 (both modes) and in the IE9 beta I have, version 9.0.7390 (all modes). >>typeof document.images(0) "object" >>clientInformation [object Navigator] { appCodeName : "Mozilla", appMinorVersion : "beta", browserLanguage : "en-us", cookieEnabled : true, cpuClass : "x86", mimeTypes : [object MSMimeTypesCollection], plugins : [object MSPluginsCollection], systemLanguage : "en-us", userLanguage : "en-us", appName : "Microsoft Internet Explorer" ... } >>document.documentMode 9 >>typeof document.images "object" :-( > 2. Keep them callable but hack typeof to return "object" like this patch does. This is no worse than the document.all hack and just like that one this is a win for compatibility. Another spec violation. That weakens the spec and causes interoperability problems for other violations that don't follow your cowpath (which was originally IE's cowpath). I suggest instead that you propose such language extensions to es-discuss. 292615 43 arv 2010-10-11 12:36:08 -0700 (In reply to comment #42) > (In reply to comment #38) > Collections are callable in Opera 10.6 (both modes) and in the IE9 beta I have, version 9.0.7390 (all modes). > >>typeof document.images(0) > "object" I did try this but my page had no images in it which causes a "Member not found" error. It was a bad test. I apologize for giving false hope. typeof collection === 'function' is a hazard since these collections are not behaving like functions. The do not have the right [[Class]], instanceof function is false, there is no bind but more serious is the lack of call and apply. I'm sorry for making this discussion even less on topic than it already is. It is clear that the WebKit/JSC bindings are the exception amongst the browsers and that this is causing compatibility issues. 292627 44 ggaren 2010-10-11 13:18:55 -0700 I don't think a new virtual function -- "hasFunctionType()" -- for asking an object about its callability, in addition to the existing virtual function -- "getCallData()" -- is the best solution. When the two disagree, how do I know which one is right? I think a better solution is to add a bit to the CallType returned by getCallData, which specifies the behavior of typeof. I say "I think" because I'm not sure what behavior we're ultimately trying to implement. Are we just trying to bludgeon typeof into matching the behavior of other browsers for a fixed set of DOM objects? If so, that's probably the right solution. But maybe we're trying to implement a different rule -- for example, that only objects that are callable and descendants of the original value of Function.prototype return "function" to typeof. In that case, a completely different solution is appropriate. Adam, (In reply to comment #35) > > Please bring this up for discussion on relevant working groups. > > That seems overly conservative. Why wouldn't we want to match every other browser? Since we need to know what behavior we're trying to implement in order to judge whether the code communicates that behavior well, and whether it's fully tested, I think the best way forward is to discuss this with the relevant working groups and decide on a behavior. I think my comments above are a reason to use a different approach than the one you've used, and to require a certain set of test cases, but I'm just not sure. 292639 45 abarth 2010-10-11 13:58:37 -0700 > I think a better solution is to add a bit to the CallType returned by getCallData, which specifies the behavior of typeof. Ok. That seems to have further reaching implications, but I can study them and see what the consequences would be. > I say "I think" because I'm not sure what behavior we're ultimately trying to implement. Are we just trying to bludgeon typeof into matching the behavior of other browsers for a fixed set of DOM objects? If so, that's probably the right solution. I believe bludgeon is a very appropriate verb here. :) > But maybe we're trying to implement a different rule -- for example, that only objects that are callable and descendants of the original value of Function.prototype return "function" to typeof. In that case, a completely different solution is appropriate. I don't believe that's the behavior we want. For example, just because you mutate an object's prototype chain doesn't mean it's typeof behavior should change. We could test other browsers to see, but I think this behavior is something specific for these host objects. > Adam, (In reply to comment #35) > > > Please bring this up for discussion on relevant working groups. > > > > That seems overly conservative. Why wouldn't we want to match every other browser? > > Since we need to know what behavior we're trying to implement in order to judge whether the code communicates that behavior well, and whether it's fully tested, I think the best way forward is to discuss this with the relevant working groups and decide on a behavior. I didn't understand this comment. > I think my comments above are a reason to use a different approach than the one you've used, and to require a certain set of test cases, but I'm just not sure. There are two threads to this discussion: 1) What observable behavior do we want? 2) How should we implement that behavior? It sounds like you agree that our observable behavior should match other browsers and that your comments are more directed at the second question. 293486 46 ggaren 2010-10-13 10:20:33 -0700 > There are two threads to this discussion: > > 1) What observable behavior do we want? > 2) How should we implement that behavior? I think the questions are linked. A good implementation depends on a good definition of the desired behavior. 1004881 47 m.goleb+bugzilla 2014-04-29 01:53:15 -0700 Both Safari & WebKit nightly have: typeof document.body.childNodes === 'object' Therefore, the bug as reported is no longer present. 1875899 48 ahmad.saleem792 2022-06-14 15:40:46 -0700 Using Wayback Archive, I tested "DHTML" test case and now all browsers (Firefox Nightly 103, Chrome Canary 105 and Safari 15.5) aligns and give same output. Link - https://web.archive.org/web/20101207041718/http://dhtmlkitchen.com/jstest/isFunctionTest.html Can we close this bug based on all browser behave same now. Thanks! 70337 2010-10-08 21:28:25 -0700 2010-10-08 22:13:03 -0700 approach bug-14547-20101008212824.patch text/plain 8028 abarth SW5kZXg6IEphdmFTY3JpcHRDb3JlL0phdmFTY3JpcHRDb3JlLmV4cAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBK YXZhU2NyaXB0Q29yZS9KYXZhU2NyaXB0Q29yZS5leHAJKHJldmlzaW9uIDY5NDE4KQorKysgSmF2 YVNjcmlwdENvcmUvSmF2YVNjcmlwdENvcmUuZXhwCSh3b3JraW5nIGNvcHkpCkBAIC0yMjUsNiAr MjI1LDcgQEAgX19aTjNKU0M2SlNDZWxsMTFnZXRDYWxsRGF0YUVSTlNfOENhbGxEYQogX19aTjNK U0M2SlNDZWxsMTFnZXRKU051bWJlckV2CiBfX1pOM0pTQzZKU0NlbGwxNGRlbGV0ZVByb3BlcnR5 RVBOU185RXhlY1N0YXRlRVJLTlNfMTBJZGVudGlmaWVyRQogX19aTjNKU0M2SlNDZWxsMTRkZWxl dGVQcm9wZXJ0eUVQTlNfOUV4ZWNTdGF0ZUVqCitfX1pOM0pTQzZKU0NlbGwxNWhhc0Z1bmN0aW9u VHlwZUV2CiBfX1pOM0pTQzZKU0NlbGwxNmdldENvbnN0cnVjdERhdGFFUk5TXzEzQ29uc3RydWN0 RGF0YUUKIF9fWk4zSlNDNkpTQ2VsbDE4Z2V0T3duUHJvcGVydHlTbG90RVBOU185RXhlY1N0YXRl RVJLTlNfMTBJZGVudGlmaWVyRVJOU18xMlByb3BlcnR5U2xvdEUKIF9fWk4zSlNDNkpTQ2VsbDE4 Z2V0T3duUHJvcGVydHlTbG90RVBOU185RXhlY1N0YXRlRWpSTlNfMTJQcm9wZXJ0eVNsb3RFCklu ZGV4OiBKYXZhU2NyaXB0Q29yZS9KYXZhU2NyaXB0Q29yZS54Y29kZXByb2ovcHJvamVjdC5wYnhw cm9qCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIEphdmFTY3JpcHRDb3JlL0phdmFTY3JpcHRDb3JlLnhjb2RlcHJv ai9wcm9qZWN0LnBieHByb2oJKHJldmlzaW9uIDY5NDE4KQorKysgSmF2YVNjcmlwdENvcmUvSmF2 YVNjcmlwdENvcmUueGNvZGVwcm9qL3Byb2plY3QucGJ4cHJvagkod29ya2luZyBjb3B5KQpAQCAt MjQwNyw3ICsyNDA3LDYgQEAKIAkJCWlzYSA9IFBCWFByb2plY3Q7CiAJCQlidWlsZENvbmZpZ3Vy YXRpb25MaXN0ID0gMTQ5QzI3NzEwODkwMkFGRTAwOEE5RUZDIC8qIEJ1aWxkIGNvbmZpZ3VyYXRp b24gbGlzdCBmb3IgUEJYUHJvamVjdCAiSmF2YVNjcmlwdENvcmUiICovOwogCQkJY29tcGF0aWJp bGl0eVZlcnNpb24gPSAiWGNvZGUgMi40IjsKLQkJCWRldmVsb3BtZW50UmVnaW9uID0gRW5nbGlz aDsKIAkJCWhhc1NjYW5uZWRGb3JFbmNvZGluZ3MgPSAxOwogCQkJa25vd25SZWdpb25zID0gKAog CQkJCUVuZ2xpc2gsCkluZGV4OiBKYXZhU2NyaXB0Q29yZS9ydW50aW1lL0pTQ2VsbC5jcHAKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gSmF2YVNjcmlwdENvcmUvcnVudGltZS9KU0NlbGwuY3BwCShyZXZpc2lvbiA2 OTQxOCkKKysrIEphdmFTY3JpcHRDb3JlL3J1bnRpbWUvSlNDZWxsLmNwcAkod29ya2luZyBjb3B5 KQpAQCAtMTA5LDYgKzEwOSwxMiBAQCBDYWxsVHlwZSBKU0NlbGw6OmdldENhbGxEYXRhKENhbGxE YXRhJikKICAgICByZXR1cm4gQ2FsbFR5cGVOb25lOwogfQogCitib29sIEpTQ2VsbDo6aGFzRnVu Y3Rpb25UeXBlKCkKK3sKKyAgICBDYWxsRGF0YSBjYWxsRGF0YTsKKyAgICByZXR1cm4gZ2V0Q2Fs bERhdGEoY2FsbERhdGEpICE9IENhbGxUeXBlTm9uZTsKK30KKwogQ29uc3RydWN0VHlwZSBKU0Nl bGw6OmdldENvbnN0cnVjdERhdGEoQ29uc3RydWN0RGF0YSYpCiB7CiAgICAgcmV0dXJuIENvbnN0 cnVjdFR5cGVOb25lOwpJbmRleDogSmF2YVNjcmlwdENvcmUvcnVudGltZS9KU0NlbGwuaAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBKYXZhU2NyaXB0Q29yZS9ydW50aW1lL0pTQ2VsbC5oCShyZXZpc2lvbiA2OTQx OCkKKysrIEphdmFTY3JpcHRDb3JlL3J1bnRpbWUvSlNDZWxsLmgJKHdvcmtpbmcgY29weSkKQEAg LTkyLDggKzkyLDkgQEAgbmFtZXNwYWNlIEpTQyB7CiAgICAgICAgIFVTdHJpbmcgZ2V0U3RyaW5n KEV4ZWNTdGF0ZSogZXhlYykgY29uc3Q7IC8vIG51bGwgc3RyaW5nIGlmIG5vdCBhIHN0cmluZwog ICAgICAgICBKU09iamVjdCogZ2V0T2JqZWN0KCk7IC8vIE5VTEwgaWYgbm90IGFuIG9iamVjdAog ICAgICAgICBjb25zdCBKU09iamVjdCogZ2V0T2JqZWN0KCkgY29uc3Q7IC8vIE5VTEwgaWYgbm90 IGFuIG9iamVjdAotICAgICAgICAKKwogICAgICAgICB2aXJ0dWFsIENhbGxUeXBlIGdldENhbGxE YXRhKENhbGxEYXRhJik7CisgICAgICAgIHZpcnR1YWwgYm9vbCBoYXNGdW5jdGlvblR5cGUoKTsK ICAgICAgICAgdmlydHVhbCBDb25zdHJ1Y3RUeXBlIGdldENvbnN0cnVjdERhdGEoQ29uc3RydWN0 RGF0YSYpOwogCiAgICAgICAgIC8vIEV4dHJhY3RpbmcgaW50ZWdlciB2YWx1ZXMuCkluZGV4OiBK YXZhU2NyaXB0Q29yZS9ydW50aW1lL09wZXJhdGlvbnMuY3BwCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIEphdmFT Y3JpcHRDb3JlL3J1bnRpbWUvT3BlcmF0aW9ucy5jcHAJKHJldmlzaW9uIDY5NDE4KQorKysgSmF2 YVNjcmlwdENvcmUvcnVudGltZS9PcGVyYXRpb25zLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNzMs OCArNzMsNyBAQCBKU1ZhbHVlIGpzVHlwZVN0cmluZ0ZvclZhbHVlKENhbGxGcmFtZSogCiAgICAg ICAgIC8vIGFzIG51bGwgd2hlbiBkb2luZyBjb21wYXJpc29ucy4KICAgICAgICAgaWYgKGFzT2Jq ZWN0KHYpLT5zdHJ1Y3R1cmUoKS0+dHlwZUluZm8oKS5tYXNxdWVyYWRlc0FzVW5kZWZpbmVkKCkp CiAgICAgICAgICAgICByZXR1cm4ganNOb250cml2aWFsU3RyaW5nKGNhbGxGcmFtZSwgInVuZGVm aW5lZCIpOwotICAgICAgICBDYWxsRGF0YSBjYWxsRGF0YTsKLSAgICAgICAgaWYgKGFzT2JqZWN0 KHYpLT5nZXRDYWxsRGF0YShjYWxsRGF0YSkgIT0gQ2FsbFR5cGVOb25lKQorICAgICAgICBpZiAo YXNPYmplY3QodiktPmhhc0Z1bmN0aW9uVHlwZSgpKQogICAgICAgICAgICAgcmV0dXJuIGpzTm9u dHJpdmlhbFN0cmluZyhjYWxsRnJhbWUsICJmdW5jdGlvbiIpOwogICAgIH0KICAgICByZXR1cm4g anNOb250cml2aWFsU3RyaW5nKGNhbGxGcmFtZSwgIm9iamVjdCIpOwpJbmRleDogV2ViQ29yZS9X ZWJDb3JlLnhjb2RlcHJvai9wcm9qZWN0LnBieHByb2oKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9X ZWJDb3JlLnhjb2RlcHJvai9wcm9qZWN0LnBieHByb2oJKHJldmlzaW9uIDY5NDE4KQorKysgV2Vi Q29yZS9XZWJDb3JlLnhjb2RlcHJvai9wcm9qZWN0LnBieHByb2oJKHdvcmtpbmcgY29weSkKQEAg LTIxMTUwLDcgKzIxMTUwLDYgQEAKIAkJCWlzYSA9IFBCWFByb2plY3Q7CiAJCQlidWlsZENvbmZp Z3VyYXRpb25MaXN0ID0gMTQ5QzI4NDMwODkwMkIxMTAwOEE5RUZDIC8qIEJ1aWxkIGNvbmZpZ3Vy YXRpb24gbGlzdCBmb3IgUEJYUHJvamVjdCAiV2ViQ29yZSIgKi87CiAJCQljb21wYXRpYmlsaXR5 VmVyc2lvbiA9ICJYY29kZSAyLjQiOwotCQkJZGV2ZWxvcG1lbnRSZWdpb24gPSBFbmdsaXNoOwog CQkJaGFzU2Nhbm5lZEZvckVuY29kaW5ncyA9IDE7CiAJCQlrbm93blJlZ2lvbnMgPSAoCiAJCQkJ RW5nbGlzaCwKSW5kZXg6IFdlYkNvcmUvYmluZGluZ3MvanMvSlNIVE1MQWxsQ29sbGVjdGlvbkN1 c3RvbS5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9iaW5kaW5ncy9qcy9KU0hUTUxBbGxDb2xs ZWN0aW9uQ3VzdG9tLmNwcAkocmV2aXNpb24gNjk0MTgpCisrKyBXZWJDb3JlL2JpbmRpbmdzL2pz L0pTSFRNTEFsbENvbGxlY3Rpb25DdXN0b20uY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0xMDYsNiAr MTA2LDEyIEBAIENhbGxUeXBlIEpTSFRNTEFsbENvbGxlY3Rpb246OmdldENhbGxEYXQKICAgICBy ZXR1cm4gQ2FsbFR5cGVIb3N0OwogfQogCitib29sIEpTSFRNTEFsbENvbGxlY3Rpb246Omhhc0Z1 bmN0aW9uVHlwZSgpCit7CisgICAgQVNTRVJUX05PVF9SRUFDSEVEKCk7ICAvLyBKU0hUTUxBbGxD b2xsZWN0aW9uIG1hc3F1ZXJhZGVzIGFzIHVuZGVmaW5lZC4KKyAgICByZXR1cm4gZmFsc2U7Cit9 CisKIGJvb2wgSlNIVE1MQWxsQ29sbGVjdGlvbjo6Y2FuR2V0SXRlbXNGb3JOYW1lKEV4ZWNTdGF0 ZSosIEhUTUxBbGxDb2xsZWN0aW9uKiBjb2xsZWN0aW9uLCBjb25zdCBJZGVudGlmaWVyJiBwcm9w ZXJ0eU5hbWUpCiB7CiAgICAgVmVjdG9yPFJlZlB0cjxOb2RlPiA+IG5hbWVkSXRlbXM7CkluZGV4 OiBXZWJDb3JlL2JpbmRpbmdzL2pzL0pTSFRNTEFwcGxldEVsZW1lbnRDdXN0b20uY3BwCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIFdlYkNvcmUvYmluZGluZ3MvanMvSlNIVE1MQXBwbGV0RWxlbWVudEN1c3RvbS5j cHAJKHJldmlzaW9uIDY5NDE4KQorKysgV2ViQ29yZS9iaW5kaW5ncy9qcy9KU0hUTUxBcHBsZXRF bGVtZW50Q3VzdG9tLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNTMsNCArNTMsOSBAQCBDYWxsVHlw ZSBKU0hUTUxBcHBsZXRFbGVtZW50OjpnZXRDYWxsRGF0CiAgICAgcmV0dXJuIHJ1bnRpbWVPYmpl Y3RHZXRDYWxsRGF0YSh0aGlzLCBjYWxsRGF0YSk7CiB9CiAKK2Jvb2wgSlNIVE1MQXBwbGV0RWxl bWVudDo6aGFzRnVuY3Rpb25UeXBlKCkKK3sKKyAgICByZXR1cm4gZmFsc2U7Cit9CisKIH0gLy8g bmFtZXNwYWNlIFdlYkNvcmUKSW5kZXg6IFdlYkNvcmUvYmluZGluZ3MvanMvSlNIVE1MQ29sbGVj dGlvbkN1c3RvbS5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9iaW5kaW5ncy9qcy9KU0hUTUxD b2xsZWN0aW9uQ3VzdG9tLmNwcAkocmV2aXNpb24gNjk0MTgpCisrKyBXZWJDb3JlL2JpbmRpbmdz L2pzL0pTSFRNTENvbGxlY3Rpb25DdXN0b20uY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0xMDIsNiAr MTAyLDExIEBAIENhbGxUeXBlIEpTSFRNTENvbGxlY3Rpb246OmdldENhbGxEYXRhKEMKICAgICBy ZXR1cm4gQ2FsbFR5cGVIb3N0OwogfQogCitib29sIEpTSFRNTENvbGxlY3Rpb246Omhhc0Z1bmN0 aW9uVHlwZSgpCit7CisgICAgcmV0dXJuIGZhbHNlOworfQorCiBib29sIEpTSFRNTENvbGxlY3Rp b246OmNhbkdldEl0ZW1zRm9yTmFtZShFeGVjU3RhdGUqLCBIVE1MQ29sbGVjdGlvbiogY29sbGVj dGlvbiwgY29uc3QgSWRlbnRpZmllciYgcHJvcGVydHlOYW1lKQogewogICAgIFZlY3RvcjxSZWZQ dHI8Tm9kZT4gPiBuYW1lZEl0ZW1zOwpJbmRleDogV2ViQ29yZS9iaW5kaW5ncy9qcy9KU0hUTUxF bWJlZEVsZW1lbnRDdXN0b20uY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvYmluZGluZ3MvanMv SlNIVE1MRW1iZWRFbGVtZW50Q3VzdG9tLmNwcAkocmV2aXNpb24gNjk0MTgpCisrKyBXZWJDb3Jl L2JpbmRpbmdzL2pzL0pTSFRNTEVtYmVkRWxlbWVudEN1c3RvbS5jcHAJKHdvcmtpbmcgY29weSkK QEAgLTUzLDQgKzUzLDkgQEAgQ2FsbFR5cGUgSlNIVE1MRW1iZWRFbGVtZW50OjpnZXRDYWxsRGF0 YQogICAgIHJldHVybiBydW50aW1lT2JqZWN0R2V0Q2FsbERhdGEodGhpcywgY2FsbERhdGEpOwog fQogCitib29sIEpTSFRNTEVtYmVkRWxlbWVudDo6aGFzRnVuY3Rpb25UeXBlKCkKK3sKKyAgICBy ZXR1cm4gZmFsc2U7Cit9CisKIH0gLy8gbmFtZXNwYWNlIFdlYkNvcmUKSW5kZXg6IFdlYkNvcmUv YmluZGluZ3MvanMvSlNIVE1MT2JqZWN0RWxlbWVudEN1c3RvbS5jcHAKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g V2ViQ29yZS9iaW5kaW5ncy9qcy9KU0hUTUxPYmplY3RFbGVtZW50Q3VzdG9tLmNwcAkocmV2aXNp b24gNjk0MTgpCisrKyBXZWJDb3JlL2JpbmRpbmdzL2pzL0pTSFRNTE9iamVjdEVsZW1lbnRDdXN0 b20uY3BwCSh3b3JraW5nIGNvcHkpCkBAIC01Myw0ICs1Myw5IEBAIENhbGxUeXBlIEpTSFRNTE9i amVjdEVsZW1lbnQ6OmdldENhbGxEYXQKICAgICByZXR1cm4gcnVudGltZU9iamVjdEdldENhbGxE YXRhKHRoaXMsIGNhbGxEYXRhKTsKIH0KIAorYm9vbCBKU0hUTUxPYmplY3RFbGVtZW50OjpoYXNG dW5jdGlvblR5cGUoKQoreworICAgIHJldHVybiBmYWxzZTsKK30KKwogfSAvLyBuYW1lc3BhY2Ug V2ViQ29yZQpJbmRleDogV2ViQ29yZS9iaW5kaW5ncy9qcy9KU05vZGVMaXN0Q3VzdG9tLmNwcAo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBXZWJDb3JlL2JpbmRpbmdzL2pzL0pTTm9kZUxpc3RDdXN0b20uY3BwCShy ZXZpc2lvbiA2OTQxOCkKKysrIFdlYkNvcmUvYmluZGluZ3MvanMvSlNOb2RlTGlzdEN1c3RvbS5j cHAJKHdvcmtpbmcgY29weSkKQEAgLTUxLDYgKzUxLDExIEBAIENhbGxUeXBlIEpTTm9kZUxpc3Q6 OmdldENhbGxEYXRhKENhbGxEYXQKICAgICByZXR1cm4gQ2FsbFR5cGVIb3N0OwogfQogCitib29s IEpTTm9kZUxpc3Q6Omhhc0Z1bmN0aW9uVHlwZSgpCit7CisgICAgcmV0dXJuIGZhbHNlOworfQor CiBib29sIEpTTm9kZUxpc3Q6OmNhbkdldEl0ZW1zRm9yTmFtZShFeGVjU3RhdGUqLCBOb2RlTGlz dCogaW1wbCwgY29uc3QgSWRlbnRpZmllciYgcHJvcGVydHlOYW1lKQogewogICAgIHJldHVybiBp bXBsLT5pdGVtV2l0aE5hbWUoaWRlbnRpZmllclRvQXRvbWljU3RyaW5nKHByb3BlcnR5TmFtZSkp OwpJbmRleDogV2ViQ29yZS9iaW5kaW5ncy9zY3JpcHRzL0NvZGVHZW5lcmF0b3JKUy5wbQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBXZWJDb3JlL2JpbmRpbmdzL3NjcmlwdHMvQ29kZUdlbmVyYXRvckpTLnBtCShy ZXZpc2lvbiA2OTQxOCkKKysrIFdlYkNvcmUvYmluZGluZ3Mvc2NyaXB0cy9Db2RlR2VuZXJhdG9y SlMucG0JKHdvcmtpbmcgY29weSkKQEAgLTc3MCw3ICs3NzAsMTAgQEAgc3ViIEdlbmVyYXRlSGVh ZGVyCiAgICAgcHVzaChAaGVhZGVyQ29udGVudCwgIiAgICB2aXJ0dWFsIHZvaWQgcHVzaEV2ZW50 SGFuZGxlclNjb3BlKEpTQzo6RXhlY1N0YXRlKiwgSlNDOjpTY29wZUNoYWluJikgY29uc3Q7XG5c biIpIGlmICRkYXRhTm9kZS0+ZXh0ZW5kZWRBdHRyaWJ1dGVzLT57IkN1c3RvbVB1c2hFdmVudEhh bmRsZXJTY29wZSJ9OwogCiAgICAgIyBDdXN0b20gY2FsbCBmdW5jdGlvbnMKLSAgICBwdXNoKEBo ZWFkZXJDb250ZW50LCAiICAgIHZpcnR1YWwgSlNDOjpDYWxsVHlwZSBnZXRDYWxsRGF0YShKU0M6 OkNhbGxEYXRhJik7XG5cbiIpIGlmICRkYXRhTm9kZS0+ZXh0ZW5kZWRBdHRyaWJ1dGVzLT57IkN1 c3RvbUNhbGwifTsKKyAgICBpZiAoJGRhdGFOb2RlLT5leHRlbmRlZEF0dHJpYnV0ZXMtPnsiQ3Vz dG9tQ2FsbCJ9KSB7CisgICAgICAgIHB1c2goQGhlYWRlckNvbnRlbnQsICIgICAgdmlydHVhbCBK U0M6OkNhbGxUeXBlIGdldENhbGxEYXRhKEpTQzo6Q2FsbERhdGEmKTtcbiIpOworICAgICAgICBw dXNoKEBoZWFkZXJDb250ZW50LCAiICAgIHZpcnR1YWwgYm9vbCBoYXNGdW5jdGlvblR5cGUoKTtc blxuIik7CisgICAgfQogCiAgICAgIyBDdXN0b20gZGVsZXRlUHJvcGVydHkgZnVuY3Rpb24KICAg ICBwdXNoKEBoZWFkZXJDb250ZW50LCAiICAgIHZpcnR1YWwgYm9vbCBkZWxldGVQcm9wZXJ0eShK U0M6OkV4ZWNTdGF0ZSosIGNvbnN0IEpTQzo6SWRlbnRpZmllciYpO1xuIikgaWYgJGRhdGFOb2Rl LT5leHRlbmRlZEF0dHJpYnV0ZXMtPnsiQ3VzdG9tRGVsZXRlUHJvcGVydHkifTsK 70341 2010-10-08 22:13:07 -0700 2010-10-09 12:35:43 -0700 Patch bug-14547-20101008221306.patch text/plain 13749 abarth SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDY5NDQwKQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMjMgQEAKKzIwMTAtMTAtMDggIEFkYW0gQmFy dGggIDxhYmFydGhAd2Via2l0Lm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9P UFMhKS4KKworICAgICAgICB0eXBlb2YgZG9jdW1lbnQuYm9keS5jaGlsZE5vZGVzPT0iZnVuY3Rp b24iICgib2JqZWN0IiBleHBlY3RlZCkKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcv c2hvd19idWcuY2dpP2lkPTE0NTQ3CisKKyAgICAgICAgVGhpcyBwYXRjaCBhZGRzIGEgdmlydHVh bCBmdW5jdGlvbiB0byBKU0NlbGwgdG8gaW5kaWNhdGUgd2hldGhlciB0aGUKKyAgICAgICAgb2Jq ZWN0IHNob3VsZCBoYXZlIGEgdHlwZW9mICJmdW5jdGlvbiIgb3IgIm9iamVjdCIuICBQcmV2aW91 c2x5LCB3ZQorICAgICAgICB1c2VkIHdoZXRoZXIgdGhlIG9iamVjdCB3YXMgY2FsbGFibGUgYXMg YSBwcm94eSBmb3IgdGhpcyBiaXQsIGJ1dAorICAgICAgICB0aGF0J3Mgbm90IGNvcnJlY3QgZm9y IHNvbWUgRE9NIG9iamVjdHMgd2hpY2ggYXJlIGNhbGxhYmxlIGJ1dCBzdHVsbAorICAgICAgICBo YXZlIGEgdHlwZW9mICJvYmplY3QiLgorCisgICAgICAgICogSmF2YVNjcmlwdENvcmUuZXhwOgor ICAgICAgICAqIHJ1bnRpbWUvSlNDZWxsLmNwcDoKKyAgICAgICAgKEpTQzo6SlNDZWxsOjpoYXNG dW5jdGlvblR5cGUpOgorICAgICAgICAqIHJ1bnRpbWUvSlNDZWxsLmg6CisgICAgICAgICogcnVu dGltZS9PcGVyYXRpb25zLmNwcDoKKyAgICAgICAgKEpTQzo6anNUeXBlU3RyaW5nRm9yVmFsdWUp OgorCiAyMDEwLTEwLTA4ICBNaWNoYWVsIFNhYm9mZiAgPG1zYWJvZmZAYXBwbGUuY29tPgogCiAg ICAgICAgIFJldmlld2VkIGJ5IERhcmluIEFkbGVyLgpJbmRleDogSmF2YVNjcmlwdENvcmUvSmF2 YVNjcmlwdENvcmUuZXhwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIEphdmFTY3JpcHRDb3JlL0phdmFTY3JpcHRD b3JlLmV4cAkocmV2aXNpb24gNjk0MTgpCisrKyBKYXZhU2NyaXB0Q29yZS9KYXZhU2NyaXB0Q29y ZS5leHAJKHdvcmtpbmcgY29weSkKQEAgLTIyNSw2ICsyMjUsNyBAQCBfX1pOM0pTQzZKU0NlbGwx MWdldENhbGxEYXRhRVJOU184Q2FsbERhCiBfX1pOM0pTQzZKU0NlbGwxMWdldEpTTnVtYmVyRXYK IF9fWk4zSlNDNkpTQ2VsbDE0ZGVsZXRlUHJvcGVydHlFUE5TXzlFeGVjU3RhdGVFUktOU18xMElk ZW50aWZpZXJFCiBfX1pOM0pTQzZKU0NlbGwxNGRlbGV0ZVByb3BlcnR5RVBOU185RXhlY1N0YXRl RWoKK19fWk4zSlNDNkpTQ2VsbDE1aGFzRnVuY3Rpb25UeXBlRXYKIF9fWk4zSlNDNkpTQ2VsbDE2 Z2V0Q29uc3RydWN0RGF0YUVSTlNfMTNDb25zdHJ1Y3REYXRhRQogX19aTjNKU0M2SlNDZWxsMThn ZXRPd25Qcm9wZXJ0eVNsb3RFUE5TXzlFeGVjU3RhdGVFUktOU18xMElkZW50aWZpZXJFUk5TXzEy UHJvcGVydHlTbG90RQogX19aTjNKU0M2SlNDZWxsMThnZXRPd25Qcm9wZXJ0eVNsb3RFUE5TXzlF eGVjU3RhdGVFalJOU18xMlByb3BlcnR5U2xvdEUKSW5kZXg6IEphdmFTY3JpcHRDb3JlL3J1bnRp bWUvSlNDZWxsLmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0Q29yZS9ydW50aW1lL0pTQ2Vs bC5jcHAJKHJldmlzaW9uIDY5NDE4KQorKysgSmF2YVNjcmlwdENvcmUvcnVudGltZS9KU0NlbGwu Y3BwCSh3b3JraW5nIGNvcHkpCkBAIC0xMDksNiArMTA5LDEyIEBAIENhbGxUeXBlIEpTQ2VsbDo6 Z2V0Q2FsbERhdGEoQ2FsbERhdGEmKQogICAgIHJldHVybiBDYWxsVHlwZU5vbmU7CiB9CiAKK2Jv b2wgSlNDZWxsOjpoYXNGdW5jdGlvblR5cGUoKQoreworICAgIENhbGxEYXRhIGNhbGxEYXRhOwor ICAgIHJldHVybiBnZXRDYWxsRGF0YShjYWxsRGF0YSkgIT0gQ2FsbFR5cGVOb25lOworfQorCiBD b25zdHJ1Y3RUeXBlIEpTQ2VsbDo6Z2V0Q29uc3RydWN0RGF0YShDb25zdHJ1Y3REYXRhJikKIHsK ICAgICByZXR1cm4gQ29uc3RydWN0VHlwZU5vbmU7CkluZGV4OiBKYXZhU2NyaXB0Q29yZS9ydW50 aW1lL0pTQ2VsbC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIEphdmFTY3JpcHRDb3JlL3J1bnRpbWUvSlNDZWxs LmgJKHJldmlzaW9uIDY5NDE4KQorKysgSmF2YVNjcmlwdENvcmUvcnVudGltZS9KU0NlbGwuaAko d29ya2luZyBjb3B5KQpAQCAtOTIsOCArOTIsOSBAQCBuYW1lc3BhY2UgSlNDIHsKICAgICAgICAg VVN0cmluZyBnZXRTdHJpbmcoRXhlY1N0YXRlKiBleGVjKSBjb25zdDsgLy8gbnVsbCBzdHJpbmcg aWYgbm90IGEgc3RyaW5nCiAgICAgICAgIEpTT2JqZWN0KiBnZXRPYmplY3QoKTsgLy8gTlVMTCBp ZiBub3QgYW4gb2JqZWN0CiAgICAgICAgIGNvbnN0IEpTT2JqZWN0KiBnZXRPYmplY3QoKSBjb25z dDsgLy8gTlVMTCBpZiBub3QgYW4gb2JqZWN0Ci0gICAgICAgIAorCiAgICAgICAgIHZpcnR1YWwg Q2FsbFR5cGUgZ2V0Q2FsbERhdGEoQ2FsbERhdGEmKTsKKyAgICAgICAgdmlydHVhbCBib29sIGhh c0Z1bmN0aW9uVHlwZSgpOwogICAgICAgICB2aXJ0dWFsIENvbnN0cnVjdFR5cGUgZ2V0Q29uc3Ry dWN0RGF0YShDb25zdHJ1Y3REYXRhJik7CiAKICAgICAgICAgLy8gRXh0cmFjdGluZyBpbnRlZ2Vy IHZhbHVlcy4KSW5kZXg6IEphdmFTY3JpcHRDb3JlL3J1bnRpbWUvT3BlcmF0aW9ucy5jcHAKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gSmF2YVNjcmlwdENvcmUvcnVudGltZS9PcGVyYXRpb25zLmNwcAkocmV2aXNp b24gNjk0MTgpCisrKyBKYXZhU2NyaXB0Q29yZS9ydW50aW1lL09wZXJhdGlvbnMuY3BwCSh3b3Jr aW5nIGNvcHkpCkBAIC03Myw4ICs3Myw3IEBAIEpTVmFsdWUganNUeXBlU3RyaW5nRm9yVmFsdWUo Q2FsbEZyYW1lKiAKICAgICAgICAgLy8gYXMgbnVsbCB3aGVuIGRvaW5nIGNvbXBhcmlzb25zLgog ICAgICAgICBpZiAoYXNPYmplY3QodiktPnN0cnVjdHVyZSgpLT50eXBlSW5mbygpLm1hc3F1ZXJh ZGVzQXNVbmRlZmluZWQoKSkKICAgICAgICAgICAgIHJldHVybiBqc05vbnRyaXZpYWxTdHJpbmco Y2FsbEZyYW1lLCAidW5kZWZpbmVkIik7Ci0gICAgICAgIENhbGxEYXRhIGNhbGxEYXRhOwotICAg ICAgICBpZiAoYXNPYmplY3QodiktPmdldENhbGxEYXRhKGNhbGxEYXRhKSAhPSBDYWxsVHlwZU5v bmUpCisgICAgICAgIGlmIChhc09iamVjdCh2KS0+aGFzRnVuY3Rpb25UeXBlKCkpCiAgICAgICAg ICAgICByZXR1cm4ganNOb250cml2aWFsU3RyaW5nKGNhbGxGcmFtZSwgImZ1bmN0aW9uIik7CiAg ICAgfQogICAgIHJldHVybiBqc05vbnRyaXZpYWxTdHJpbmcoY2FsbEZyYW1lLCAib2JqZWN0Iik7 CkluZGV4OiBXZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL0NoYW5nZUxv ZwkocmV2aXNpb24gNjk0NDApCisrKyBXZWJDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpA QCAtMSwzICsxLDM0IEBACisyMDEwLTEwLTA4ICBBZGFtIEJhcnRoICA8YWJhcnRoQHdlYmtpdC5v cmc+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgdHlw ZW9mIGRvY3VtZW50LmJvZHkuY2hpbGROb2Rlcz09ImZ1bmN0aW9uIiAoIm9iamVjdCIgZXhwZWN0 ZWQpCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNDU0 NworCisgICAgICAgIElmIHRoZSBJREwgZm9yIGEgYmluZGluZyBkZWNsYXJlcyBDdXN0b21DYWxs LCB3ZSBub3cgbmVlZCB0byBkZWNpZGUKKyAgICAgICAgZXhwbGljaXRseSB3aGV0aGVyIHRoZSBv YmplY3QgaGFzIGEgdHlwZW9mICJmdW5jdGlvbiIgb3IgIm9iamVjdCIuICBJbgorICAgICAgICBh bGwgdGhlIGV4YW1wbGVzIHdlIGhhdmUgdGh1cyBmYXIsIHRoZSBhbnN3ZXIgaXMgIm9iamVjdCIu ICBJCisgICAgICAgIGNvbnNpZGVyZWQgaGF2aW5nIHRoZSBjb2RlIGdlbmVyYXRvciBnZW5lcmF0 ZSBjb2RlIGZvciB0aGF0IGJlaGF2aW9yCisgICAgICAgIGF1dG9tYXRpY2FsbHksIGJ1dCB0aGlz IHNpdHV0YXRpb24gc2VlbXMgc3VmZmljaWVudGx5IHJhcmUgdGhhdCBpdCdzCisgICAgICAgIHdv cnRoIHRoaW5raW5nIGFib3V0IGV4cGxpY2l0bHkgd2hlbiBpdCBjb21lcyB1cC4KKworICAgICAg ICBUZXN0OiBmYXN0L2RvbS90eXBlb2YtY3VzdG9tY2FsbC5odG1sCisKKyAgICAgICAgKiBXZWJD b3JlLnhjb2RlcHJvai9wcm9qZWN0LnBieHByb2o6CisgICAgICAgICogYmluZGluZ3MvanMvSlNI VE1MQWxsQ29sbGVjdGlvbkN1c3RvbS5jcHA6CisgICAgICAgIChXZWJDb3JlOjpKU0hUTUxBbGxD b2xsZWN0aW9uOjpoYXNGdW5jdGlvblR5cGUpOgorICAgICAgICAqIGJpbmRpbmdzL2pzL0pTSFRN TEFwcGxldEVsZW1lbnRDdXN0b20uY3BwOgorICAgICAgICAoV2ViQ29yZTo6SlNIVE1MQXBwbGV0 RWxlbWVudDo6aGFzRnVuY3Rpb25UeXBlKToKKyAgICAgICAgKiBiaW5kaW5ncy9qcy9KU0hUTUxD b2xsZWN0aW9uQ3VzdG9tLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkpTSFRNTENvbGxlY3Rpb246 Omhhc0Z1bmN0aW9uVHlwZSk6CisgICAgICAgICogYmluZGluZ3MvanMvSlNIVE1MRW1iZWRFbGVt ZW50Q3VzdG9tLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkpTSFRNTEVtYmVkRWxlbWVudDo6aGFz RnVuY3Rpb25UeXBlKToKKyAgICAgICAgKiBiaW5kaW5ncy9qcy9KU0hUTUxPYmplY3RFbGVtZW50 Q3VzdG9tLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkpTSFRNTE9iamVjdEVsZW1lbnQ6Omhhc0Z1 bmN0aW9uVHlwZSk6CisgICAgICAgICogYmluZGluZ3MvanMvSlNOb2RlTGlzdEN1c3RvbS5jcHA6 CisgICAgICAgIChXZWJDb3JlOjpKU05vZGVMaXN0OjpoYXNGdW5jdGlvblR5cGUpOgorICAgICAg ICAqIGJpbmRpbmdzL3NjcmlwdHMvQ29kZUdlbmVyYXRvckpTLnBtOgorCiAyMDEwLTEwLTA4ICBD aHJpcyBSb2dlcnMgIDxjcm9nZXJzQGdvb2dsZS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkg SmFtZXMgUm9iaW5zb24uCkluZGV4OiBXZWJDb3JlL2JpbmRpbmdzL2pzL0pTSFRNTEFsbENvbGxl Y3Rpb25DdXN0b20uY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvYmluZGluZ3MvanMvSlNIVE1M QWxsQ29sbGVjdGlvbkN1c3RvbS5jcHAJKHJldmlzaW9uIDY5NDE4KQorKysgV2ViQ29yZS9iaW5k aW5ncy9qcy9KU0hUTUxBbGxDb2xsZWN0aW9uQ3VzdG9tLmNwcAkod29ya2luZyBjb3B5KQpAQCAt MTA2LDYgKzEwNiwxMiBAQCBDYWxsVHlwZSBKU0hUTUxBbGxDb2xsZWN0aW9uOjpnZXRDYWxsRGF0 CiAgICAgcmV0dXJuIENhbGxUeXBlSG9zdDsKIH0KIAorYm9vbCBKU0hUTUxBbGxDb2xsZWN0aW9u OjpoYXNGdW5jdGlvblR5cGUoKQoreworICAgIEFTU0VSVF9OT1RfUkVBQ0hFRCgpOyAvLyBKU0hU TUxBbGxDb2xsZWN0aW9uIG1hc3F1ZXJhZGVzIGFzIHVuZGVmaW5lZC4KKyAgICByZXR1cm4gZmFs c2U7Cit9CisKIGJvb2wgSlNIVE1MQWxsQ29sbGVjdGlvbjo6Y2FuR2V0SXRlbXNGb3JOYW1lKEV4 ZWNTdGF0ZSosIEhUTUxBbGxDb2xsZWN0aW9uKiBjb2xsZWN0aW9uLCBjb25zdCBJZGVudGlmaWVy JiBwcm9wZXJ0eU5hbWUpCiB7CiAgICAgVmVjdG9yPFJlZlB0cjxOb2RlPiA+IG5hbWVkSXRlbXM7 CkluZGV4OiBXZWJDb3JlL2JpbmRpbmdzL2pzL0pTSFRNTEFwcGxldEVsZW1lbnRDdXN0b20uY3Bw Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIFdlYkNvcmUvYmluZGluZ3MvanMvSlNIVE1MQXBwbGV0RWxlbWVudEN1 c3RvbS5jcHAJKHJldmlzaW9uIDY5NDE4KQorKysgV2ViQ29yZS9iaW5kaW5ncy9qcy9KU0hUTUxB cHBsZXRFbGVtZW50Q3VzdG9tLmNwcAkod29ya2luZyBjb3B5KQpAQCAtNTMsNCArNTMsOSBAQCBD YWxsVHlwZSBKU0hUTUxBcHBsZXRFbGVtZW50OjpnZXRDYWxsRGF0CiAgICAgcmV0dXJuIHJ1bnRp bWVPYmplY3RHZXRDYWxsRGF0YSh0aGlzLCBjYWxsRGF0YSk7CiB9CiAKK2Jvb2wgSlNIVE1MQXBw bGV0RWxlbWVudDo6aGFzRnVuY3Rpb25UeXBlKCkKK3sKKyAgICByZXR1cm4gZmFsc2U7Cit9CisK IH0gLy8gbmFtZXNwYWNlIFdlYkNvcmUKSW5kZXg6IFdlYkNvcmUvYmluZGluZ3MvanMvSlNIVE1M Q29sbGVjdGlvbkN1c3RvbS5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9iaW5kaW5ncy9qcy9K U0hUTUxDb2xsZWN0aW9uQ3VzdG9tLmNwcAkocmV2aXNpb24gNjk0MTgpCisrKyBXZWJDb3JlL2Jp bmRpbmdzL2pzL0pTSFRNTENvbGxlY3Rpb25DdXN0b20uY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0x MDIsNiArMTAyLDExIEBAIENhbGxUeXBlIEpTSFRNTENvbGxlY3Rpb246OmdldENhbGxEYXRhKEMK ICAgICByZXR1cm4gQ2FsbFR5cGVIb3N0OwogfQogCitib29sIEpTSFRNTENvbGxlY3Rpb246Omhh c0Z1bmN0aW9uVHlwZSgpCit7CisgICAgcmV0dXJuIGZhbHNlOworfQorCiBib29sIEpTSFRNTENv bGxlY3Rpb246OmNhbkdldEl0ZW1zRm9yTmFtZShFeGVjU3RhdGUqLCBIVE1MQ29sbGVjdGlvbiog Y29sbGVjdGlvbiwgY29uc3QgSWRlbnRpZmllciYgcHJvcGVydHlOYW1lKQogewogICAgIFZlY3Rv cjxSZWZQdHI8Tm9kZT4gPiBuYW1lZEl0ZW1zOwpJbmRleDogV2ViQ29yZS9iaW5kaW5ncy9qcy9K U0hUTUxFbWJlZEVsZW1lbnRDdXN0b20uY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvYmluZGlu Z3MvanMvSlNIVE1MRW1iZWRFbGVtZW50Q3VzdG9tLmNwcAkocmV2aXNpb24gNjk0MTgpCisrKyBX ZWJDb3JlL2JpbmRpbmdzL2pzL0pTSFRNTEVtYmVkRWxlbWVudEN1c3RvbS5jcHAJKHdvcmtpbmcg Y29weSkKQEAgLTUzLDQgKzUzLDkgQEAgQ2FsbFR5cGUgSlNIVE1MRW1iZWRFbGVtZW50OjpnZXRD YWxsRGF0YQogICAgIHJldHVybiBydW50aW1lT2JqZWN0R2V0Q2FsbERhdGEodGhpcywgY2FsbERh dGEpOwogfQogCitib29sIEpTSFRNTEVtYmVkRWxlbWVudDo6aGFzRnVuY3Rpb25UeXBlKCkKK3sK KyAgICByZXR1cm4gZmFsc2U7Cit9CisKIH0gLy8gbmFtZXNwYWNlIFdlYkNvcmUKSW5kZXg6IFdl YkNvcmUvYmluZGluZ3MvanMvSlNIVE1MT2JqZWN0RWxlbWVudEN1c3RvbS5jcHAKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gV2ViQ29yZS9iaW5kaW5ncy9qcy9KU0hUTUxPYmplY3RFbGVtZW50Q3VzdG9tLmNwcAko cmV2aXNpb24gNjk0MTgpCisrKyBXZWJDb3JlL2JpbmRpbmdzL2pzL0pTSFRNTE9iamVjdEVsZW1l bnRDdXN0b20uY3BwCSh3b3JraW5nIGNvcHkpCkBAIC01Myw0ICs1Myw5IEBAIENhbGxUeXBlIEpT SFRNTE9iamVjdEVsZW1lbnQ6OmdldENhbGxEYXQKICAgICByZXR1cm4gcnVudGltZU9iamVjdEdl dENhbGxEYXRhKHRoaXMsIGNhbGxEYXRhKTsKIH0KIAorYm9vbCBKU0hUTUxPYmplY3RFbGVtZW50 OjpoYXNGdW5jdGlvblR5cGUoKQoreworICAgIHJldHVybiBmYWxzZTsKK30KKwogfSAvLyBuYW1l c3BhY2UgV2ViQ29yZQpJbmRleDogV2ViQ29yZS9iaW5kaW5ncy9qcy9KU05vZGVMaXN0Q3VzdG9t LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2JpbmRpbmdzL2pzL0pTTm9kZUxpc3RDdXN0b20u Y3BwCShyZXZpc2lvbiA2OTQxOCkKKysrIFdlYkNvcmUvYmluZGluZ3MvanMvSlNOb2RlTGlzdEN1 c3RvbS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTUxLDYgKzUxLDExIEBAIENhbGxUeXBlIEpTTm9k ZUxpc3Q6OmdldENhbGxEYXRhKENhbGxEYXQKICAgICByZXR1cm4gQ2FsbFR5cGVIb3N0OwogfQog Citib29sIEpTTm9kZUxpc3Q6Omhhc0Z1bmN0aW9uVHlwZSgpCit7CisgICAgcmV0dXJuIGZhbHNl OworfQorCiBib29sIEpTTm9kZUxpc3Q6OmNhbkdldEl0ZW1zRm9yTmFtZShFeGVjU3RhdGUqLCBO b2RlTGlzdCogaW1wbCwgY29uc3QgSWRlbnRpZmllciYgcHJvcGVydHlOYW1lKQogewogICAgIHJl dHVybiBpbXBsLT5pdGVtV2l0aE5hbWUoaWRlbnRpZmllclRvQXRvbWljU3RyaW5nKHByb3BlcnR5 TmFtZSkpOwpJbmRleDogV2ViQ29yZS9iaW5kaW5ncy9zY3JpcHRzL0NvZGVHZW5lcmF0b3JKUy5w bQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL2JpbmRpbmdzL3NjcmlwdHMvQ29kZUdlbmVyYXRvckpT LnBtCShyZXZpc2lvbiA2OTQxOCkKKysrIFdlYkNvcmUvYmluZGluZ3Mvc2NyaXB0cy9Db2RlR2Vu ZXJhdG9ySlMucG0JKHdvcmtpbmcgY29weSkKQEAgLTc3MCw3ICs3NzAsMTAgQEAgc3ViIEdlbmVy YXRlSGVhZGVyCiAgICAgcHVzaChAaGVhZGVyQ29udGVudCwgIiAgICB2aXJ0dWFsIHZvaWQgcHVz aEV2ZW50SGFuZGxlclNjb3BlKEpTQzo6RXhlY1N0YXRlKiwgSlNDOjpTY29wZUNoYWluJikgY29u c3Q7XG5cbiIpIGlmICRkYXRhTm9kZS0+ZXh0ZW5kZWRBdHRyaWJ1dGVzLT57IkN1c3RvbVB1c2hF dmVudEhhbmRsZXJTY29wZSJ9OwogCiAgICAgIyBDdXN0b20gY2FsbCBmdW5jdGlvbnMKLSAgICBw dXNoKEBoZWFkZXJDb250ZW50LCAiICAgIHZpcnR1YWwgSlNDOjpDYWxsVHlwZSBnZXRDYWxsRGF0 YShKU0M6OkNhbGxEYXRhJik7XG5cbiIpIGlmICRkYXRhTm9kZS0+ZXh0ZW5kZWRBdHRyaWJ1dGVz LT57IkN1c3RvbUNhbGwifTsKKyAgICBpZiAoJGRhdGFOb2RlLT5leHRlbmRlZEF0dHJpYnV0ZXMt PnsiQ3VzdG9tQ2FsbCJ9KSB7CisgICAgICAgIHB1c2goQGhlYWRlckNvbnRlbnQsICIgICAgdmly dHVhbCBKU0M6OkNhbGxUeXBlIGdldENhbGxEYXRhKEpTQzo6Q2FsbERhdGEmKTtcbiIpOworICAg ICAgICBwdXNoKEBoZWFkZXJDb250ZW50LCAiICAgIHZpcnR1YWwgYm9vbCBoYXNGdW5jdGlvblR5 cGUoKTtcblxuIik7CisgICAgfQogCiAgICAgIyBDdXN0b20gZGVsZXRlUHJvcGVydHkgZnVuY3Rp b24KICAgICBwdXNoKEBoZWFkZXJDb250ZW50LCAiICAgIHZpcnR1YWwgYm9vbCBkZWxldGVQcm9w ZXJ0eShKU0M6OkV4ZWNTdGF0ZSosIGNvbnN0IEpTQzo6SWRlbnRpZmllciYpO1xuIikgaWYgJGRh dGFOb2RlLT5leHRlbmRlZEF0dHJpYnV0ZXMtPnsiQ3VzdG9tRGVsZXRlUHJvcGVydHkifTsKSW5k ZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9DaGFu Z2VMb2cJKHJldmlzaW9uIDY5NDQwKQorKysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3JraW5n IGNvcHkpCkBAIC0xLDMgKzEsMjEgQEAKKzIwMTAtMTAtMDggIEFkYW0gQmFydGggIDxhYmFydGhA d2Via2l0Lm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAg ICAgICB0eXBlb2YgZG9jdW1lbnQuYm9keS5jaGlsZE5vZGVzPT0iZnVuY3Rpb24iICgib2JqZWN0 IiBleHBlY3RlZCkKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp P2lkPTE0NTQ3CisKKyAgICAgICAgVGVzdCB0aGUgdHlwZW9mIGZvciB2YXJpb3VzIG9iamVjdHMg d2l0aCBDdXN0b21DYWxsLgorCisgICAgICAgICogZmFzdC9kb20vdHlwZW9mLWN1c3RvbWNhbGwt ZXhwZWN0ZWQudHh0OiBBZGRlZC4KKyAgICAgICAgKiBmYXN0L2RvbS90eXBlb2YtY3VzdG9tY2Fs bC5odG1sOiBBZGRlZC4KKyAgICAgICAgKiBwbHVnaW5zL25wcnVudGltZS9wbHVnaW4tc2NyaXB0 YWJsZS1vYmplY3QtaW52b2tlLWRlZmF1bHQtZXhwZWN0ZWQudHh0OgorICAgICAgICAqIHBsdWdp bnMvbnBydW50aW1lL3BsdWdpbi1zY3JpcHRhYmxlLW9iamVjdC1pbnZva2UtZGVmYXVsdC5odG1s OgorICAgICAgICAgICAgLSBUaGlzIG5ldyBleHBlY3RlZCByZXN1bHQgbWF0Y2hlcyBDaHJvbWUg YW5kIE9wZXJhLCBidXQgaXMKKyAgICAgICAgICAgICAgZGlmZmVyZW50IHRoYW4gRmlyZWZveC4g IEkgaGF2ZW4ndCB0ZXN0ZWQgSUUuICBCZWxpZXZlIHRoZSBuZXcKKyAgICAgICAgICAgICAgYmVo YXZpb3IgaXMgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlIHNwZWNpZmljYXRpb24gYW5kCisgICAg ICAgICAgICAgIHNlbnNpYmlsaXR5LgorCiAyMDEwLTEwLTA4ICBNYXJ0aW4gUm9iaW5zb24gIDxt cm9iaW5zb25AaWdhbGlhLmNvbT4KIAogICAgICAgICBTa2lwIG1vcmUgdGVzdHMgd2hpY2ggc2hv dyBkaWZmZXJlbmNlcyBiZXR3ZWVuIGkzODYgYW5kIHg4Nl82NC4gQWxzbwpJbmRleDogTGF5b3V0 VGVzdHMvZmFzdC9kb20vdHlwZW9mLWN1c3RvbWNhbGwtZXhwZWN0ZWQudHh0Cj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIExheW91dFRlc3RzL2Zhc3QvZG9tL3R5cGVvZi1jdXN0b21jYWxsLWV4cGVjdGVkLnR4dAko cmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL2Zhc3QvZG9tL3R5cGVvZi1jdXN0b21jYWxsLWV4 cGVjdGVkLnR4dAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw4IEBACit0eXBlb2YgZG9jdW1lbnQu YWxsID0+IHVuZGVmaW5lZAordHlwZW9mIGRvY3VtZW50LmltYWdlcyA9PiBvYmplY3QKK3R5cGVv ZiBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgicHJlIikgPT4gb2JqZWN0Cit0eXBlb2Yg ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgiYXBwbGV0IikgPT4gb2JqZWN0Cit0eXBlb2YgZG9jdW1l bnQuY3JlYXRlRWxlbWVudCgiZW1iZWQiKSA9PiBvYmplY3QKK3R5cGVvZiBkb2N1bWVudC5jcmVh dGVFbGVtZW50KCJvYmplY3QiKSA9PiBvYmplY3QKKworCkluZGV4OiBMYXlvdXRUZXN0cy9mYXN0 L2RvbS90eXBlb2YtY3VzdG9tY2FsbC5odG1sCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL2Zh c3QvZG9tL3R5cGVvZi1jdXN0b21jYWxsLmh0bWwJKHJldmlzaW9uIDApCisrKyBMYXlvdXRUZXN0 cy9mYXN0L2RvbS90eXBlb2YtY3VzdG9tY2FsbC5odG1sCShyZXZpc2lvbiAwKQpAQCAtMCwwICsx LDE5IEBACis8cHJlPgorPHNjcmlwdD4KK2lmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIp CisgICAgbGF5b3V0VGVzdENvbnRyb2xsZXIuZHVtcEFzVGV4dCgpOworCitmdW5jdGlvbiB0ZXN0 KGV4cHJlc3Npb24pIHsKKyAgICBkb2N1bWVudC53cml0ZShleHByZXNzaW9uKTsKKyAgICBkb2N1 bWVudC53cml0ZSgnID0+ICcpOworICAgIGRvY3VtZW50LndyaXRlbG4oZXZhbChleHByZXNzaW9u KSk7Cit9CisKK3Rlc3QoJ3R5cGVvZiBkb2N1bWVudC5hbGwnKTsKK3Rlc3QoJ3R5cGVvZiBkb2N1 bWVudC5pbWFnZXMnKTsKK3Rlc3QoJ3R5cGVvZiBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFt ZSgicHJlIiknKTsKK3Rlc3QoJ3R5cGVvZiBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJhcHBsZXQi KScpOwordGVzdCgndHlwZW9mIGRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoImVtYmVkIiknKTsKK3Rl c3QoJ3R5cGVvZiBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJvYmplY3QiKScpOworPC9zY3JpcHQ+ Cis8L3ByZT4KSW5kZXg6IExheW91dFRlc3RzL3BsdWdpbnMvbnBydW50aW1lL3BsdWdpbi1zY3Jp cHRhYmxlLW9iamVjdC1pbnZva2UtZGVmYXVsdC1leHBlY3RlZC50eHQKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g TGF5b3V0VGVzdHMvcGx1Z2lucy9ucHJ1bnRpbWUvcGx1Z2luLXNjcmlwdGFibGUtb2JqZWN0LWlu dm9rZS1kZWZhdWx0LWV4cGVjdGVkLnR4dAkocmV2aXNpb24gNjk0MTgpCisrKyBMYXlvdXRUZXN0 cy9wbHVnaW5zL25wcnVudGltZS9wbHVnaW4tc2NyaXB0YWJsZS1vYmplY3QtaW52b2tlLWRlZmF1 bHQtZXhwZWN0ZWQudHh0CSh3b3JraW5nIGNvcHkpCkBAIC00LDcgKzQsNyBAQCBUaGlzIHBhZ2Ug dGVzdHMgaW52b2tpbmcgYXMgZnVuY3Rpb25zIEphCiBPbiBzdWNjZXNzLCB5b3Ugd2lsbCBzZWUg YSBzZXJpZXMgb2YgIlBBU1MiIG1lc3NhZ2VzLCBmb2xsb3dlZCBieSAiVEVTVCBDT01QTEVURSIu CiAKIAotUEFTUyB0eXBlb2YocGx1Z2luV2l0aEludm9rZURlZmF1bHQpIGlzICdmdW5jdGlvbicK K1BBU1MgdHlwZW9mKHBsdWdpbldpdGhJbnZva2VEZWZhdWx0KSBpcyAnb2JqZWN0JwogUEFTUyBw bHVnaW5XaXRoSW52b2tlRGVmYXVsdCgpIGlzIDEKIFBBU1MgdHlwZW9mKHBsdWdpbldpdGhvdXRJ bnZva2VEZWZhdWx0KSBpcyAnb2JqZWN0JwogUEFTUyBwbHVnaW5XaXRob3V0SW52b2tlRGVmYXVs dCgpIHRocmV3IGV4Y2VwdGlvbiBUeXBlRXJyb3I6IFJlc3VsdCBvZiBleHByZXNzaW9uICdwbHVn aW5XaXRob3V0SW52b2tlRGVmYXVsdCcgW1tvYmplY3QgSFRNTEVtYmVkRWxlbWVudF1dIGlzIG5v dCBhIGZ1bmN0aW9uLi4KSW5kZXg6IExheW91dFRlc3RzL3BsdWdpbnMvbnBydW50aW1lL3BsdWdp bi1zY3JpcHRhYmxlLW9iamVjdC1pbnZva2UtZGVmYXVsdC5odG1sCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExh eW91dFRlc3RzL3BsdWdpbnMvbnBydW50aW1lL3BsdWdpbi1zY3JpcHRhYmxlLW9iamVjdC1pbnZv a2UtZGVmYXVsdC5odG1sCShyZXZpc2lvbiA2OTQxOCkKKysrIExheW91dFRlc3RzL3BsdWdpbnMv bnBydW50aW1lL3BsdWdpbi1zY3JpcHRhYmxlLW9iamVjdC1pbnZva2UtZGVmYXVsdC5odG1sCSh3 b3JraW5nIGNvcHkpCkBAIC0xNCw3ICsxNCw3IEBAIGZ1bmN0aW9uIGRvVGVzdCgpCiAKICAgICBw bHVnaW5XaXRoSW52b2tlRGVmYXVsdCA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdwbHVnaW4t d2l0aC1pbnZva2UtZGVmYXVsdCcpOwogICAgIAotICAgIHNob3VsZEJlKCJ0eXBlb2YocGx1Z2lu V2l0aEludm9rZURlZmF1bHQpIiwgIidmdW5jdGlvbiciKTsKKyAgICBzaG91bGRCZSgidHlwZW9m KHBsdWdpbldpdGhJbnZva2VEZWZhdWx0KSIsICInb2JqZWN0JyIpOwogICAgIHNob3VsZEJlKCJw bHVnaW5XaXRoSW52b2tlRGVmYXVsdCgpIiwgIjEiKQogCiAgICAgcGx1Z2luV2l0aG91dEludm9r ZURlZmF1bHQgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgncGx1Z2luLXdpdGhvdXQtaW52b2tl LWRlZmF1bHQnKTsK