Re: Return-value-optimization when return type is RefPtr

2016-05-24 Thread
jww...@mozilla.com writes:

> For
>
> RefPtr GetFoo() {
>   RefPtr foo;
>   // ...
> }
>
> should we:
>
> 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release
> 2. return foo.forget()
> 3. return Move(foo)
>
> Which one is preferred?
>
> ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also 
> true for other compilers.

I think the current practice is to use already_AddRefed as return
type and return foo.forget()

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


Out parameters, References vs. Pointers (was: Proposal: use nsresult& outparams in constructors to represent failure)

2016-04-20 Thread
Nicholas Nethercote  writes:

> Hi,
>
> C++ constructors can't be made fallible without using exceptions. As a result,
> for many classes we have a constructor and a fallible Init() method which must
> be called immediately after construction.
>
> Except... there is one way to make constructors fallible: use an |nsresult&
> aRv| outparam to communicate possible failure. I propose that we start doing
> this.

Current coding style guidelines suggest that out parameters should use
pointers instead of references. The suggested |nsresult&| will be
consistent with |ErrorResult&| usage from DOM but against many other out
parameters, especially XPCOM code.

Should we special case that nsresult and ErrorResult as output
parameters should always use references, or make it also the default
style for out parameters?

I think this topic has been discussed before didn't reach a
consensus. Based the recent effort to make the code using somewhat
consistent style, should we expend on this on the wiki?

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


Re: now available on desktop Firefox

2016-03-08 Thread
It's only available to chrome code on desktop. For FxOS I'm not sure how
the permission model will evolve.

Kanru

Chris Mills  writes:

> So I guess this means we need to move the API out of Firefox-OS-specific 
> APIs, and back into the regular APIs section?
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/API/Browser_API
>
> And this is only available to privileged code on desktop (and FxOS still), 
> right?
>
> Chris Mills
>  Senior tech writer || Mozilla
> developer.mozilla.org || MDN
>  cmi...@mozilla.com || @chrisdavidmills
>
>> On 7 Mar 2016, at 21:55, J. Ryan Stinnett  wrote:
>> 
>> Do you like HTML? Do you like to build core browsing UI for desktop
>> Firefox? Now you can have both together!
>> 
>> In more detail,  is now enabled[1] on desktop Firefox.
>> This makes it possible to create frames for displaying web content (similar
>> to a ) from HTML chrome pages. This is the same system that
>> B2G has used for some time to display web content from an HTML UI. (This
>> feature is not available to web content and is not meant to be used there.)
>> 
>> This gives us a core building block that can be used to build a fully HTML
>> browser UI. Of course, the existing UI has many XUL / XBL dependencies, but
>> this is at least one step. The DevTools team plans to use this new feature
>> quite soon as part of a refreshed Responsive Design Mode. Additionally, it
>> should make it easier for projects like browser.html to run from unmodified
>> Firefox.
>> 
>> By default,  can't access the storage used by
>>  for cookies and other site data, making it hard to share page
>> state across the two browser frame types. An additional feature > mozbrowser noisolation> has been added, which gives the frame access to the
>> same storage as . This is only meant for use on desktop
>> Firefox to allow HTML and XUL browser frames to work together.
>> 
>> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1238160
>> 
>> - Ryan
>> ___
>> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: dump() calls now available in NSPR logging

2016-01-07 Thread
Kyle Huey  writes:

> In Bug 1059469 I added a logging module for calls to dump() on Window
> and WorkerGlobalScope.  You can enable it with
> NSPR_LOG_MODULES="Dump:5".  This is really handy when you're using
> other logging modules and want to see how content script execution
> fits into the logging output.

This is great! You said Window and WorkerGlobalScope so I guess this is
not for chrome JS. A related issue, regarding to OneLogger (Bug 881389)
should we also unify the chrome JS logging story with NSPR logging?

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


New memory profiling tool available

2015-11-16 Thread
Hi!

This is an on going project that recently moved into a usable state. The
objective is to let developers profile their website or apps to analyze
their memory allocation characteristics. For example it could be used to
find memory allocation hot spots that might give memory pressure to
other apps on the system.

The profiler is designed at the very beginning to support not only
JavaScript but also native codes. Naturally, not only JavaScript objects
but also native allocations are tracked.

It samples memory allocation based on accumulated allocation sizes so it
could detect both rapid allocations and large allocations. Each
allocation sampled has size and stack trace recorded so these sampled
events can be used to approximate the full history of allocations
afterwards. It also impose very low overhead on the system being
profiled.

Currently the gecko support has been landed on mozilla-central and
enabled by default. The ability to sample native allocations is enabled
when replace-malloc is enabled, which is default on Nightly.

The user interface is developed as an devtools add-on. Once installed it
could be accessed from developer toolbar or WebIDE.
Here are instructions for installing and using the Memory Profiler add-on:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Memory_Profiler

We also plan to work on a command line interface for scripting and
custom post-processing.

Here is the project page if you are interested and want to contribute:
https://wiki.mozilla.org/MemoryProfiler

Please try it out and file bugs in the "Core" product and "Gecko
Profiler" component! We want this to be a useful tool for _you_!

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


Make sure DOM modifications are drawn onto the screen

2015-11-12 Thread
Hi,

This has been discussed briefly on public-web-perf
https://lists.w3.org/Archives/Public/public-web-perf/2015Mar/0009.html

When we measure an app's performance, we want to measure what a user
actually sees. For example when we insert something to the DOM and place
a performance marker; The marker does not reflect the timing when the
user observes the update but only reflects the timing when the DOM
operation is finished.

This is crucial to get realistic performance measurement. We often could
only use high speed camera but it's not widely available.

I think I could explain what I want in this simple example:

  // do the work to update DOM
  performance.delayedMark('drawn', 'visuallyLoaded');

The UA should add the marker when modifications up to that point have
been drawn onto the screen.

We cannot simply use rAF because it could change the performance
characteristic and we can't easily correlate a frame to our js code.
Combining rAF and frame timing API might achieve what we want but
frame timing API only reports "slow-frame" now; it also cannot avoid the
use of rAF.

Do you think this API makes sense? Would it be very hard to implement in
gecko?

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


Re: Intent to implement: Metrics API for FxOS data collection

2015-05-04 Thread
Tamara Hills  writes:

> Summary: We want to expose a Web API to Gaia to collect metrics for FxOS.
> This API would leverage the existing Gecko toolkit/components/telemetry
> capabilities to provide histograms to Telemetry Servers for analysis by
> data owners.

This is interesting. I wanted to do use the User Timing API to collect
performance telemetry data recently. Currently we collect the app
startup time data to http://raptor-ui.divshot.io/ but we plan to add
more probes to better understand the performance situation of Gaia
apps. Will this replace raptor in the long-term?

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


Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

2015-03-30 Thread
Bobby Holley  writes:

> On Mon, Mar 30, 2015 at 10:54 AM, Chris Peterson 
> wrote:
>
>> On 3/29/15 3:35 PM, smaug wrote:
>>
>>> Having the one commit in the blame doesn't really matter. Often one
>>> needs to go to the first commit of the code anyway.
>>>
>>
>> Is there an hg or git equivalent to Perforce's "Time-Lapse View" tool? It
>> shows a global view of a file's blame history and you can visually "scrub"
>> through the blame history.
>>
>
> You mean like git log -p FILE? I'm sure there are fancier graphic ways to
> visualize it, but that's the way I usually scrub my way back through
> restyles etc.

I think Chris might want to follow the history of a particular line,
that is usually what we use flame for. I find |git gui blame |
very useful.

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


Re: gecko-dev and Git replication will be broken for a little while

2015-01-30 Thread
Tim Guan-tin Chien  writes:

> On Fri, Jan 30, 2015 at 6:48 AM, Mike Hommey  wrote:
>>
>> People using Git for Gecko development can also try a new workflow that
>> doesn't involve gecko-dev at all.
>>
>> http://glandium.org/blog/?page_id=3438
>>
>> Mike
>
> This sure look promising!
>
> Any support for Level 1 people for creating a patch-to-commit for
> attaching on Bugzilla?
> I tried :jlebar's moz-git-tools once but the exported patch was broken for hg.

I use this alias in ~/.gitconfig

  [alias]
hg-format-patch = !sh -c 'git format-patch -kp -U8 "$@"|tee 
/dev/stderr|xargs git-patch-to-hg-patch' git

Get git-patch-to-hg-patch from https://github.com/mozilla/moz-git-tools

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


Test coverage?

2014-11-25 Thread
Hi,

Currently we have many tests that are skipped for various reasons. Do we
have data on which test runs on which platforms? For example if a test
is accidentally skipped on all platforms, could we identify it?

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


Policy of EXPORTS?

2014-11-24 Thread
Hi,

Do we have policy about what headers should/could be in EXPORTS? I found
that some exported headers include other headers that aren't exported so
the header using site has to use LOCAL_INCLUDES which IMO defeats the
purpose of EXPORTS.

So exporting more headers could fix it, but that leads to the question
about what headers should/could be in EXPORTS. I don't know much about
the history of embedding gecko but I guess the exported files were
considered part of the stable API?

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


Re: How to use 'require' in XPCOM javascript components?

2014-11-18 Thread
Yonggang Luo  writes:

> I was trying to use require('sdk/') to import
> some javascript libraries in 
> XPCOM javascript components.
> But I can not do that.

You need to import "require" first

  const require = Cu.import("resource://gre/modules/devtools/Loader.jsm", 
{}).devtools.require;

then you could require the modules you want.

Disclaimer: I don't know whether using sdk modules in XPCOM components
is allowed or not. Presumably you're writing addons then it's ok..

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


Re: Git -> Hg workflows?

2014-11-01 Thread
Gregory Szorc  writes:

> I'm trying to learn more about how the people who use Git for
> Firefox/Gecko development manage interacting with repositories that
> have their canonical home in Mercurial (mozilla-central, Try,
> etc). I'm doing this to ensure the replacement Try architecture will
> be usable by Git users.
>
> I'm looking for more information and trying to tease out the relative
> popularity and pain points of the technical solutions for the
> following tasks:
>
> a) Landing code to inbound, fx-team, aurora, etc

I have an git alias

 hg-format-patch = !sh -c 'git format-patch -kp -U8 "$@"|tee /dev/stderr|xargs 
git-patch-to-hg-patch' git

So I could use |git hg-format-patch -| or |git hg-format-patch |
as using |git format-patch|. That also ensures the generated patch has
enough lines of context. I think git-patch-to-hg-patch is from moz-git-tools.

The generated patches could then be upload to bugzilla for review or
applied to a canonical hg repo and push.

> b) Pushing to Try

git hg-format-patch mozillaorg/master
cd $hg;
hg qimport $git/*.patch
hg qpush -a
hg try -m'try syntax'

> c) Fetching new commits

git remote update

> d) Collaborating/sharing commits with others, especially hg<->git
> sharing

changes are published to github. Collectors usually pull directly from
github or use patches attached to bugzilla.

Kanru

> I found https://etherpad.mozilla.org/moz-git-tools and the like-named
> GitHub repo with a suite of Mozilla-centric Git commands. These seem
> to be largely based on top of low-level patch format conversion and
> make little attempt (if any) to preserve commit SHA-1 mappings to
> enable bi-directional conversion (i.e. they are unidirectional, lossy
> tools). Many of them seem to have `hg` invocations buried under the
> covers.
>
> I'm interested in knowing how people feel about these "hidden hg"
> tools. Is going through a hidden, local hg bridge seamless?
> Satisfactory? Barely tolerable? A horrible pain point? (I noticed some
> of the hg interactions in moz-git-tools aren't optimal. If these are
> important tools, please ping me off list so I can help you improve
> them.)
>
> Is moz-git-tools the de facto standard for Mozilla developers? Are
> there other competing tools?
>
> Does anyone use hg-git (it has gotten *much* faster in the past year
> thanks to Facebook's investment)?
>
> I'm particularly interested in knowing if any Git developers have been
> able to eliminate local hg completely. i.e. you are fetching and
> pushing from/to Git repos exclusively. If so, what are you using? What
> limitations do you have?
>
> Overall, how happy are you with your Git fetch/push workflows? Short
> of switching the canonical repositories to Git, what do you need to be
> more productive?
>
> I'm asking all these questions because I'm helping design the
> replacement architecture for Try and the more optimal solutions that
> will deliver a faster and better user experience tend to be easier to
> implement for Mercurial and may partially preclude Git because, well,
> Git just doesn't have the extensibility points as Mercurial (yay
> extensions and dynamic programming languages). I'm not saying Git
> users would be locked out: I'm just saying that having Mercurial
> running locally and "proxying" certain actions through Mercurial (like
> Try pushes) keeps more options on the table. It also means we have to
> design, implement, and maintain 1 server interface instead of 2. From
> my perspective, I like the server-side simplicity. But I'm also
> largely ignorant of what Git users are going through. I'm trying to
> gauge whether additional effort is warranted to placate the Git
> crowd. I'd like to gauge things like e.g. how loudly people would
> scream if one day I announced that pushing to Try will require a
> Mercurial extension. (If that day comes, the carrot would be near
> instantaneous pushes with no contention and infinite server-side
> scalability to millions of pushes.)
>
> Gregory
> ___
> 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: Intent to Implement:

2014-10-20 Thread
Ehsan Akhgari  writes:

> On 2014-10-13, 10:35 PM, Kan-Ru Chen (陳侃如) wrote:
>> Jonas Sicking  writes:
>>
>>> On Mon, Oct 13, 2014 at 4:36 PM, Kan-Ru Chen (陳侃如)  
>>> wrote:
>>>> Jonas Sicking  writes:
>>>>
>>>>> This will only be exposed to privileged and certified apps, right?
>>>>> Other content that does createElement("webview") will simply get a
>>>>> HTMLUnknownElement, right?
>>>>
>>>> Correct.
>>>
>>> Cool, then this sounds great to me!
>>>
>>> Where is this API discussed? I'd like to take the opportunity to fix
>>> some of the bugs that we have in .
>>
>> Cool. Please post your ideas to dev-webapi with [webview] prefix in
>> subject.
>
> Well, <http://benfrancis.github.io/webview/> is mostly empty right
> now, so that may be hard to do.  :-)  Should we discuss the API more
> before we move towards implementing it?

Let's get started and send proposals :)

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


Re: Intent to Implement:

2014-10-13 Thread
Jonas Sicking  writes:

> On Mon, Oct 13, 2014 at 4:36 PM, Kan-Ru Chen (陳侃如)  wrote:
>> Jonas Sicking  writes:
>>
>>> This will only be exposed to privileged and certified apps, right?
>>> Other content that does createElement("webview") will simply get a
>>> HTMLUnknownElement, right?
>>
>> Correct.
>
> Cool, then this sounds great to me!
>
> Where is this API discussed? I'd like to take the opportunity to fix
> some of the bugs that we have in .

Cool. Please post your ideas to dev-webapi with [webview] prefix in
subject.

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


Re: Intent to Implement:

2014-10-13 Thread
Jonas Sicking  writes:

> This will only be exposed to privileged and certified apps, right?
> Other content that does createElement("webview") will simply get a
> HTMLUnknownElement, right?

Correct.

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


Intent to Implement:

2014-10-13 Thread
Summary: 
 Currently we have  which has a bunch additional
 functionality than simple  and is a top level browsing context
 by itself. Having  avoids overloading  and provides
 clarity. We also think this is the right direction towards the
 standardization of the browser-element.

 For the story of  see
 https://hacks.mozilla.org/2014/08/building-the-firefox-browser-for-firefox-os/

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

Link to standard:
 Currently no formal standard. Ben Francis has created a draft which
 largely resembles the current mozbrowser API. Google and Microsoft both
 have their  implementation similar to this proposal.

 http://benfrancis.github.io/webview/
 https://developer.mozilla.org/en-US/docs/Web/API/Using_the_Browser_API
 https://developer.chrome.com/apps/tags/webview
 http://msdn.microsoft.com/en-gb/library/windows/apps/dn301831.aspx

Platform coverage:
 Initially on Firefox OS

Estimated or target release:
 Firefox OS 2.4

Preference behind which this will be implemented:
 It will be behind a pref dom.enable_webview. The html5 parser should be
 taught to treat the tag as HTMLUnknownElement when preffed off.


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Using c++11 right angle bracket in template code?

2014-10-01 Thread
Cameron McCormack  writes:

> On 01/10/14 17:57, Kan-Ru Chen (陳侃如) wrote:
>> It seems all the compilers we use support the c++11 ">>" in template,
>> could we start using it in new code?
>
> Yes we have some uses of that already.  It's also mentioned in
> https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code.

Thanks, I found it. It's listed under the Foo> feature.

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


Using c++11 right angle bracket in template code?

2014-10-01 Thread
Hi,

It seems all the compilers we use support the c++11 ">>" in template,
could we start using it in new code?

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


PSA: TabParents now also live in content processes

2014-08-20 Thread
Hi all,

As a part of the ongoing nested content process work[1][2], the
TabParent now could be created in a content process so please don't
assume it's in the chrome process. Passing PBrowser around in ipdl
protocol is not safe either, because the PBrowser may live in a
different protocol tree. If you absolutely need to pass a PBrowser in
the protocol, please use PBrowserOrId (bug 1041419).

Before the testing infrastructure is ready[3] we could only track this
issue by hand. Many bugs has already been filed and tracked in [1]. The
feature is currently pref'ed off but reviewers please be aware of this
and suggest alternative way to implement if they use TabParent/PBrowser
incorrectly.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=nested-oop
[2]: https://wiki.mozilla.org/Nested_Content_Processes
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1038620

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


Re: Proposed W3C Charter: HTML5 Chinese Interest Group

2014-02-11 Thread
Kyle Huey  writes:

> On Wed, Feb 12, 2014 at 3:27 AM, L. David Baron  wrote:
>> W3C is proposing a revised charter for the HTML5 Chinese Interest
>> Group.  For more details, see:
>> http://www.w3.org/2013/12/html-ig-zh-charter.html
>> http://lists.w3.org/Archives/Public/public-new-work/2014Jan/0007.html
>>
>> Mozilla has the opportunity to send comments or objections through
>> February 24.  Please reply to this thread if you think there's
>> something we should say.
>
> Does Mozilla have someone who would be interested in and capable of
> following discussions in this group?

I'm subscribed to the mailing list but was not following the discussions
very closely. Is there anything I could do in addition to follow the
discussions?

Kanru

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


Re: Parallel sandboxed iframes

2014-01-19 Thread
Bill McCloskey  writes:

>> About the front-end breakages, the ongoing e10s work should help with
>> that right?  I mean, do we usually make assumptions about what frame the
>> content process belongs to, or whether the iframe content process is the
>> same as the iframe host content process?
>
> Unfortunately, we do often make assumptions like that. But once we
> make the initial transition to electrolysis, it should just be a
> matter of ensuring that messages go to the right process. I don't know
> much more than that though, since I haven't looked closely enough at
> the patches in bug 879475.

>From the front-end point of view there shouldn't be much difference of
same process or difference content process using frame message manager,
since the detail of communications are hidden under the hood.

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


Re: How to create a child process in a chrome mochitest?

2013-09-06 Thread
You need to enable the mozbrowser attribute by flipping

 dom.mozBrowserFramesEnabled

And you need the "browser" permission.

layout/base/tests/test_remote_passpointerevents.html is a good example.

  Kanru

Nicholas Nethercote  writes:

> Hi,
>
> I want to create a child process in
> toolkit/components/aboutmemory/tests/test_memoryReporters.xul, so I
> can test the cross-process memory reporting.
>
> In theory, this is as easy as  or  remote>, or something like that.  But I've tried about 80 different
> variations on these, and I cannot get a child process.
>
> This is the closest I've got:
>
> remote="true"/>
>
> AIUI, the |html:| prefix and the |="true"| attribute values are
> necessary because this is a XUL file and hence XML.  My 
> element looks like this:
>
>  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul";
> xmlns:html="http://www.w3.org/1999/xhtml";>
>
> With the above code I do get an iframe that loads about:about, which
> is good.  But there's no child process created, and when I inspect the
> |remote| attribute of the iframe it is |undefined|, as if something
> prevented it from being set to true.
>
> What am I doing wrong?  The docs
> (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe and
> https://developer.mozilla.org/en-US/docs/WebAPI/Browser?redirectlocale=en-US&redirectslug=DOM%2FUsing_the_Browser_API
> and https://developer.mozilla.org/en-US/docs/XUL/iframe) make it
> sounds like this should be easy.
>
> Nick
> ___
> 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: gps support in g2g

2012-09-09 Thread
Hi,

albert.vi...@gmail.com writes:

> Just read about new OS for mobile devices and am anxious to learn more
> about it.  We are presently developing a mobile banking app for Latin
> America using Android, but the new G2G system seems ideal for our
> market.  Can anyone out there throw some light into this issue?  I
> assume the new phones would be equipped with a GPS chip, but I may be
> mistaken.

I'm developing the GPS backend support for Firefox OS, the functionality
could be accessed through the geolocation API¹. Currently all of our
hardware for development has GPS chip built-in and it is on the roadmap,
so I think you can assume it will be there.

  Kanru

[1]: https://developer.mozilla.org/en-US/docs/Using_geolocation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform