[Ann] Displaying uncaught asynchronous errors
I am happy to inform you that we have recently landed Bug 903433, which ensures that uncaught errors or rejections in Promise.jsm or Task.jsm are now displayed. So, from now on, if you are attempting to debug asynchronous code using Promise.jsm/Task.jsm, don't forget to look in the browser console output, you should find the error that you are looking for. Additionally, since bug 908955 landed, Promise.jsm/Task.jsm will dump() any programming error (e.g. TypeError, SyntaxError and the ilk) immediately, regardless of whether it is caught. So, keep an eye on your stderr, too. Both changes should make debugging async code much easier. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Cost of ICU data
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: Cost of ICU data
On 15/10/2013 17:06, Benjamin Smedberg wrote: 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. As a heads up, I'm currently intending on using DecimalFormat (a subclass of NumberFormat) to parse numbers from strings as part of implementing type=number>. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On Tue, Oct 15, 2013 at 9:06 AM, Benjamin Smedberg wrote: > 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? My understanding is that web content should not be able to tell which locale the browser is configured to use, for privacy (fingerprinting) reasons. If we went the route suggested above, it would be easy to figure out, for many users, which locale he/she is using. > I am still working to get better number to quantify the costs in terms of > lost adoption for additional download weight. My (naive) understanding is that the Windows has its own API that does what ICU does. I believe that Internet Explorer 11 is an existence proof of that. If we used the Windows API on Windows, maybe we could avoid building ICU altogether on Windows. Since that accounts to 90+% of our users, that would almost make it "problem solved" all on its own even if we did nothing else. 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: Cost of ICU data
On 10/15/2013 06:06 PM, Benjamin Smedberg wrote: > 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? It seems a fairly bad thing to me for us to get into the habit of prioritizing certain languages above others. Technically, if the data is compiled into the code, this would mean language repacks would...not be repacks any more. If you had sidealong data files everywhere, then you could perhaps repack still. This might require some repacking adjustments, possibly. ICU provides a udata_setCommonData function that lets you load data from anywhere, so there's some flexibility here. It's worth noting we currently have no central "hook" to insert this call before ICU's ever used. We init ICU at startup, but that init-call is fast. Presumably this new call can't be so fast, because you have to page in all the ICU data. And if you can't delay that til ICU is used, there's really no difference between the current setup and a setup that calls udata_setCommonData at startup. Of course, this is all just software. :-) > 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) Grunging through v8's code, I...think...they cull locale lists for stuff to some degree. Maybe to the language set they ship. I'm looking at https://code.google.com/p/chromium/codesearch#chromium/src/third_party/icu/README.chromium and honestly don't understand enough about ICU to fully grok the substantial set of changes they've made. > Also, we are currently duplicating the data tables on mac universal builds, > because they are compiled-in symbols. That means sync I/O on the main thread, and not well-optimized because it won't be part of the binary. Just to note. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/15/2013 1:18 PM, Brian Smith wrote: On Tue, Oct 15, 2013 at 9:06 AM, Benjamin Smedberg wrote: 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? My understanding is that web content should not be able to tell which locale the browser is configured to use, for privacy (fingerprinting) reasons. I haven't heard this rule before. By default your browser language affects the HTTP accept-lang setting, as well as things like default font choices. You can certainly customize those back to a non-fingerprintable setting, but I'm not convinced that we should worry about this as a fingerprinting vector. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On Tue, Oct 15, 2013 at 6:45 PM, Benjamin Smedberg wrote: > On 10/15/2013 1:18 PM, Brian Smith wrote: >> My understanding is that web content should not be able to tell which >> locale the browser is configured to use, for privacy (fingerprinting) >> reasons. > > I haven't heard this rule before. By default your browser language affects > the HTTP accept-lang setting, as well as things like default font choices. > You can certainly customize those back to a non-fingerprintable setting, but > I'm not convinced that we should worry about this as a fingerprinting > vector. I think preventing fingerprinting at a technical level is something we've lost though we should try to avoid introducing new vectors. As far as JavaScript API features go, I don't think we should vary our offering by locale. E.g. for Firefox OS we want changing locale to just work and not require a new version of Firefox OS. The same goes for a computer in a hotel or hostel or some such. Firefox should work for each locale users might have set in Gmail. -- 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 10/15/2013 1:50 PM, Anne van Kesteren wrote: As far as JavaScript API features go, I don't think we should vary our offering by locale. E.g. for Firefox OS we want changing locale to just work and not require a new version of Firefox OS. The same goes for a computer in a hotel or hostel or some such. Firefox should work for each locale users might have set in Gmail. And yet, we don't ship by default a version of Firefox that has all the languages in it, even though that would be good for those use cases also. If it didn't cost us anything to include all languages, I wouldn't be harping on this. But we know that increased package sizes cost us Firefox desktop adoption. So what would the practical effect be of only including the English data files in the English Firefox, and so forth, and allowing users to get additional ICU data via langpacks, the same way we get a Firefox translation? Is there a primary use case for supporting these Intl APIs for languages that a user normally doesn't see? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On Tue, Oct 15, 2013 at 10:50 AM, Anne van Kesteren wrote: > On Tue, Oct 15, 2013 at 6:45 PM, Benjamin Smedberg > wrote: >> On 10/15/2013 1:18 PM, Brian Smith wrote: >>> My understanding is that web content should not be able to tell which >>> locale the browser is configured to use, for privacy (fingerprinting) >>> reasons. >> >> I haven't heard this rule before. By default your browser language affects >> the HTTP accept-lang setting, as well as things like default font choices. >> You can certainly customize those back to a non-fingerprintable setting, but >> I'm not convinced that we should worry about this as a fingerprinting >> vector. > > I think preventing fingerprinting at a technical level is something > we've lost though we should try to avoid introducing new vectors. I think, at least, we should consider ways to avoid adding new vectors when we are making decisions. It doesn't have to be *the* deciding factor. > As far as JavaScript API features go, I don't think we should vary our > offering by locale. E.g. for Firefox OS we want changing locale to > just work and not require a new version of Firefox OS. The same goes > for a computer in a hotel or hostel or some such. Firefox should work > for each locale users might have set in Gmail. I strongly agree with this. No doubt there is a strong correlation between the UI locale and the locale used for web content, but it is far from a perfect correlation. Socially, we should be erring on the side of encouraging a multilingual society instead of discouraging a multilingual society. Technically, we should minimize the web-facing differences between different installations of Firefox, because having a consistent platform for web developers is a good thing. That is why we create web standards, and that is why making parts of standards optional is generally a bad thing. I have no idea how to install a langpack. Presumably it is something that is done through AMO. I am skeptical that this is easy enough to make it acceptable to push this task off to the user. we should at least automate it for them. If this data is too large and contributing towards aborted installs, why not just split the installation phase into two parts, and install the locale data in parallel to starting up the browser? 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: Extensibility of JavaScript modules
In general I am also against monkeypatching, but especially for products that don't have releases quite as often I think it has its valid use cases. Especially in the enterprise environment, where a client wants a fix now, its not an option to say "well, we've submitted this patch for the next Firefox/Thunderbird/Lightning release, but you're going to have to wait until its available". The client will want a fix asap, so monkeypatching until the next release is available is the only option. If that is blocked then forking the Product is the next option and that is even more ugly than monkeypatching. If this is restricted, I don't think it should be done generally, but kept on a per-module basis. This way each product can decide which modules need to be kept free from hacks. Philipp On 10/8/13 5:06 PM, Bobby Holley wrote: In general, I'm pretty against this kind of monkey-patching if it's made available to out-of-tree consumers. We should learn our lesson from XPCOM and recognize what a royal PITA it can be when extensions start to depend on implementation details. Allowing something to be modified/overridden by embeddors should be an explicit decision, rather than the other-way around. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
wrote in message news:z_mdnf_gw67ebmxpnz2dnuvz_ssdn...@mozilla.org... > 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. > Why are these ignored? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/15/13 12:28 PM, Brian Smith wrote: I have no idea how to install a langpack. Presumably it is something that is done through AMO. I am skeptical that this is easy enough to make it acceptable to push this task off to the user. we should at least automate it for them. If this data is too large and contributing towards aborted installs, why not just split the installation phase into two parts, and install the locale data in parallel to starting up the browser? How large is a langpack? Could Firefox install (all) langpacks in the background or on demand? I've heard rumblings about a Firefox updater project to unify updates for Firefox data files that are not coupled to a particular Firefox release (such as CRLS and GPU driver blocklists). chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
Jeff Walden writes: > On 10/15/2013 06:06 PM, Benjamin Smedberg wrote: > > That means sync I/O on the main thread, and not well-optimized because it > won't be part of the binary. Just to note. When sync I/O is performed to read in-binary-object data, how is that better? Just readahead? Wouldn't something similar be possible with separate files? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/15/13 2:41 PM, Chris Peterson wrote: > On 10/15/13 12:28 PM, Brian Smith wrote: >> I have no idea how to install a langpack. Presumably it is something >> that is done through AMO. I am skeptical that this is easy enough to >> make it acceptable to push this task off to the user. we should at >> least automate it for them. If this data is too large and contributing >> towards aborted installs, why not just split the installation phase >> into two parts, and install the locale data in parallel to starting up >> the browser? > > How large is a langpack? Could Firefox install (all) langpacks in the > background or on demand? > > I've heard rumblings about a Firefox updater project to unify updates > for Firefox data files that are not coupled to a particular Firefox > release (such as CRLS and GPU driver blocklists). > > > chris A quick look at this page (https://addons.mozilla.org/firefox/language-tools/) shows that they're generally in the 350-400 Kb range, each. I don't know how those would compare with "ICU lang packs". Jorge ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
