What's the intention of TreeBoxObject.webidl and its partners?
I found it's duplicated with nsITreeBoxObject.idl and it's partners. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Components.returnCode not working as expected.
In bug 1100069, bz suggested I look at using Components.returnCode so a JS component called by c++ can return failure without having an exception logged. However, this isn't working as I expect. Further, the few uses of this in the tree also don't seem to work as expected. SessionStore.js uses the pattern: throw (Components.returnCode = Cr.NS_ERROR_INVALID_ARG); If we trace through XPCWrappedJSClass.cpp, we see that this is treated as a "normal" failure, so end up in CheckForException(). The fact we are throwing an integer *does* mean the rv ends up as NS_ERROR_INVALID_ARG - but at no point is Components.returnCode used as a special case (ie, things work identically without setting .returnCode). CheckForException() ends up with both a "js exception" and an "xpc exception", ends up calling JS_ReportPendingException() which still reports the error. However, if instead of throwing an integer we do something like: Components.returnCode = NS_ERROR_INVALID_ARG; return; (ie, set Components.returnCode and return without throwing) then we *also* don't get the expected behaviour - we end up at http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCWrappedJSClass.cpp#1405, which is: 1405 // set to whatever the JS code might have set as the result 1406 retval = pending_result; So the comment implies this is where the magic should happen, but pending_result hasn't been updated - it's still NS_OK which is what it was initialized to at the start of that function. If I change that line to: retval = xpcc->GetPendingResult(); It works as expected. So I guess I have 2 questions: * Is Components.returnCode expected to be used when the code throws (as SessionStore.jsm does) or when the code returns without an exception? (Or maybe both?) * If it is supposed to be used with a normal return, is the change so GetPendingResult() is called the correct approach to take? (ie, should I open a bug with that as the patch?) Thanks, Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Array.prototype.includes available in Nightly *only* & String.prototype.contains renamed to includes
On Fri, Nov 21, 2014 at 11:55 PM, Jonas Sicking wrote: > Has TC39 discussed how to handle the fact that there are a couple of > classes in the DOM, like DOMStringList, which we'd like to replace > with normal JS Arrays. But these DOM classes have a .contains function > which so far has meant that such a switch was not possible due to the > arrays not having a .contains. > I don't know if that aspect has been discussed, though I suspect it might not have been in any depth. > > I had hoped that once Arrays got a .contains function that we could > make this switch. > Switching those classes to JS Arrays would only work if it were web-compatible which, sadly, Array#contains doesn't seem to be. > > Does TC39 recommend that we stick with returning DOM objects here and > not switch to Arrays? Or that we do something else? > I don't know :/. Perhaps Jason does? > > / Jonas > > On Fri, Nov 21, 2014 at 5:10 AM, Till Schneidereit > wrote: > > Greetings! > > > > TC39 has decided to solve the web-compat issues with > > Array.prototype.contains that forced us to back out the feature on > October > > 1st by renaming the method to "includes". This has now landed on Nightly. > > However, it is Nightly-only for now, so don't use it in production code > > that's intended to make the merge to Developer's Edition. > > > > In further news and for similar reasons, String.prototype.contains will > be > > renamed to "includes" as well. This is somewhat unfortunate as we've been > > shipping String.prototype.contains since Firefox 18. To work around that, > > it'll probably be necessary to keep contains as an alias for a while, > > ideally with a warning logged to the console. The rename is tracked in > bug > > 1102219. > > > > thank you, > > till > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
