Re: Hiding 'new' statements - Good or Evil?

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.

Re: Intent to ship: Changes to ‘X-Frame-Options: SAMEORIGIN’

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

Re: Hiding 'new' statements - Good or Evil?

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

Re: Intent to ship: Changes to ‘X-Frame-Options: SAMEORIGIN’

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

Re: Hiding 'new' statements - Good or Evil?

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

Re: Hiding 'new' statements - Good or Evil?

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

Re: Hiding 'new' statements - Good or Evil?

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

Re: Hiding 'new' statements - Good or Evil?

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

Re: Intent to ship: Treating object subrequests as mixed active content

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

Re: Intent to implement: scroll-boundary-behavior

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

Re: Intent to ship: Treating object subrequests as mixed active content

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

Intent to ship: Treating object subrequests as mixed active content

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

Intent to ship: Changes to ‘X-Frame-Options: SAMEORIGIN’

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

Re: Intent to implement (again): Shadow DOM

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

Re: Intent to implement (again): Shadow DOM

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

[Firefox Desktop] Issues found: November 20th to November 24th

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

Intent to implement (again): Shadow DOM

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.

Re: Intent to implement (again): Shadow DOM

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

Re: Hiding 'new' statements - Good or Evil?

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

Re: Hiding 'new' statements - Good or Evil?

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