Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On 15/04/16 03:58 AM, Tanvi Vyas wrote: > So how about a preference that treats all cookies set in a third party > context as session cookies. We could restrict this to HTTP, or even > apply it to third party HTTPS cookies. We seem to have this already: network.cookie.thirdparty.sessionOnly Fran

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

Thanks for all the feedbck. I anticipated this proposal might not be practical with real world sites, so it's better to halt it here. :) I should have framed this email as an RFC instead of an intent to ship. Focusing on third-party session cookies is an interesting idea. "Sessionizing" non-HT

Re: One Firefox repository to rule them all

When will mozilla-central use generaldelta? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: One Firefox repository to rule them all

On Thu, Apr 14, 2016 at 5:22 PM, Gregory Szorc wrote: > I'm pleased to announce the immediate availability of some *experimental* > read-only Mercurial repositories containing the combined, useful history of > the various Firefox repositories, all in chronological order and stored in > a more eff

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

Chris, Le 14 avr. 2016 à 17:54, Chris Peterson a écrit : > Instead, I propose treating all cookies set over non-secure HTTP as session > cookies, regardless of whether they have the `secure` flag. […] To test my > proposal, I loaded the home pages of the Alexa Top 25 News sites [2]. To test th

One Firefox repository to rule them all

I'm pleased to announce the immediate availability of some *experimental* read-only Mercurial repositories containing the combined, useful history of the various Firefox repositories, all in chronological order and stored in a more efficient format that is faster to clone and pull from and results

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

The restriction to third-party requests is an interesting suggestion and might provide some of the benefits Chris mentioned in the original proposal. Seems like a change done carefully and with others. best, Joe On Thu, Apr 14, 2016 at 4:32 PM, Martin Thomson wrote: > I would like to see other br

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

I would like to see other browsers on board before taking on these risks. And a lot more testing. For instance, is there a way to collect telemetry on the impact of such a change without actually implementing it? Does restricting it to 3rd party requests change things? On Fri, Apr 15, 2016 at 1

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On the surface, this seems like a great idea and privacy win - it gets rid of all those pesky tracking cookies! But under the covers there are a lot of issues, as mentioned by previous replies and summarized below: * Puts the user's password at greater risk, since the user has to enter it and

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On Thu, Apr 14, 2016 at 1:54 AM, Chris Peterson wrote: > Summary: Treat cookies set over non-secure HTTP as session cookies > > Exactly one year ago today (!), Henri Sivonen proposed [1] treating > cookies without the `secure` flag as session cookies. > > PROS: > > * Security: login cookies set o

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

This seems like the right question. -Ekr On Thu, Apr 14, 2016 at 9:17 AM, Kyle Huey wrote: > Why should we be the ones to take the web compat hit on this? > > - Kyle > On Apr 14, 2016 1:55 AM, "Chris Peterson" wrote: > > > Summary: Treat cookies set over non-secure HTTP as session cookies > >

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

I have two concerns with this. First off, it means that users might need to actively log in to websites more often. This is a really big hassle for users, especially on mobile. We did some studies when we did FirefoxOS between the differences between native versions and web version of various apps

Engineering Productivity Q1 Update

Engineering Productivity is off to a great start in 2016; here’s what we’ve been up to in Q1. Build System Build system improvements are a major priority for Engineering Productivity in 2016. The build team made great progress in Q1: - Windows builds are now made using VS2015. This shaves

Re: Why do we still need to include Qt widget in mozilla-central?

Added Raine Mäkeläinen, who has been committing to qtmozembed lately, to CC. On Thu, Apr 14, 2016 at 1:51 AM, Jim Blandy wrote: > On Tue, Apr 12, 2016 at 4:27 AM, Henri Sivonen wrote: >> >> On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano >> wrote: >> > So, my question is, why do we still have

Re: Intent to Implement/Ship: -webkit-text-stroke

On 04/14/2016 02:40 AM, Ms2ger wrote: >> Preference behind which this will be implemented: >> layout.css.prefixes.webkit > > Should this have a more specific pref? Absent a compelling reason, no -- it should not. We're using layout.css.prefixes.webkit here because, without this -webkit-text-stro

New talos e10s comparison mode: e10s-vs-non-e10s on a single push

Hey all, I added a new mode to the talos e10s comparison view, that lets you compare e10s-vs-non-e10s numbers on the same push. For example: https://treeherder.mozilla.org/perf.html#/e10s?repo=try&revision=77c805ba9c18 Currently there is no UI wired up, the expectation is that this would be

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

Why should we be the ones to take the web compat hit on this? - Kyle On Apr 14, 2016 1:55 AM, "Chris Peterson" wrote: > Summary: Treat cookies set over non-secure HTTP as session cookies > > Exactly one year ago today (!), Henri Sivonen proposed [1] treating > cookies without the `secure` flag a

Re: Spidernode/JXCore

There are indeed discussions in nodejs to became more vm agnostic. This was also hinted at in https://github.com/mozilla/spidernode/issues/3 On Thu, Apr 14, 2016 at 6:08 PM, Steve Fink wrote: > On 04/14/2016 06:21 AM, Philip Chee wrote: >> >> On 12/04/2016 19:27, Henri Sivonen wrote: >> >>> My un

Re: Spidernode/JXCore

On 04/14/2016 06:21 AM, Philip Chee wrote: On 12/04/2016 19:27, Henri Sivonen wrote: My understanding is that https://git.merproject.org/mer-core/qtmozembed/ still uses it. As we are figuring out how to be more embeddable (see https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ), it

Re: Dump frame tree in real time

On 4/14/16 10:52 AM, Jip de Beer wrote: The Frame Dump doesn't contain any information about z-order. That information is not stored in the frame tree, really. It's computed during display list construction. How can I know which nodes are in front of other nodes? The answer, in general,

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

I don't see how we can do this by default without harming our users. We can be confident that this will break persistent login for lots of sites. I appreciate the goal of moving HTTPS forward, but we are not in a position where we our marketshare would force changes to the web ecosystem. Before tu

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Hi Lawrence, The team is saying we do not know him, but I've raised this to Andrei and Alexandra to provide him some guidance. Regards, Florin. On Tue, Apr 12, 2016 at 2:06 AM, Lawrence Mandel wrote: > > > On Monday, 11 April 2016, Mike Taylor wrote: > >> On 4/11/16 5:04 PM, Mats Palmgren wro

Re: Dump frame tree in real time

Unfortunately Dump -> Frames using the Layout Debugger doesn't give me the information I'm looking for. I would like to access the following information about all visible DOM nodes (nodes that take up space in the document): - z-order - position - dimensions The Frame Dump doesn't contain any i

Spidernode/JXCore

On 12/04/2016 19:27, Henri Sivonen wrote: > My understanding is that > https://git.merproject.org/mer-core/qtmozembed/ still uses it. As we > are figuring out how to be more embeddable (see > https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ), it's AFAICT Spidernode is an ex-parrot.

Re: Intent to Implement/Ship: -webkit-text-stroke

On Thu, Apr 14, 2016 at 7:40 PM, Ms2ger wrote: > On 14/04/16 09:26, Jeremy Chen wrote: > > *Summary*: We don't currently support -webkit-text-stroke; however, it > has > > been available for years in webkit based browsers and has seen widespread > > usage on the web. This css property is current

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On Thu, Apr 14, 2016 at 11:54 AM, Chris Peterson wrote: > * Sites that allow users to configure preferences without logging into an > account would forget the users' preferences if they are not using HTTPS. For > example, companies that have regional sites would forget the user's selected > region

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On Thu, Apr 14, 2016 at 6:54 PM, Chris Peterson wrote: > > Do other browser engines implement this? No > I have no particular thought about the idea itself, but it seems to me this is a breaking change to the web. As it's a major breaking change, I don't think we should do this without support

Re: Intent to Implement/Ship: -webkit-text-stroke

On 14/04/16 09:26, Jeremy Chen wrote: > *Summary*: We don't currently support -webkit-text-stroke; however, it has > been available for years in webkit based browsers and has seen widespread > usage on the web. This css property is currently available in Chrome and > Safari. How about Edge? Shou

Re: Intent to Ship: HTML5 and tags

On Thu, Apr 14, 2016 at 6:51 PM, Ting-Yu Lin wrote: > On Firefox: > summary::-moz-list-bullet { list-style-type: none; } OR summary { > display: block; } Shouldn't "summary { list-style-type: none; }" be enough? - Xidorn ___ dev-platform mailing li

Re: Intent to Ship: HTML5 and tags

On Thu, Apr 14, 2016 at 5:03 PM, Xidorn Quan wrote: > On Thu, Apr 14, 2016 at 6:51 PM, Ting-Yu Lin wrote: > >> On Firefox: >> summary::-moz-list-bullet { list-style-type: none; } OR summary { >> display: block; } > > > Shouldn't "summary { list-style-type: none; }" be enough? > > Yes. With Bug

Re: Intent to Ship: HTML5 and tags

> No other implementation supports ::marker either, right? If that is > correct, it seems fine to me to perfect styling support in a later > release. Yes. Currently, no other vendor support ::marker. > Do other browsers support styling the disclosure triangle? Chrome and Safari could style the tri

Intent to ship: Treat cookies set over non-secure HTTP as session cookies

Summary: Treat cookies set over non-secure HTTP as session cookies Exactly one year ago today (!), Henri Sivonen proposed [1] treating cookies without the `secure` flag as session cookies. PROS: * Security: login cookies set over non-secure HTTP can be sniffed and replayed. Clearing those co

Re: Intent to Ship: HTML5 and tags

On Thu, Apr 14, 2016 at 12:53 AM, Ting-Yu Lin wrote: > One major concern in the "intent to implement" discussion is the ability to > style the summary disclosure triangle. Currently summary has default style > "display: list-item", so we can style the triangle via the pseudo element > |summary::-

Intent to Ship: HTML5 and tags

As of Firefox 48 I intent to ship HTML5 and tags on all platforms. The features has been developed behind pref "dom.details_element.enabled", and had been enabled on non-release build in bug 1241750 Bug: https://bugzilla.mozilla.org/show_bu

Intent to Implement/Ship: -webkit-text-stroke

*Summary*: We don't currently support -webkit-text-stroke; however, it has been available for years in webkit based browsers and has seen widespread usage on the web. This css property is currently available in Chrome and Safari. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1248708 *Link

Intent to Implement/Ship: -webkit-text-stroke

*Summary*: We don't currently support -webkit-text-stroke; however, it has been available for years in webkit based browsers and has seen widespread usage on the web. This css property is currently available in Chrome and Safari. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1248708 *Link