Re: Killing the Moz Audio Data API
On 10/17/2013 12:09 AM, Ehsan Akhgari wrote: I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of Web Audio. We added a deprecation warning for this API in Firefox 23 (bug 855570). I'm not sure what our usual process for this kind of thing is, should we just take the patch, and evangelize on the broken websites enough times so that we're able to remove the feature in a stable build? Thanks! -- Ehsan http://ehsanakhgari.org/ I thought some games/emscripten still relied on the Moz Audio API. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Killing the Moz Audio Data API
The other day, while testing some B2G v1.2 stuff, I noticed the Moz Audio Data deprecation warning flying in adb logcat. So you probably need to check with B2G/Gaia people about the timing to kill this API. Benoit 2013/10/16 Ehsan Akhgari ehsan.akhg...@gmail.com I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of Web Audio. We added a deprecation warning for this API in Firefox 23 (bug 855570). I'm not sure what our usual process for this kind of thing is, should we just take the patch, and evangelize on the broken websites enough times so that we're able to remove the feature in a stable build? Thanks! -- Ehsan http://ehsanakhgari.org/ ___ 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: Cost of ICU data
On 10/17/13 12:02 PM, Gervase Markham wrote: On 16/10/13 16:02, Axel Hecht wrote: We'll need to go down a path that works for Firefox OS. With Firefox OS, we don't have the download-size issue, do we? So we can ship all the data. Gerv We have issues with disk space, currently. We're already in the situation where all our keyboard data doesn't fit on quite a few of the devices out there. Also, FOTA size matters a bit, though that's probably less of a problem. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/16/13 5:39 PM, Jeff Walden wrote: On 10/16/2013 02:10 PM, Axel Hecht wrote: I wonder how far we can get by doing something along the lines we use for webfonts, starting to do the best we can with the data we already have, and improve once the perfect data is local. Having the Intl.Foo algorithms returning different data over time is, IMO, even worse than deciding that certain locales are less important than others. Aside from Math.random, of course, I can't think of anything in JS that has different behavior on the same inputs over time. Jeff For one, I don't think that's true for web. You might think so in terms of stuff in the js specs, but the distinction between that and html5 and all kinds of server errors and timing differences is just theory. More importantly, the impact of supporting a finite set of languages can easily be the nail in the coffin for the others. I don't think that's what mozilla stands for. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
On 12.10.2013 08:51, al...@yahoo.com wrote: This applies to xp without acceleration: 1. Fx 15: grayscale aa in the urlbar https://bugzilla.mozilla.org/show_bug.cgi?id=828073 2. Fx 18: bad cleartype (gamma?) on selected menu items https://bugzilla.mozilla.org/show_bug.cgi?id=828192 3. Fx 27: grayscale aa in menus https://bugzilla.mozilla.org/show_bug.cgi?id=926023 It's difficult to understand why something as fundamental as text rendering is allowed to regress like this. You can help ensure that we don't ship such regressions by setting the appropriate tracking flag such as tracking-firefox27? and narrowing down the regression range (e.g. identify the first broken nightly or hourly build if available). Obviously this is already too late for the first two regressions. Dao ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
On Thursday, October 17, 2013 1:54:48 PM UTC+2, Dao wrote: On 12.10.2013 08:51, al...@yahoo.com wrote: This applies to xp without acceleration: 1. Fx 15: grayscale aa in the urlbar https://bugzilla.mozilla.org/show_bug.cgi?id=828073 2. Fx 18: bad cleartype (gamma?) on selected menu items https://bugzilla.mozilla.org/show_bug.cgi?id=828192 3. Fx 27: grayscale aa in menus https://bugzilla.mozilla.org/show_bug.cgi?id=926023 It's difficult to understand why something as fundamental as text rendering is allowed to regress like this. You can help ensure that we don't ship such regressions by setting the appropriate tracking flag such as tracking-firefox27? and narrowing down the regression range (e.g. identify the first broken nightly or hourly build if available). Obviously this is already too late for the first two regressions. Dao I've already narrowed down the second issue back in February by compiling revisions myself (as much as I could, many of the revisions in between won't build) and reported my findings in bug 812871. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 16.10.2013 17:02, Axel Hecht wrote: We'll need to go down a path that works for Firefox OS. [...] But, yes, I think we'll need a hosted service to provide that data on demand in the end. This sounds like a non-starter for mobile devices, doesn't it? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
char16_t in Mozilla code
I landed bug 895047 last night which makes the following changes: 1. It makes the char16_t type globally available across the tree. 2. It defines PRUnichar and jschar to be char16_t. These changes do not affect NSPR and NSS, but the char16_t type is ABI compatible with the PRUnichar type used in those libraries so things should work fine. I'm planning to follow up with a massive replacing of PRUnichar with char16_t across the tree soon if this patch sticks. See bug 927728 if you're interested in that. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/17/13 2:41 PM, Dao wrote: On 16.10.2013 17:02, Axel Hecht wrote: We'll need to go down a path that works for Firefox OS. [...] But, yes, I think we'll need a hosted service to provide that data on demand in the end. This sounds like a non-starter for mobile devices, doesn't it? Well, it makes the implementation trickier. Of course, telefonica just updated the phones from 1.0.1 to 1.1 in spain, over the air without charges, so the infrastructure is there. It's an organizational effort to tie into that infrastructure. We'll need a reference implementation like we have with software update, and then get the our partner contacts in shape to explain how to do that on their side. Plus customizable hooks, of course. And then, yes, we'd need to still disable the downloads, or make them really optional, if you're on roaming data or something. But software update can do that already, too, I suspect. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Killing the Moz Audio Data API
Looks like the comms app has some residual use of the old audio API: apps/communications/dialer/js/keypad.js:this._audio.mozSetup(1, this._sampleRate); apps/system/emergency-call/js/keypad.js: this._audio.mozSetup(2, this._sampleRate); Should be easy to replace. I will file a bug and make sure we do this for 1.3. Andreas On Oct 17, 2013, at 3:02 AM, Benoit Jacob jacob.benoi...@gmail.com wrote: The other day, while testing some B2G v1.2 stuff, I noticed the Moz Audio Data deprecation warning flying in adb logcat. So you probably need to check with B2G/Gaia people about the timing to kill this API. Benoit 2013/10/16 Ehsan Akhgari ehsan.akhg...@gmail.com I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of Web Audio. We added a deprecation warning for this API in Firefox 23 (bug 855570). I'm not sure what our usual process for this kind of thing is, should we just take the patch, and evangelize on the broken websites enough times so that we're able to remove the feature in a stable build? Thanks! -- Ehsan http://ehsanakhgari.org/ ___ 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: Cost of ICU data
On Thu, Oct 17, 2013 at 3:46 AM, Axel Hecht l...@mozilla.com wrote: We have issues with disk space, currently. We're already in the situation where all our keyboard data doesn't fit on quite a few of the devices out there. Where can one read more about this? This ICU data is not *that* huge. If we can't afford a couple of megabytes now on B2G then it seems like we're in for severe problems soon. Isn't Gecko alone growing by megabytes per year? Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Killing the Moz Audio Data API
On 10/17/2013 2:28 AM, smaug wrote: On 10/17/2013 12:09 AM, Ehsan Akhgari wrote: I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of Web Audio. We added a deprecation warning for this API in Firefox 23 (bug 855570). I'm not sure what our usual process for this kind of thing is, should we just take the patch, and evangelize on the broken websites enough times so that we're able to remove the feature in a stable build? Thanks! -- Ehsan http://ehsanakhgari.org/ I thought some games/emscripten still relied on the Moz Audio API. Can the moz audio API be implemented in terms of the web audio api as a JS shim? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Killing the Moz Audio Data API
On 2013-10-17 9:29 AM, Andreas Gal wrote: Looks like the comms app has some residual use of the old audio API: apps/communications/dialer/js/keypad.js:this._audio.mozSetup(1, this._sampleRate); apps/system/emergency-call/js/keypad.js: this._audio.mozSetup(2, this._sampleRate); Should be easy to replace. I will file a bug and make sure we do this for 1.3. I think Etienne is working on rewriting that code to use Web Audio already. Cheers, Ehsan On Oct 17, 2013, at 3:02 AM, Benoit Jacob jacob.benoi...@gmail.com wrote: The other day, while testing some B2G v1.2 stuff, I noticed the Moz Audio Data deprecation warning flying in adb logcat. So you probably need to check with B2G/Gaia people about the timing to kill this API. Benoit 2013/10/16 Ehsan Akhgari ehsan.akhg...@gmail.com I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of Web Audio. We added a deprecation warning for this API in Firefox 23 (bug 855570). I'm not sure what our usual process for this kind of thing is, should we just take the patch, and evangelize on the broken websites enough times so that we're able to remove the feature in a stable build? Thanks! -- Ehsan http://ehsanakhgari.org/ ___ 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: Killing the Moz Audio Data API
On 2013-10-16 6:56 PM, Matthew Gregan wrote: At 2013-10-16T17:09:50-0400, Ehsan Akhgari wrote: I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of Web Audio. We added a deprecation warning for this API in Firefox 23 (bug 855570). I'm not sure what our usual process for this kind of thing is, should we just take the patch, and evangelize on the broken websites enough times so that we're able to remove the feature in a stable build? Nice timing, I filed bug 927245 about this yesterday. I've got a patch that builds, but a few things still need to be addressed (mentioned in the initial comment). Great minds think alike! ;-) I commented on the bug. Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
On Oct 17, 2013, at 8:07 AM, bram.speecka...@gmail.com wrote: I've already narrowed down the second issue back in February by compiling revisions myself (as much as I could, many of the revisions in between won't build) and reported my findings in bug 812871. Aside that I was going to mail off-list, but it might help others: thanks for doing that! Narrowing regression ranges is a pain, but extremely helpful in finding problems. Doing it by building on each bisect is extra-exciting, and I appreciate your work, there. If you (or others reading this) are helping to hunt down regression ranges in the future, consider this my regularly scheduled pitch for mozregression. http://harthur.github.io/mozregression/ It takes a minute to learn how it works, but it will bisect through nightlies and let you say yes, good or no, bad until it finds a one-day range, and then give you an hg-link to the range itself. Awfully helpful, and yet I'm often surprised to find that people don't know about it. J --- Johnathan Nightingale VP Firefox @johnath ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Killing the Moz Audio Data API
On 2013-10-17 10:06 AM, Benjamin Smedberg wrote: On 10/17/2013 2:28 AM, smaug wrote: On 10/17/2013 12:09 AM, Ehsan Akhgari wrote: I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of Web Audio. We added a deprecation warning for this API in Firefox 23 (bug 855570). I'm not sure what our usual process for this kind of thing is, should we just take the patch, and evangelize on the broken websites enough times so that we're able to remove the feature in a stable build? Thanks! -- Ehsan http://ehsanakhgari.org/ I thought some games/emscripten still relied on the Moz Audio API. Can the moz audio API be implemented in terms of the web audio api as a JS shim? It can be approximated, but the exact semantics cannot be replicated. However that may be fine for small games using this API since they're probably not that performance intensive. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Studying Lossy Image Compression Efficiency
This is the discussion thread for the Mozilla Research blog post entitled Studying Lossy Image Compression Efficiency, and the related study. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Studying Lossy Image Compression Efficiency
Blog post is here: https://blog.mozilla.org/research/2013/10/17/studying-lossy-image-compression-efficiency/ Study is here: http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feature tracking via bug keyword
- Original Message - Lukas Blakk wrote: This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now picks up on the keyword 'feature' in your meta/tracking bugs. Please add this to your feature work to make sure it gets early QA, Stability, PR, User Advocacy, and Release Management awareness in preparation (and in support) of their initial launch. What counts as a feature? At this point I would consider any major change to the browser as a 'feature'. This is definitely a judgement call. As Juan pointed out with QA, I would consider flagging any work that requires cross team collaboration (QA, releng, IT, etc.), that makes a significant, user or dev visible change (i.e. changes to the UI and changes to DOM/JS APIs), or that you think should be relnoted or announced on the Mozilla blog (alerting comms). I'm sure there are other suitable criteria and just because one or more of these criteria are met doesn't mean you necessarily have to flag a bug as a feature. We should learn as we go. I think over flagging is welcome at this point. Lawrence ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/17/13 3:41 PM, Brian Smith wrote: On Thu, Oct 17, 2013 at 3:46 AM, Axel Hecht l...@mozilla.com wrote: We have issues with disk space, currently. We're already in the situation where all our keyboard data doesn't fit on quite a few of the devices out there. Where can one read more about this? This ICU data is not *that* huge. If we can't afford a couple of megabytes now on B2G then it seems like we're in for severe problems soon. Isn't Gecko alone growing by megabytes per year? I wish there were docs and clear cuts. We've been in dire problems already, when our QA smoketest phones wouldn't get updates for days due to system.img being too large. And thus we didn't get QA to run tests. These are the questions I asked last time, and don't have answers to: - What exactly are the limiting sizes? -- image size (per bootloader?) -- disk partition size --- at which point in time? user dependent? --- can we have telemetry for this, if so? I suspect we're talking about the joint size for gaia and gecko, but I'm not sure that's the case, or at least always the case. I.e., do we get a cookie if we move data from gaia into gecko? There's probably more that I don't know, just because I don't know much about phones, and the various processes to get software on to them. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Killing the Moz Audio Data API
Yes, I pinged him an hour ago, and he plans to replace all uses of Audio Data API by Web Audio. I think he posted in the bug. Paul. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Monitoring software being installed on performance test machines
tl:dr: We recently installed system monitoring software on our buildbot masters, build-not-test slaves, and various other RelEng machines. IT want to continue this rollout, deploying monitoring software onto RelEng production test machines, which raises a concern about possible impact to performance numbers. If you see any production impact, please let us know. == We are being asked by IT to deploy monitoring tools onto all build, unittest and performance testing machines. These are to help gather system level statistics about CPU, memory, disk utilization, etc. This is so IT can monitor efficiency of production jobs run on these systems. This monitoring software has already been installed on buildbot masters, linux+mac builders, and some misc other servers. As those changes were zero-risk to production, we didn't need to forewarn these newsgroups. However, installing this software on production win32/64 builders and win/mac/linux performance testers has a small-but-non-zero risk that the act of running these tools will change the timing results in performance test jobs. Hence this advance notice. Exact timing of this rollout is waiting on some unrelated win64 toolchain builder fixes to finish being deployed into production. We all agreed that adding these monitoring tools *at the same time* as doing windows toolchain upgrade, would unnecessarily complicate problem detection. Once everything is ready for final deploy, another post will be sent to newsgroup (and sheriffs), to help with any possible after-the-fact regression range hunting. If there are any performance result wobble because of these changes, I've been told we can tolerate minor performance result disruption for a week or so, without impacting releases. Currently, this experiment is slated to run for 2 weeks, but obviously, if this monitoring introduces larger disruption, we will disable them asap. Sheriffs and RelEng buildduty will be monitoring closely, but as always, if you see anything weird, please make sure they know asap. No downtime is required, as our systems will pick up these changes between test runs as machines reboot. The curious can follow along in bug#920626 (deploy collectd to RelEng mac+linux test systems) and bug#920629 (deploy graphite client to RelEng Windows build and test systems). If you've any questions, or concerns, please let me know. John. signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Monitoring software being installed on performance test machines
We have enough tooling in place to see if these affect performance or not. What we will need is a clear demarcation of when the change is made to each OS. Ideally the change would go out across all OS's at the same (or nearly the same) time. If we can at least get the change rolled out across all OS's within the same small number of hours (or at worst the same day) that will vastly help us determine if there are any impacts to performance testing due to this change. Thanks for the head's up. Clint On 10/17/2013 09:00 AM, John O'Duinn wrote: tl:dr: We recently installed system monitoring software on our buildbot masters, build-not-test slaves, and various other RelEng machines. IT want to continue this rollout, deploying monitoring software onto RelEng production test machines, which raises a concern about possible impact to performance numbers. If you see any production impact, please let us know. == We are being asked by IT to deploy monitoring tools onto all build, unittest and performance testing machines. These are to help gather system level statistics about CPU, memory, disk utilization, etc. This is so IT can monitor efficiency of production jobs run on these systems. This monitoring software has already been installed on buildbot masters, linux+mac builders, and some misc other servers. As those changes were zero-risk to production, we didn't need to forewarn these newsgroups. However, installing this software on production win32/64 builders and win/mac/linux performance testers has a small-but-non-zero risk that the act of running these tools will change the timing results in performance test jobs. Hence this advance notice. Exact timing of this rollout is waiting on some unrelated win64 toolchain builder fixes to finish being deployed into production. We all agreed that adding these monitoring tools *at the same time* as doing windows toolchain upgrade, would unnecessarily complicate problem detection. Once everything is ready for final deploy, another post will be sent to newsgroup (and sheriffs), to help with any possible after-the-fact regression range hunting. If there are any performance result wobble because of these changes, I've been told we can tolerate minor performance result disruption for a week or so, without impacting releases. Currently, this experiment is slated to run for 2 weeks, but obviously, if this monitoring introduces larger disruption, we will disable them asap. Sheriffs and RelEng buildduty will be monitoring closely, but as always, if you see anything weird, please make sure they know asap. No downtime is required, as our systems will pick up these changes between test runs as machines reboot. The curious can follow along in bug#920626 (deploy collectd to RelEng mac+linux test systems) and bug#920629 (deploy graphite client to RelEng Windows build and test systems). If you've any questions, or concerns, please let me know. John. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Studying Lossy Image Compression Efficiency
Thank you for publishing this study, here are my first questions: - Why didn't you include JPEG 2000? - Correct me if I'm wrong but JPEG-XR native color space is not Y'CbCr this means that this format had to perform an extra (possibly lossy) color space conversion. - I suppose that the final lossless step used for JPEGs was the usual Huffman encoding and not arithmetic coding, have you considered testing the later one independently? - The image set is some what biased toward outdoor photographic images and highly contrasted artificial black and white ones, what about fractal renderings, operating systems and 2D/3D games screen-shots, blurry, out of frame or night shots? - I've found only two cats and not a single human face in the Tecnick image set, no fancy à la Instagram filters, this can't be seriously representative of web images, a larger image corpus would be welcome. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
On 10/17/13 7:27 AM, Johnathan Nightingale wrote: If you (or others reading this) are helping to hunt down regression ranges in the future, consider this my regularly scheduled pitch for mozregression. http://harthur.github.io/mozregression/ It takes a minute to learn how it works, but it will bisect through nightlies and let you say yes, good or no, bad until it finds a one-day range, and then give you an hg-link to the range itself. Awfully helpful, and yet I'm often surprised to find that people don't know about it. If a regression is in a recent (~4 weeks) Nightly build, you may be able to further bisect the regression range using TBPL's mozilla-inbound builds: http://ftp-scl3.mozilla.com/pub/mozilla.org/firefox/tinderbox-builds/ chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Add-ons Firefox 24 crash due to recent change in JSAPI
On Wednesday, October 16, 2013 1:53:24 PM UTC+5:30, Bobby Holley wrote:
As you've discovered, there's a lot of magic and boilerpate that's
easy to get wrong. You can find some simple test XPCOM components in
js/xpconnect/components. Try grabbing one of those, making sure that
it works, and then iterating on it to turn it into what you need.
bholley
On Wed, Oct 16, 2013 at 10:16 AM, Vasu Yadav vasuyadavkri...@gmail.com
wrote:
On Friday, October 4, 2013 6:16:36 PM UTC+5:30, Bobby Holley wrote:
On Fri, Oct 4, 2013 at 2:36 PM, vasuyadavkri...@gmail.com wrote:
Based on my understanding, I need to create a JS XPCOM component apart
from the existing C++ XPCOM component I already have. All the JavaScript
function calls need to be made from JS XPCOM component.
Precisely.
How will the C++ XPCOM and JS XPCOM communicate to each other? Can we
instantiate JS XPCOM component from C++ XPCOM Component?
Yes. The great the about XPCOM components is that they can be instantiated
and manipulated in either C++ or JS - the language of the implementation
doesn't matter.
I want to deliver only one .xpi to my customers. I hope it is possible to
package both C++ XPCOM and JS XPCOM components in the same .xpi file.
Please let me know if this is possible and whether you see any problems
in
this approach.
Yep, that should work just fine.
Here are some links that might be useful:
https://developer.mozilla.org/en/docs/How_to_Build_an_XPCOM_Component_in_Javascript
http://kb.mozillazine.org/Implementing_XPCOM_components_in_JavaScript
bholley
Sorry for troubling you again.
I am trying to create one sample JavaScript XPCOM component.But not able to
instantiate JavaScript XPCOM component from C++ code.
Steps to create JavaScript XPCOM component-
1) Create nsIHelloWorld.idl file for nsIHelloWorld interface.
2) Create nsIHelloWorld.js file
3) Generating .xpt and header file using Python22.0.
4) Instantiate JavaScript XPCOM component from C++ code.
Code-
nsIHelloWorld.idl
--
#include nsISupports.idl
[scriptable, uuid(8e001740-322b-11e3-aa6e-0800200c9a66)]
interface nsIHelloWorld : nsISupports
{
string Hellovasu();
};
--
nsIHelloWorld.js
-
Components.utils.import(resource://gre/modules/XPCOMUtils.jsm);
function HelloWorld()
{
}
HelloWorld.prototype = {
classDescription: My Hello World Javascript XPCOM Component,
classID: Components.ID({031572f4-3629-11e3-98fd-ce3f5508acd9}),
contractID: @keynote.com/firefox/helloworld;1,
QueryInterface:
XPCOMUtils.generateQI([Components.interfaces.nsIHelloWorld]),
Hellovasu: function() {
return Hello World!;
}
};
var components = [HelloWorld];
if (XPCOMUtils.generateNSGetFactory)
this.NSGetFactory = XPCOMUtils.generateNSGetFactory([components]); //
Firefox 4.0 and higher
else
var NSGetModule = XPCOMUtils.generateNSGetModule([components]); //
Firefox 3.x
chrome.manifest
--
interfaces components/nsIHelloWorld.xpt
component 031572f4-3629-11e3-98fd-ce3f5508acd9 nsIHelloWorld.js
contract @keynote.com/firefox/helloworld;1
{031572f4-3629-11e3-98fd-ce3f5508acd9}
application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}
---
Instantiate JavaScript XPCOM compnent from C++ code
---
#include nsComponentManagerUtils.h
#include nsIHelloWorld.h
nsCOMPtrnsISupports iSupports =
do_CreateInstance(@keynote.com/Firefox/helloworld;1,rv1);
or
nsCOMPtrnsIHelloWorld ihello =
do_CreateInstance(@keynote.com/Firefox/helloworld;1,rv1);
Not able to instantiate helloworld component.
---
Logs value for IHello and rv1 in hexa formet- IHello=0 rv1=80040154
Do you fell anything missing or wrong in this code? If you have any better
approach or solution please suggest me. I am completely stuck here.
Regards
Vasu
___
Re: Studying Lossy Image Compression Efficiency
On 10/17/2013 9:48 AM, Josh Aas wrote: This is the discussion thread for the Mozilla Research blog post entitled Studying Lossy Image Compression Efficiency, and the related study. HEVC-MSP did really well. Its unfortunate that Mozilla could not use it in any capacity since its tied to the encumbered MPEG HEVC standard. Also, I didn't know that someone was working on a JPEG-XR FOSS encoder. I wonder how it compares to the Microsoft reference encoder. -- == ~Omega X MozillaZine Nightly Tester ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Wanted: Feedback on Windows 64-bit rev2 cutover options
Here are three different proposals to cut over to the new Windows 64-bit rev2 (win64-rev2) machines (see https://groups.google.com/forum/#!topic/mozilla.dev.platform/zACrUe_JwKw for context), along with some of the pros and cons of each approach. I would prefer option #3 (gradual phase-in) so long as we're okay with having a mixed pool of rev1/rev2 win64 build machines on the same branches. Timing will depend on which option we go with. Please let me know as soon as possible your preference or whether you have any other comments/concerns. I will assume option #3 if there are no objections by end of day Friday. In addition, I'd like to have a smoke test performed against the Windows builds on one of our project branches (which have already been cut over) - fx-team or ux seem like good candidates. I will follow up with the QA team. Win64-rev2 Cutover Proposals: 1) Cut over all of inbound/try/central to win64-rev2 over a weekend. Pros: - all branches built using the same machine image - lowest volume of checkins happen on weekends, so less wait time impact Cons: - big bang upgrade. If someone discovers an issue on Monday, a lengthy downtime could be required to resolve it. - build wait times on the weekend could be lengthy or require a tree closure - staffing weekend work is problematic 2) Cut over inbound/try/central branches one at a time, each early on a Monday (over several weeks) Pros: - more people around to find/fix problems Cons: - longer wait times - not all branches using the same build machine image - longer cutover time 3) Gradual phase-in of win64-rev2 machines on inbound/try/central in a mixed rev1/rev2 pool Pros: - limited impact of bustages (due to mixing in a small number of rev2 build machines to start and gradually increasing) - no impact on wait times (could even improve them slightly since we're a bit low on rev1 capacity at the moment) - no weekend work required, can be done during the week as time permits Cons: - mix of rev1/rev2 build machines, mitigated by having exclusively rev2 allocated to project branches for testing rev2-specific bustage fixes Note: This will not impact release branches (aurora, beta, release, esr). We will cut over to those branches only once win64 rev2 has been proven on inbound/try/central. Bug 781277 is the overall tracking bug. Thanks, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/17/2013 10:24 AM, Ehsan Akhgari wrote: We used to have codesighs measurements (and perhaps still do) but historically many people just ignored them. We stopped collecting codesighs measurements in November 2012 (bug 803736). As Ehsan says, it was widely ignored. It regressed constantly, and it never seemed reasonable to demand that people implement desired features and fixes without adding any code. For this reason, I'm a bit confused at the level of scrutiny of ICU's size when we've added many times that amount to our download size over the past couple of years without any pushback or even discussion. (On a related note, what happened to http://www.arewesmallyet.com/?) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Wanted: Feedback on Windows 64-bit rev2 cutover options
Option #3 sounds logical. What way would sheriffs/devs have to determine which machines are rev2 and which ones are rev1? Should they use the info in production_config.py? - rev2 machines: [1] - rev2 (try): currently empty [2] [1] http://hg.mozilla.org/build/buildbot-configs/file/production/mozilla/production_config.py#l8 [2] http://hg.mozilla.org/build/buildbot-configs/file/production/mozilla/production_config.py#l33 On 2013-10-17 2:34 PM, John Hopkins wrote: Here are three different proposals to cut over to the new Windows 64-bit rev2 (win64-rev2) machines (see https://groups.google.com/forum/#!topic/mozilla.dev.platform/zACrUe_JwKw for context), along with some of the pros and cons of each approach. I would prefer option #3 (gradual phase-in) so long as we're okay with having a mixed pool of rev1/rev2 win64 build machines on the same branches. Timing will depend on which option we go with. Please let me know as soon as possible your preference or whether you have any other comments/concerns. I will assume option #3 if there are no objections by end of day Friday. In addition, I'd like to have a smoke test performed against the Windows builds on one of our project branches (which have already been cut over) - fx-team or ux seem like good candidates. I will follow up with the QA team. Win64-rev2 Cutover Proposals: 1) Cut over all of inbound/try/central to win64-rev2 over a weekend. Pros: - all branches built using the same machine image - lowest volume of checkins happen on weekends, so less wait time impact Cons: - big bang upgrade. If someone discovers an issue on Monday, a lengthy downtime could be required to resolve it. - build wait times on the weekend could be lengthy or require a tree closure - staffing weekend work is problematic 2) Cut over inbound/try/central branches one at a time, each early on a Monday (over several weeks) Pros: - more people around to find/fix problems Cons: - longer wait times - not all branches using the same build machine image - longer cutover time 3) Gradual phase-in of win64-rev2 machines on inbound/try/central in a mixed rev1/rev2 pool Pros: - limited impact of bustages (due to mixing in a small number of rev2 build machines to start and gradually increasing) - no impact on wait times (could even improve them slightly since we're a bit low on rev1 capacity at the moment) - no weekend work required, can be done during the week as time permits Cons: - mix of rev1/rev2 build machines, mitigated by having exclusively rev2 allocated to project branches for testing rev2-specific bustage fixes Note: This will not impact release branches (aurora, beta, release, esr). We will cut over to those branches only once win64 rev2 has been proven on inbound/try/central. Bug 781277 is the overall tracking bug. Thanks, John -- Zambrano Gasparnian, Armen (armenzg) Mozilla's Release Engineer https://mozillians.org/en-US/u/armenzg/ http://armenzg.blogspot.ca ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Wanted: Feedback on Windows 64-bit rev2 cutover options
On 13-10-17 3:22 PM, Armen Zambrano Gasparnian wrote: Option #3 sounds logical. Based on feedback I received from joduinn, one small adjustment to option #3: phase-in to try first and wait for confirmation before phasing-in inbound/central to further reduce risk exposure to those branches. What way would sheriffs/devs have to determine which machines are rev2 and which ones are rev1? Should they use the info in production_config.py? - rev2 machines: [1] - rev2 (try): currently empty [2] Yes, using production_config.py would be a sure way to tell the difference. You can also tell them apart by looking at the build root in a build log: rev1 - e:\builds\moz2_slave rev2 - c:\builds\moz2_slave John [1] http://hg.mozilla.org/build/buildbot-configs/file/production/mozilla/production_config.py#l8 [2] http://hg.mozilla.org/build/buildbot-configs/file/production/mozilla/production_config.py#l33 On 2013-10-17 2:34 PM, John Hopkins wrote: Here are three different proposals to cut over to the new Windows 64-bit rev2 (win64-rev2) machines (see https://groups.google.com/forum/#!topic/mozilla.dev.platform/zACrUe_JwKw for context), along with some of the pros and cons of each approach. I would prefer option #3 (gradual phase-in) so long as we're okay with having a mixed pool of rev1/rev2 win64 build machines on the same branches. Timing will depend on which option we go with. Please let me know as soon as possible your preference or whether you have any other comments/concerns. I will assume option #3 if there are no objections by end of day Friday. In addition, I'd like to have a smoke test performed against the Windows builds on one of our project branches (which have already been cut over) - fx-team or ux seem like good candidates. I will follow up with the QA team. Win64-rev2 Cutover Proposals: 1) Cut over all of inbound/try/central to win64-rev2 over a weekend. Pros: - all branches built using the same machine image - lowest volume of checkins happen on weekends, so less wait time impact Cons: - big bang upgrade. If someone discovers an issue on Monday, a lengthy downtime could be required to resolve it. - build wait times on the weekend could be lengthy or require a tree closure - staffing weekend work is problematic 2) Cut over inbound/try/central branches one at a time, each early on a Monday (over several weeks) Pros: - more people around to find/fix problems Cons: - longer wait times - not all branches using the same build machine image - longer cutover time 3) Gradual phase-in of win64-rev2 machines on inbound/try/central in a mixed rev1/rev2 pool Pros: - limited impact of bustages (due to mixing in a small number of rev2 build machines to start and gradually increasing) - no impact on wait times (could even improve them slightly since we're a bit low on rev1 capacity at the moment) - no weekend work required, can be done during the week as time permits Cons: - mix of rev1/rev2 build machines, mitigated by having exclusively rev2 allocated to project branches for testing rev2-specific bustage fixes Note: This will not impact release branches (aurora, beta, release, esr). We will cut over to those branches only once win64 rev2 has been proven on inbound/try/central. Bug 781277 is the overall tracking bug. Thanks, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Studying Lossy Image Compression Efficiency
On Thursday, October 17, 2013 12:50:12 PM UTC-5, cry...@free.fr wrote: Thank you for publishing this study, here are my first questions: - Why didn't you include JPEG 2000? We couldn't test everything, we picked a small set of the formats that we hear the most about and that seem interesting. We're not opposed to including JPEG 2000 in future testing, particularly if we see more evidence that it's competitive. - The image set is some what biased toward outdoor photographic images and highly contrasted artificial black and white ones, what about fractal renderings, operating systems and 2D/3D games screen-shots, blurry, out of frame or night shots? - I've found only two cats and not a single human face in the Tecnick image set, no fancy à la Instagram filters, this can't be seriously representative of web images, a larger image corpus would be welcome. We considered improving the image sets in some of the ways you suggest, we just didn't get to it this time. Trying to be thorough and accurate with these kinds of studies is more work that it seems like it'll be, we couldn't do everything. We'll try to do better with image sets in future work. I still think this set produces meaningful results. Thanks for the feedback. Maybe Tim, Gregory, or Jeff can respond to some of your other questions. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: char16_t in Mozilla code
On Thu, Oct 17, 2013 at 5:58 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: I landed bug 895047 last night which makes the following changes: 1. It makes the char16_t type globally available across the tree. 2. It defines PRUnichar and jschar to be char16_t. Nice! Replacing crusty old custom PR/JS types with modern standard types is tedious but important. Thanks for doing this. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Studying Lossy Image Compression Efficiency
HDR-VDP-2 is relatively recent metric that produces predictions for difference visibility and quality degradation. http://sourceforge.net/apps/mediawiki/hdrvdp/index.php?title=Main_Page It could been interesting to add this metric in future studies. Rafał Mantiuk (the guy behind HDR-VDP-2) also worked on this paper: New Measurements Reveal Weaknesses of Image Quality Metrics in Evaluating Graphics Artifacts http://www.mpi-inf.mpg.de/resources/hdr/iqm-evaluation/ Which leads to think that doing some blinded experiment (real people evaluating the images) to compare compressed images has still some value. It could be fun to conduct such an experience, presenting 2 or 3 versions of the same image compressed with different methods and asking a wide panel (could be open to anyone on the web) to pick their favorite one. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feature tracking via bug keyword
I would include any major rewrites of significant portions of the back end as well. Marc S. - Original Message - From: Lawrence Mandel lman...@mozilla.com To: Cameron McCormack c...@mcc.id.au Cc: Lukas Blakk lsbl...@mozilla.com, dev-platform@lists.mozilla.org, dev-plann...@lists.mozilla.org () dev-plann...@lists.mozilla.org, fx-t...@mozilla.com, mobile-...@mozilla.com Sent: Thursday, October 17, 2013 7:54:52 AM Subject: Re: Feature tracking via bug keyword - Original Message - Lukas Blakk wrote: This wiki page: https://wiki.mozilla.org/Features/Release_Tracking now picks up on the keyword 'feature' in your meta/tracking bugs. Please add this to your feature work to make sure it gets early QA, Stability, PR, User Advocacy, and Release Management awareness in preparation (and in support) of their initial launch. What counts as a feature? At this point I would consider any major change to the browser as a 'feature'. This is definitely a judgement call. As Juan pointed out with QA, I would consider flagging any work that requires cross team collaboration (QA, releng, IT, etc.), that makes a significant, user or dev visible change (i.e. changes to the UI and changes to DOM/JS APIs), or that you think should be relnoted or announced on the Mozilla blog (alerting comms). I'm sure there are other suitable criteria and just because one or more of these criteria are met doesn't mean you necessarily have to flag a bug as a feature. We should learn as we go. I think over flagging is welcome at this point. Lawrence ___ 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
Capturing text from Firefox
Hi, I am working on GUI automation component of a performance monitoring product. One of the common approaches to monitoring application is periodically capture text from the control where changes are expected (content area of the browser for Web applications). Text capturing ideally captures all text, including not selectable and user input. In the product I work on this is achieved by (1) forcing the application to re-draw the texts in the window or part of the window of interest and (2) hooking the functions that responsible for text drawing during the time interval of the capturing is performed. Hooking is performed by modifying the first bytes of the binary code of the hooked functions to jump to the hooking functions, which process the same parameters and then jump back to allow the hooked function to perform their job. In relation to Firefox, his worked well with releases up to 10 ESR (starting from 10, we implement support only to ESR releases), even though with each Ff release forcing the text to be redrawn was more and more difficult. In relation to this I have questions related to both Ff17 and Ff24 (I assume that some answers might be not the same for these releases): Which functions/technologies are drawing the text? Is drawing performed by normal Windows APIs, like DrawTextEx or ExtTextOut, or this is no longer the case? Does Ff use some Microsoft technology which was not used before? Does Ff use its own text drawing functions? Does it delegates drawing to another process? BTW. In relation to these questions, even if I disable use of Direct2D and Direct Write according to http://forums.mozillazine.org/viewtopic.php?t=1775755, I still see DWrite.dll loaded into Firefox.exe process. Does Ff caches drawn text, say, in memory device contexts, so that in case the window or a region needs to be repainted, text does not need to be redrawn and widow device context is updated through functions like BitBlt? If so, can such caching be disabled programmatically or through configuration? Does Ff patch Windows DLLs? Are there other approaches to capturing text form Ff you can suggest? Any help is very much appreciated. Thank you, Yuriy Look | Software Developer | Compuware APM yuriy.l...@compuware.commailto:yuriy.l...@compuware.com 313 227 3107 ... Simply Smarter APM | Compuware.com/APMhttp://www.compuware.com/en_us/application-performance-management.html?utm_source=signatureutm_medium=email | Facebookhttp://www.facebook.com/CompuwareAPM | Twitterhttp://www.twitter.com/CompuwareAPM | APMbloghttp://apmblog.compuware.com/?utm_source=signatureutm_medium=email | Google+http://gplus.to/CompuwareAPM ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
