Use .then(null, Cu.reportError); with Promise.jsm
This is a quick reminder to anyone writing or reviewing code that uses
Promise.jsm.
You should check that exceptions aren't swallowed, and this is typically
done with a logging rejection handler. You should always use the handler
unless you're handing off the promise to other code. For some examples:
https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise#Handling_errors_and_common_pitfalls
As of now, this amounts to a pattern like:
myPromise.then(value = {
// ...
}).then(null, Components.utils.reportError);
Or when creating a task without returning the promise:
Task.spawn(function () {
// yield ...
}).then(null, Components.utils.reportError);
I admit that having to explicitly provide an error handler at the end
of a promise chain may be considered less than optimal, but for now it
is the recommended way in new code. We're discussing ways to make it
less likely that exceptions are swallowed, in bug 902866:
https://bugzilla.mozilla.org/show_bug.cgi?id=902866
Please reply in the bug if you have anything to add to the discussion.
Cheers,
Paolo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: nsIDownloadManager replaced by Downloads.jsm
On 06/08/2013 18.49, Robert Kaiser wrote: Paolo Amadini schrieb: The Downloads back-end will not call any method of nsIDownloadManagerUI anymore So I cannot implement an alternative download manager any more? You can for sure :-) Anything we're changing and has a valid use case will still be implemented in new ways, hopefully simpler to hook into. Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIDownloadManager replaced by Downloads.jsm
On 06/08/2013 22.56, garys...@gmail.com wrote: I flipped on 'browser.download.useJSTransfer' and downloaded some zip files from Fx inbound Thanks a lot for testing! and they all were zero byte files. This was done in safe mode. Hope this is a WIP ;-) This is probably bug 901563, should be fixed in Nightly. And yes, this is a work in progress :-) Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use .then(null, Cu.reportError); with Promise.jsm
Paolo Amadini wrote: This is a quick reminder to anyone writing or reviewing code that uses Promise.jsm. How do the other promise implementations in the tree compare in this respect? (For instance I suspect it might be feasible for DOM promises to report any pending exception when they get garbage collected.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On 08/08/13 23:52, Ehsan Akhgari wrote: I think you forgot the bug number. :-) Ehsan: any chance you could trim your responses? I had to page-down 9 times in my mail client just to read this one line... Thanks :-) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feedback wanted on font checker
Axel Hecht writes: On 8/8/13 10:45 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 5:17 PM, Jonathan Kew wrote: On 8/8/13 15:17, Axel Hecht wrote: Couter example seems to be Chinese, the unagi shows something, while my tool reports 13k missing glyphs for zh-TW. If we're using Droid Sans Fallback, I believe it supports somewhere well over 20,000 Chinese characters, so that probably includes all those in fontconfig's list - but that still doesn't mean it has *every* possible Chinese character. Yeah, I see DroidSansFallback in fonts.mk in moztt, https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk#L31, but how would we pick that up? I suspect you want to add font.name-list support to your tool. These fonts should be searched by the product after font.name. pref(font.name-list.serif.zh-TW, Droid Serif, Droid Sans Fallback); pref(font.name-list.sans-serif.zh-TW, Roboto, Droid Sans, Droid Sans Fallback); pref(font.name-list.monospace.zh-TW, Droid Sans Fallback); Right. I pick up both, but not name-list as fallback to name. Basically, what comes last in all.js wins right now. Is there a reason why font.name.* isn't just the first in font.name-list.* ? I.e., why do we have two of them, and does it matter for what I'm trying to do? This was set up before I was around, so I'm not clear on the reasoning. Some comments [1] point out that only .name. is configurable in Firefox Preferences UI. Perhaps that would even support the idea of .name. remaining in the .name-list. in case some other font accidentally selected by the user was not helpful. I think you do want to check both preferences for the situation where a Latin font may have been inserted in .name. before a native font in .name-list. in an attempt to get better Latin characters. I suspect usually one font will cover the language, so your tool may not need to find the union the ranges or intersection of missing. At one stage IIRC only these fonts were being checked on Android, while desktop platforms had a fallback search through every font on the system. That has changed a bit with desktop platforms not always checking exhaustively, for perf reasons, and it may have changed on Android also. Even if other system fonts are checked in fallback, it is important that the .name. and .name-list. fonts cover their language, or you can get an awkward mix of characters from different fonts that don't work together. That can be as simple as a collage of different characters, or as bad as not working at all because some scripts require the presentation of characters to depend on neighbouring characters and this is not supported across a mix of fonts. [1] http://hg.mozilla.org/mozilla-central/annotate/e33c2011643e/layout/base/nsPresContext.cpp#l485 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feedback wanted on font checker
On 8/9/13 1:27 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 10:45 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 5:17 PM, Jonathan Kew wrote: On 8/8/13 15:17, Axel Hecht wrote: Couter example seems to be Chinese, the unagi shows something, while my tool reports 13k missing glyphs for zh-TW. If we're using Droid Sans Fallback, I believe it supports somewhere well over 20,000 Chinese characters, so that probably includes all those in fontconfig's list - but that still doesn't mean it has *every* possible Chinese character. Yeah, I see DroidSansFallback in fonts.mk in moztt, https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk#L31, but how would we pick that up? I suspect you want to add font.name-list support to your tool. These fonts should be searched by the product after font.name. pref(font.name-list.serif.zh-TW, Droid Serif, Droid Sans Fallback); pref(font.name-list.sans-serif.zh-TW, Roboto, Droid Sans, Droid Sans Fallback); pref(font.name-list.monospace.zh-TW, Droid Sans Fallback); Right. I pick up both, but not name-list as fallback to name. Basically, what comes last in all.js wins right now. Is there a reason why font.name.* isn't just the first in font.name-list.* ? I.e., why do we have two of them, and does it matter for what I'm trying to do? This was set up before I was around, so I'm not clear on the reasoning. Some comments [1] point out that only .name. is configurable in Firefox Preferences UI. Perhaps that would even support the idea of .name. remaining in the .name-list. in case some other font accidentally selected by the user was not helpful. I think you do want to check both preferences for the situation where a Latin font may have been inserted in .name. before a native font in .name-list. in an attempt to get better Latin characters. I suspect usually one font will cover the language, so your tool may not need to find the union the ranges or intersection of missing. At one stage IIRC only these fonts were being checked on Android, while desktop platforms had a fallback search through every font on the system. That has changed a bit with desktop platforms not always checking exhaustively, for perf reasons, and it may have changed on Android also. Even if other system fonts are checked in fallback, it is important that the .name. and .name-list. fonts cover their language, or you can get an awkward mix of characters from different fonts that don't work together. That can be as simple as a collage of different characters, or as bad as not working at all because some scripts require the presentation of characters to depend on neighbouring characters and this is not supported across a mix of fonts. [1] http://hg.mozilla.org/mozilla-central/annotate/e33c2011643e/layout/base/nsPresContext.cpp#l485 Yeah, we've seen those on our website a few times. Ughly, and a reason why I started writing this tool. To clarify, the tool does support either .name. or .name-list. at this point. Is there a code path or a setup where we have for any language/family both a .name. and a .name-list. entry? I.e. pref(font.name.serif.zh-TW, Times); pref(font.name-list.serif.zh-TW, Droid Serif, Droid Sans Fallback); Just a randomly constructed example. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use .then(null, Cu.reportError); with Promise.jsm
On 8/9/13 5:54 AM, Neil wrote: (For instance I suspect it might be feasible for DOM promises to report any pending exception when they get garbage collected.) Oh, that is a _very_ interesting idea. I wonder whether we can get that specced, or at least allowed by the spec. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use .then(null, Cu.reportError); with Promise.jsm
On Fri, Aug 9, 2013 at 2:08 PM, Boris Zbarsky bzbar...@mit.edu wrote: Oh, that is a _very_ interesting idea. I wonder whether we can get that specced, or at least allowed by the spec. If it's just to the error console, we can do whatever we want. Do you have something else in mind? -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Removing xml:base
There is a proposal in https://bugzilla.mozilla.org/show_bug.cgi?id=903372 to remove xml:base support. Do we actually use this for anything? I thought we used to set it for xbl stuff, but I don't see obvious code doing that. If we can, it would be great to rip this out: it would significantly simplify a bunch of things. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use .then(null, Cu.reportError); with Promise.jsm
On 8/9/13 9:27 AM, Boris Zbarsky wrote: I think we should definitely report to the error console. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=903419 -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Thu, Aug 8, 2013 at 7:50 PM, Nikhil Marathe nsm.nik...@gmail.com wrote: There is no bug number yet, because I have about 15 lines of additional code :) There is now! https://bugzilla.mozilla.org/show_bug.cgi?id=903441 -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feedback wanted on font checker
On 8/9/13 1:51 PM, Axel Hecht wrote: On 8/9/13 1:27 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 10:45 PM, Karl Tomlinson wrote: Axel Hecht writes: On 8/8/13 5:17 PM, Jonathan Kew wrote: On 8/8/13 15:17, Axel Hecht wrote: Couter example seems to be Chinese, the unagi shows something, while my tool reports 13k missing glyphs for zh-TW. If we're using Droid Sans Fallback, I believe it supports somewhere well over 20,000 Chinese characters, so that probably includes all those in fontconfig's list - but that still doesn't mean it has *every* possible Chinese character. Yeah, I see DroidSansFallback in fonts.mk in moztt, https://github.com/mozilla-b2g/moztt/blob/master/fonts.mk#L31, but how would we pick that up? I suspect you want to add font.name-list support to your tool. These fonts should be searched by the product after font.name. pref(font.name-list.serif.zh-TW, Droid Serif, Droid Sans Fallback); pref(font.name-list.sans-serif.zh-TW, Roboto, Droid Sans, Droid Sans Fallback); pref(font.name-list.monospace.zh-TW, Droid Sans Fallback); Right. I pick up both, but not name-list as fallback to name. Basically, what comes last in all.js wins right now. Is there a reason why font.name.* isn't just the first in font.name-list.* ? I.e., why do we have two of them, and does it matter for what I'm trying to do? This was set up before I was around, so I'm not clear on the reasoning. Some comments [1] point out that only .name. is configurable in Firefox Preferences UI. Perhaps that would even support the idea of .name. remaining in the .name-list. in case some other font accidentally selected by the user was not helpful. I think you do want to check both preferences for the situation where a Latin font may have been inserted in .name. before a native font in .name-list. in an attempt to get better Latin characters. I suspect usually one font will cover the language, so your tool may not need to find the union the ranges or intersection of missing. At one stage IIRC only these fonts were being checked on Android, while desktop platforms had a fallback search through every font on the system. That has changed a bit with desktop platforms not always checking exhaustively, for perf reasons, and it may have changed on Android also. Even if other system fonts are checked in fallback, it is important that the .name. and .name-list. fonts cover their language, or you can get an awkward mix of characters from different fonts that don't work together. That can be as simple as a collage of different characters, or as bad as not working at all because some scripts require the presentation of characters to depend on neighbouring characters and this is not supported across a mix of fonts. [1] http://hg.mozilla.org/mozilla-central/annotate/e33c2011643e/layout/base/nsPresContext.cpp#l485 Yeah, we've seen those on our website a few times. Ughly, and a reason why I started writing this tool. To clarify, the tool does support either .name. or .name-list. at this point. Is there a code path or a setup where we have for any language/family both a .name. and a .name-list. entry? I.e. pref(font.name.serif.zh-TW, Times); pref(font.name-list.serif.zh-TW, Droid Serif, Droid Sans Fallback); Just a randomly constructed example. Axel So I created three test cases based on the data I see, Greek and Bulgarian monospace and Hindi sans-serif. They're linked off of http://pike.github.io/fonts/. It's prerendered images on the left column, and regular text on the right. Hindi is blank squares as I expect, but for Bulgarian and Greek, I see Bulgarian and Greek letters on my 1.1 unagi. It'd be great to get some help as to what I actually see there. Oh fonts. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Feedback wanted on font checker
On 9/8/13 15:36, Axel Hecht wrote: So I created three test cases based on the data I see, Greek and Bulgarian monospace and Hindi sans-serif. They're linked off of http://pike.github.io/fonts/. It's prerendered images on the left column, and regular text on the right. Hindi is blank squares as I expect, but for Bulgarian and Greek, I see Bulgarian and Greek letters on my 1.1 unagi. It'd be great to get some help as to what I actually see there. Oh fonts. Font fallback means that if there's ANY font on your Unagi that includes Cyrillic (or Greek) characters, you'll see them rather than blank boxes, even if that font isn't what's listed in the font.name prefs (And it may not even be monospaced... it's probably falling back to Open Sans or Charis SIL or something.) JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Rendering meeting on Monday/Tuesday (at time good for Taipei, bad for Europe)
The Rendering meeting is about all things Gfx, Image, Layout, and Media. It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm PDT. The next meeting will take place today, Monday, August 12th at 5:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-August-12 San Francisco - Monday, 5:30pm Winnipeg - Monday, 7:30pm Toronto - Monday, 8:30pm GMT/UTC - Tuesday, 0:30 Paris - Tuesday, 2:30am Taipei - Tuesday, 8:30am Auckland - Tuesday, 12:30pm Video conferencing: Vidyo room Graphics (9366) https://v.mozilla.com/flex.html?roomdirect.htmlkey=vu1FKlkBlT29 Phone conferencing: +1 650 903 0800 x92 Conf# 99366 +1 416 848 3114 x92 Conf# 99366 +1 800 707 2533 (pin 369) Conf# 99366 -- - Milan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
