Re: [b2g] Log collection needs improvement
Thanks Al for raising the issue. To clarify, I didn't say log switch should be centralized in System app. It should be centralized in Gecko. Gaia developers are specifically told not to use |console.log/error| etc. for normal operations because it comes with performance penalty. It sounds like this ended up shoot us in the foot because of these testing needs. What I am looking at is somehow enable us to add logs in Gaia regardless, and introduce a pref in Gecko to turn them on or off. When it's turned off we should not have any performance penalty. Previously we had a creative invention from Frsela that turning on/off a all-caps DUMP() function with mozSettings. I would love that being formalized in Gecko. https://github.com/mozilla-b2g/gaia/blob/master/shared/js/dump.js Is that possible? (PS |console.log| does not comes with the right order if the code throws -- not sure if that can be fixed too.) On Thu, Aug 21, 2014 at 12:16 PM, James Lal ja...@lightsofapollo.com wrote: +sicking, +jst, +paul So over the last few weeks I have had various discussions with people about logging (there are metrics and log like data and bunch of random stuff across gecko/gonk/gaia that fit other names too) we really badly need sane logging data that is reachable by some single source. This is needed for a couple of critical things: - debugging - tests - logs on other peoples phones [dogfooding builds] (another form of debugging but you don't have the device.) We not only need a place to input data (in a wide reaching way) but also nice apis for extracting that data (automation, periodic server side dumps, crazy random new things). Our current situation is pretty awful (I can list the reasons but those involved likely know what I am talking about) and we need to unify efforts to build something better... I spoke with jst about this recently and we are trying to find the right person to fix this. If you feel super excited/angry about logging get in touch with one/any/all of us so we can mentor/bribe/help you through this. - james On Wed, Aug 20, 2014 at 8:09 PM, Al Tsai at...@mozilla.com wrote: Hi all, I am sending this e-mail to start a discussion about current log mechanism. As you might know that we have different ways to collect logs, most kinds of logs need extra actions to enable them since performance issues. With more devices and users, the issues reported may not always come with solid STR (steps to reproduce). Some automation tests (such as MTBF and Orangutan Test) will not always have STR. Worse than that, the logs collected during testing contain no clues for resolving issues most of the time. Currently, the information we can get by adb logcat command is about WiFi. We'll need to use special methods to trigger RIL and it's not known by public. For Gaia logs, we'll need to reach the developers to know how to trigger its logger, or there's no logger due to performance concern. Within offline discuss with Tim, a centralized log mechanism control by the system app could be a solution. Or we can implement the log server inside gecko, direct all configuration to gecko, and let gecko decide when to drop logs. More thoughts are welcome. Best Regards, Al -- Al Tsai Senior QA Engineer, MoCo Taiwan Tel: +886-2-87861100 ext.358 ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g -- Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox OS, Mozilla Corp. (Taiwan) ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Log collection needs improvement
On 21/08/2014 08:21, Tim Chien wrote: Previously we had a creative invention from Frsela that turning on/off a all-caps DUMP() function with mozSettings. I would love that being formalized in Gecko. https://github.com/mozilla-b2g/gaia/blob/master/shared/js/dump.js Standardizing all gaia applications on DUMP() would already be a big improvement even though the interface is currently very simple. Gecko has similar problems regarding logging with certain components being well made and others a total mess (often dumping output via 3/4 different unrelated methods). Also, the most common mechanism used in C++ code (PR_Log) is not available under chrome code and thus we normally resort to ad hoc logging solutions there (see the RIL component for example). Gabriele signature.asc Description: OpenPGP digital signature ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] ZTE Open 1.2 Beta
On 20/08/2014 15:22, Paul Hannington wrote: Although I see that many people have raised the issue regarding ZTE Open updates in the past and it has fallen down a bottomless pit between Mozilla and ZTE, but after seeing the potential improvements which could be achieved by at least one more update (maybe to 1.3 ?) then surely existing owners deserve that ? There's been nothing official from ZTE past that 1.2 beta but there's some custom builds floating around, see here: http://vegnuxmod.wordpress.com/inari-zte-open/ I'm not sure about the relative stability of those images but if you need help moving past 1.2 that looks like a good place to start from. I get a strong feeling from various discussions on the internet that the current ZTE Open experience will ensure that they never by a ZTE device again and possibly not even a Firefox OS device in the future which may be a great shame for everyone. The ZTE Open experience - as far as updates go - has been extremely sketchy and that's really an unfortunate state of affairs. I've been toying with the ZTE Open C and that one has already received multiple (!) updates so they might be getting their update story straight. Gabriele signature.asc Description: OpenPGP digital signature ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Review of QA's Smoketests
For the Dialer, I'm thinking those are important for dogfooders: - Notification of missed calls (could be part of case #1306) - User can use MMI codes. And respond to MMI sessions. (This is useful to check your phone credits) PS: The link works if you're already logged into moztrap. On 20/08/14 23:20, Jason Smith wrote: Hi Everyone, I'd like to get feedback on our current smoketest suite to see if there's agreement or disagreement with the test cases currently included in the test suite. Here is a link to the smoketest suite below: https://moztrap.mozilla.org/runtests/run/5060/env/347/?pagenumber=1pagesize=100 Some questions I'd like feedback on include: 1. Which test cases do you think make sense to be included in a smoketest suite? 2. Which test cases do you think don't make sense to be included in a smoketest suite? 3. Are there test cases you don't see in the test suite that should be included? 4. Do you think the steps in certain test cases make sense or do you think there's some refinement needed on those test cases? Sincerely, Jason Smith ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Log collection needs improvement
On Thu, Aug 21, 2014 at 4:01 PM, Gabriele Svelto gsve...@mozilla.com wrote: On 21/08/2014 08:21, Tim Chien wrote: Previously we had a creative invention from Frsela that turning on/off a all-caps DUMP() function with mozSettings. I would love that being formalized in Gecko. https://github.com/mozilla-b2g/gaia/blob/master/shared/js/dump.js Standardizing all gaia applications on DUMP() would already be a big improvement even though the interface is currently very simple. Gecko has similar problems regarding logging with certain components being well made and others a total mess (often dumping output via 3/4 different unrelated methods). Also, the most common mechanism used in C++ code (PR_Log) is not available under chrome code and thus we normally resort to ad hoc logging solutions there (see the RIL component for example). Gabriele Yeah, but that would mean every app need to read that mozSettings value (and have the permission to access that) right? Plus log will not appear during app start-up until the mozSettings get() returns positive value. I may be naive but I would really love that being done in Gecko... -- Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox OS, Mozilla Corp. (Taiwan) ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Log collection needs improvement
console.log doesn’t have to be slow. Its only slow in Gecko. Its ridiculously fast in Chrome. We should probably simply optimize it. Andreas On Aug 21, 2014, at 8:47 AM, Tim Chien timdr...@mozilla.com wrote: On Thu, Aug 21, 2014 at 4:01 PM, Gabriele Svelto gsve...@mozilla.com wrote: On 21/08/2014 08:21, Tim Chien wrote: Previously we had a creative invention from Frsela that turning on/off a all-caps DUMP() function with mozSettings. I would love that being formalized in Gecko. https://github.com/mozilla-b2g/gaia/blob/master/shared/js/dump.js Standardizing all gaia applications on DUMP() would already be a big improvement even though the interface is currently very simple. Gecko has similar problems regarding logging with certain components being well made and others a total mess (often dumping output via 3/4 different unrelated methods). Also, the most common mechanism used in C++ code (PR_Log) is not available under chrome code and thus we normally resort to ad hoc logging solutions there (see the RIL component for example). Gabriele Yeah, but that would mean every app need to read that mozSettings value (and have the permission to access that) right? Plus log will not appear during app start-up until the mozSettings get() returns positive value. I may be naive but I would really love that being done in Gecko... -- Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox OS, Mozilla Corp. (Taiwan) ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Log collection needs improvement
On 08/21/2014 07:51 AM, Andreas Gal wrote: console.log doesn’t have to be slow. Its only slow in Gecko. Its ridiculously fast in Chrome. We should probably simply optimize it. Yes, it's very ancient code. I think when I tweaked the buffering to limit memory usage some parts had not been touched since... the CVS import! I think it's a nice project for someone that want to get his/her hands dirty with gecko stuff. Fabrice -- Fabrice Desré b2g team Mozilla Corporation ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Log collection needs improvement
There is also the issue of turning the logs on/off. I've come to like the ability to use android properties, since you can manipulate them from the adb shell command line using getprop/setprop. Using preferences is nice on the desktop, because we have a UI that can be used to control them. That same UI is currently unavailable on the phone. The only reason I would use mozSettings is if I wanted some gaia UI to be able to control things. We already have code to allow changes in a mozSetting to update a preference and vice-versa. I'd like to propose that we allow properties to also be updated/have changes reflected in preferences as well. The reason console.log has issues is that console.log requests made by a child are passed via IPC to the parent, and then they're logged. With dump() the call to the android logger happens in the child. linux has an interesting approach to system logging. Everybody uses syslog, and then there is a configuration file/daemon that takes care of actually distributing the log data. On the phone, logcat already takes care of the hard part. We just need to be a bit more clever about integrating things. Right now, all dump calls come out tagged as Gecko. It probably makes sense to tag dump statements from an app using the app name. Then you'd be able to filter your logcat output and just get dumps from a particular app. You can get some very interesting logcat filters. I have a script that automatically does: adb logcat -v threadtime memalloc:I ONCRPC:S HWComposer:S Diag_Lib:S QCALOG:S QCRIL_RPC:S EventHub:I OMX.google.mp3.decoder:V You can add logging categories with :S to silence a particular category (or use *:S to silence everything) and then add back stuff you're interested in. Run adb logcat -h to get full details on filterspecs. If we want the ability to put the logging data off-device, then it probably makes sense to have a daemon that grabs data from logcat and sends it whereever it is that it needs to go. Dave Hylands - Original Message - From: Tim Chien timdr...@mozilla.com To: Gabriele Svelto gsve...@mozilla.com Cc: dev-b2g dev-b2g@lists.mozilla.org, qa-b2g qa-...@mozilla.org, Johnny Stenback j...@mozilla.com, Al Tsai at...@mozilla.com, James Lal ja...@lightsofapollo.com, Jonas Sicking jo...@sicking.cc Sent: Thursday, August 21, 2014 7:47:13 AM Subject: Re: [b2g] Log collection needs improvement On Thu, Aug 21, 2014 at 4:01 PM, Gabriele Svelto gsve...@mozilla.com wrote: On 21/08/2014 08:21, Tim Chien wrote: Previously we had a creative invention from Frsela that turning on/off a all-caps DUMP() function with mozSettings. I would love that being formalized in Gecko. https://github.com/mozilla-b2g/gaia/blob/master/shared/js/dump.js Standardizing all gaia applications on DUMP() would already be a big improvement even though the interface is currently very simple. Gecko has similar problems regarding logging with certain components being well made and others a total mess (often dumping output via 3/4 different unrelated methods). Also, the most common mechanism used in C++ code (PR_Log) is not available under chrome code and thus we normally resort to ad hoc logging solutions there (see the RIL component for example). Gabriele Yeah, but that would mean every app need to read that mozSettings value (and have the permission to access that) right? Plus log will not appear during app start-up until the mozSettings get() returns positive value. I may be naive but I would really love that being done in Gecko... -- Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox OS, Mozilla Corp. (Taiwan) ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
[b2g] API call to get phone number of device?
Hi, I'm working on a very simple app that is just a login entry point for an online service. Login credentials are phone number and a password. Since we are on a phone, it would be nice to pre-fill the phone number input field, so it contains the user's own phone number which should be known to the device. I searched the interfaces described at https://developer.mozilla.org/en-US/docs/Web/API. Telephony MozContacts MozMobileNetworkInfo MozMobileConnectionInfo they don't provide that information. navigator.mozPhoneNumberService seems to be only for matching or normalizing phone numbers of different formats. In the permissions table, I found a permission mobileid, see https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm How can I obtain the user's phone number? ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] API call to get phone number of device?
On 21/08/14 12:59 PM, Daniel Wacker wrote: Since we are on a phone, it would be nice to pre-fill the phone number input field, so it contains the user's own phone number which should be known to the device. It is not always known. Lot of carriers don't bother to have this implemented in their SIM card. Non-withstanding the security implications which IMHO require the app to be certified. Hub ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] API call to get phone number of device?
There's a new API in 2.0, the MSISDN verification API: https://bugzilla.mozilla.org/show_bug.cgi?id=988469 (MSISDN being the hard way to say phone number ;) I don't know if it's documented anywhere yet. On Thu, Aug 21, 2014 at 11:59 AM, Daniel Wacker wac...@tuxen.de wrote: Hi, I'm working on a very simple app that is just a login entry point for an online service. Login credentials are phone number and a password. Since we are on a phone, it would be nice to pre-fill the phone number input field, so it contains the user's own phone number which should be known to the device. I searched the interfaces described at https://developer.mozilla.org/en-US/docs/Web/API. Telephony MozContacts MozMobileNetworkInfo MozMobileConnectionInfo they don't provide that information. navigator.mozPhoneNumberService seems to be only for matching or normalizing phone numbers of different formats. In the permissions table, I found a permission mobileid, see https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm How can I obtain the user's phone number? ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g -- Ian Bicking | Cloud Services Engineering Manager ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
