On Fri, Dec 7, 2012 at 1:45 PM, Robert O'Callahan wrote:
> Bug 804606 is a pretty bad Flash crash that we're chasing for beta.
>
> If you have an old-ish Mac (5 years old?) and about:support shows "Intel
> GMA X3100" or "Intel GMA 950" under "WebGL Renderer" then please try
> loading Yahoo mail wi
On Fri, Dec 7, 2012 at 4:25 PM, Robert O'Callahan wrote:
> On Fri, Dec 7, 2012 at 4:08 PM, Norbert Lindenberg <
> mozillali...@lindenbergsoftware.com> wrote:
>
>> This sounds like non-trivial surgery on ICU. Yes, the APIs are
>> synchronous. And we don't know whether the time when a user stumbles
On Fri, Dec 7, 2012 at 4:08 PM, Norbert Lindenberg <
mozillali...@lindenbergsoftware.com> wrote:
> This sounds like non-trivial surgery on ICU. Yes, the APIs are
> synchronous. And we don't know whether the time when a user stumbles onto a
> Chinese web page that requests Chinese collation is real
On 12/6/12 6:36 PM, Robert O'Callahan wrote:
How hard would it be to incrementally download data for the locales we need?
It seems that most users won't ever need the collation tables for Chinese,
for example. If we could figure out a way to make them available
just-in-time, that could be a win.
On Dec 6, 2012, at 18:36 , Robert O'Callahan wrote:
> How hard would it be to incrementally download data for the locales we need?
>
> It seems that most users won't ever need the collation tables for Chinese,
> for example. If we could figure out a way to make them available
> just-in-time, that
How hard would it be to incrementally download data for the locales we need?
It seems that most users won't ever need the collation tables for Chinese,
for example. If we could figure out a way to make them available
just-in-time, that could be a win.
I assume the relevant APIs are synchronous, s
On Dec 6, 2012, at 16:33 , Axel Hecht wrote:
> On 07.12.12 01:08, Asa Dotzler wrote:
>> On 12/3/2012 2:39 PM, Norbert Lindenberg wrote:
>>> Well, the first question is what size increase would be acceptable
>>> given the benefits that ICU provides.
>>
>> I don't understand what benefits this actu
On Dec 6, 2012, at 16:08 , Asa Dotzler wrote:
> On 12/3/2012 2:39 PM, Norbert Lindenberg wrote:
>> Well, the first question is what size increase would be acceptable
>> given the benefits that ICU provides.
>
> I don't understand what benefits this actually provides. How are users'
> online live
Bug 804606 is a pretty bad Flash crash that we're chasing for beta.
If you have an old-ish Mac (5 years old?) and about:support shows "Intel
GMA X3100" or "Intel GMA 950" under "WebGL Renderer" then please try
loading Yahoo mail with Flash enabled and Flash hardware acceleration
enabled. (You may
On 07.12.12 01:08, Asa Dotzler wrote:
On 12/3/2012 2:39 PM, Norbert Lindenberg wrote:
Well, the first question is what size increase would be acceptable
given the benefits that ICU provides.
I don't understand what benefits this actually provides. How are users'
online lives improved by this c
On 12/3/2012 2:39 PM, Norbert Lindenberg wrote:
Well, the first question is what size increase would be acceptable
given the benefits that ICU provides.
I don't understand what benefits this actually provides. How are users'
online lives improved by this change, either today or in the future?
On 12/06/12 04:16 PM, Anthony Jones wrote:
> On 07/12/12 08:22, Chris Peterson wrote:
>> On 12/6/12 9:34 AM, Ed Morley wrote:
>>> As such, if testing just one platform on Try, use Linux64 instead for
>>> reduced overall turnaround times. (Use '-p linux64' in your trychooser
>>> [2] line).
>>
>> Sou
On 07/12/12 08:22, Chris Peterson wrote:
> On 12/6/12 9:34 AM, Ed Morley wrote:
>> As such, if testing just one platform on Try, use Linux64 instead for
>> reduced overall turnaround times. (Use '-p linux64' in your trychooser
>> [2] line).
>
> Sounds like Try could implement a naive '-p fastest/w
On 12/6/12 9:34 AM, Ed Morley wrote:
As such, if testing just one platform on Try, use Linux64 instead for reduced
overall turnaround times. (Use '-p linux64' in your trychooser [2] line).
Sounds like Try could implement a naive '-p fastest/whatever' that
simply maps to '-p linux64'. A smarte
On a related note, I've neglected to document or promote a new try
syntax feature: you can filter test builders with square bracket
syntax. You could infer details from bug 802937, but in practice
probably the only useful strings are variants of:
Windows XP only - try: -b do -p win32 -u all[5.
On Thursday, 6 December 2012 18:18:53 UTC, Andrew McCreight wrote:
> Is there any possibility of getting a '-p whatever' that would
> semi-intelligently pick a desktop platform that isn't overwhelmed with
> build/test jobs? For the kinds of bugs I work on, I don't really care which
> one it ru
Is there any possibility of getting a '-p whatever' that would
semi-intelligently pick a desktop platform that isn't overwhelmed with
build/test jobs? For the kinds of bugs I work on, I don't really care which one
it runs on. I sometimes approximate this myself by seeing in the most recent
push
On Thursday, 6 December 2012 18:08:23 UTC, Ehsan Akhgari wrote:
> Doesn't this trend just get reversed if everyone starts to use Linux64 now?
>
> Ehsan
No, the B2G emulator tests will still be using the Linux32 slaves & are the
primary cause of the problem at the moment. At such point if/when w
Doesn't this trend just get reversed if everyone starts to use Linux64 now?
Ehsan
On 2012-12-06 12:34 PM, Ed Morley wrote:
Whilst Linux32 is on average our fastest building platform (by ~5-10 mins over
Linux64), it currently has much longer test wait times [1] (time until a
testpool machine i
Whilst Linux32 is on average our fastest building platform (by ~5-10 mins over
Linux64), it currently has much longer test wait times [1] (time until a
testpool machine is available to take the job).
For example there are currently over 1000 queued Linux32 test jobs on Try, but
only 26 for Lin
Jonathan Kew wrote:
You shouldn't normally see a flash of fallback text unless the font is
particularly slow to load; the text should be invisible until the font
is available. We aim to hide the text until the font is ready, unless
it takes more than a few seconds to load. (The timeout is conf
21 matches
Mail list logo
