On Mon, 15 Sep 2014 17:04:28 -0400, Ehsan Akhgari wrote:
> On 2014-09-15, 5:47 AM, Kilik kuo wrote:
>> One more thing,
>>
>> We would like to support URL of app scheme for requesting session.
>> And the scope will be as below.
>> - Certified and Privileged with declaration of origin apps are
>> su
Hello all,
Today I landed bug 1001090 (assuming it doesn't bounce), implementing ES6
lexical temporal dead zone for function-level `let` declarations, on
mozilla-central. As a refresher on the email I sent on Aug. 13, this is a
backwards-incompatible change.
Everything inside mozilla-central need
On Mon, Sep 15, 2014 at 10:40 PM, Jonas Sicking wrote:
> The argument that I'm making, and I think Anne is too, is that we
> should have the ability to store policies like this in the
> nsIPermissionManager. That way we *can* use it in places where it
> makes sense, or we can choose to simply stor
On 2014-09-15, 4:40 PM, Jonas Sicking wrote:
On Mon, Sep 15, 2014 at 11:15 AM, Ehsan Akhgari wrote:
On 2014-09-14, 3:54 AM, Anne van Kesteren wrote:
On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla wrote:
I just tested this and it appears that at least for gUM, IFRAMEs do *not*
get persisten
On 2014-09-15, 5:47 AM, Kilik kuo wrote:
One more thing,
We would like to support URL of app scheme for requesting session.
And the scope will be as below.
- Certified and Privileged with declaration of origin apps are supported.
- Privileged apps w/o declaration of origin are NOT supported.
- R
On Mon, Sep 15, 2014 at 11:15 AM, Ehsan Akhgari wrote:
> On 2014-09-14, 3:54 AM, Anne van Kesteren wrote:
>>
>> On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla wrote:
>>>
>>> I just tested this and it appears that at least for gUM, IFRAMEs do *not*
>>> get persistent permissions even if they would
The next MemShrink meeting will be brought to you by app-theme-changed
observers not getting double-added:
https://bugzilla.mozilla.org/show_bug.cgi?id=1061202
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bug
First, the "overly broad block" was an absolutely lazy way out, and should have
been readdressed long ago.
Second, you (in the collective sense) should "remove the broad block", by all
means. Posthaste.
Third, "block[ing] the known-vulnerable versions, which would require coming up
with a reg
On 2014-09-14, 3:54 AM, Anne van Kesteren wrote:
On Sat, Sep 13, 2014 at 5:42 PM, Eric Rescorla wrote:
I just tested this and it appears that at least for gUM, IFRAMEs do *not*
get persistent permissions even if they would have them if they were
in the top level window. Rather, you always get p
On 9/15/14 11:08, Anne van Kesteren wrote:
Google seems to have the right trade off
and the "IETF consensus" seems to be unaware of what is happening
elsewhere.
You're confused.
The whole line of argumentation that web browsers and servers should be
taking advantage of opportunistic encryptio
On Mon, Sep 15, 2014 at 9:08 AM, Anne van Kesteren wrote:
> On Mon, Sep 15, 2014 at 5:59 PM, Richard Barnes
> wrote:
> > On Sep 15, 2014, at 5:11 AM, Henri Sivonen wrote:
> >> I think the primary way for making the experience better for users
> >> currently accessing http sites should be gettin
On Mon, Sep 15, 2014 at 5:59 PM, Richard Barnes wrote:
> On Sep 15, 2014, at 5:11 AM, Henri Sivonen wrote:
>> I think the primary way for making the experience better for users
>> currently accessing http sites should be getting the sites to switch
>> to https so that subsequently people accessin
On Sep 15, 2014, at 5:11 AM, Henri Sivonen wrote:
> On Mon, Sep 15, 2014 at 11:24 AM, Daniel Stenberg wrote:
>> On Mon, 15 Sep 2014, Henri Sivonen wrote:
>>> What the Chrome folks suggest for HTTP/2 would give rise to a situation
>>> where your alternatives are still one one hand unencrypted an
On Mon, Sep 15, 2014 at 4:40 PM, Mark Côté wrote:
> Yes, we plan on supporting more than just mozilla-central. The initial
> deployment will only support Mercurial, but we plan on adding git
> support soon after--and there's no reason it couldn't work with GitHub
> as well.
>
That's great to he
Yes, we plan on supporting more than just mozilla-central. The initial
deployment will only support Mercurial, but we plan on adding git
support soon after--and there's no reason it couldn't work with GitHub
as well.
Mark
On 2014-09-15 10:24 AM, Till Schneidereit wrote:
> I agree with Ehsan: th
For now, this is only limited to test jobs. I should have made emphasis
on it.
My apologies about it. I was hoping to deal with different use cases as
people tried them out.
Filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1067354
On 14-09-11 08:58 AM, Armen Zambrano G. wrote:
> Hello all,
>
I agree with Ehsan: this is really exciting!
Do you also plan to add integration with external repositories at a later
point?
I'm working on the Shumway project, and we do our bug tracking in BMO, but
have our source in github (largely for historical reasons, but a reason for
not moving away from
Filed to make it clearer next time:
https://bugzilla.mozilla.org/show_bug.cgi?id=1067354
Thanks for trying it!
On 14-09-15 12:11 AM, Ting-Yu Chou wrote:
> Hi,
>
> The patch of bug 1049290 failed linux64-br-haz_try_dep, I am trying to debug
> it
> locally. I read:
>
>
> https://wiki.mozilla.
One more thing,
We would like to support URL of app scheme for requesting session.
And the scope will be as below.
- Certified and Privileged with declaration of origin apps are supported.
- Privileged apps w/o declaration of origin are NOT supported.
- Remote UA will launch the URL of app scheme
On Mon, Sep 15, 2014 at 11:24 AM, Daniel Stenberg wrote:
> On Mon, 15 Sep 2014, Henri Sivonen wrote:
>> What the Chrome folks suggest for HTTP/2 would give rise to a situation
>> where your alternatives are still one one hand unencrypted and
>> unauthenticated and on the other hand encrypted and a
Never mind, I just found this:
https://wiki.mozilla.org/Javascript:SpiderMonkey:ExactStackRooting
Will try ask on #jsapi.
Ting
- Original Message -
> From: "Ting-Yu Chou"
> To: "dev-platform"
> Sent: Monday, September 15, 2014 12:11:28 PM
> Subject: How to run browser rooting analys
On Mon, Sep 15, 2014 at 10:24 AM, Daniel Stenberg wrote:
> Shouldn't we strive to make the user experience better for all
> users, even those accessing HTTP sites?
Well, the question is whether we want HTTP in the end. E.g. we are
opting to not enable new powerful features such as service workers
On Mon, 15 Sep 2014, Henri Sivonen wrote:
What the Chrome folks suggest for HTTP/2 would give rise to a situation
where your alternatives are still one one hand unencrypted and
unauthenticated and on the other hand encrypted and authenticated *but* the
latter is *faster*.
You mess up that re
On Fri, Sep 12, 2014 at 6:07 PM, Trevor Saunders
wrote:
> Do we really want all servers to have to authenticate themselves?
On the level of DV, yes, I think. (I.e. the user has a good reason to
believe that the [top-level] page actually comes from the host named
in the location bar.)
> In
> m
24 matches
Mail list logo
