When is onscroll called if apzc is enabled?
How often?
When is the first scroll event fired?
Will using onscroll prevent apzc to work properly?
Thanks,
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listin
On 2015年02月24日 20:28, Kyle Huey wrote:
> I'm also not sure why you care about arcane architectures like
> Itanium, Alpha, and SPARC, since there are approximately zero users of
> those.
>
> - Kyle
I think there are users of ultrasparc out there.
But as long as SPARC is returned as the architect
I visited the mozilla website to get instructions for flashing my phone with
B2G but it turns out that it isn't supported yet.
My device : Karbonn Sparkle V (Android One), identified as 'sprout' on
Cynogenmod.
How do I get started with the codebase on github? and what are the things that
I nee
On Mon, Feb 23, 2015 at 4:26 PM, Jonas Sicking wrote:
> On Mon, Feb 23, 2015 at 4:01 PM, Robert O'Callahan
> wrote:
>> On Tue, Feb 24, 2015 at 12:09 PM, Jonas Sicking wrote:
>>>
>>> I think this would fall over more often than not.
>>>
>>> Most developers will not write their code to be resilie
On Friday, February 20, 2015 at 3:27:48 AM UTC+1, Robert O'Callahan wrote:
> Obvious question: how do we stop UIWorkers janking the compositor? We could
> give them a time budget (say 8ms).
Onboard USB hubs usually add 8ms latency, and John Carmack once noted that a
repaint of an LCD monitor trig
On Tue, Feb 24, 2015 at 8:17 AM, Philip Chee wrote:
> On 24/02/2015 19:28, Kyle Huey wrote:
>
> > Assuming you just want to know what the architecture of the build is, not
> > what the architecture of the machine it's running on is, you're making
> this
> > far more complicated than it needs to b
On 24/02/2015 19:28, Kyle Huey wrote:
> Assuming you just want to know what the architecture of the build is, not
> what the architecture of the machine it's running on is, you're making this
> far more complicated than it needs to be. "x86", "arm", and "ppc" are 32
> bit, "x86_64" and "aarch64" a
Actually, it's slightly more complicated than I remembered, but I
believe that it's still a good first bug.
Filed as bug 1136110.
On 24/02/15 13:38, Mike Hoye wrote:
>
> Flag the easy ones as [good first bug]s and cc me, please. These are the
> little fish we throw back in the water to reel in t
Flag the easy ones as [good first bug]s and cc me, please. These are the
little fish we throw back in the water to reel in the big fish.
- mhoye
On 2015-02-24 7:28 AM, David Rajchenbach-Teller wrote:
It might be useful to add this to OS.Constants.Sys, which is available
to all threads. It's
It might be useful to add this to OS.Constants.Sys, which is available
to all threads. It's basically one line of code in
dom/system/OSFileConstants.cpp
Cheers,
David
On 24/02/15 12:44, mratcli...@mozilla.com wrote:
>> Assuming you just want to know what the architecture of the build is, not
>>
> Assuming you just want to know what the architecture of the build is, not
> what the architecture of the machine it's running on is, you're making this
> far more complicated than it needs to be.
We don't know what we will support in the future so I wanted a future proof
solution... adding is64
On Tue, Feb 24, 2015 at 2:11 AM, wrote:
> The DevTools team need to log some telemetry about whether the current
> Firefox build is 32 or 64-bit.
>
> I was told to use XPCOMABI but the possible results are x86, x86_64,
> ia_64, ppc, SPARC, Alpha or ARM.
>
> The problem is that early mac versions
I have settled on doing it the easy way at compile time in nsAppRunner.cpp:
NS_IMETHODIMP
nsXULAppInfo::GetIs64Bit(bool* aResult)
{
#ifdef HAVE_64BIT_BUILD
*aResult = true;
#else
*aResult = false;
#endif
return NS_OK;
}
___
dev-platform mailing list
The DevTools team need to log some telemetry about whether the current Firefox
build is 32 or 64-bit.
I was told to use XPCOMABI but the possible results are x86, x86_64, ia_64,
ppc, SPARC, Alpha or ARM.
The problem is that early mac versions were 32-bit so assuming ppc is 64-bit is
not accura
14 matches
Mail list logo
