Re: Merging comm-central into mozilla-central
On Fri, 23 Oct 2015 11:18:32 +0200, Ms2ger wrote: > On the plus side, it could make it easier to share code between > thunderbird and the b2g email code. Not really since the b2g email app is on github and doesn't share code with thunderbird for now. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ESLint is now available in the entire tree
The plan in general for chrome JS is to switch from #ifdefs to having things defined in AppConstants.jsm Fabrice On 11/30/2015 01:05 AM, Tim Guan-tin Chien wrote: > The Gecko JavaScript is also littered with #ifdef and # is really not a > token for comment in JS... is there any plan to migrate that away since > there is ESLint present? > > On Sun, Nov 29, 2015 at 10:37 PM, Vivien Nicolas <mailto:vnico...@mozilla.com>> wrote: > > On Sun, Nov 29, 2015 at 2:30 PM, David Bruant <mailto:bruan...@gmail.com>> wrote: > > > Hi, > > > > Just a drive-by comment to inform folks that there is an effort to > > transition Mozilla JavaScript codebase to standard JavaScript. > > Main bugs is: https://bugzilla.mozilla.org/show_bug.cgi?id=867617 > > > > And https://bugzilla.mozilla.org/show_bug.cgi?id=1103158 is about > > removing non-standard features from SpiderMonkey. > > Of course this can rarely be done right away and most often requires > > dependent bugs to move code to standard ECMAScript (with a period with > > warnings about the usage of the non-standard feature). > > > > What about .jsm modules ? Or is that not really considered ? > > I have been told that ES6 modules may help to solve some of the problems > covered by .jsm but I don't see how you can create a ES6 module that > is can > be accessed from multiple js context from the same origin. Mostly > interested as it would be nice to be able to write a module once and > share > it between multiple tabs instead of having to reload the same JS > script for > all similar tabs, like all the bugzilla tabs many of us have open for > example. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-platform > > > > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > -- Fabrice Desré b2g team Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Moving FirefoxOS into Tier 3 support
Hi all, With the smartphone activity shifting to a more exploratory status, we have been discussing with the platform & releng people which setup would allow us to keep improving the product and supporting our community of users while minimizing impact on other parts of the organization. The decision we ended up with is to move Firefox OS into Tier 3 support category (see https://developer.mozilla.org/en-U/docs/Supported_build_configurations). That means that other teams won't be backed out and yelled at by sheriffs for breaking b2g tests, and that the FirefoxOS team will be responsible for fixing such breakage. Landing code for FirefoxOS stays the same as today - we don't fork. We're also working on a solution to move the b2g builds & tests to their own infrastructure from which we'll ship our builds & updates. I want to thank all the people from various corners of the platform that helped us so far. I guess I'll have to bribe you now! Feel free to reach out to me if you need any more details on the subject, -- Fabrice Desré Connected Devices Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving FirefoxOS into Tier 3 support
Hi Ehsan, On 01/25/2016 08:38 AM, Ehsan Akhgari wrote: > I have two questions about this: > > 1. What does this mean for Firefox OS specific code in Gecko which is > designed to keep some level of testing possible on the Firefox OS side > by adding hacks to Gecko? Another example is hacks that we have needed > around Firefox OS's toolchain limitations (the gcc version requirements, > for example.) Can we remove such hacks now? First, what you call "now" will not happen until we setup the infrastructure we need for b2g. I would appreciate you to send me bug numbers for all these issues you're talking about. Secondly, since I really don't want us to fork gecko it would be unfortunate if people felt like they can just burn the house. Please use your best judgment and talk to people before *knowingly* breaking us. > 2. What about patches that couldn't land because of Firefox OS tests > failing in ways the author couldn't figure out? I'm thinking of > examples such as bug 1043562. Can we land such patches now? Yes. -- Fabrice Desré Connected Devices Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving FirefoxOS into Tier 3 support
On 01/25/2016 09:30 AM, Ehsan Akhgari wrote: > For example, for a long time b2g partners held back our minimum > supported gcc. Now that there are no such partner requirements, perhaps > we can consider bumping up the minimum to gcc 4.8? (bug 1175546) We moved to 4.8 on b2g a year ago: see https://bugzilla.mozilla.org/show_bug.cgi?id=1056337 Who's behind? :P > Another example, last year because of 2.5 release pressure where people > were planning on using service workers in gaia app, we had to add a huge > hack for "supporting" app:// URIs for service worker interception. The > last time that this code bit me was earlier this morning. It would be > nice if I can remove this broken code now instead of worrying about how > to keep supporting it going forward (this makes fixing bug 1222008 more > complicated than it needs to be.) I have no objections to remove this particular support. -- Fabrice Desré Connected Devices Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving FirefoxOS into Tier 3 support
On 01/25/2016 05:15 PM, Tim Guan-tin Chien wrote: > What's the scope of "b2g tests"? > > I can see obvious ones like any test testing Gaia and tests running on > Mulet or Emulator, but how about DOM mochitests on, say, Firefox > Desktop, for APIs that only B2G uses? > > Is there a definitive list? Are we purposely not going to make a list > just to be flexible? I expect all products built with MOZ_B2G to not be built and tested on the main treeherder. This means device builds, emulator builds and tests, mulet build and tests, and b2gdroid builds. You're right that for apis that are turned on by prefs in tests that's a gray area. That will be on the module owners to decide what to do. -- Fabrice Desré Connected Devices Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML-based chrome and
On 02/26/2016 01:26 PM, Ehsan Akhgari wrote: > Without intending to start a shadow discussion on top of what's already > happening on the internal list (sadly), to answer your technical > question, the "platform"/Firefox point is a false dichotomy. As an > example, you can create a new application target similar to browser, > b2g/dev or mobile/android, select that using --enable-application, and > start to hack away. That should make it possible to create a > non-Firefox project on top of Gecko. You can use an HTML file for > browser.startup.homepage, and you can use if you > need to load Web content. So it's definitely possible to achieve what > you want as things stand today. Look at what you need to implement to get the simplest gecko based product that builds with --enable-application=my_great_app and compare it to the same project as an Electron app. There's no surprise why people are not using gecko here. Just having to build a custom gecko for N platforms is big drawback. Oh, and you're obviously Tier 100 when you do that, so you have to chase gecko's changes, sec fixes etc. It's not whether it's doable (especially not whether a gecko engineer can do it) but if it's a reasonable tool for others to use. Gecko is not one unfortunately. -- Fabrice Desré Connected Devices Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HTML-based chrome and
On 02/26/2016 02:42 PM, Ehsan Akhgari wrote: >> Look at what you need to implement to get the simplest gecko based >> product that builds with --enable-application=my_great_app and compare >> it to the same project as an Electron app. > > I never said that it is as easy as Electron, did I? :-) Ben explicitly > said he doesn't care for Electron compat, hence my suggestion. But your suggestion is not a reasonable alternative for people looking at an alternative to Electron, even with no api compat. >> It's not whether it's doable (especially not whether a gecko engineer >> can do it) but if it's a reasonable tool for others to use. Gecko is not >> one unfortunately. > > Who are these "others"? If you are talking about a random person who > wants to create a new desktop app, then yes, that solution is far from > desirable. If you're talking about a Mozilla engineer wanting to create > a new product on top of Gecko that is completely separate from Firefox, > this is the way to do it. If you're implying that in order to satisfy > the second use case we need to solve the first one, then I'm not sure if > I agree. I say that we should focus more on solving the first use case, since the second one is ... not really a problem for a Mozilla engineer and happens rarely. But if your point is that we should not care about 3rd party devs that want to use gecko, I'm puzzled - that seems like major shortsightedness coming from a 'platform' team. If I misunderstood, my apologies. -- Fabrice Desré Connected Devices Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: b2g builds on trunk- perma failing for weeks?
On 03/21/2016 08:31 AM, jmaher wrote: I have noticed that since March 4th, the b2g builds on m-c are perma failing. Doing some basic searching we have about 15 hours of machine time going to failed builds on every push (which is ~1350 builds or 20,250 machine hours). These show up in mozreview as failed jobs when you autoland a push. I assume we plan to get all of these builds green and tests green, otherwise we wouldn't keep them running on every push for inbound/fx-team/central. Do we need to keep these running on inbound and fx-team, or can they only run on mozilla-central? I assume somebody is working on getting the builds to green up, could we be made aware of the work done here (maybe a tracking bug) so it doesn't seem that we are just letting builds run because we can? We need them on inbound, yes. I think https://bugzilla.mozilla.org/show_bug.cgi?id=1257127 is tracking the fix. thanks, -- Fabrice Desré Connected Devices Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Non-standard stuff in the /dom/ directory
On 08/16/2016 09:05 PM, Kyle Huey wrote: On Tue, Aug 16, 2016 at 8:56 PM, wrote: I'm wondering, would it be worth while cleaning up the dom/ directory to move non-standard stuff out of there? There is a bunch of legacy stuff from B2G that could be moved out to, say, b2g/apis or some such for historical reasons. It would make searching/working-with for standardized DOM related stuff much easier. s/moved out/deleted/ This is a complicated subject caught in a variety of internal politics. I suggest you raise it with your management chain ;) Or just start by fixing https://bugzilla.mozilla.org/show_bug.cgi?id=1291291 which is up for grabs. -- Fabrice Desré Connected Devices Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: packaged apps and origins
On Fri, 26 Apr 2013 09:31:30 -0700, Ben Adida wrote: >> 3. I recall talking with Fabrice that this was a non-trivial amount of >> work for fixing this, > > I'm having trouble seeing how that is. We can stage the feature in a > couple of ways, first by letting marketplace packaged apps claim an > origin. That's one line in the manifest and a change to the app's origin > from app:// to app://facebook.com. The self-hosted use case can be > fixed later. Because my understanding was that people wanted packaged apps to have http (s) origins to allow them to retrieve data from remote sites without using CORS or SystemXHR. If this is just about choosing the app://XXX origin, this is much simpler indeed. But it doesn't really solve the issue for eg. some oauth providers that only accept http(s) redirection URIs. The origin of hosted apps is already the origin of the manifest, so I don't think we have anything to change there. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting the current UI locale from C++
Hi Henri,
On Thu, 29 Aug 2013 10:12:05 +0300, Henri Sivonen wrote:
> How do I get the language code for the currently active UI language pack
> from within Gecko C++ code in a way that works across desktop, Android,
> B2G and Metro?
A c++ version of could work:
let chrome = Cc["@mozilla.org/chrome/chrome-registry;1"]
.getService(Ci.nsIXULChromeRegistry)
.QueryInterface(Ci.nsIToolkitChromeRegistry);
let locale = chrome.getSelectedLocale("global")
Fabrice
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
webidl events and JS implementations
In the download api we are working on for b2g, a download event in webidl
looks like:
[Constructor(DOMString type, optional DownloadEventInit eventInitDict)]
interface DownloadEvent : Event
{
readonly attribute DOMDownload? download;
};
dictionary DownloadEventInit : EventInit
{
DOMDownload? download = null;
};
DOMDownload is also defined in webidl, and has no xpidl equivalent, but
has a js/xpcom implementation.
I'm creating a download event with :
let event = new this._window.DownloadEvent("downloadstarted", {
download: createDOMDowloadObject(this._window, data)
});
where createDOMDownloadObject() returns a xpcom object implementing the
webidl interface. However this fails with this error:
[JavaScript Error: "'download' member of DownloadEventInit does not
implement interface DOMDownload." {file: "jar:file:///system/b2g/omni.ja!/
components/DownloadsAPI.js" line: 62}]
Is there a trick to get the js object to be seen as implementing
DOMDownload?
Fabrice
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Icon fonts in FxOS
On 06/18/2014 04:51 AM, Andreas Gal wrote: >> So for certified app, we landed a fast path. It would be good to >> investigate if this is purely related to the CSP or not, by simply >> disabling it (security.csp.enable = false), and if yes, investigate if >> reducing the number of files by aggregating them helps. > > Please profile this. I am sure this can be optimized. We likely don’t > need to involve xpconnect here for starters. The xpconnect overhead should have disappeared with the new c++ csp implementation that Sid's team landed. The hardcoded implementation of the certified apps csp is still there though, and will be hard to beat perf wise. I'm not sure how many resources the app is loading at startup, but the csp cost is mostly linear with the resource number and that adds up. Fabrice -- Fabrice Desré b2g team Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement/ship: Support for msApplication-TileImage/Color
On Sun, 03 Aug 2014 14:37:40 -0700, Florian Bender wrote: > Am Freitag, 1. August 2014 18:11:23 UTC+2 schrieb Wesley Johnston: >> Link to standard: There is no public standard in place for these >> meta-tags and none in progress either. > > Have you seen https://github.com/whatwg/meta-theme-color ? Indeed, and we have support for the theme-color meta in b2g through the mozbrowser api. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to support apple-touch-icon with Browser API
On Mon, 04 Aug 2014 10:42:49 +0100, Gervase Markham wrote: > On 28/07/14 17:12, Dale Harvey wrote: >> We specifically chose a User Agent to something compatible with our >> Android release to get more compatible websites, despite the "standard" >> way would be to not do browser sniffing. > > I'm not quite sure what you mean here. Who is "we" in that sentence? The > Content HTTP Headers team did a load of analysis and decided that the UA > for Firefox OS should not contain "Android". Has that changed for some > or all of Firefox OS without us knowing? No, we still don't send Android on b2g. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Non-backward compatible changes to JS 'let' semantics
Hi, On 08/13/2014 02:29 PM, Shu-yu Guo wrote: > We are in the process of making JS 'let' semantics ES6-compliant in > SpiderMonkey. I hope to land bug 1001090 sometime this month or early next > month (I've been told there's a B2G uplift on Sept 1st), which is one of many > for ES6 'let'-compliance. It changes 'let' semantics in two non-backward > compatible ways: We are less 3 weeks away from b2g branching (Sept 1st) and there is no way we can take such a risk there. So yes please, wait for Sept 2 to break the world ;) > I can fix (or can find someone to fix) code that is in mozilla-central. But > code that is outside of that tree will be problematic. Namely, Gaia and > addons. > Can someone own updating Gaia JS to be ES6-compliant? It is unclear to me what > should be done about addons. Gaia doesn't use |let| at all, so there's nothing to do there. Fabrice -- Fabrice Desré b2g team Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [PresentationAPI] Intend to implement
On Mon, 15 Sep 2014 17:04:28 -0400, Ehsan Akhgari wrote: > On 2014-09-15, 5:47 AM, Kilik kuo wrote: >> One more thing, >> >> We would like to support URL of app scheme for requesting session. >> And the scope will be as below. >> - Certified and Privileged with declaration of origin apps are >> supported. >> - Privileged apps w/o declaration of origin are NOT supported. >> - Remote UA will launch the URL of app scheme only when this app is >> already installed on device. Once URL of packaged hosted app is landed, >> remote UA can launch installed app via the URL of http scheme. >> (Maybe the 1st version of API will support app scheme for certified app >> only) > > I'm not sure if I understand how a remote UA is supposed to render an > app:// URL coming from a privileged app? The app needs to be installed on both UAs, but to ensure we have a common origin on both sides, only apps that declare their origin will be supported. I'd like us to get packaged hosted apps done instead of needing to support this, so I think this should be relatively low priority. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Evaluating the performance of new features
On Sat, 31 Jan 2015 20:05:46 +0800, Philip Chee wrote: > On 31/01/2015 14:03, Vladan Djeric wrote: >> We do need a performant key-value store implementation. This has been >> discussed before and various people have come up with proposals (myself >> included), but no one has had the time & focus to see it through to the >> end :/ >> I suspect part of the problem is that different use cases (IndexedDB >> re-implementation, prefs, simple storage, etc) have different >> requirements so no single solution satisfies everyone. I doubt I'll >> have time in Q1 but this is definitely something I want to do, or help >> out with, if some one else would like to step up. > > Are we going to roll our own or use an existing OSS implementation like > SQLite4 or LMDB? It was decided 2,5 years ago to not use LevelDB (https:// bugzilla.mozilla.org/show_bug.cgi?id=leveldb). Maybe it's time to revisit this decision? Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XULRunner future and ownership
On Wed, 29 Jul 2015 14:30:00 -0400, Benjamin Smedberg wrote: > If I do not find a suitable owner in the next two weeks, I intend to > remove the XULRunner code from the mozilla-central repository on > 14-August. Two weeks during summer time seems a bit short. You may not get interested people that are vacationing. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Coordinating landing on m-c and c-c
In Bug 778668 I'm making changes to the nsIAlertsService that impacts code in m-c and c-c. What's the best way coordinate these landings while not breaking c-c? My m-c patch will do m-i -> m-c -> c-c, but I have no idea which revision of m-c is picked up by c-c and when. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
