Implementing an identical JSON.stringify

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementing an identical JSON.stringify

Michael Theriot
`JSON.stringify` has unintuitive behavior regarding interal slots.

```js
// Number with    [[NumberData]]
// "0"
JSON.stringify(Object(Number(0)));

// Number without [[NumberData]]
// "{}"
JSON.stringify(Reflect.construct(Object, [], Number));

// Number without [[NumberData]]
// Number with    [[StringData]]
// throws TypeError
JSON.stringify(Reflect.construct(String, [], Number));

// String with    [[StringData]]
// ""
JSON.stringify(Object(String()));

// String without [[StringData]]
// "{}"
JSON.stringify(Reflect.construct(Object, [], String));

// String without [[StringData]]
// String with    [[NumberData]]
// throws TypeError
JSON.stringify(Reflect.construct(Number, [], String));

// Object with    [[StringData]]
// "[object String]"
JSON.stringify(Reflect.construct(String, [], Object));

// Object with    [[NumberData]]
// null
JSON.stringify(Reflect.construct(Number, [], Object));
```

Weird, but not impossible to implement.

* You can detect class with instanceof
* You can detect internal slots by try-catching `<class>.prototype.valueOf`

e.g.
```js
const isNumberInstance = (item) => item instanceof Number;
const isStringInstance = (item) => item instanceof String;

const hasNumberData = (item) => {
  try { Number.prototype.valueOf.call(item); } catch { return false; }
  return true;
};
const hasStringData = (item) => {
  try { String.prototype.valueOf.call(item); } catch { return false; }
  return true;
};
```

Since this relies on having a reference to the classes, it will not work with an instance of `Number` from another realm for example.

```js
const item = Reflect.construct(iframe.contentWindow.String, [], iframe.contentWindow.Number);

iframe.contentWindow.Number !== Number;
```

I think this is related to `Array.isArray`. Is there an equivalent `Number.isNumber`? Or is this just something only `JSON.stringify` can do?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Claude Pache


> Le 5 août 2018 à 00:16, Michael Theriot <[hidden email]> a écrit :
>
> `JSON.stringify` has unintuitive behavior regarding interal slots.

I don’t think that anything involving an object that has a [[StringData]] internal slot but has `Number.prototype` in its prototype chain could have an ”intuitive” behaviour...

>
>
> I think this is related to `Array.isArray`. Is there an equivalent `Number.isNumber`? Or is this just something only `JSON.stringify` can do?

Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and only if `obj` has no [[NumberData]] internal slot. Ditto for String, Boolean and Symbol.

—Claude
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Michael Theriot
Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and only if `obj` has no [[NumberData]] internal slot. Ditto for String, Boolean and Symbol.

I already mention this and demonstrate why it is not sufficient in my example.

Reiterated plainly:
```js
JSON.stringify(Reflect.construct(Number, [], Number)); // "0"
JSON.stringify(Reflect.construct(Number, [], String)); // TypeError
JSON.stringify(Reflect.construct(Number, [], Object)); // null
```

Even though both of these have [[NumberData]] internal slots, it also considers the type when throwing. Hence the question if you can type check cross-realm in a way that does not depend on internal slots.

On Sat, Aug 4, 2018 at 6:35 PM Claude Pache <[hidden email]> wrote:


> Le 5 août 2018 à 00:16, Michael Theriot <[hidden email]> a écrit :
>
> `JSON.stringify` has unintuitive behavior regarding interal slots.

I don’t think that anything involving an object that has a [[StringData]] internal slot but has `Number.prototype` in its prototype chain could have an ”intuitive” behaviour...

>
>
> I think this is related to `Array.isArray`. Is there an equivalent `Number.isNumber`? Or is this just something only `JSON.stringify` can do?

Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and only if `obj` has no [[NumberData]] internal slot. Ditto for String, Boolean and Symbol.

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing an identical JSON.stringify

Darien Valentine
In reply to this post by Michael Theriot
Is this a question about how/if one could replicate its behavior in theory from ES code, or are you suggesting a change to the existing behavior for these exotic cases?

Assuming the former:

The relevant steps are [here](https://tc39.github.io/ecma262/#sec-serializejsonproperty). The `instanceof` a value isn’t significant in this algorithm, just its slots (if it is an object) or its primitive type. So one can handle number and string by leveraging branded checks as you’ve shown — nothing more is needed than branded methods and typeof to manage that one.

However it is ultimately not possible to replicate because there is no possible brand test for [[BooleanData]].

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Claude Pache


> Le 5 août 2018 à 04:14, Darien Valentine <[hidden email]> a écrit :
>
>
> However it is ultimately not possible to replicate because there is no possible brand test for [[BooleanData]].

Per spec, checking whether `Boolean.prototype.valueOf.call(obj)` throws will test whether an object has [[BooleanData]] internal slot.

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Darien Valentine
Oh, thanks Claude, I missed that. I guess it is all replicable then.

On Sat, Aug 4, 2018 at 10:28 PM Claude Pache <[hidden email]> wrote:


> Le 5 août 2018 à 04:14, Darien Valentine <[hidden email]> a écrit :
>
>
> However it is ultimately not possible to replicate because there is no possible brand test for [[BooleanData]].

Per spec, checking whether `Boolean.prototype.valueOf.call(obj)` throws will test whether an object has [[BooleanData]] internal slot.

—Claude


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Claude Pache
In reply to this post by Michael Theriot


Le 5 août 2018 à 01:43, Michael Theriot <[hidden email]> a écrit :

Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and only if `obj` has no [[NumberData]] internal slot. Ditto for String, Boolean and Symbol.

I already mention this and demonstrate why it is not sufficient in my example.

Reiterated plainly:
```js
JSON.stringify(Reflect.construct(Number, [], Number)); // "0"
JSON.stringify(Reflect.construct(Number, [], String)); // TypeError
JSON.stringify(Reflect.construct(Number, [], Object)); // null
```

Per spec, the three expressions should produce `"0"`, as the three objects have a [[NumberData]] internal slot (step 4 of [1]). I guess there is some discrepancy between implementation and spec for those exotic edge cases?


—Claude



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Darien Valentine
In reply to this post by Darien Valentine
> Per spec, the three expressions should produce "0", as the three objects have a [[NumberData]] internal slot (step 4 of [1]). I guess there is some discrepancy between implementation and spec for those exotic edge cases?

There’s no discrepancy — they shouldn’t all produce "0", because the algorithm calls ToNumber on the value if it has the [[NumberData]] slot. This in turn calls ToPrimitive because the value is an object. This ultimately ends up calling the `@@toPrimitive` or `toValue` method _of_ the object. In the case of the object with String.prototype for its prototype, this will be `String.prototype.toValue`, which throws if its receiver doesn’t have [[StringData]]. In the case of the object with Object.prototype for its prototype, this will be `Object.prototype.toValue`.

On Sat, Aug 4, 2018 at 10:31 PM Darien Valentine <[hidden email]> wrote:
Oh, thanks Claude, I missed that. I guess it is all replicable then.

On Sat, Aug 4, 2018 at 10:28 PM Claude Pache <[hidden email]> wrote:


> Le 5 août 2018 à 04:14, Darien Valentine <[hidden email]> a écrit :
>
>
> However it is ultimately not possible to replicate because there is no possible brand test for [[BooleanData]].

Per spec, checking whether `Boolean.prototype.valueOf.call(obj)` throws will test whether an object has [[BooleanData]] internal slot.

—Claude


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Claude Pache
In reply to this post by Claude Pache


Le 5 août 2018 à 04:50, Claude Pache <[hidden email]> a écrit :



Le 5 août 2018 à 01:43, Michael Theriot <[hidden email]> a écrit :

Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and only if `obj` has no [[NumberData]] internal slot. Ditto for String, Boolean and Symbol.

I already mention this and demonstrate why it is not sufficient in my example.

Reiterated plainly:
```js
JSON.stringify(Reflect.construct(Number, [], Number)); // "0"
JSON.stringify(Reflect.construct(Number, [], String)); // TypeError
JSON.stringify(Reflect.construct(Number, [], Object)); // null
```

Per spec, the three expressions should produce `"0"`, as the three objects have a [[NumberData]] internal slot (step 4 of [1]). I guess there is some discrepancy between implementation and spec for those exotic edge cases?


—Claude


I see that there is a difference in this algorithm between the current spec and ES 2015 for that particular step. From my tests, current stable Firefox and Safari (other browsers not tested) still follow the old algorithm.

—Claude



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Claude Pache


Le 5 août 2018 à 05:07, Claude Pache <[hidden email]> a écrit :



Le 5 août 2018 à 04:50, Claude Pache <[hidden email]> a écrit :



Le 5 août 2018 à 01:43, Michael Theriot <[hidden email]> a écrit :

Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and only if `obj` has no [[NumberData]] internal slot. Ditto for String, Boolean and Symbol.

I already mention this and demonstrate why it is not sufficient in my example.

Reiterated plainly:
```js
JSON.stringify(Reflect.construct(Number, [], Number)); // "0"
JSON.stringify(Reflect.construct(Number, [], String)); // TypeError
JSON.stringify(Reflect.construct(Number, [], Object)); // null
```

Per spec, the three expressions should produce `"0"`, as the three objects have a [[NumberData]] internal slot (step 4 of [1]). I guess there is some discrepancy between implementation and spec for those exotic edge cases?


—Claude


I see that there is a difference in this algorithm between the current spec and ES 2015 for that particular step. From my tests, current stable Firefox and Safari (other browsers not tested) still follow the old algorithm.

—Claude


Nevrmind, forget the previous message. The algorithm does indeed somewhat strange here.

—Claude


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Isiah Meadows-2
In reply to this post by Claude Pache
It's very subtle, but no, that's correct per spec, and any engine that
doesn't do that is buggy. When `JSON.stringify` is invoked on a
number, it first performs ToNumber on number objects (which each of
these are) to get the number value, which itself indirectly calls
`valueOf`. The first calls `Number.prototype.valueOf` with a number,
which makes sense. The second creates an object with a [[NumberData]]
internal slot, as expected, but it tries to call
`String.prototype.valueOf` because the prototype of the object is set
to `new.target.prototype === String.prototype` on creation. And by
spec, that throws if the object doesn't have a [[StringData]] slot
(which the `Number` constructor doesn't set, of course).

It's a similar situation with the third, but it's a little more
indirect. First it calls `Object.prototype.valueOf` because
`new.target.prototype === Object.prototype` when constructing the
number. But this returns an object, not a primitive. in the ToNumber
algorithm, if `valueOf` returns a non-primitive, it falls back to
`Object.prototype.toString()`, and in either case, recursively coerces
*that*. The result of coercing that result, `"[object Number]"`, to a
number is `NaN`, and `JSON.stringify(NaN)` returns `null` due to step
9.a/9.b in the SerializeJSONProperty algorithm (`NaN` is not a finite
number).

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Sat, Aug 4, 2018 at 10:50 PM, Claude Pache <[hidden email]> wrote:

>
>
> Le 5 août 2018 à 01:43, Michael Theriot <[hidden email]> a
> écrit :
>
>> Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and
>> only if `obj` has no [[NumberData]] internal slot. Ditto for String, Boolean
>> and Symbol.
>
>
> I already mention this and demonstrate why it is not sufficient in my
> example.
>
> Reiterated plainly:
> ```js
> JSON.stringify(Reflect.construct(Number, [], Number)); // "0"
> JSON.stringify(Reflect.construct(Number, [], String)); // TypeError
> JSON.stringify(Reflect.construct(Number, [], Object)); // null
> ```
>
>
> Per spec, the three expressions should produce `"0"`, as the three objects
> have a [[NumberData]] internal slot (step 4 of [1]). I guess there is some
> discrepancy between implementation and spec for those exotic edge cases?
>
> [1]: https://tc39.github.io/ecma262/#sec-serializejsonproperty
>
> —Claude
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing an identical JSON.stringify

Michael Theriot
In reply to this post by Darien Valentine
Regarding cases like Reflect.construct(Number, [], String), the reason this throws is because the ToNumber algorithm calls ToPrimitive if its operand is an object. This in turn will call String.prototype.valueOf on the object which does not have [[StringData]]. There’s nothing funny going on, it’s just a weird effect in aggregate. You would just need to implement all the steps here — internal ops like ToNumber, ToPrimitive, etc. It’s not that it "considers type", but rather that these algorithms will call methods by specific names on objects they receive. String.prototype and Object.prototype both implement "valueOf", but only the former will fail the slot check.

Thanks for demystifying this. I never realized it was just ducktyping .valueOf on the object.

```js
Number.prototype.valueOf = () => 0;

JSON.stringify(1); // 1
JSON.stringify(new Number(1)); // 0
```

I guess what confused me is that it would detect a [[NumberData]] internal slot, but instead of unboxing to that value it tries to ducktype call .valueOf on the object. So the presence of [[NumberData]] changes the behavior even if it does not actually use this value.

On Sat, Aug 4, 2018 at 10:14 PM Darien Valentine <[hidden email]> wrote:
Is this a question about how/if one could replicate its behavior in theory from ES code, or are you suggesting a change to the existing behavior for these exotic cases?

Assuming the former:

The relevant steps are [here](https://tc39.github.io/ecma262/#sec-serializejsonproperty). The `instanceof` a value isn’t significant in this algorithm, just its slots (if it is an object) or its primitive type. So one can handle number and string by leveraging branded checks as you’ve shown — nothing more is needed than branded methods and typeof to manage that one.

However it is ultimately not possible to replicate because there is no possible brand test for [[BooleanData]].
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Implementing an identical JSON.stringify

Darien Valentine
> I guess what confused me is that it would detect a [[NumberData]] internal slot, but instead of unboxing to that value it tries to ducktype call .valueOf on the object. So the presence of [[NumberData]] changes the behavior even if it does not actually use this value.

This surprised me too initially, but I think we can infer a rationale if we read between the lines a bit. A similar pattern appears in the JSON stringify algorithm itself (as opposed to the SerializeJSONProperty algorithm) when interpreting the "space" argument. So it might seem to be that it’s a peculiarity of how JSON-related operations are defined — but I don’t think that’s the pattern. What these two cases have in common is that either a numeric value or a string value would be valid: neither hint would be more correct. In the case of SerializeJSONProperty, this is because both string values and numeric values are valid JSON values; in the case of stringify’s space argument, it’s because this is overloaded to either specify a number of spaces or a whitespace string. In the absence of a reason to weight one to-primitive operation over another, it sniffs for the singular unambiguous clue about type that’s really available, the slot.

Why doesn’t it then just use the slot value directly? Because this would depart from expectations about the @@toPrimitive / toValue / toString contract that is honored everywhere else, I believe.

On Sun, Aug 5, 2018 at 12:30 AM Michael Theriot <[hidden email]> wrote:
Regarding cases like Reflect.construct(Number, [], String), the reason this throws is because the ToNumber algorithm calls ToPrimitive if its operand is an object. This in turn will call String.prototype.valueOf on the object which does not have [[StringData]]. There’s nothing funny going on, it’s just a weird effect in aggregate. You would just need to implement all the steps here — internal ops like ToNumber, ToPrimitive, etc. It’s not that it "considers type", but rather that these algorithms will call methods by specific names on objects they receive. String.prototype and Object.prototype both implement "valueOf", but only the former will fail the slot check.

Thanks for demystifying this. I never realized it was just ducktyping .valueOf on the object.

```js
Number.prototype.valueOf = () => 0;

JSON.stringify(1); // 1
JSON.stringify(new Number(1)); // 0
```

I guess what confused me is that it would detect a [[NumberData]] internal slot, but instead of unboxing to that value it tries to ducktype call .valueOf on the object. So the presence of [[NumberData]] changes the behavior even if it does not actually use this value.

On Sat, Aug 4, 2018 at 10:14 PM Darien Valentine <[hidden email]> wrote:
Is this a question about how/if one could replicate its behavior in theory from ES code, or are you suggesting a change to the existing behavior for these exotic cases?

Assuming the former:

The relevant steps are [here](https://tc39.github.io/ecma262/#sec-serializejsonproperty). The `instanceof` a value isn’t significant in this algorithm, just its slots (if it is an object) or its primitive type. So one can handle number and string by leveraging branded checks as you’ve shown — nothing more is needed than branded methods and typeof to manage that one.

However it is ultimately not possible to replicate because there is no possible brand test for [[BooleanData]].
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an identical JSON.stringify

Allen Wirfs-Brock


On Aug 4, 2018, at 9:47 PM, Darien Valentine <[hidden email]> wrote:

> I guess what confused me is that it would detect a [[NumberData]] internal slot, but instead of unboxing to that value it tries to ducktype call .valueOf on the object. So the presence of [[NumberData]] changes the behavior even if it does not actually use this value.

Fundamentally, the tests are trying to determine which values are supposed to be serialized as JSON primitive values and which need to be serialized as JSON objects (or arrays). The assumption in JSON stingify is that JS wrapper objects for numbers, strings, and booleans should be serialized as primitive values.

The ES JSON functions were based upon Crockford's original JSON 2 API and his implementation of it as it existed in mid 2008 (https://web.archive.org/web/20090213004934/http://www.json.org/json2.js). Crockford, in his design,  made the decisions that the wrapper objects should serialize as primitives. In his implementation he accomplished that adding toJSON methods to the prototypes of Number, String, and Boolean. The body of those methods were: return this.valueOf();

In ES5, we wanted to avoid having to add a bunch of toJSON methods to the builtins (Date was the exception). So, we needed a cross-realm way to test for those primitive wrapper values. In ES1-5 the way to do that was to test the  value of the [[Class]] internal property which was set for all built-in objects. If a Number or Stream wrapper [[Class]] value was detected, we did an internal ToNumber or ToString to get the primitive value. This is equivalent to what the built-in valueOf methods do. 

In ES6, [[Class]] was eliminated as a specification device because it was confusing and starting to be misused. I realized that (for specification purposes) we could describe the equivalent test as a test for an internal slot that was unique to each kind of wrapper.  So, the [[Class]] test was replaced with tests for [[NumberData]], [[StringDate]], and [[BooleanData]]. That specification change should not be observable to JS code.  I didn’t change the ToNumber and ToString calls because that would have been a potentially observable change.


This surprised me too initially, but I think we can infer a rationale if we read between the lines a bit. A similar pattern appears in the JSON stringify algorithm itself (as opposed to the SerializeJSONProperty algorithm) when interpreting the "space" argument. So it might seem to be that it’s a peculiarity of how JSON-related operations are defined — but I don’t think that’s the pattern. What these two cases have in common is that either a numeric value or a string value would be valid: neither hint would be more correct. In the case of SerializeJSONProperty, this is because both string values and numeric values are valid JSON values; in the case of stringify’s space argument, it’s because this is overloaded to either specify a number of spaces or a whitespace string. In the absence of a reason to weight one to-primitive operation over another, it sniffs for the singular unambiguous clue about type that’s really available, the slot.

Yes, this is correct.  It is because of overload resolution. Crockford’s original implementation only recognized primitive Numbers or Strings as the 3rd argument. Any object, including wrapper objects, passed as the 3rd argument were ignored. I thought that wrapper objects should also be accepted so I introduced the sequence you see in the spec. which is similar to what was also done in SerializeJSONProperty.

In retrospect is might have been better to have followed Crockford’s example. It’s very unlike that a wrapper object would ever be passed as that argument.  It’s probably more likely that an object with a bespoke valueOf or toString might be passed and the algorithm, as specified, ignores such objects..

Allen



Why doesn’t it then just use the slot value directly? Because this would depart from expectations about the @@toPrimitive / toValue / toString contract that is honored everywhere else, I believe.

On Sun, Aug 5, 2018 at 12:30 AM Michael Theriot <[hidden email]> wrote:
Regarding cases like Reflect.construct(Number, [], String), the reason this throws is because the ToNumber algorithm calls ToPrimitive if its operand is an object. This in turn will call String.prototype.valueOf on the object which does not have [[StringData]]. There’s nothing funny going on, it’s just a weird effect in aggregate. You would just need to implement all the steps here — internal ops like ToNumber, ToPrimitive, etc. It’s not that it "considers type", but rather that these algorithms will call methods by specific names on objects they receive. String.prototype and Object.prototype both implement "valueOf", but only the former will fail the slot check.

Thanks for demystifying this. I never realized it was just ducktyping .valueOf on the object.

```js
Number.prototype.valueOf = () => 0;

JSON.stringify(1); // 1
JSON.stringify(new Number(1)); // 0
```

I guess what confused me is that it would detect a [[NumberData]] internal slot, but instead of unboxing to that value it tries to ducktype call .valueOf on the object. So the presence of [[NumberData]] changes the behavior even if it does not actually use this value.

On Sat, Aug 4, 2018 at 10:14 PM Darien Valentine <[hidden email]> wrote:
Is this a question about how/if one could replicate its behavior in theory from ES code, or are you suggesting a change to the existing behavior for these exotic cases?

Assuming the former:

The relevant steps are [here](https://tc39.github.io/ecma262/#sec-serializejsonproperty). The `instanceof` a value isn’t significant in this algorithm, just its slots (if it is an object) or its primitive type. So one can handle number and string by leveraging branded checks as you’ve shown — nothing more is needed than branded methods and typeof to manage that one.

However it is ultimately not possible to replicate because there is no possible brand test for [[BooleanData]].
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss