Re: Add-ons Firefox 24 crash due to recent change in JSAPI
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: unified shader for layer rendering
2013/10/10 Benoit Jacob jacob.benoi...@gmail.com this is the kind of work that would require very careful performance measurements Here is a benchmark: http://people.mozilla.org/~bjacob/webglbranchingbenchmark/webglbranchingbenchmark.html Some results: http://people.mozilla.org/~bjacob/webglbranchingbenchmark/webglbranchingbenchmarkresults.txt Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
Jumping in late, so top posting. I think being able to load language data dynamically is a good idea. I don't see a reason why this should be tied in to a language pack, though. The other way around is a different question. i.e. language data doesn't include UI localization UI localization should include language data We have several multi-language products by now, those should work, in particular Firefox OS. We're doing quite a few things there that already duplicate language data. Much of that is in /shared, which isn't shared, but copied to many apps. Having that data inside gecko would actually get it to be shared. I think much of the ICU data (which is technically CLDR data packed in ICU mostly) flows along similar lines of our hyphenation dictionaries. The web should just work, independent of which UI locale you're using. 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. I'm personally OK if this is a notification bar to reload, even. Axel PS: ICU is driven by js globalization api. That API was driven by MS and Google to get the data into their html app platforms. For mozilla, IMHO, the driver for g18n api should be Firefox OS, we're struggling to work around the lack of data for sorting, timezones, language data all around. On 10/15/13 6:06 PM, Benjamin Smedberg wrote: With the landing of bug 853301, we are now shipping ICU in desktop Firefox builds. This costs us about 10% in both download and on-disk footprint: see https://bugzilla.mozilla.org/show_bug.cgi?id=853301#c2. After a discussion with Waldo, I'm going to post some details here about how much this costs in terms of disk footprint, to discuss whether there are things we can remove from this footprint, and whether the footprint is actually worth the cost. This is particularly important because our user research team has identified Firefox download weight as an important factor affecting Firefox adoption and update rates in some markets. On-disk, ICU data breaks into the following categories: * collation tables - 3.3MB These are rules for sorting strings in multiple languages and situations. See http://userguide.icu-project.org/collation for basic background. These tables are necessary for implementing Intl.Collator. The Intl.Collator API has methods to expose a subset of languages. It is not clear from my reading of the specification whether it is expected that browsers will normally ship with the full set of languages or only the subset of the browser locale. * currency tables - 1.9 MB These are primarily the localized name of each currency in each language. This is used by the Intl.NumberFormat API to format international currencies. * timezone tables - 1.7MB Primarily the name of every time zone in each language. This data is necessary for implementing Intl.DateTimeFormat. * language data - 2.1 MB This is a bunch of other data associated with displaying information for a particular language: number formatting in various long and short formats, calendar formats and names for the various world calendar systems. == Do we need this data for any language other than the language Firefox ships in? Can we just include the relevant language data in each localized build of Firefox, and allow users to get other language data via downloadable language packs, similarly to how dictionaries are handled? Is it possible that some of this data (the collation tables?) should be in all Firefox locales, but other data (currency and timezone names) is not as important and we can ship it only in one language? As far as I can tell, the spec allows user agents to ship whatever languages they need; the real question is what users and site authors actually need and expect out of the API. (I'm reading the spec out of http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts) I am still working to get better number to quantify the costs in terms of lost adoption for additional download weight. Also, we are currently duplicating the data tables on mac universal builds, because they are compiled-in symbols. We should clearly use a separate file for these tables to avoid unnecessary download/install weight. This is now filed as bug 926980. --BDS ___ 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:46:48 PM UTC+5:30, Vasu Yadav 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: @vasu.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 @vasu.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(@vasu.com/Firefox/helloworld;1,rv1);
or
nsCOMPtrnsIHelloWorld ihello =
do_CreateInstance(@vasu.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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 15/10/13 17:06, Benjamin Smedberg wrote: With the landing of bug 853301, we are now shipping ICU in desktop Firefox builds. This costs us about 10% in both download and on-disk footprint: see https://bugzilla.mozilla.org/show_bug.cgi?id=853301#c2. After a discussion with Waldo, I'm going to post some details here about how much this costs in terms of disk footprint, to discuss whether there are things we can remove from this footprint, and whether the footprint is actually worth the cost. This is particularly important because our user research team has identified Firefox download weight as an important factor affecting Firefox adoption and update rates in some markets. You have given on-disk footprint values, but surely download size values are the important ones for the issue you are raising? After all, some of this data may be very compressible, and some may not. * currency tables - 1.9 MB These are primarily the localized name of each currency in each language. This is used by the Intl.NumberFormat API to format international currencies. * timezone tables - 1.7MB Primarily the name of every time zone in each language. This data is necessary for implementing Intl.DateTimeFormat. I wonder if we could do this as a webservice? That is, when the browser is asked to render a timezone string or a currency string in a particular language, it goes and grabs all the data for that language. We could therefore have full support, but a one-off delay for each new language the user wanted to see UI rendered in (which, for most people, will be a very small set). We could ship a set of common ones plus the UI language one to reduce still further the number of times the service would get hit. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Faster builds, now ; on windows, too.
Hi, Episode 1 was the You want faster builds, don't you thread. Episode 2 was the Faster builds, now thread. Here comes episode 3. I'm sure fellow developers building on Windows felt sad that they were left out on the recent build improvements. Rejoice at last, as we are now bringing those to you. As of current mozilla-inbound, and I'm sure mozilla-central soon, it only takes a few steps: - Download the mozmake binary from http://people.mozilla.org/~mhommey/mozmake.exe and place it in some location in your $PATH. c:\mozilla-build\msys\local\bin is probably good for most people. See bug 927213 if you want to know how it was built. It will eventually be shipped in next release of MozillaBuild. - Add the following to your mozconfig: export MOZ_PSEUDO_DERECURSE=no-pymake (Note this should become the default next week) - Build with: ./mach build After you built once, you can do edit-compile-edit-compile cycles with: ./mach build binaries Enjoy the faster build times. Cheers, Mike PS: mozmake is also being tested on the birch branch, and it is showing promising turnaround times on Windows build slaves (-35 minutes on opt builds, -1 hour on debug builds ; most of which is, surprisingly, is gained on make check, see https://bugzilla.mozilla.org/show_bug.cgi?id=925605#c13 ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On Wed, Oct 16, 2013 at 2:39 PM, Gervase Markham g...@mozilla.org wrote: I wonder if we could do this as a webservice? That is, when the browser is asked to render a timezone string or a currency string in a particular language, it goes and grabs all the data for that language. We could therefore have full support, but a one-off delay for each new language the user wanted to see UI rendered in (which, for most people, will be a very small set). We could ship a set of common ones plus the UI language one to reduce still further the number of times the service would get hit. The API is synchronous so that seems like a bad idea. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 16/10/13 14:47, Anne van Kesteren wrote: The API is synchronous so that seems like a bad idea. As in, it'll cause the tab to freeze (one time only, when a new language is called for) while the file is downloading? OK, that's bad, but so is having Firefox be a lot bigger... Perhaps, as Brian suggested, we should be looking at using the Windows APIs and/or system ICU for some of this data, even if there are some things for which we want to ship our own implementation. Gerv ___ 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 3:50 PM, Gervase Markham wrote: On 16/10/13 14:47, Anne van Kesteren wrote: The API is synchronous so that seems like a bad idea. As in, it'll cause the tab to freeze (one time only, when a new language is called for) while the file is downloading? OK, that's bad, but so is having Firefox be a lot bigger... Perhaps, as Brian suggested, we should be looking at using the Windows APIs and/or system ICU for some of this data, even if there are some things for which we want to ship our own implementation. Gerv We'll need to go down a path that works for Firefox OS. I think that being less-than-great at the first time you hit something off the main track is OK. We should see what actually happens with what's in the g18n apis now. We'll likely also need a way to free excessive use of disk space, or DOS attacks by sneaking up little fragments of language content for 200 languages or somesuch. But, yes, I think we'll need a hosted service to provide that data on demand in the end. 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/2013 12:45 AM, Karl Tomlinson wrote: When sync I/O is performed to read in-binary-object data, how is that better? Just readahead? Readahead, it being part of the binary/libxul/whatever so already one coherent file to load, etc. I'm not aware that you can reasonably predict adjacency predictions from the OS if you use separate files. But I could be mistaken about that. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Summit Innovation Fair: Improving developer productivity at Mozilla?
- Original Message - At the summit's Innovation Fairs, Mozilla's program management team will be hosting Developer Productivity booths to gather suggestions for streamlining our development processes and reducing developer frustration. What speed bumps are getting you down? Hardware, software, tools, trees, hg, git, builds, Bugzilla, bugmail, code reviews, office noise, Vidyo, or something else? Bring your ideas to the Innovation Fairs on Saturday between 11:30 AM to 1:30 PM. After the summit, we'll review the suggestions and try to address the most pressing issues. Our plan is for this to be just the beginning of an ongoing improvement program. :) Thank you to those of you who contributed your ideas at the Summit. We have dumped the information that we collected at https://etherpad.mozilla.org/kHpv9jvGMj If you missed us at the Summit and have additional ideas, feel free to add them at the bottom of the etherpad. Chris will provide the rundown and next steps during next week's Engineering meeting and on dev-platform. Lawrence ___ 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/15/2013 1:36 PM, al...@yahoo.com wrote: Why are these ignored? I can't speak for anyone else, but I would guess it's because no one who has looked at them has figured out any useful information to add, or found the time to investigate further. As to whether we should pull someone off of other tasks to focus on these XP text-rendering bugs, that's tricky. They are user-visible regressions and a large portion of our users are on XP. On the other hand, they do not affect web content; XP is a (slowly) shrinking platform; and the difference between grayscale and subpixel AA is jarring to some users but subtle or invisible to others. In general, if I understand correctly, it's hard to use native subpixel AA in layers that use hardware accelerated compositing. So in some cases we might need to choose between speed and subpixel rendering. (I'm not at all an expert in this area, though.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 7:01 PM, Gervase Markham g...@mozilla.org wrote: A quick survey of the security-group led to the following suggestions, and I'm sure there are more: * Character encoding detectors that are not enabled by default for any locale (bugs are already on file). * Multi-byte character encoding converters for encodings that are not in the Encoding Standard (if we still have some of these in the tree; I didn't check). -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ 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 6:39 AM, Gervase Markham wrote: You have given on-disk footprint values, but surely download size values are the important ones for the issue you are raising? After all, some of this data may be very compressible, and some may not. Can we repackage the ICU data so we can compress it using a smarter content-aware algorithm? We could decompress the ICU data on first use. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/16/2013 9:39 AM, Gervase Markham wrote: On 15/10/13 17:06, Benjamin Smedberg wrote: You have given on-disk footprint values, but surely download size values are the important ones for the issue you are raising? After all, some of this data may be very compressible, and some may not. Correct. The download weight costs are listed in the bug, https://bugzilla.mozilla.org/show_bug.cgi?id=853301#c2 MacOS X, 32+64 bit (dmg):60.7 MB 54.7 MB 5.9 MB 10.8 % Windows, 32 bit (installer.exe): 22.4 MB 20.5 MB 1.9 MB9.2 % I don't know whether there is a way to more optimally compress these in the installer. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shumway UX
Greetings, We are having a UX kick off meeting today at Noon PDT, in Vidyo-Shumway. I'll post notes here since I know this is really short notice. We will also likely discuss the conclusions/next steps in tomorrow's 11AM PDT Cross-Functional for folks who can't join today. Erin On Oct 9, 2013, at 12:05 PM, Jet Villegas j...@mozilla.com wrote: Hi All: I hope everyone had a chance to see Shumway on the big screen at the Summit. I'm very proud of what the Shumway team has accomplished to date. While the demos looked amazing, we've got quite a bit to do to get Shumway to a product-ready state. In particular, the user experience on desktop and mobile need focused design and integration work to get right. The integration with other Firefox features (eg. click-to-play) also needs special consideration. I'm preparing some mock-ups of some ideas I have re: UX based on my own observations and experiences with both Shumway and the Adobe Flash Player. I should have these ready to share by the end of the week. I'm not alone in thinking about the problems to solve here, and I'd like to get the discussion going on this thread. Please share your own experiences/concerns/ideas. We meet every Thursday at 11:00AM Pacific. Please join us on the #shumway IRC channel to get the meeting details. Thanks, --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Feature tracking via bug keyword
Hello all, 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. Thank you, Lukas *-*-*-*-*-* Release Manager, Mozillian mozillians.org/lsblakk ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
Matt Brubeck writes: On 10/15/2013 1:36 PM, al...@yahoo.com wrote: Why are these ignored? As to whether we should pull someone off of other tasks to focus on these XP text-rendering bugs, that's tricky. So in some cases we might need to choose between speed and subpixel rendering. Many people use browsers for reading text, so I would like to claim that text rendering quality is usually more important than performance. I apologize for not looking through the referenced bugs. My information is that XP is still considered an important platform. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
Matt Brubeck mbrub...@mozilla.com wrote in message news:525eb9f5.8050...@mozilla.com... On 10/15/2013 1:36 PM, al...@yahoo.com wrote: Why are these ignored? I can't speak for anyone else, but I would guess it's because no one who has looked at them has figured out any useful information to add, or found the time to investigate further. As to whether we should pull someone off of other tasks to focus on these XP text-rendering bugs, that's tricky. They are user-visible regressions and a large portion of our users are on XP. On the other hand, they do not affect web content; XP is a (slowly) shrinking platform; and the difference between grayscale and subpixel AA is jarring to some users but subtle or invisible to others. In general, if I understand correctly, it's hard to use native subpixel AA in layers that use hardware accelerated compositing. So in some cases we might need to choose between speed and subpixel rendering. (I'm not at all an expert in this area, though.) This is non accelerated rendering using old, stable, xp era rendering apis. There's no question that proper cleartype rendering can be achieved. This all used to work even with the post 4.0 rendering susbsytem, these are relatively recent regressions (15, 18, 27). It's unreasonable that after a decade of adequate rendering on xp it should start falling apart like this. ___ 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 Wed, Oct 16, 2013 at 1:39 PM, al...@yahoo.com wrote: In general, if I understand correctly, it's hard to use native subpixel AA in layers that use hardware accelerated compositing. So in some cases we might need to choose between speed and subpixel rendering. (I'm not at all an expert in this area, though.) This is non accelerated rendering using old, stable, xp era rendering apis. There's no question that proper cleartype rendering can be achieved. This all used to work even with the post 4.0 rendering susbsytem, these are relatively recent regressions (15, 18, 27). It's unreasonable that after a decade of adequate rendering on xp it should start falling apart like this. I agree with the others that correct ClearType rendering is more important than whatever performance gain we'd get by having poor ClearType rendering. ClearType is one of the biggest reasons keeping me using Windows instead of switching to other platforms; I almost feel like I couldn't work without it. Further, because we generally have quite small text in our browser chrome, ClearType rendering in Chrome is especially important to get right, at least in the address bar. My understanding is that Windows XP is our top platform or second-to-top platform behind Windows 7. We have more Windows XP users than we have on Mac, Linux, B2G, and Android combined, right? Because most people at Mozilla don't run Windows, and especially because almost nobody at Mozilla runs Windows XP (and nobody should, inside or outside of Mozilla), it may be a little too easy for us to marginalize concerns like this, since we have no dogfooding and because non-Windows users probably have a hard time grasping the importance of ClearType for many end-users. Still, I think this issue is one that is more appropriately discussed on dev-firefox, not dev-platform. The dev-firefox mailing list is here: https://mail.mozilla.org/pipermail/firefox-dev/ Note that the dev-firefox mailing list is moderated and I recommend that you use a more positive tone when posting to that mailing list. If you have trouble getting your messages through moderation, let me know and I will help. 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: devolution of cleartype rendering in Fx chrome
On 16/10/13 22:52 , Brian Smith wrote: On Wed, Oct 16, 2013 at 1:39 PM, al...@yahoo.com wrote: In general, if I understand correctly, it's hard to use native subpixel AA in layers that use hardware accelerated compositing. So in some cases we might need to choose between speed and subpixel rendering. (I'm not at all an expert in this area, though.) This is non accelerated rendering using old, stable, xp era rendering apis. There's no question that proper cleartype rendering can be achieved. This all used to work even with the post 4.0 rendering susbsytem, these are relatively recent regressions (15, 18, 27). It's unreasonable that after a decade of adequate rendering on xp it should start falling apart like this. I agree with the others that correct ClearType rendering is more important than whatever performance gain we'd get by having poor ClearType rendering. ClearType is one of the biggest reasons keeping me using Windows instead of switching to other platforms; I almost feel like I couldn't work without it. Further, because we generally have quite small text in our browser chrome, ClearType rendering in Chrome is especially important to get right, at least in the address bar. My understanding is that Windows XP is our top platform or second-to-top platform behind Windows 7. We have more Windows XP users than we have on Mac, Linux, B2G, and Android combined, right? Because most people at Mozilla don't run Windows, and especially because almost nobody at Mozilla runs Windows XP (and nobody should, inside or outside of Mozilla), it may be a little too easy for us to marginalize concerns like this, since we have no dogfooding and because non-Windows users probably have a hard time grasping the importance of ClearType for many end-users. Still, I think this issue is one that is more appropriately discussed on dev-firefox, not dev-platform. The dev-firefox mailing list is here: https://mail.mozilla.org/pipermail/firefox-dev/ Note that the dev-firefox mailing list is moderated and I recommend that you use a more positive tone when posting to that mailing list. If you have trouble getting your messages through moderation, let me know and I will help. Cheers, Brian Err, I would actually think that this is the correct list. The issue has little to do with Firefox-the-application (and how its browser chrome is defined as opposed to other XUL/HTML applications) and everything with how the platform renders text in the browser. I'm unaware of the front-end code doing anything special here (CSS or markupwise) that breaks the ClearType/AA support. ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Killing the Moz Audio Data API
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
compositor IPC crashes
https://bugzilla.mozilla.org/show_bug.cgi?id=893404 and https://bugzilla.mozilla.org/show_bug.cgi?id=898825 are two of the last parent-process crash bugs in the current e10s-crash list (https://bugzilla.mozilla.org/show_bug.cgi?id=899758). Drew and I are planning to let the background thumbnailing service (which exposes these crashes on Desktop) ride the 27 train to beta, to get some better feedback about their severity (in terms of users affected/frequency). They both appear at a high level to be IPC issues with the compositor. I know you're busy, but any insight or investigative resources graphics folk could offer on these would be appreciated! Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Killing the Moz Audio Data API
On Wed, Oct 16, 2013 at 10:09 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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? For obscure DOM methods we do the warnings, then give it a try in nightlies and see if anyone screams. So yeah, you want to do that I think. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed build system Q4 goals
The proposed quarterly goals for the build system have been posted to dev.builds and will be discussed at a meeting in ~24 hours. If you are interested in influencing what build work happens this quarter, now is the opportunity to get engaged. Please keep discussion unified on dev.builds. https://groups.google.com/forum/#!topic/mozilla.dev.builds/PUebwBF6Ewk ___ 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 2:26 PM, Anne van Kesteren wrote: For obscure DOM methods we do the warnings, then give it a try in nightlies and see if anyone screams. So yeah, you want to do that I think. Sounds good to me. -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
Possible crazy idea: do we actively track and send tree management notices when package or binary size changes? This seems like something we'd want to cover under the perf regressions get backed out or need approval policy. It may also help identify build system regressions and compiler oddities where sections in the binaries change in size surprisingly. On 10/15/13 9:06 AM, Benjamin Smedberg wrote: With the landing of bug 853301, we are now shipping ICU in desktop Firefox builds. This costs us about 10% in both download and on-disk footprint: see https://bugzilla.mozilla.org/show_bug.cgi?id=853301#c2. After a discussion with Waldo, I'm going to post some details here about how much this costs in terms of disk footprint, to discuss whether there are things we can remove from this footprint, and whether the footprint is actually worth the cost. This is particularly important because our user research team has identified Firefox download weight as an important factor affecting Firefox adoption and update rates in some markets. On-disk, ICU data breaks into the following categories: * collation tables - 3.3MB These are rules for sorting strings in multiple languages and situations. See http://userguide.icu-project.org/collation for basic background. These tables are necessary for implementing Intl.Collator. The Intl.Collator API has methods to expose a subset of languages. It is not clear from my reading of the specification whether it is expected that browsers will normally ship with the full set of languages or only the subset of the browser locale. * currency tables - 1.9 MB These are primarily the localized name of each currency in each language. This is used by the Intl.NumberFormat API to format international currencies. * timezone tables - 1.7MB Primarily the name of every time zone in each language. This data is necessary for implementing Intl.DateTimeFormat. * language data - 2.1 MB This is a bunch of other data associated with displaying information for a particular language: number formatting in various long and short formats, calendar formats and names for the various world calendar systems. == Do we need this data for any language other than the language Firefox ships in? Can we just include the relevant language data in each localized build of Firefox, and allow users to get other language data via downloadable language packs, similarly to how dictionaries are handled? Is it possible that some of this data (the collation tables?) should be in all Firefox locales, but other data (currency and timezone names) is not as important and we can ship it only in one language? As far as I can tell, the spec allows user agents to ship whatever languages they need; the real question is what users and site authors actually need and expect out of the API. (I'm reading the spec out of http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts) I am still working to get better number to quantify the costs in terms of lost adoption for additional download weight. Also, we are currently duplicating the data tables on mac universal builds, because they are compiled-in symbols. We should clearly use a separate file for these tables to avoid unnecessary download/install weight. This is now filed as bug 926980. --BDS ___ 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 16 October 2013 23:10:39, Gregory Szorc wrote: Possible crazy idea: do we actively track and send tree management notices when package or binary size changes? Not at present as far as I know, though Tim Taubert created something temporary last year (no longer accessible, but perhaps worth following up with him): https://groups.google.com/d/msg/mozilla.dev.apps.firefox/k7fzkhdt9io/n6jnbeFsIBMJ Best wishes, Ed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feature tracking via bug keyword
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? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Killing the Moz Audio Data API
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). -mjg ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feature tracking via bug keyword
Anything you think would benefit from people in QA spending quality time doing manual testing qualifies as a feature, for example. There will be times when this is not clear, but if there's a chance an end-user could see the effect, it would be great to see it flagged. juanb - Original Message - From: Cameron McCormack c...@mcc.id.au To: Lukas Blakk lsbl...@mozilla.com Cc: dev-plann...@lists.mozilla.org () dev-plann...@lists.mozilla.org, dev-platform@lists.mozilla.org, fx-t...@mozilla.com, mobile-...@mozilla.com Sent: Wednesday, October 16, 2013 3:48:30 PM Subject: Re: Feature tracking via bug keyword 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? ___ 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/16/2013 1:24 PM, Karl Tomlinson wrote: Many people use browsers for reading text, so I would like to claim that text rendering quality is usually more important than performance. I apologize for not looking through the referenced bugs. To repeat a point from my previous message: These bugs do not affect rendering of text on web pages. They are about rendering of specific items in the Firefox chrome. (That doesn't mean we should ignore the bugs; I'm just addressing the people use browsers for reading comment above.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
Thanks for putting this together, and thanks to everybody working on making the build faster and thus making us all more productive. This sped up clobber build times on Windows for me by 6 minutes, around 22%, which is great. Some of us can't switch to a *nix based platform in order to get faster builds, so thanks very much. Cheers, Chris P. On 17-Oct-13 2:43 AM, Mike Hommey wrote: Hi, Episode 1 was the You want faster builds, don't you thread. Episode 2 was the Faster builds, now thread. Here comes episode 3. I'm sure fellow developers building on Windows felt sad that they were left out on the recent build improvements. Rejoice at last, as we are now bringing those to you. As of current mozilla-inbound, and I'm sure mozilla-central soon, it only takes a few steps: - Download the mozmake binary from http://people.mozilla.org/~mhommey/mozmake.exe and place it in some location in your $PATH. c:\mozilla-build\msys\local\bin is probably good for most people. See bug 927213 if you want to know how it was built. It will eventually be shipped in next release of MozillaBuild. - Add the following to your mozconfig: export MOZ_PSEUDO_DERECURSE=no-pymake (Note this should become the default next week) - Build with: ./mach build After you built once, you can do edit-compile-edit-compile cycles with: ./mach build binaries Enjoy the faster build times. Cheers, Mike PS: mozmake is also being tested on the birch branch, and it is showing promising turnaround times on Windows build slaves (-35 minutes on opt builds, -1 hour on debug builds ; most of which is, surprisingly, is gained on make check, see https://bugzilla.mozilla.org/show_bug.cgi?id=925605#c13 ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey m...@glandium.org wrote: I'm sure fellow developers building on Windows felt sad that they were left out on the recent build improvements. Rejoice at last, as we are now bringing those to you. In case you're interested how this happened... AIUI, these improvements are because make 4.0 came out and it actually implements -jN properly on Windows, and with -jN working it's faster than pymake. (Well, almost properly, which is why glandium had to fix some things. Presumably/hopefully his fixes will end up in make 4.01 soon.) Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster builds, now ; on windows, too.
On Wed, Oct 16, 2013 at 08:09:23PM -0700, Nicholas Nethercote wrote: On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey m...@glandium.org wrote: I'm sure fellow developers building on Windows felt sad that they were left out on the recent build improvements. Rejoice at last, as we are now bringing those to you. In case you're interested how this happened... AIUI, these improvements are because make 4.0 came out and it actually implements -jN properly on Windows, and with -jN working it's faster than pymake. (Well, almost properly, which is why glandium had to fix some things. Presumably/hopefully his fixes will end up in make 4.01 soon.) (FYI, FWIW) -jN itself works properly. I just had to patch for unrelated issues, namely: - a typo that makes $(info), $(warning) and $(error) unreliable at best, or crashy at worst. - attempt to execute msys-path programs (e.g. /usr/bin/install) with CreateProcess() (yeah, that doesn't work well) - enable a builtin workaround for sh.exe not working very very well with quotes in a sh -c command. The latter is a #define in config.h that exists for that purpose but is not enabled by default, the former two are submitted upstream. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
