On Thu, Feb 19, 2015, at 06:32 AM, a...@mozilla.com wrote:
On Tuesday, February 17, 2015 at 6:33:42 PM UTC+1, Ted Mielczarek wrote:
On Tue, Feb 17, 2015, at 10:27 AM, Axel Hecht wrote:
Hi,
I'd like to write tests to validate my assumptions around what's an error
and what's a
On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan rob...@ocallahan.org wrote:
Should UIWorkers have access to the full Worker API? It seems like there's
no reason not to give them that.
There's two use-cases that I think argues against that.
First off I'd like to enable saving a webpage for
On Thu, Feb 19, 2015 at 7:11 PM, James Long longs...@gmail.com wrote:
Note however that people in the native app world believe that it's
very important that whatever applies the animations is run on the same
thread that handles input. Otherwise it's very easy for animations to
get out-of-sync.
On Fri, Feb 20, 2015 at 3:27 AM, Robert O'Callahan rob...@ocallahan.org wrote:
One good thing about UIWorkers is extensibility. We can imagine providing
touch input coordinates to UIWorkers to enable 60fps object dragging (with
arbitrary effects like resistance, snapping, etc). UIWorkers could
It's great to see this being discussed! Personally, I'd like to see all
three of these, and I think they have quite particular use-cases. #2 is my
least favourite, however, and I'll discuss this below.
I'd like to see #1 implemented first for two reasons; 1- I know this is
easy to do given our
On Friday, February 20, 2015 at 12:57:44 PM UTC+1, Ted Mielczarek wrote:
On Thu, Feb 19, 2015, at 06:32 AM, a...@mozilla.com wrote:
On Tuesday, February 17, 2015 at 6:33:42 PM UTC+1, Ted Mielczarek wrote:
On Tue, Feb 17, 2015, at 10:27 AM, Axel Hecht wrote:
Hi,
I'd like to write
Feature Summary:
While the HTTP Referer header can be suppressed for links with the noreferrer
link type, authors might wish to control its content more directly for a number
of reasons:
* Privacy - stripping the path or blocking referrer entirely on outbound links
* Efficiency - referrer can be
Hooray! Thank you.
Nick
On Fri, Feb 20, 2015 at 12:33 PM, Birunthan Mohanathas
birunt...@mohanathas.com wrote:
Greetings,
If your commit modifies an IDL interface (think `[...] interface Foo
{};`), you will now have to either
1) Bump the corresponding interface UUID.
Use e.g. `./mach
Greetings,
If your commit modifies an IDL interface (think `[...] interface Foo
{};`), you will now have to either
1) Bump the corresponding interface UUID.
Use e.g. `./mach update-uuids nsISomething` to bump the UUID of
nsISomething and all its descendant interfaces.
or
2) Include
Hi all,
When discussing the recent transition to only supporting unified builds,
some people were apparently concerned about how this would affect Visual
Studio projects (i.e. Intellisense), since the Visual Studio project files
generated via |mach build-backend| only listed the individual source
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2015 09:12 PM, Jonas Sicking wrote:
On Fri, Feb 20, 2015 at 8:11 AM, Julien Wajsberg
jwajsb...@mozilla.com wrote:
Le 20/02/2015 04:25, Robert O'Callahan a écrit :
On Fri, Feb 20, 2015 at 4:02 PM, James Long
longs...@gmail.com wrote:
Is there any way we could add something that would cause a notification to go
out to the MDN writing team if IDL is changed? That could have enormous
repercussions on our ability to keep up with doc updates for XPCOM interfaces.
Eric Shepherd
Sr. Technical Writer
Mozilla(https://mozilla.org/)
On 2/20/2015 7:36 PM, Eric Shepherd wrote:
Is there any way we could add something that would cause a notification to go
out to the MDN writing team if IDL is changed? That could have enormous
repercussions on our ability to keep up with doc updates for XPCOM interfaces.
Eric Shepherd
Sr.
On Fri, Feb 20, 2015 at 3:20 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Feb 19, 2015 at 7:11 PM, James Long longs...@gmail.com wrote:
Note however that people in the native app world believe that it's
very important that whatever applies the animations is run on the same
thread that
On Thu, Feb 19, 2015 at 11:21 AM, James Graham ja...@hoppipolla.co.uk
wrote:
On 18/02/15 17:31, nsm.nik...@gmail.com wrote:
It's still disappointing that we are implementing greenfield
web technologies with such an ad-hoc approach to obtaining
interoperability. This seems like a clear case
Le 20/02/2015 04:25, Robert O'Callahan a écrit :
On Fri, Feb 20, 2015 at 4:02 PM, James Long longs...@gmail.com wrote:
Personally I think what we *really* need to be working on is making
all of the DOM APIs asynchronous. That's what Servo needs anyway.
That's a step in the right
Axel == axel-4eJtQOnFJqFBDgjK7y7TUQ
axel-4ejtqonfjqfbdgjk7y7...@public.gmane.org writes:
Axel We can only do this in the compiler if we actually compiled each
Axel localized version by itself.
Yes, I see what you mean.
Axel The other easy way to reduce impact here is to reduce the use of
On Friday, February 20, 2015 at 6:34:07 PM UTC+1, Tom Tromey wrote:
Axel == axel-4eJtQOnFJqFBDgjK7y7TUQ
axel-4ejtqonfjqfbdgjk7y7...@public.gmane.org writes:
Axel We can only do this in the compiler if we actually compiled each
Axel localized version by itself.
Yes, I see what you
Status:
gecko-dev.git updating normally at present.
tl;dr: there
were some significant conversion delays Friday morning PT
(approx 0500-1040PT). Service has been restored. One additional
(much shorter) delay will be needed for final
On Fri, Feb 20, 2015 at 8:11 AM, Julien Wajsberg jwajsb...@mozilla.com wrote:
Le 20/02/2015 04:25, Robert O'Callahan a écrit :
On Fri, Feb 20, 2015 at 4:02 PM, James Long longs...@gmail.com wrote:
Personally I think what we *really* need to be working on is making
all of the DOM APIs
20 matches
Mail list logo
