Re: Changes in chrome JS code due to ES6 global lexical scope

[Shu-yu Guo]

Good catch and thanks for the correction! The take-home from the example is
that: due to the global lexical scope, a TDZ error could arise later due to
newly introduced bindings.

On Thu, Sep 17, 2015 at 7:34 PM, Boris Zbarsky  wrote:

> On 9/17/15 8:26 PM, Shu-yu Guo wrote:
>
>> ​The first call to f() does not throw.
>>
>
> It actually does, because the bareword lookup for "x" fails.  You get
> "ReferenceError: x is not defined".
>
> If you replaced "x" with "window.x" or "self.x" or "this.x" or something I
> think you'd get the behavior you describe.
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
   shu
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Canvas CaptureStream

[Robert O'Callahan]

On Fri, Sep 18, 2015 at 9:02 PM, Ms2ger  wrote:

> That bug does not seem to support the claim that they intend to ship
> this feature. No intent-to-ship is mentioned, and it appears the
> intent-to-implement has not been sent.
>

Here's evidence they intend to implement:
https://docs.google.com/document/d/1JmWfOtUP6ZqsYJ--U8y0OtHkBt-VyjX4N-JqIjb1t78/edit#heading=h.2ki8zk71f7w2

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Canvas CaptureStream

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Andreas,

On 09/18/2015 04:39 AM, Andreas Pehrson wrote:
> Other UAs intending to ship it are at least Chromium/Blink, who
> have started work in this bug: 
> https://code.google.com/p/chromium/issues/detail?id=524218.
> 

That bug does not seem to support the claim that they intend to ship
this feature. No intent-to-ship is mentioned, and it appears the
intent-to-implement has not been sent.

Have other browser vendors provided any implementation feedback?

Thanks
Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJV+9MXAAoJEOXgvIL+s8n2g+oH/2Hjp/oW5yiAPcZeBbelkG7Q
ocK3q6hHDMKNF9Tubyvv33ciEjDkvgoUXQEMuvrnz09EPuR4el0L4GsRk65iJwR6
eWay0ndxBjbNJ/0v7GFHPmr66tK9eauIKe467kOW5YUWlopPuuVfOsv54IoIJ0ln
SeuxXESOyKLFwqV78dAwHgwFPNRzMO2C18fOkfC+rVeWYytKlqkOnf2gbwd9chsY
ncdS5k8ZkecOq5T8vJ+sCDRUnwOFEy/QPgoDC7vt66kuu0naj7fwr2kxr3Ic0yM6
rxXUdCZkscdAICLNgQfnHAm0PuKQRx8X9MzzudTL8ZKMXYDbq+F9SGX8L6hDrEM=
=OqsW
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Platform help needed for Firefox OS L10n/Intl

[Zibi Braniecki]

Hi all,

There are two things in the platform that need a developer, which would 
significantly help Firefox OS L10n/Intl work.

1) Move navigator.mozHour12 to platform

This is a shim [0] that currently requires us to give all apps that want to 
properly display time to elevate its privileges to have access to mozSettings, 
while reading this settings should not require any privs.

Moving this to the platform would make our code more secure, and enable 
third-party apps to create better UX for the users.

For desktop/android Gecko I think it's totally fine to leave it as undefined 
for now (which means that Intl API will use automatic value for a language) or 
we could take the data from the platform and follow it (which would be nice as 
well).

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1172732

2) MutationObserver callbacks should be called before executing defer scritps

It seems like it should be easy to add, but I don't understand the codebase to 
write it myself.

This one will allow us to write better shims for API's that we'd be 
standardizing. The reason why it hurts us right now is because all of our code 
is deferred and it means that we cannot rely on MutationObserver based shims to 
provide the experience matching the one a platform would give.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1180927

I would appreciate help with those two things.

Thank you!
zb.


[0] 
https://github.com/mozilla-b2g/gaia/blob/2c14ecccd4c5b8c1217f2adc655ba75579d1/shared/js/date_time_helper.js
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: API request: MutationObserver with querySelector

[smaug]

On 09/18/2015 06:30 AM, Zibi Braniecki wrote:

Hi,

One of the major use cases for MutationObserver is all kinds of libraries that 
either shim APIs or provide intrinsic modifications to DOM experience.

Examples of such libraries may be:

* A library that provides Date/Time pickers only caring about 
* A library that extends behavior of a particular web component from outside
* A library that extends behavior of common elements with particular attributes
   * our l10n library only looks for element with data-l10n-id|data-l10n-args
   * a resource API shim may be looking for  with a given attribute

Unfortunately, at the moment, MutationObserver API makes it particularly hard 
for libraries to narrow down the scope of elements that are monitored by them 
which results in three things:

*) Higher CPU/power cost of running a MutationObserver on a DOM tree
*) More noise inside the MutationObserver callback
*) Requirement for fairly sophisticated filtering to get the right elements

The reason for so much noise is that there's no way to instrument 
MutationObserver to notice only specific elements. The only filtering can be 
done for attributes, but for node adding/removing MutationObserver reports 
*all* elements and often in form of a DOMFragment which has to be filtered.

Example from our l10n library:

const observerConfig = {
   attributes: true,
   characterData: false,
   childList: true,
   subtree: true,
   attributeFilter: ['data-l10n-id', 'data-l10n-args']
};

var mo = new MutationObserver(onMutations);
mo.observe(this.doc, observerConfig);

function onMutations(mutations) {
   const targets = new Set();

   for (let mutation of mutations) {
 switch (mutation.type) {
   case 'attributes':
 targets.add(mutation.target);
 break;

   case 'childList':
 for (let addedNode of mutation.addedNodes) {
   if (addedNode.nodeType === addedNode.ELEMENT_NODE) {
 if (addedNode.hasAttribute('data-l10n-id')) {
   targets.add(addedNode);
 }
 if (addedNode.childElementCount) {
   element.querySelectorAll('[data-l10n-id]').forEach(
 elem => targets.add(elem));
 }



   }
 }
 break;
 }
   }

   if (targets.size === 0) {
 return;
   }

   translateElements(targets);
}

Proposal:

const observerConfig = {
   attributes: true,
   attributeFilter: ['data-l10n-id', 'data-l10n-args']
   querySelector: '*[data-l10n-id]'
};


I don't understand what querySelector would filter here. We're observing only 
attributes but then what...




var mo = new MutationObserver(onMutations);
mo.observe(this.doc, observerConfig);

function onMutations(mutations) {
   const targets = new Set();

   for (let mutation of mutations) {
 switch (mutation.type) {
   case 'attributes':
 targets.add(mutation.target);
 break;

   case 'childList':
 for (let addedNode of mutation.addedNodes) {
   targets.add(addedNode);
 }

Hmm, or are you just missing childList from observerConfig.
How would the filtering work for node removals? Would it need to run the filter 
right before removal?

Are you thinking that querySelector filtering would map also to all the 
descendants of the actually added child node?
That would be quite a big change how the API works currently. addedNodes 
wouldn't be about childNodes anymore, but any descendant. Would it be
also about any removed descendants?



 break;
 }
   }

   if (targets.size === 0) {
 return;
   }

   translateElements(targets);
}


And it's not only about cleaner code. In Firefox OS' Settings app, our 
onMutations is fired hundreds of times as we construct DOM dynamically, while 
l10n cares about 70 elements out of those.

I believe that there's a substantial value in extending MutationObserver API to 
help with such filtering for all scenarios listed at the top and many similar 
ones.

Would it be possible to do within MutationObserver API or would it be material 
for a separate API?


selector based observing/filtering was discussed when MutationObserver API was 
being designed. Some old documentation here
http://www.w3.org/2008/webapps/wiki/MutationReplacement (note, that 
documentation is from the era when there were no microtasks yet)
IIRC there were concerns selector based filtering being too slow, and also it 
is a higher level thing, so first
we wanted a low level API. (one could say even attribute filtering should have 
been left out)

If you want new web exposed changes to the API, better to file a spec bug 
https://github.com/whatwg/dom/issues/new
so that also other browser vendors and API users can easily comment the 
proposal.


But in principle I think some kind of filtering would be nice. Implementing it for node removals would be a bit annoying in Gecko case (since our 
internal nsIMutationObserver::ContentRemoved happens after the removal) but it is doable. 

Re: Intent to ship: Canvas CaptureStream

[Randell Jesup]

>On Fri, Sep 18, 2015 at 9:02 PM, Ms2ger  wrote:
>
>> That bug does not seem to support the claim that they intend to ship
>> this feature. No intent-to-ship is mentioned, and it appears the
>> intent-to-implement has not been sent.
>>
>
>Here's evidence they intend to implement:
>https://docs.google.com/document/d/1JmWfOtUP6ZqsYJ--U8y0OtHkBt-VyjX4N-JqIjb1t78/edit#heading=h.2ki8zk71f7w2

The working group originally gave broad consensus to this a year ago at
an interim with Google and Microsoft in agreement there.  We just held
another interim and covered this, with focus on nits in the wordings and
a few surprises we found in implementing it which needed minor
adjustments.  Again, Google and Microsoft were directly involved, and
there was no opposition to moving forward and finishing it.

Everyone I've talked to in the WG involved expects it to be widely
implemented (and I believe Edge will be implementing it; MS has been
involved all along, and have recently started doing a lot of
implementation work related to WebRTC including VP8 and Opus support.
They're very clearly focused on using WebRTC/ORTC to implement
conferencing solutions (i.e. Lync and Skype), and this feature helps
with that.)

We showed demos of canvas.captureStream() at KrankyGeek in SF last week,
to major interest from developers, and at the event fielded questions
from Google engineers and Google's lead product person for WebRTC about
the interaction with DRM (which is fine; it can't be used to break EME).

I think it's clear that Google intends to implement and ship it, and I
believe Microsoft will do likewise in Edge.  It adds a ton of power to
WebRTC and really (along with the associated
mediaElement.captureStream/etc) fills out the "ecosystem' of media
routing and ability to transform it (as we can with WebAudio &
MediaStreams).

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes in chrome JS code due to ES6 global lexical scope

[Neil]

Shu-yu Guo wrote:


Good catch and thanks for the correction! The take-home from the example is
that: due to the global lexical scope, a TDZ error could arise later due to
newly introduced bindings.


So for that I guess the code would have to look like this?


var x;
function f() { dump(x); }
f(); // prints undefined​
​


f(); // throws TDZ error?
​let x = 42;


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes in chrome JS code due to ES6 global lexical scope

[Gervase Markham]

On 17/09/15 19:59, Shu-yu Guo wrote:
> ​Because ​until now, our global 'let' semantics have been identical to
> those of 'var', I have already landed a patch that mass replaces global
> 'let' with 'var' as part of bug 1202902.

I think someone should make you a "var is the new let" t-shirt...

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes in chrome JS code due to ES6 global lexical scope

[Tom Schuster]

I think that would fail as well, because the let would be shadowing the
global x, which isn't allowed.
On Sep 18, 2015 2:25 PM, "Neil"  wrote:

> Shu-yu Guo wrote:
>
> Good catch and thanks for the correction! The take-home from the example is
>> that: due to the global lexical scope, a TDZ error could arise later due
>> to
>> newly introduced bindings.
>>
>> So for that I guess the code would have to look like this?
>
> 
> var x;
> function f() { dump(x); }
> f(); // prints undefined​
> ​
>
> 
> f(); // throws TDZ error?
> ​let x = 42;
> 
>
> --
> Warning: May contain traces of nuts.
> ___
> 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