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. Tec
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. Tec
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/)
-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
> wrote:
>> Le 20/02/2015 04:25, Robert O'Callahan a écrit :
>>> On Fri, Feb 20, 2015 at 4:02 PM, James Long
>>> wrote:
>>>
>>> Personally I think what w
Hooray! Thank you.
Nick
On Fri, Feb 20, 2015 at 12:33 PM, Birunthan Mohanathas
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 update-uuids nsISo
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
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 'IGN
On Fri, Feb 20, 2015 at 8:11 AM, Julien Wajsberg wrote:
> Le 20/02/2015 04:25, Robert O'Callahan a écrit :
>> On Fri, Feb 20, 2015 at 4:02 PM, James Long wrote:
>>
>> Personally I think what we *really* need to be working on is making
>> all of the DOM APIs asynchronous. That's what Servo
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 fix,
On Friday, February 20, 2015 at 6:34:07 PM UTC+1, Tom Tromey wrote:
> > "Axel" == axel-4eJtQOnFJqFBDgjK7y7TUQ
> > 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 "
> "Axel" == axel-4eJtQOnFJqFBDgjK7y7TUQ
> 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
Axel> nsTextFormatter, or cr
On Thu, Feb 19, 2015 at 11:21 AM, James Graham
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 where we could have
Le 20/02/2015 04:25, Robert O'Callahan a écrit :
> On Fri, Feb 20, 2015 at 4:02 PM, James Long 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 direction for #
On Fri, Feb 20, 2015 at 3:20 AM, Jonas Sicking wrote:
> On Thu, Feb 19, 2015 at 7:11 PM, James Long 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 v
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
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,
> > > >
> > > >
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
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 pla
On Fri, Feb 20, 2015 at 3:27 AM, Robert O'Callahan 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 render
> to canvas
On Thu, Feb 19, 2015 at 7:11 PM, James Long 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.
Does that mea
On Thu, Feb 19, 2015 at 6:27 PM, Robert O'Callahan 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 later viewing. Right
21 matches
Mail list logo
