Platform help needed for Firefox OS L10n/Intl
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
Reported: https://github.com/whatwg/dom/issues/77 zb. ___ 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
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
Re: Changes in chrome JS code due to ES6 global lexical scope
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: Intent to ship: Canvas CaptureStream
>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
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: API request: MutationObserver with querySelector
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. Howeve
Re: Intent to ship: Canvas CaptureStream
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
-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