Re: Visibility plan for document.registerElement (custom elements)

[Anne van Kesteren]

On Wed, Jan 28, 2015 at 9:04 PM, James Burke  wrote:
> We use some custom elements inside the app, so cannot currently go
> privileged. While it would be relatively straightforward for the app to
> move away from using document.registerElement, I would prefer to just leave
> it as-is if document.registerElement was going to be more widely available
> in the FxOS 3.0 timeframe (extra nice if it were to happen in the first
> half of this year).

I definitely hope we have it sorted by Q2 though currently there's a
bit of disagreement as to how upgrading has to work and it will
probably take a while for that to get resolved. It is however unclear
whether we can reuse the method names as it might break pages that use
a polyfill if the finalized custom elements is not identical to what
Chrome is shipping now.

I recommend keeping that backup plan and evaluate again in April. If
we know something sooner we can let you know. (And this list will
probably be informed by an intent email.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

gecko-dev and Git replication will be broken for a little while

[Gregory Szorc]

Git replication is currently broken due to a mistake of mine when mass
closing branches earlier today.

Don't expect restoration before 1200 PDT.

Bug 927219.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JS-Ctype IRC Room

[noitidart]

On Monday, January 19, 2015 at 8:40:04 PM UTC-8, Philip Chee wrote:
> On 20/01/2015 07:21, noitid...@gmail.com wrote:
> > New irc room we're trying to establish. #jsctypes
> > 
> > https://client00.chat.mibbit.com/?url=irc%3A%2F%2Firc.mozilla.org%2F%23jsctypes
> 
> That's wrong. The correct link is irc://moznet/jsctypes
> 
> Phil
> 
> -- 
> Philip Chee , 
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.

Thanks Philip that's awesome i didnt know you can share a link like that! 
Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JS-Ctype IRC Room

[noitidart]

On Tuesday, January 20, 2015 at 12:30:02 AM UTC-8, helpcrypto helpcrypto wrote:
> Is there a maillist for jsctypes? Wouldn't that be better than an irc
> channel?
> 
> 
> On Tue, Jan 20, 2015 at 5:39 AM, Philip Chee  wrote:
> 
> > On 20/01/2015 07:21, noitid...@gmail.com wrote:
> > > New irc room we're trying to establish. #jsctypes
> > >
> > >
> > https://client00.chat.mibbit.com/?url=irc%3A%2F%2Firc.mozilla.org%2F%23jsctypes
> >
> > That's wrong. The correct link is irc://moznet/jsctypes
> >
> > Phil
> >
> > --
> > Philip Chee , 
> > http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> > Guard us from the she-wolf and the wolf, and guard us from the thief,
> > oh Night, and so be good for us to pass.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

I'm not sure crypo, i havent seen one :(

So far theres 3 regulars, we got mac linux and windows covered between us three 
pretty good :D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reversely iterating nsTArray

[Trevor Saunders]

On Wed, Jan 28, 2015 at 10:59:48AM -0500, Ehsan Akhgari wrote:
> On 2015-01-27 9:24 PM, Xidorn Quan wrote:
> >I asked a question in #developers that what is the best way to reversely
> >iterating nsTArray, and there are some suggestions:
> >
> > uint32_t count = array.Length(); for (uint32_t i = length - 1; i
> >< length; i--)
> > iterate from length() to 1 and index using i - 1
> > for (uint32_t i = array.Length(); i-- > 0; ) { }
> >
> >tbsaunde's method should work fine, but not intuitive. smaug's looks fine
> >to me, but could cause some problem if I use i instead of i-1 by mistake.
> >jcranmer's... I don't think it is a good idea, anyway. None of them looks
> >prefect to me.
> >
> >
> >As we have supported range-based for loop in our code, I purpose that we
> >have something like ReverseIntegerRange, and use this with range-based loop
> >to iterate the index. So we can use, for example: for (auto i :
> >ReverseIntegerRange(array.Length()))
> >
> >Maybe we can also add IntegerRange to benefit from the integer type
> >dedution.
> >
> >How does it sound?
> 
> No, please don't do this.  We need to make our container classes more
> similar to the STL containers, not less, and since this is about adding new
> functionality, here is what we need to do:

where the stl didn't make poor choices sure, and I'll agree while stl
iterators are a bit weird they aren't terrible.

> * Add a begin() and end() function to nsTArray that return iterators with
> STL semantics.
> * Add a rbegin() and rend() function to nsTArray with similar semantics
> which return a reverse iterator.
> * Add something similar to boost::adaptors::reverse, probably to MFBT.
> 
> That way you can write:
> 
> for (auto& elem : array)
> 
> or:
> 
> for (auto& elem : mozilla::Reverse(array))

imho auto in range based for should be strongly discouraged since you
need to go look up the type of the array and then play games to figure
out what the type of elem is.

Trev

> 
> And that would work no matter whether array is an nsTArray or a std::vector.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Web APIs documentation meeting Friday

[Eric Shepherd (Sheppy)]

Once again, we'll be holding our weekly Web APIs documentation meeting this
upcoming Friday, January 30. The meeting begins at 10 AM PST and rarely
lasts longer than 15-20 minutes. See http://bit.ly/APIdocsMDN to convert
this time into your time zone.

We welcome and encourage anyone interested in Web APIs to attend; the
mission of this project is to create documentation for all APIs that are
exposed to Web content, so if you work on those APIs or just have an
interest in seeing that they're properly documented, please join us!

We have an agenda, as well as details on how to join, available on this
etherpad:

https://etherpad.mozilla.org/WebAPI-docs-2015-01-30.

If you have topics you wish to discuss, please feel free to add them to the
agenda. Also, if you're unable to attend but have been working on
documentation related to APIs, please add notes to the agenda about what
you've been doing so we can share your progress.

https://etherpad.mozilla.org/WebAPI-docs-2015-01-30

-- 

Eric Shepherd
Sr. Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Gregory Szorc]

The steps within my control to potentially fix this issue have been
postponed until at least tomorrow due to the Firefox Beta build today.
tl;dr is people don't want to take on additional risk changing repositories.

I hate to say this, but people using Git for Gecko development will have to
wait another day for replication to turn on again.

If you haven't tried Mercurial lately, you may want to. Read the "Mercurial
for Mozillians" guide at
http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html
for some good pointers.


On Thu, Jan 29, 2015 at 1:06 AM, Gregory Szorc  wrote:

> Git replication is currently broken due to a mistake of mine when mass
> closing branches earlier today.
>
> Don't expect restoration before 1200 PDT.
>
> Bug 927219.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Memory management in C programs

[ISHIKAWA, Chiaki]

On 2015/01/12 22:46, Philip Chee wrote:

""
One large difference between C and most other programming languages is
that in C, you have to handle memory yourself rather than having a
garbage collector do it for you. Ensuring that memory is allocated at
the correct moment is not very difficult (and something that needs to be
done manually in pretty much every language); the hard part is to ensure
that enough memory is allocated, and to ensure that the memory is
deallocated when it is no longer in use.

There are several techniques available for memory management in C. Many
of them are used in NetHack 3.4.3; and even more are used somewhere in
NetHack 4. In this blog post, I'd like to look at them and discuss their
advantages and disadvantages. I'm mostly concerned about correctness,
rather than efficiency, here; that means that unless the performance
difference is very large, I care more about clean code than I do about
fast code.
""



Phil



Nethack? That nethack?
I looked at the web page.
Yes, *that* nethack.

Do people still play it? It seems so
and on a UTF-8 capable terminal (?)
We have come a long way from vt100.

Anyway, a surprise that there are so memory allocation issues under the 
hood even for nethack! It now even has an interface for JSON library (?)


Written on "Sun Mar 16 19:10:57 UTC 2014" it is a good summary, and 
something good old DDJ would carry.


But after all, the author of the page states in a section
titled 'Avoiding allocations in the first place':
As can be seen above, memory allocation in C is something of a mess ...

So we are better off with more modern languages although at
low-level we DO need to deal with issues mentioned in the blog.

Hmm, the author seems to be rewriting nethack using some modern memory 
handling approach

using contorted C. Long live nethack.

I am not sure if he or anybody will rewrite nethack
in more modern languages. Nethack in haskel may be an interesting Google 
summer intern programming topic (?)


Moral of the story:
This blog has a bearing on mozilla software. too.

I am struggling to clean up a mess of stream handling in TB's message 
download code: it is not entirely clear who owns the stream in the sense 
that who should close an open stream. Because of the confusion, TB 
currently closes already closed stream left and right.
Also, it must have broken subtle handling regarding stream and buffering 
cannot be enabled without causing a strange message corruption.


So topic of who frees the allocated memory hits home (hard to done 
correctly in C.)


At least we use C++ for mozilla software, so we are better off. I notice 
there have been tricks to make sure
some allocated objects not released accidentally, etc. to make memory 
management more robust automatically.


Unfortunately, stream handling in the current TB code
suffers from the similar issue suffered from C programs. Maybe we can 
tweak the stream class more robust, but I think in the current case, TB 
ought to be re-coded somewhat to show us its handling of stream in an 
explicit accountable manner.)



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote:
> On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron  wrote:
> > Please reply to this thread if you think there's something else we
> > should say, or if you think we should support the charter.
> 
> I think in general it's fine, but there's a couple things:
> 
> * "Confinement with Origin Web Labels" the description does not make
> it clear what this actually is.

I suppose I can ask that the description be made clearer.  Is there
something in particular that you think it should say?

> * "Entry Point Regulation for Web Applications" in a way this is nice
> for defense-in-depth, but also seems to allow a site to completely
> isolate itself from the rest of the web.

I don't see what feedback you want me to give here.

> * "Permissions API" this has been tried several times before. Given
> that there's hardly any involvement from UX in standards, it's not
> clear that this is a good idea. See also
> http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html

Are you ok with sicking's response to this?

> Also, can we request that they adopt a public asynchronous decision
> policy? I think we should start making that request from any WG.

What do the Mozillians involved in the WG think about this?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Eric Rescorla]

On Thu, Jan 29, 2015 at 12:31 PM, Gregory Szorc  wrote:

> The steps within my control to potentially fix this issue have been
> postponed until at least tomorrow due to the Firefox Beta build today.
> tl;dr is people don't want to take on additional risk changing
> repositories.
>
> I hate to say this, but people using Git for Gecko development will have to
> wait another day for replication to turn on again.
>
> If you haven't tried Mercurial lately, you may want to. Read the "Mercurial
> for Mozillians" guide at
>
> http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html
> for some good pointers.


Coming as it does in the middle of a git outage, this advertisement reads
rather
like "Dear git users, pound sand".

-Ekr



>
> On Thu, Jan 29, 2015 at 1:06 AM, Gregory Szorc  wrote:
>
> > Git replication is currently broken due to a mistake of mine when mass
> > closing branches earlier today.
> >
> > Don't expect restoration before 1200 PDT.
> >
> > Bug 927219.
> >
> ___
> dev-version-control mailing list
> dev-version-cont...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-version-control
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Gregory Szorc]

On Thu, Jan 29, 2015 at 1:07 PM, Eric Rescorla  wrote:

> On Thu, Jan 29, 2015 at 12:31 PM, Gregory Szorc  wrote:
>
>> The steps within my control to potentially fix this issue have been
>> postponed until at least tomorrow due to the Firefox Beta build today.
>> tl;dr is people don't want to take on additional risk changing
>> repositories.
>>
>> I hate to say this, but people using Git for Gecko development will have
>> to
>> wait another day for replication to turn on again.
>>
>> If you haven't tried Mercurial lately, you may want to. Read the
>> "Mercurial
>> for Mozillians" guide at
>>
>> http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html
>> for some good pointers.
>
>
> Coming as it does in the middle of a git outage, this advertisement reads
> rather
> like "Dear git users, pound sand".
>

Not my intent. Trying to make the best of a bad situation.

I brushed up against 7+ years of technical debt around the way we manage
our Firefox repositories (the horrible "branching" model) and I lost. I'm
deeply sorry for any inconvenience that's caused and will cause.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Eric Rescorla]

On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron  wrote:

> On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote:
> > On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron 
> wrote:
> > > Please reply to this thread if you think there's something else we
> > > should say, or if you think we should support the charter.
> >
> > I think in general it's fine, but there's a couple things:
> >
> > * "Confinement with Origin Web Labels" the description does not make
> > it clear what this actually is.
>
> I suppose I can ask that the description be made clearer.  Is there
> something in particular that you think it should say?
>
> > * "Entry Point Regulation for Web Applications" in a way this is nice
> > for defense-in-depth, but also seems to allow a site to completely
> > isolate itself from the rest of the web.
>
> I don't see what feedback you want me to give here.


Is this arguably a violation of the priority of constituencies principle?
It seems like it may serve the site more than the user.


> > * "Permissions API" this has been tried several times before. Given
> > that there's hardly any involvement from UX in standards, it's not
> > clear that this is a good idea. See also
> >
> http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html
>
> Are you ok with sicking's response to this?
>
> > Also, can we request that they adopt a public asynchronous decision
> > policy? I think we should start making that request from any WG.
>
> What do the Mozillians involved in the WG think about this?


It depends what this means. If it means that decisions have to be confirmed
on the list then fine. If it means that they can't be made F2F or on calls
and then confirmed the list, then not so fine.

-Ekr

-David
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Eric Rescorla]

Thanks. Hopefully all will be back to normal soon.

Best,
-Ekr


On Thu, Jan 29, 2015 at 1:27 PM, Gregory Szorc  wrote:

> On Thu, Jan 29, 2015 at 1:07 PM, Eric Rescorla  wrote:
>
>> On Thu, Jan 29, 2015 at 12:31 PM, Gregory Szorc  wrote:
>>
>>> The steps within my control to potentially fix this issue have been
>>> postponed until at least tomorrow due to the Firefox Beta build today.
>>> tl;dr is people don't want to take on additional risk changing
>>> repositories.
>>>
>>> I hate to say this, but people using Git for Gecko development will have
>>> to
>>> wait another day for replication to turn on again.
>>>
>>> If you haven't tried Mercurial lately, you may want to. Read the
>>> "Mercurial
>>> for Mozillians" guide at
>>>
>>> http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html
>>> for some good pointers.
>>
>>
>> Coming as it does in the middle of a git outage, this advertisement reads
>> rather
>> like "Dear git users, pound sand".
>>
>
> Not my intent. Trying to make the best of a bad situation.
>
> I brushed up against 7+ years of technical debt around the way we manage
> our Firefox repositories (the horrible "branching" model) and I lost. I'm
> deeply sorry for any inconvenience that's caused and will cause.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship extended FormData methods

[nsm . nikhil]

Summary: FormData[1] has been an append only interface since it was introduced. 
The WHATWG version of the XHR spec added several methods to has/get/set/delete 
on the entries and introduced iteration support. This puts it in the same class 
as URLSearchParams and Headers.

The proposed patch does not add iterator support.

This email is about 24 hours late in that I've already implemented the changes 
yesterday.

Blink already implements this but hides it behind a flag - 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ksXEB6uB7RY/ZwtCdZGyIVgJ.
 It is the only known engine shipping the feature.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1085283

Link to standard: 
https://xhr.spec.whatwg.org/#interface-formdata
Old standard [1] - http://www.w3.org/TR/XMLHttpRequest/#interface-formdata

Platform coverage: All platforms.
Estimated or target release: Firefox 38

Preference behind which this will be implemented: Should this be preffed off by 
default? It seems a very additive feature to me. In addition the similar 
URLSearchParams has been around for a while as has Headers, so the operation 
patterns seem to be well established. Happy to put it behind 
"dom.formdata.advanced" though.

Nikhil
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

On Thursday 2015-01-29 13:27 -0800, Eric Rescorla wrote:
> On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron  wrote:
> 
> > On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote:
> > > On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron 
> > wrote:
> > > > Please reply to this thread if you think there's something else we
> > > > should say, or if you think we should support the charter.
> > >
> > > I think in general it's fine, but there's a couple things:
> > >
> > > * "Confinement with Origin Web Labels" the description does not make
> > > it clear what this actually is.
> >
> > I suppose I can ask that the description be made clearer.  Is there
> > something in particular that you think it should say?
> >
> > > * "Entry Point Regulation for Web Applications" in a way this is nice
> > > for defense-in-depth, but also seems to allow a site to completely
> > > isolate itself from the rest of the web.
> >
> > I don't see what feedback you want me to give here.
> 
> 
> Is this arguably a violation of the priority of constituencies principle?
> It seems like it may serve the site more than the user.

Do you want to insist that it be removed from the charter, or is
this something you think should be addressed during the development
of the spec (perhaps via some requirement that should be added to
the charter)?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship FormData on workers

[nsm . nikhil]

Summary: The FormData interface allows sending forms directly via XHR. It has 
previously been exposed on window. This intent is to expose it on workers and 
allow the same usage, i.e:
- Creating FormData objects and adding string values or blobs to them
- Sending FormData objects via a call to xhr.send().

It is not possible to directly create a FormData from a HTML form element since 
form elements are not available on workers.

The exposure on workers is a requirement for the Fetch API which we intend to 
ship this quarter. [1]

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=739173

Link to standard: https://xhr.spec.whatwg.org/#interface-formdata

Platform coverage: All platforms
Estimated or target release: Firefox 38
Pref: I intend to hide this behind dom.fetch.enabled, which also controls the 
Fetch specification.

[1]: 
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/intent$20fetch/mozilla.dev.platform/EWGghGeRAV0/2DWWR-KPa_IJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Martin Thomson]

On Thu, Jan 29, 2015 at 1:59 PM, L. David Baron  wrote:

> > Is this arguably a violation of the priority of constituencies principle?
> > It seems like it may serve the site more than the user.
>
> Do you want to insist that it be removed from the charter, or is
> this something you think should be addressed during the development
> of the spec (perhaps via some requirement that should be added to
> the charter)?



In my experience, it's customary for controversial issues like this to be
discussed more in detail before entering them onto an official work plan.
I'm only casually following the working group mailing list, is there a
proposal (or proposals) that outlines a direction for this work?

As for the permissions work, I'm not enthused by its presence, and would
prefer if it were stricken.

I realize at this point that might be unrealistic.  Currently, there is no
requirement to engage with the groups that might be affected by this work.
That must be fixed by adding to the liaison section: a trivial change.

Ultimately though, I have serious reservations about the viability of the
effort - permissions grants are contextual, and the proposed API fails to
address that requirement - but I am happy to engage in discussion to that
effect.  I don't know what expectations are with respect to chartered
items, but if listing on a charter implies some inevitability: a commitment
to complete the listed work, I think that I would rather object to its
inclusion.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship FormData on workers

[Xidorn Quan]

Personally, I don't think it needs to be hidden behind a pref. Given that
FormData has been exposed on window, and the usage is mostly identical, I
suggest it be shipped directly.

- Xidorn

On Fri, Jan 30, 2015 at 9:10 AM,  wrote:

> Summary: The FormData interface allows sending forms directly via XHR. It
> has previously been exposed on window. This intent is to expose it on
> workers and allow the same usage, i.e:
> - Creating FormData objects and adding string values or blobs to them
> - Sending FormData objects via a call to xhr.send().
>
> It is not possible to directly create a FormData from a HTML form element
> since form elements are not available on workers.
>
> The exposure on workers is a requirement for the Fetch API which we intend
> to ship this quarter. [1]
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=739173
>
> Link to standard: https://xhr.spec.whatwg.org/#interface-formdata
>
> Platform coverage: All platforms
> Estimated or target release: Firefox 38
> Pref: I intend to hide this behind dom.fetch.enabled, which also controls
> the Fetch specification.
>
> [1]:
> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/intent$20fetch/mozilla.dev.platform/EWGghGeRAV0/2DWWR-KPa_IJ
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship FormData on workers

[Kyle Huey]

On Fri, Jan 30, 2015 at 8:34 AM, Xidorn Quan  wrote:

> Personally, I don't think it needs to be hidden behind a pref. Given that
> FormData has been exposed on window, and the usage is mostly identical, I
> suggest it be shipped directly.
>
> - Xidorn
>
> On Fri, Jan 30, 2015 at 9:10 AM,  wrote:
>
> > Summary: The FormData interface allows sending forms directly via XHR. It
> > has previously been exposed on window. This intent is to expose it on
> > workers and allow the same usage, i.e:
> > - Creating FormData objects and adding string values or blobs to them
> > - Sending FormData objects via a call to xhr.send().
> >
> > It is not possible to directly create a FormData from a HTML form element
> > since form elements are not available on workers.
> >
> > The exposure on workers is a requirement for the Fetch API which we
> intend
> > to ship this quarter. [1]
> >
> > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=739173
> >
> > Link to standard: https://xhr.spec.whatwg.org/#interface-formdata
> >
> > Platform coverage: All platforms
> > Estimated or target release: Firefox 38
> > Pref: I intend to hide this behind dom.fetch.enabled, which also controls
> > the Fetch specification.
> >
> > [1]:
> >
> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/intent$20fetch/mozilla.dev.platform/EWGghGeRAV0/2DWWR-KPa_IJ
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

+1  No pref.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)

[Mike Hommey]

On Wed, Jan 28, 2015 at 10:07:09AM -0800, Jed Davis wrote:
> Short version: On desktop Linux systems too old to support seccomp-bpf
> system call filtering[1], Gecko Media Plugins will be disabled; in
> practice, this means OpenH264, which is used for H.264 video compression
> in WebRTC.  This will be controlled with a pref, "media.gmp.insecure.allow".

(snip)

So, in practice, because the h264 code is not sandboxed on some setups,
we're disabling it so that vp8, which is not sandboxed either, is used
instead. We have about the same amount of control over openh264 and
vp8 code bases. What makes the difference?

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Mike Hommey]

On Thu, Jan 29, 2015 at 12:31:35PM -0800, Gregory Szorc wrote:
> The steps within my control to potentially fix this issue have been
> postponed until at least tomorrow due to the Firefox Beta build today.
> tl;dr is people don't want to take on additional risk changing repositories.
> 
> I hate to say this, but people using Git for Gecko development will have to
> wait another day for replication to turn on again.

People using Git for Gecko development can also try a new workflow that
doesn't involve gecko-dev at all.

http://glandium.org/blog/?page_id=3438

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)

[Jed Davis]

On Thu, Jan 29, 2015 at 06:57:30AM +0900, Mike Hommey wrote:
> So, in practice, because the h264 code is not sandboxed on some setups,
> we're disabling it so that vp8, which is not sandboxed either, is used
> instead. We have about the same amount of control over openh264 and
> vp8 code bases. What makes the difference?

This is more a question for the WebRTC module leadership, but: assuming
the attacker can choose the codec (do we always secure the media content
at least as much as the script that set up the session?), the set of
vulnerabilities is the union of the codecs' vulnerabilities, and adding
a codec can only add more of them.

Possibly also relevant: we already prefer VP8 over H.264 on desktop.

--Jed

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship extended FormData methods

[Boris Zbarsky]

On 1/29/15 4:56 PM, nsm.nik...@gmail.com wrote:

The proposed patch does not add iterator support.


Is there a bug tracking adding this?


https://xhr.spec.whatwg.org/#interface-formdata


I assume something defines what happens if you delete() while sending 
the formdata and that we implement whatever that is and have test 
coverage for such things?


Apart from those two concerns, this looks fine to me.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship FormData on workers

[Boris Zbarsky]

On 1/29/15 5:10 PM, nsm.nik...@gmail.com wrote:

Pref: I intend to hide this behind dom.fetch.enabled, which also controls the 
Fetch specification.


May I ask why?  This seems like a totally reasonable thing to expose 
independently of Fetch, and might be good to have it in a release before 
Fetch, even.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Evaluating the performance of new features

[Vladan Djeric]

Hi all,

There are a lot of good tools available now for studying Firefox
performance, and I think a lot of them are not well known, so I put
together a list of steps to follow when evaluating the performance of your
next Firefox feature.

   1. Make sure to test your feature on a low-end or mid-range computer;
   our dev machines are uncommonly powerful. Think machines with spinning hard
   drives, not SSDs. Also make sure to test on Windows, as it is used by the
   vast majority of our users.
  - The perf team, fx-team, and gfx team have Windows Asus T100
  

  tablets available in multiple offices just for this purpose. Contact me,
  Gavin, or Milan Sreckovic if you need one.
   2. Ensure your feature does not touch storage on the main thread, either
   directly or indirectly
   - If there's any chance it might cause main-thread IO, test it with
the Gecko
  profiler
  
.
  The profiler now has an option to show you all the IO done on the main
  thread, no matter how brief it is.
  - Also be careful about using SQLite
  


   3. Make sure to add Telemetry probes that measure how well your feature
   performs on real user machines.
   - Check the Telemetry numbers again after your feature reaches the
  release channel. The release channel has a diversity of
configurations that
  simply don't exist on any of the pre-release channels.
 - You can check for regressions in the Telemetry dash
 , or you can ask the perf-team to
 show you how to do a custom analysis (e.g. performance on a
particular gfx
 card type) using MapReduce
 

 or Spark
 

 .
- The learning curve can be a bit steep, so the perf team can
do one-off analyses for you.
 - We have additional performance dashboards; they are listed in
 the "More Dashboards" sidebar on telemetry.mozilla.org
  - Always set the "alert_mails" field for your histogram in
  Histograms.json
  

  so you get automatic e-mail notifications
  
  of performance regressions and improvements.
 - Ideally, this email address should point to an alias for your
 team.
 - Note that the Telemetry regression detector
  has an extremely
 low false-positive rate so you won't be getting any emails unless
 performance has changed significantly.
  4. Keep an eye out on the Talos scores.
  - The Talos tests are much less noisy now than they used to be,
  and more sensitive as well. This is thanks to Avi Halachmi's,
Joel Maher's,
  and others' efforts.
 - Partly as a result of this, we now have a stricter Talos
 sheriffing policy. The patch author has 3 business days to
respond to a
 Talos regression bug (before getting backed out), and two
weeks to decide
 what to do with the regression.
  - Joel Maher will file a regression bug against you if you regress a
  Talos test.
  - The list of unresolved regressions in each release is tracked in
 the meta bugs: Firefox 36
 , Firefox 37
 , Firefox 38
 , etc
 - Joel tracks all the improvements together with all the
 regressions in a dashboard
 
  - If you cause a regression that you can't reproduce on your own
  machine, you can capture a profile directly inside the Talos environment:
  https://wiki.mozilla.org/Buildbot/Talos/Profiling
 - MattN has an excellent tool for comparing the scores of two
 Talos pushes:
 http://compare-talos.mattn.ca/
  - Some Talos tests can be run locally as extensions, others may
  require you to set up a Talos harness
  
.
  Instructions for doing this will be provided in the Talos regression bugs
  from now on.
  - The graph server  can show
  you a history of test scores and test noise to help you determine if the
  reporte

Evaluating the performance of new features (plain text version)

[Vladan Djeric]

(I forgot step 0, don't post HTML messages to a newsgroup ;))

Hi all,

There are a lot of good tools available now for studying Firefox
performance, and I think a lot of them are not well known, so I put
together a list of steps to follow when evaluating the performance of
your next Firefox feature.

1. Make sure to test your feature on a low-end or mid-range Windows computer

- Our dev machines are uncommonly powerful. Think machines with
spinning hard drives, not SSDs. Also make sure to test on Windows, as
it is used by the vast majority of our users.
- The perf team, fx-team, and gfx team have Windows Asus T100 tablets
[1] available in multiple offices just for this purpose. Contact me,
Gavin, or Milan Sreckovic if you need one.

2. Ensure your feature does not touch storage on the main thread,
either directly or indirectly

- If there's any chance it might cause main-thread IO, test it with
the Gecko profiler [2]. The profiler now has an option to show you all
the IO done on the main thread, no matter how brief it is.
- Also be careful about using SQLite [3]

3. Make sure to add Telemetry probes that measure how well your
feature performs on real user machines

- Check the Telemetry numbers again after your feature reaches the
release channel. The release channel has a diversity of configurations
that simply don't exist on any of the pre-release channels.
- You can check for regressions in the Telemetry dash [4] or you can
ask the perf-team to show you how to do a custom analysis (e.g.
performance on a particular gfx card type) using MapReduce [5] or
Spark [6]
- The learning curve can be a bit steep, so the perf team can do
one-off analyses for you.
- There are additional performance dashboards, listed in the "More
Dashboards" sidebar [4]
- Always set the "alert_mails" field [7] for your histogram in
Histograms.json so you get automatic e-mail notifications [8] of
performance regressions and improvements.
- Ideally, this email address should point to an alias for your team.
- Note that the Telemetry regression detector [9] has an extremely low
false-positive rate so you won't be getting any emails unless
performance has changed significantly.

4. Keep an eye out on the Talos scores

- The Talos tests are much less noisy now than they used to be, and
more sensitive as well. This is thanks to Avi Halachmi's, Joel
Maher's, and others' efforts.

How Talos sheriffing works:
- Partly as a result of the test noise improvements, we now have a
stricter Talos sheriffing policy. The patch author has 3 business days
to respond to a Talos regression bug (before getting backed out), and
two weeks to decide what to do with the regression.
- Joel Maher will file a regression bug against you if you regress a Talos test.
- The list of unresolved regressions in each release is tracked in the
meta bugs [10]
- Joel tracks all the improvements together with all the regressions
in his dashboard [11]

Diagnosing regressions:
- If you cause a regression that you can't reproduce on your own
machine, you can capture a profile directly inside the Talos try
environment [12]
- MattN has an excellent tool for comparing the scores of two Talos pushes [13]
- Some Talos tests can be run locally as extensions, others may
require you to set up a Talos harness [14]. Instructions for doing
this will be provided in the Talos regression bugs from now on.
- The graph server [15] can show you a history of test scores and test
noise to help you determine if the reported regression is real.
William Lachance is working on a new & improved graphing UI for
treeherder.

5. Consider writing a new Talos test
- Add a new Talos test [16] if the performance of your feature is
important and it is not covered by existing tests. The Perf team would
be happy to help you design a meaningful and reliable test.
-  Make sure your test measures the right things, isn't noisy and that
it is is able to detect real regressions

Thanks!


Links:
1. 
http://www.amazon.com/Transformer-T100TA-C1-GR-Detachable-Touchscreen-Laptop/dp/B00K0G2XA4
2. 
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem
3. 
https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature
4. https://telemetry.mozilla.org/
5. 
http://mreid-moz.github.io/blog/2013/11/06/current-state-of-telemetry-analysis/
6. 
http://robertovitillo.com/2015/01/16/next-gen-data-analysis-framework-for-telemetry/
7. 
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe#Declaring_a_Histogram
8. https://groups.google.com/forum/#!forum/mozilla.dev.telemetry-alerts
9. http://mozilla.github.io/cerberus/dashboard/
10. For example https://bugzilla.mozilla.org/show_bug.cgi?id=1122690
11. http://alertmanager.allizom.org:8080/alerts.html?showAll=1
12. https://wiki.mozilla.org/Buildbot/Talos/Profiling
13. http://compare-talos.mattn.ca/
14. 
https://wiki.mozilla.org/Buildbot/Talos/Running#Running_locally_-_Source_Code
15. http://graphs.m

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

On Sunday 2015-01-18 21:00 -0800, Brian Smith wrote:
> L. David Baron  wrote:
> >   http://www.w3.org/2014/12/webappsec-charter-2015.html
> 
> Please see the threads at
> 
> [1] https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0179.html
> [2] 
> https://groups.google.com/d/topic/mozilla.dev.privacy/Rbm1XdfXX6k/discussion
> 
> In particular, although I think the sub-origin work is potentially
> very useful, it seems to have some pretty negative unintended
> consequences. Even if you don't share my specific concerns about the
> potential negative interaction between the sub-origin part of the
> proposed charter with respect to Mozilla's Tracking Protection work,

I'm having trouble understanding those concerns.

Is the argument you're making that if the site can serve the ads
from the same hostname rather than having to use a different
hostname to get same-origin protection, then ad-blocking (or
tracking-blocking) tools will no longer be able to block the ads?

I suppose I can see that it could make some forms of ad-blocking
(network-level rather than URI-level) more difficult.  But it's not
clear to me what the additional tracking potential is in this case.
I don't see where it introduces vectors for sharing cookies (or
other similar data) between sites that don't already exist.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship extended FormData methods

[nsm . nikhil]

On Thursday, January 29, 2015 at 6:39:22 PM UTC-8, Boris Zbarsky wrote:
> On 1/29/15 4:56 PM, nsm.nik...@gmail.com wrote:
> > The proposed patch does not add iterator support.
> 
> Is there a bug tracking adding this?

https://bugzilla.mozilla.org/show_bug.cgi?id=1127703

> 
> > https://xhr.spec.whatwg.org/#interface-formdata
> 
> I assume something defines what happens if you delete() while sending 
> the formdata and that we implement whatever that is and have test 
> coverage for such things?

The fetch spec states that FormData is immediately serialized when send() is 
called (send defers to Fetch's "extract body" routine) 
https://fetch.spec.whatwg.org/#concept-bodyinit-extract.

In Gecko, an nsFSMultipartFormData object serializes all entries to a multiplex 
stream immediately, so delete()/set()s called after a call to send() won't 
change the entries.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

Here are the comments I have so far on this charter, based on the
thread.  I'd note that this is a relatively large set of demands to make
in the charter review stage at the AC, especially for a recharter of a
WG that we're involved in.  So it may come across to W3C staff as
somewhat demanding.

I'm particularly interested in review of point (3) in what I've written;
I feel that the argument I've written so far is weak, I think because I
don't particularly understand the concerns about the powerfulfeatures
draft.

I also haven't included anything about Brian's objection to the
suborigin namespaces work because I don't understand the objection, and
I don't see how to extract any actionable charter feedback directly from
Brian's message.  (Or is it that the deliverable should be removed from
the charter?  If so, I could use an explanation as to why.)

In any case, here's the feedback I have so far.  Comments are
welcome through roughly 5pm California time on Friday --
particularly actionable ones that suggest how to revise this
feedback or at least say how the charter should be different!

(Sorry for not getting this gathered together sooner.)

-David


There are a number of problematic aspects to this charter to which
we object:

(1) The "Confinement with Origin Web Labels" deliverable is described
in a way that makes it unclear what the deliverable would do.  It
should be clearer.  Furthermore, the lack of clarity means we
couldn't evaluate whether we are comfortable with it being in the
charter.

(2) The "Entry Point Regulation for Web Applications" deliverable seems
to have serious risks of breaking the ability to link.  It's not
clear that the security benefits of this specification outweigh the
risks to the abilities of Web users.

(3) In the scope section, the item "Application awareness of powerful
features which may require explicit user permission to enable."
It's not clear whether this part of the scope is intended to
allow https://w3c.github.io/permissions/ to be a document in the
working group (which may be comfortable with, although some of us
have serious concerns about whether it is actually workable), or
whether it's intended to put
https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope
of the working group, which we believe should not be, because we
don't believe the WebAppSec WG should be in the role of policing the
specifications of other groups (which is not the role it has
historically held), and we believe that in general specifications
about how to write other specifications have not been successful,
particularly if they attempt to have any mandatory status.

At a minimum, it would be good to rephrase this item so that it
doesn't use the term "powerful features".  It would probably be
preferable to explicitly state that work like the powerfulfeatures
draft is not in the scope of the working group.

(4) We believe the charter should have provision for asynchronous
decision making, perhaps as in
http://www.w3.org/2012/webapps/charter/#decisions .

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship FormData on workers

[nsm . nikhil]

On Thursday, January 29, 2015 at 6:41:53 PM UTC-8, Boris Zbarsky wrote:
> On 1/29/15 5:10 PM, nsm.nik...@gmail.com wrote:
> > Pref: I intend to hide this behind dom.fetch.enabled, which also controls 
> > the Fetch specification.
> 
> May I ask why?  This seems like a totally reasonable thing to expose 
> independently of Fetch, and might be good to have it in a release before 
> Fetch, even.
> 
> -Boris

Well my work on getting FormData on workers was because Fetch uses it, and 
there doesn't seem to have been demand for it on workers before. 

Blink does not implement it yet (and doesn't seem to have activity on the 
bug[1]). I don't know about IE/Safari. If there are no compat issues, I'm happy 
to just ship it.

[1]: 
https://code.google.com/p/chromium/issues/detail?id=89532&q=formdata%20worker&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Evaluating the performance of new features

[Jonas Sicking]

On Thu, Jan 29, 2015 at 6:52 PM, Vladan Djeric  wrote:
>   
> 

Definitely not intending to point you out here Vladan.

However, it would be cool if we fixed our IndexedDB implementation
rather than told our own developers not to use it. Web developers are
not so lucky as to have other options.

There's no reason we couldn't make IndexedDB use flat files and
something similar to writeAtomic() when the amount of data stored is
small. And then dynamically switch to the current SQLite backend as
data grows large enough that that is better.

That seems more efficient than ask every frontend developer to write
their own storage implementation.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform