Whee, I get to be a wet blanket!
We don't even have any request-writable storage at the moment. SQLite is
horrible with write concurrency (and is on an NFS share, to make matters
worse), and straight NFS-based writing (sans SQL) would have to be guarded with
locks. Even if we solved those
On 03/18/2014 11:26 AM, Cameron McCormack wrote:
CSS Variables is a feature that allows authors to define custom properties that
cascade and inherit in the same way that regular properties do, and to
reference the values of these custom properties in the values of regular
properties (and other
Followup to dev-platform please.
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer service, which usually hold strong
Couldn't we insist that any reference to a DOM element in JS (or at
least in JS-implemented components) must be a weak pointer-style
wrapper? I seem to remember that we have introduced something along
these lines a few years ago as a way to fight against leaks of
references to DOM by add-ons.
On
On Wed, Mar 19, 2014 at 4:52 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Couldn't we insist that any reference to a DOM element in JS (or at
least in JS-implemented components) must be a weak pointer-style
wrapper? I seem to remember that we have introduced something along
these
On 03/20/2014 01:39 AM, Kyle Huey wrote:
Followup to dev-platform please.
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer
On 03/20/2014 01:58 AM, smaug wrote:
On 03/20/2014 01:39 AM, Kyle Huey wrote:
Followup to dev-platform please.
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message
On 03/20/2014 02:25 AM, smaug wrote:
On 03/20/2014 01:58 AM, smaug wrote:
On 03/20/2014 01:39 AM, Kyle Huey wrote:
Followup to dev-platform please.
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to
smaug wrote:
Curious, how much have we tested the performance of our implementation
and are there some known perf issues?
I have not tested. The only extra work we should be doing at the moment
when variables aren't used in the style sheet is
nsRuleNode::ResolveVariableReferences. That
On 3/19/14 4:39 PM, Kyle Huey wrote:
We are discovering a lot of leaks in JS implemented DOM objects. The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer service, which usually hold strong
On 19/03/2014 10:20, smaug wrote:
mxr can do specific revision + multiline.
Something like
http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.h?rev=492ce94e6528mark=94,96,98,100-113,120-134#90
You get the revision number from the bottom of the page. (That UI isn't too
On 2014-03-19, 7:58 PM, Kyle Huey wrote:
On Wed, Mar 19, 2014 at 4:52 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Couldn't we insist that any reference to a DOM element in JS (or at
least in JS-implemented components) must be a weak pointer-style
wrapper? I seem to remember that we
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
On 2014-03-19, 10:25 PM, 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.
On 3/19/14 10:40 PM, Ehsan Akhgari wrote:
Why do we have to touch that list on shutdown?
We Release() all the things in it (nsIWeakReferences in this case).
That said, the minutes cases are the ones where the notification is
one that's actually fired at shutdown, because then we start
On 2014-03-19, 10:50 PM, Boris Zbarsky wrote:
On 3/19/14 10:40 PM, Ehsan Akhgari wrote:
Why do we have to touch that list on shutdown?
We Release() all the things in it (nsIWeakReferences in this case).
Well, that was sort of my point (gotta work on my style of being overly
terse, sorry
Ehsan Akhgari writes:
On 2014-03-19, 10:50 PM, Boris Zbarsky wrote:
On 3/19/14 10:40 PM, Ehsan Akhgari wrote:
Why do we have to touch that list on shutdown?
We Release() all the things in it (nsIWeakReferences in this case).
Well, that was sort of my point (gotta work on my style of being
17 matches
Mail list logo
