On 11/27/17 7:45 PM, Eric Rescorla wrote:
As for the lifetime question, can you elaborate on the scenario you are
concerned about.
Olli may have a different concern, but I'm thinking something like this:
for (auto foo : myFoos) {
foo->bar();
}
where bar() can run arbitrary script. Is
I think you might be getting confused between frame-src and frame-ancestors.
"frame-src" is a allowlist for frames that can be loaded into the web page.
"frame-ancestors" is an allowlist of documents that can frame the web page.
So in your example code:
on a.com
X-Frame-Options beha
On Tue, Nov 28, 2017, at 11:45 AM, Eric Rescorla wrote:
> On Mon, Nov 27, 2017 at 4:07 PM, smaug wrote:
> > And auto makes code reading harder. It hides important information like
> > lifetime management.
> > It happens easily with auto that one doesn't even start to think whether
> > nsCOMPtr/Ref
On Monday, November 27, 2017 at 9:32:20 AM UTC-6, Jonathan Kingston wrote:
> Currently XFO only enforces same origin checks of the loading frame against
> the top-level document when the SAMEORIGIN value is set[1][2]. However, XFO
> does not check the entire ancestor chain before making a decision
On Mon, Nov 27, 2017 at 4:07 PM, smaug wrote:
> On 11/28/2017 12:53 AM, Jeff Gilbert wrote:
>
>> ranged-for issues are the same as those for doing manual iteration,
>>
> It is not, in case you iterate using
> for (i = 0; i < foo.length(); ++i)
> And that is the case which has been often converted
On Nov 27, 2017, at 6:07 PM, smaug wrote:
>
> And auto makes code reading harder. It hides important information like
> lifetime management.
> It happens easily with auto that one doesn't even start to think whether
> nsCOMPtr/RefPtr should be used there.
>
> I'm saying this all with my review
On 11/28/2017 12:53 AM, Jeff Gilbert wrote:
ranged-for issues are the same as those for doing manual iteration,
It is not, in case you iterate using
for (i = 0; i < foo.length(); ++i)
And that is the case which has been often converted to ranged-for, with bad
results.
And auto makes code readi
ranged-for issues are the same as those for doing manual iteration,
and your complaints about auto are caused by deficient code/design
review.
The further we deviate from standards, the harder it is for
contributors (and not just new ones) to do the right thing. The
default should be to move towar
My understanding is all other browsers will still would load this request.
Chrome marks this as Mixed Passive and warns in the console whilst the
request still can be seen in the network panel. I was only testing with a
self signed certificate so unsure if the URL bar would display as "Not
Secure"
This has now landed on the Nightly channel.
Cheers,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
How does this behavior compare with other browsers?
Alex
On Mon, Nov 27, 2017 at 7:47 AM, Jonathan Kingston wrote:
> Currently our mixed content blocker implementation treats object
> subrequests as mixed passive content. As part of our plan to deprecate
> insecure connections we are going to b
Currently our mixed content blocker implementation treats object
subrequests as mixed passive content. As part of our plan to deprecate
insecure connections we are going to block insecure subrequests in flash.
Mostly because such subrequests can contain data or functionality which
might be dangerou
Currently XFO only enforces same origin checks of the loading frame against
the top-level document when the SAMEORIGIN value is set[1][2]. However, XFO
does not check the entire ancestor chain before making a decision whether
the load should be allowed or blocked.
In more detail, a load of: a.com
On 11/27/2017 02:01 PM, James Graham wrote:
> On 27/11/17 12:20, smaug wrote:
>> This is basically an after the fact notification that
>> we're in progress of implementing Shadow DOM again, this time v1[1].
>> While doing this, the v0 implementation, which was never exposed to
>> the web, will be r
On 27/11/17 12:20, smaug wrote:
This is basically an after the fact notification that
we're in progress of implementing Shadow DOM again, this time v1[1].
While doing this, the v0 implementation, which was never exposed to the
web, will be removed.
v1 is luckily way simpler, so this all should
Here's the list of new issues found and filed by the Desktop Release QA
team last week.
Additional details on the team's priorities last week, as well as the plans
for the current week are available at: https://goo.gl/7YwnLr.
Bugs logged by Desktop Release QA in the last 8
daysIDSevPriPltAssigne
This is basically an after the fact notification that
we're in progress of implementing Shadow DOM again, this time v1[1].
While doing this, the v0 implementation, which was never exposed to the web,
will be removed.
v1 is luckily way simpler, so this all should simplify various bits in DOM.
FF6
On 11/27/2017 02:20 PM, smaug wrote:
This is basically an after the fact notification that
we're in progress of implementing Shadow DOM again, this time v1[1].
While doing this, the v0 implementation, which was never exposed to the web,
will be removed.
v1 is luckily way simpler, so this all sho
On 11/27/2017 01:05 PM, Nicolas B. Pierron wrote:
On 11/26/2017 12:45 AM, smaug wrote:
On 11/24/2017 06:35 PM, Eric Rescorla wrote:
On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote:
On 11/23/2017 11:54 PM, Botond Ballo wrote:
I think it makes sense to hide a 'new' call in a Make* function when
On 11/26/2017 12:45 AM, smaug wrote:
On 11/24/2017 06:35 PM, Eric Rescorla wrote:
On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote:
On 11/23/2017 11:54 PM, Botond Ballo wrote:
I think it makes sense to hide a 'new' call in a Make* function when
you're writing an abstraction that handles allocat
20 matches
Mail list logo