Rendering meeting on Monday/Tuesday (at time good for Taipei, bad for Europe)

2013-08-09 Thread Milan Sreckovic 

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.html&key=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

Re: Feedback wanted on font checker

2013-08-09 Thread Jonathan Kew 
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

Re: Feedback wanted on font checker

2013-08-09 Thread Axel Hecht 

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: Intent to implement: NavigationController

2013-08-09 Thread Ehsan Akhgari 
On Thu, Aug 8, 2013 at 7:50 PM, Nikhil Marathe  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

___
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

2013-08-09 Thread Boris Zbarsky 

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: Use ".then(null, Cu.reportError);" with Promise.jsm

2013-08-09 Thread David Rajchenbach-Teller 
This definitely makes sense.
In the JS implementation, assuming main thread only, we should be able
to rig together a finalizer/warning using XPCOM.

Cheers,
 David


On 8/9/13 3:27 PM, Boris Zbarsky wrote:
> Well, the obvious other thing would be window.onerror.  But that might
> be tough, since making GC effects be page-observable is not great.
> 
> I think we should definitely report to the error console.
> 
> -Boris
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing xml:base

2013-08-09 Thread Boris Zbarsky 
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

2013-08-09 Thread Anne van Kesteren 
On Fri, Aug 9, 2013 at 2:27 PM, Boris Zbarsky  wrote:
> Well, the obvious other thing would be window.onerror.  But that might be
> tough, since making GC effects be page-observable is not great.

Yeah, I thought that would be out for precisely that reason.


> I think we should definitely report to the error console.

Seems like a nice trick indeed.


-- 
http://annevankesteren.nl/
___
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

2013-08-09 Thread Boris Zbarsky 

On 8/9/13 9:13 AM, Anne van Kesteren wrote:

On Fri, Aug 9, 2013 at 2:08 PM, Boris Zbarsky  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?


Well, the obvious other thing would be window.onerror.  But that might 
be tough, since making GC effects be page-observable is not great.


I think we should definitely report to the error console.

-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

2013-08-09 Thread Anne van Kesteren 
On Fri, Aug 9, 2013 at 2:08 PM, Boris Zbarsky  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

Re: Use ".then(null, Cu.reportError);" with Promise.jsm

2013-08-09 Thread Boris Zbarsky 

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: Feedback wanted on font checker

2013-08-09 Thread Axel Hecht 

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: Feedback wanted on font checker

2013-08-09 Thread Karl Tomlinson 
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: Intent to implement: NavigationController

2013-08-09 Thread Gervase Markham 
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: Use ".then(null, Cu.reportError);" with Promise.jsm

2013-08-09 Thread Neil 

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: nsIDownloadManager replaced by Downloads.jsm

2013-08-09 Thread Paolo Amadini 
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: nsIDownloadManager replaced by Downloads.jsm

2013-08-09 Thread Paolo Amadini 
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

Use ".then(null, Cu.reportError);" with Promise.jsm

2013-08-09 Thread Paolo Amadini 
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