Re: Simplify async code-flows and unify unit tests
For only making tests codes (mochitest), I think it's good that we
introduce the way to write async test uniformly.
However, I seem we need consider about it for some reason.
1. We have already task.jsm modules in our source tree. It's promises
based design and it has been used in our code. the difference of
styles will causes some problem and it's not good for project. Even if
we need to mix some different paradigms for async code, we separate a
paradigm per each modules.
2. We may need to consider DOM Future
http://dom.spec.whatwg.org/#futures and the discussions on es-discuss
about introducing Future pattern to ECMAScript standards. This is the
tide which we cannot ignore about. If ECMAScript or DOM Standard adopt
them as formal standards, its design pattern will be main stream and
following it will be benefits.
2013/5/7 Mike de Boer :
> TLDR; in bug 867742 I requested to adopt two JS modules, Async.jsm and
> AsyncTest.jsm, in mozilla-central/toolkit/modules. The whole story can be
> read below as well as at https://gist.github.com/mikedeboer/5495405. I posted
> about this subject before on firefox-dev:
> https://mail.mozilla.org/pipermail/firefox-dev/2013-April/thread.html#268
>
> ...
> The thing I always do when I encounter a large code base, is roam though it
> and make a mental map of the structure; the good parts and ones that would
> benefit from some TLC. A part I noticed did not yet receive the amount of
> attention it deserves are unit tests and asynchronous code handling. I'll be
> blunt about it, here's what I did: I ported the async NodeJS library to a
> Mozilla-style module and on top of that I built a unit testing library,
> inspired by Mocha (among others). I can imagine that the fellas I just
> mentioned don't make you recall anything, so here are two links:
>
> https://github.com/caolan/async
> https://github.com/visionmedia/mocha
> First of all, the Github numbers will show you that they are crazy popular
> NodeJS libraries. And well-documented. And well-written. And awesome.
>
> Here's the thing I ended up with: https://github.com/mikedeboer/mozAsync The
> lib folder therein contains two files:
>
> Async.jsm - the port of the async library
> AsyncTest.jsm - the unit testing library The test folder contains the unit
> tests (erm, duh) and also serve as great examples of how to use the two
> modules!
> Ok, example time! I really like this one from the async module:
>
> // Sorts a list by the results of running each value through an async
> iterator.
> Async.sortBy(["file1", "file2", "file3"], function(file, callback){
> fs.stat(file, function(err, stats){
> callback(err, stats.mtime);
> });
> }, function(err, results){
> // results is now the original array of files sorted by
> // modified date
> });
> Note: this one uses a NodeJS API, but you can mentally replace that with an
> async MozFile one.
>
> I've told some of you before that I'm not a big fan of Promise libraries (if
> not, please read the 10 reasons to NOT use a Promise library:
> https://gist.github.com/mikedeboer/5305020). However, this library is not
> meant to replace them, but to augment the ecosystem with another option.
> There are many developers out there that feel uneasy about using Promises as
> long as they're not a first-class primitive in SpiderMonkey. If that's you,
> you can use this: a minimalistic, functional utility library.
>
> What about them unit tests?
>
> Design goal: create a simple, minimalistic framework that provides a clear,
> unified API to create unit tests that is as easy to use for sync code flows
> as for async ones. Rationale: unit tests are 'hot' code. They are modified as
> often - perhaps even more - as functionality it covers changes, especially in
> TDD environments. They serve as documentation for the code they cover. When
> tests fail, they usually don't on 'your computer', but somewhere else, like
> on the build infrastructure. When that happens, someone will open the unit
> test and try to understand what is going on. In all these cases it is hugely
> beneficial to a) know that most of the unit tests are written in the same
> structure and b) are structured in such a way that they're easy to read by
> someone other than you.
>
> This is an example of a minimal test:
>
> AsyncTest([
> {
> name: "Minimal Test",
> reporter: "tap",
> tests: {
> "it should execute this test": function(next) {
> Assert.equal(typeof next, "function", "'next' should be a callback
> function");
> next();
> },
>
> "! it should NOT execute this test": function(next) {
> Assert.ok(false, "BAM!");
> next();
> },
>
> "it should be aware of the correct context": function() {
> Assert.ok(this["it should execute this test"], "The function ought to
> be accessible");
> }
> }
> }
> ]);
> There are a couple of interesting things going on here:
>
> You can pass an Array of test suites or just one Object
> Su
Re: Intent to replace Promise.jsm and promise.js with DOM Promises
> My intention is: > 1) Enable Promises for all chrome code. Is this plan that enable to use DOM Promise in all chrome code? I think, Promise will be introduced in ECMA6, then we will be able to use Promise as one of the standard library of ECMAScript in js code module environment, when Spidermonkey will implement ES6 Promise. Best Regards. -- Tetsuharu OHZEKI saneyuki.s.s...@gmail.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Should we disable "autoplay" feature of HTMLMediaElement on mobile?
Hi, In Last week, I proposed the following mail to mobile-firefox-dev mailing list. I feel this proposal is related to not only Fennec, but also B2G. So I would like to hear your opinions. Best Regards. -- Forwarded message -- Hello, I propose that we should disable "autoplay" feature of HTMLMediaElement on mobile. (I'm sorry if this topics has been discussed for a long time ago in past times.) At the current configuration, Gecko runs on mobile (Firefox for Android, B2G) are enable the "autoplay" feature of HTMLMediaElement with using `media.autoplay.enabled=true`. However, I think this might not be useful for users. Because: * Mobile Devices are more used in public space than Desktop PCs. If browser auto-plays all media which come from web without some user activations, this should be privacy risk. * And, simply, it would shame me if browser auto-plays web page audio in the silent public space. * In related with above things, this behavior might have social attack risk by web pages. If browser auto-plays x-rated (violent, porn or etc) video/audio with loud volumes in the public space, his user's name will be mud. So I propose "we should disable "autoplay" feature of HTMLMediaElement on mobile". And I would like to discuss about it. I welcome your feedback to polish Firefox for mobile and web. Best Regards. -- Tetsuharu OHZEKI saneyuki.s.s...@gmail.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?
2013/12/8 Robert O'Callahan : > Don't these arguments apply to desktop Firefox used at work, in an Internet > cafe, or in a library, as well? True. This proposal could be applied to desktop Firefox. But I seem it would be hard because of historical reasons. On today's web, there are many "interactive" web sites which play sounds when open them. Some of them are not controlled by users because they doesn't not provide any control. This is website's problem for accessibility/usability. But I also think that this is a user agent (browser)'s problem originally. However, Sadly, It's too late to change the behavior now for desktop browser. > I think it's important to have an easy way to mute/unmute the browser, but > disabling autoplay is probably not the right way to address these issues. Yes. I agree that disabling autoplay is not right way. For only mobile, I think that the approach like click-to-play may be good to resolve this issues. This "click-to-play" focuses only to absorb the problem of autoplaying which includes privacy, honor, and traffic attacks. Although I think this might be resolved before mobile web expand more and more. Now, B2G are very young platform. If we try to resolve these issue, this moment would be chance to resolve it. 2013/12/8 Robert O'Callahan : > Don't these arguments apply to desktop Firefox used at work, in an Internet > cafe, or in a library, as well? > > I think it's important to have an easy way to mute/unmute the browser, but > disabling autoplay is probably not the right way to address these issues. > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le > atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > waanndt wyeonut thoo mken.o w -- Tetsuharu OHZEKI saneyuki.s.s...@gmail.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?
2013/12/8 Robert Kaiser : > I personally have not yet seen any arguments that would really apply for > making things different between mobile and desktop in your discussion, and I > think we should not make functionality different between form factors or > products when there is no good reason to make them different. > IMHO, what's named "Firefox" should work the same everywhere unless there is > a really good reason why a different variant should behave differently (and > there surely are often good reasons, but I haven't noticed those in this > discussion yet - nobody says I won't often use my laptop in public or my > mobile devices in private). Ideally, I agree that what's named "Firefox" should work the same everywhere. Though, There are some difference between "desktop" and "mobile" for general usecases. Mobile including tablet would be more used in public space than desktop. I don't say laptops are never used in public space. Of course, some people use their laptop in very crowded train like which runs in Tokyo. Other some people use their mobile devices in only private. But they are limitless. I think that we need to discuss it based on general usecases at first. On that basis, we should discuss how we bypass or resolve some problems. 2013/12/8 Robert Kaiser : > Tetsuharu OHZEKI schrieb: > >> I propose that we should disable "autoplay" feature of >> HTMLMediaElement on mobile. > > > I personally have not yet seen any arguments that would really apply for > making things different between mobile and desktop in your discussion, and I > think we should not make functionality different between form factors or > products when there is no good reason to make them different. > IMHO, what's named "Firefox" should work the same everywhere unless there is > a really good reason why a different variant should behave differently (and > there surely are often good reasons, but I haven't noticed those in this > discussion yet - nobody says I won't often use my laptop in public or my > mobile devices in private). > > That said, I think we should think about how we can enable more user control > of such features. If I open media tabs in the background, I probably don't > want them to autoplay at all. And then, there are situations on all my > devices where I may want autoplay and situations where I may not. How could > we give the user control over autoplay in an intuitive and easy way? Is > there a good way to do that on mobile form factors as well? > > KaiRo > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Tetsuharu OHZEKI saneyuki.s.s...@gmail.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?
2013/12/10 Reuben Morais : > Note that B2G doesn't have an about:config. We can resolve with to add an option to gaia UI. -- Tetsuharu OHZEKI saneyuki.s.s...@gmail.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?
2013/12/10 Benjamin Smedberg : > https://bugzilla.mozilla.org/show_bug.cgi?id=944876 may be relevant: in that > bug I'm willing to mentor somebody to add a hidden pref for additional > control over autoplay behavior. Sounds good. I feel this approach is more smart like roc said. > For desktop Firefox, I don't think we'd ever want to disable autoplay *by > default* in the foreground tab: many people expect their youtube video to > just start if they click the link. I suspect that, as discussed earlier on > this thread, it might make a lot of sense to delay starting media in a > *background* tab (e.g. opened via middle-click). Then we'd autoplay when the > video comes into the foreground. We could even implement a setting where all > media pause in a background tab. I almost agree. For desktop Firefox, we should not (cannot) change the default behavior for autoplay. This is (historical) protocol. Even if we provide other click-to-plays options, we might not change the default. However, for desktop, I don't think it's good that providing as default to delay starting in background tabs. This is same with that many people expect their youtube video to just start if they click the link. Some of them also expect their youtube video start in background tabs as podcast. For mobile, this delaying approach is well for saving power. I feel this approach make sense. -- Tetsuharu OHZEKI saneyuki.s.s...@gmail.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?
2013/12/11 Hubert Figuière : > Power? How about not blowing through your data cap allowance or paying > and other hefty charges > > Very few countries have cheap unlimited data over cellular. Of course, it includes network data traffic. I hope it saves power/data cost :) -- Tetsuharu OHZEKI saneyuki.s.s...@gmail.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?
2013/12/11 Hubert Figuière : > It should be noted that here on desktop I do have > `media.autoplay.enabled=false` (I hate videos that autoplay) and this > still doesn't stop YouTube. [1] I seem that Gecko's implementation of HTMLMediaElement.play() doesn't handle `media.autoplay.enabled`. http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLMediaElement.cpp#2112 -- Tetsuharu OHZEKI saneyuki.s.s...@gmail.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
