Re: Memory management in features implemented in JS
On 20/03/2014 02:25, Boris Zbarsky wrote: On 3/19/14 9:41 PM, Justin Dolske wrote: It uses a weak reference with the observer service, plus a dummy strong reference (via addEventListener()) to automatically manage the lifetime... When the node/document does away, so does the event listener. This is sort of ok for notifications that fire a lot, but for notifications that fire rarely, or never, this effectively leaks a word of memory in the observer service. And then they all get touched at shudown. We've had bugs with hundreds of thousands of dead weak observers all hanging out in the observer service making shutdown take minutes. :( For cases like the one linked to there, it really would be good to have a better option than dealing with the observer service... -Boris So the observer service takes a flag that indicates whether it should hold a weak ref. Can we make that flag trigger periodic 'alive' checks which clear out the dead weakrefs (or, still better, a subclass of whatever weak reference class is used, that gets notified if its target is GC'd and immediately removes itself)? Is that a dumb/impossible idea? I honestly don't know! :-) ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Memory management in features implemented in JS
So basically, you want to add a finalizer for JS component? Note that we already have a weak (post-mortem) finalization module for JS, hidden somewhere in mozilla-central. It's not meant to be used for performance critical code, and it provides no guarantees about cycles, but if this is necessary, I could rework it in something a bit faster/more robust. Cheers, David On 3/20/14 1:25 AM, smaug wrote: And we could add a flag to WrappedJS so that it would call some callback when it is about to go away. That would let cleanup of WeakPromise happen asap. Basically keep a hashtable wrappedjs - objects_implementing_callback_interface_foo. Then when adding an object to the hashtable, wrappedjs would get marked with a flag, that it should look at the hashtable when it is going away, and if there is value in the hashtable, call the foo. This cleanup mechanism could be used with weak observers and weak listeners too. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Memory management in features implemented in JS
On 03/20/2014 12:37 PM, David Rajchenbach-Teller wrote: So basically, you want to add a finalizer for JS component? No. It would be callback to tell when the thing (wrappedJS) we have a weakref to is going away. And wrappedJS keeps then a weak ref to the JS object. As far as I see, this would be trivial to implement, at least if we don't mind adding a word to nsXPCWrappedJS. If we do mind, then some tricks need to be done. Also, this all could be done outside JS engine, so the native services wouldn't need to start care about JS API. (Looks like the current nsXPCWrappedJS fits just perfectly into jemalloc's 112 bucket on 64bit, but on 32bit case we have room for an extra word) Note that we already have a weak (post-mortem) finalization module for JS, hidden somewhere in mozilla-central. It's not meant to be used for performance critical code, and it provides no guarantees about cycles, but if this is necessary, I could rework it in something a bit faster/more robust. Cheers, David On 3/20/14 1:25 AM, smaug wrote: And we could add a flag to WrappedJS so that it would call some callback when it is about to go away. That would let cleanup of WeakPromise happen asap. Basically keep a hashtable wrappedjs - objects_implementing_callback_interface_foo. Then when adding an object to the hashtable, wrappedjs would get marked with a flag, that it should look at the hashtable when it is going away, and if there is value in the hashtable, call the foo. This cleanup mechanism could be used with weak observers and weak listeners too. -Olli ___ 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
Re: DXR gets multi-line highlighting
Note that for this, analysis of the tip of each of -release, -beta, -aurora and -esr* would be enough. That's significantly more than just doing -central, but it's also significantly less than doing every single revision. That is planned! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: CSS.escape
CSS.escape is an API defined at
http://dev.w3.org/csswg/cssom/#the-css.escape%28%29-method which allows
web pages to create a valid CSS identifier that will parse to a given
string. A typical use case is:
document.querySelector('#' + CSS.escape(stringIDontControl))
Unless there are objections, I'm going to check this in without a
preference, for Firefox 31. The spec for this is very straightforward
and not likely to change, apart from the feature disappearing altogether
or something. But I think this feature is pretty much necessary in some
form, whether built into the platform or as a library, to safely use
querySelector-like APIs with non-literal strings.
Bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=955860
Please let me know if there are objections.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS.escape
On Thu, Mar 20, 2014 at 3:17 PM, Boris Zbarsky bzbar...@mit.edu wrote:
http://dev.w3.org/csswg/cssom/#the-css.escape%28%29-method which allows web
pages to create a valid CSS identifier that will parse to a given string. A
typical use case is:
document.querySelector('#' + CSS.escape(stringIDontControl))
Unless there are objections, I'm going to check this in without a
preference, for Firefox 31. The spec for this is very straightforward and
not likely to change, apart from the feature disappearing altogether or
something. But I think this feature is pretty much necessary in some form,
whether built into the platform or as a library, to safely use
querySelector-like APIs with non-literal strings.
Bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=955860
Please let me know if there are objections.
Seems fine, specification should probably clarify surrogate handling.
I would expect a paired surrogate in JavaScript to end up as a single
escape.
--
http://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Should nsIPrefBranch.set*Pref return NS_ERROR_UNEXPECTED on type mismatch?
Looking into some odd exceptions in the Addon Manager (bug 985998), I found that the behaviour of the Preference service is: a) We infer the type of a preference from the data read in from prefs.js (see e.g. http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefread.cpp#288) b) When we try to get or set the pref, we return NS_ERROR_UNEXPECTED if the type of the set*Pref() call doesn't match the inferred type (http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefapi.cpp#764) For unknown reasons, internal bookkeeping prefs used by AddonManager and XPIProvider are set to values of the wrong type on some Firefox profiles, and are now stuck that way. I can write wrapper code on these calls to catch the error and clear the broken preference, but I wonder if it would be better to change set*Pref() to force the preference to the intended type. In a way we're dancing around competing footguns here - do we protect against bad code trying to break our preferences by setting a value to the wrong type, or do we protect against a broken preference messing up our code because we can't recover from a wrong type? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should nsIPrefBranch.set*Pref return NS_ERROR_UNEXPECTED on type mismatch?
On 3/20/14, 10:38 AM, Irving Reid wrote: Looking into some odd exceptions in the Addon Manager (bug 985998), I found that the behaviour of the Preference service is: a) We infer the type of a preference from the data read in from prefs.js (see e.g. http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefread.cpp#288) b) When we try to get or set the pref, we return NS_ERROR_UNEXPECTED if the type of the set*Pref() call doesn't match the inferred type (http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefapi.cpp#764) For unknown reasons, internal bookkeeping prefs used by AddonManager and XPIProvider are set to values of the wrong type on some Firefox profiles, and are now stuck that way. I can write wrapper code on these calls to catch the error and clear the broken preference, but I wonder if it would be better to change set*Pref() to force the preference to the intended type. In a way we're dancing around competing footguns here - do we protect against bad code trying to break our preferences by setting a value to the wrong type, or do we protect against a broken preference messing up our code because we can't recover from a wrong type? I use Preferences.jsm, which uses the JS type to call the appropriate set*Pref() and calls getPrefType() as part of get() so we never have a type mismatch on retrieve. It just works. It even manages observer notifications for you. Aside from a minimal performance overhead (which I doubt is even measurable), I'm not sure why people would want to use the XPCOM interfaces over Preferences.jsm. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should nsIPrefBranch.set*Pref return NS_ERROR_UNEXPECTED on type mismatch?
On 2014-03-20 1:50 PM, Gregory Szorc wrote: On 3/20/14, 10:38 AM, Irving Reid wrote: ... For unknown reasons, internal bookkeeping prefs used by AddonManager and XPIProvider are set to values of the wrong type on some Firefox profiles, and are now stuck that way. I can write wrapper code on these calls to catch the error and clear the broken preference, but I wonder if it would be better to change set*Pref() to force the preference to the intended type. In a way we're dancing around competing footguns here - do we protect against bad code trying to break our preferences by setting a value to the wrong type, or do we protect against a broken preference messing up our code because we can't recover from a wrong type? I use Preferences.jsm, which uses the JS type to call the appropriate set*Pref() and calls getPrefType() as part of get() so we never have a type mismatch on retrieve. It just works. It even manages observer notifications for you. Aside from a minimal performance overhead (which I doubt is even measurable), I'm not sure why people would want to use the XPCOM interfaces over Preferences.jsm. Preferences.jsm is great, but it doesn't solve this particular problem; once a wrong-type value gets into prefs.js we don't have an easy way to fix it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should nsIPrefBranch.set*Pref return NS_ERROR_UNEXPECTED on type mismatch?
On 3/20/14, 10:50 AM, Gregory Szorc wrote: On 3/20/14, 10:38 AM, Irving Reid wrote: Looking into some odd exceptions in the Addon Manager (bug 985998), I found that the behaviour of the Preference service is: a) We infer the type of a preference from the data read in from prefs.js (see e.g. http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefread.cpp#288) b) When we try to get or set the pref, we return NS_ERROR_UNEXPECTED if the type of the set*Pref() call doesn't match the inferred type (http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefapi.cpp#764) For unknown reasons, internal bookkeeping prefs used by AddonManager and XPIProvider are set to values of the wrong type on some Firefox profiles, and are now stuck that way. I can write wrapper code on these calls to catch the error and clear the broken preference, but I wonder if it would be better to change set*Pref() to force the preference to the intended type. In a way we're dancing around competing footguns here - do we protect against bad code trying to break our preferences by setting a value to the wrong type, or do we protect against a broken preference messing up our code because we can't recover from a wrong type? I use Preferences.jsm, which uses the JS type to call the appropriate set*Pref() and calls getPrefType() as part of get() so we never have a type mismatch on retrieve. It just works. It even manages observer notifications for you. Aside from a minimal performance overhead (which I doubt is even measurable), I'm not sure why people would want to use the XPCOM interfaces over Preferences.jsm. And to more directly answer your question about type mismatch leading to bustage, I try to write initialization code that looks for bad values. e.g. https://hg.mozilla.org/mozilla-central/file/cf485c48b52f/services/healthreport/healthreporter.jsm#l217. The type handling in that code is behind getDatePref(). But it shouldn't be too difficult to cobble together something that verifies types match and reset if not. I reckon someone could add schema support to Preferences.jsm. That might be a nifty way of shoehorning type validation into an XPCOM interface that likely won't change any time soon. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please do not add new web-exposed XPCOM objects
Bobby Holley wrote: On Tue, Mar 18, 2014 at 6:53 AM, Neil n...@parkwaycc.co.uk wrote: Let's suppose that I want to provide a global property that provides 5 functions each with a number of string arguments. (Traditionally this would be done using a component in the JavaScript global property category.) How would this way work? (Ideally the object backing the property would only be created on demand, and would have access to the window in question, but a singleton object that was available to all globals is acceptable.) If you're shipping with the browser, use WebIDL. If not, watch for new globals, and install the functions via exportFunction. Sure, but the old category only installed the object on demand, so this is a backward step... -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should nsIPrefBranch.set*Pref return NS_ERROR_UNEXPECTED on type mismatch?
Irving Reid wrote: For unknown reasons, internal bookkeeping prefs used by AddonManager and XPIProvider are set to values of the wrong type on some Firefox profiles, and are now stuck that way. I can write wrapper code on these calls to catch the error and clear the broken preference, but I wonder if it would be better to change set*Pref() to force the preference to the intended type. a) if the pref has a default in all.js then you don't want to be able to change its type and in this case the prefs.js value should get ignored if it is the wrong type. b) by the time you're calling setPref it's too late because you know the type is wrong when your getPref failed so you might as well clear it as part of fixing the problem. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should nsIPrefBranch.set*Pref return NS_ERROR_UNEXPECTED on type mismatch?
On Thu, Mar 20, 2014 at 10:38 AM, Irving Reid irv...@mozilla.com wrote: For unknown reasons, internal bookkeeping prefs used by AddonManager and XPIProvider are set to values of the wrong type on some Firefox profiles, and are now stuck that way. I can write wrapper code on these calls to catch the error and clear the broken preference, but I wonder if it would be better to change set*Pref() to force the preference to the intended type. Which prefs, out of curiosity? I could imagine some forms of malware installers clobbering prefs.js values (or even firefox.js/all.js values, if they have appdir write access) incorrectly. If that's what's happening here it should inform our ways of mitigating it. Any way to get more data from the affected installations? Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please do not add new web-exposed XPCOM objects
On Thu, Mar 20, 2014 at 5:52 PM, Neil n...@parkwaycc.co.uk wrote: Sure, but the old category only installed the object on demand, so this is a backward step... What is your concern, exactly? Performance? I doubt it's significant. You could define the object with lazy getters if you wanted. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
