Issue processing new revisions on Phabricator
Heads up that there's an issue with processing of new revisions on Phabricator; they will be stuck in a restricted state and cannot be reviewed while this issue exists. This issue should be fixed later today. This is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1664972. Reach out to Joe Walker if you have an urgent need to land changes. -- glob — engineering workflow manager — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure
On Mon, Sep 14, 2020 at 10:00 AM Michael Reeps wrote: > I am seeing this warning now, even when I am in a first party context: > > Cookie "xxx” will be soon rejected because it has the “SameSite” attribute > set to “None” or an invalid value, without the “secure” attribute. The > cookies in question are set in the .cfainstitute.org domain and being > read only in that same domain. Am I to infer they are going to be rejected > anyway, simply because they lack the "secure" attribute? > That is what the proposed spec change requires, yes. https://tools.ietf.org/html/draft-west-cookie-incrementalism-01#section-3.2 -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure
On Wednesday, July 1, 2020 at 11:07:36 AM UTC-4, mco...@mozilla.com wrote: > Starting with Beta 79 today, we are rolling out this change to the default > behavior of SameSite cookies to a small percentage of the beta population. > The initial target is 10%, slowly increasing to 50% by the end of the beta > cycle. We will hold at 50% for at least two more beta cycles, at which point > we will consider introducing this to a small percentage of the Firefox > release population. > > Known site breakage is being tracked here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1618610 > > Web developers can find more information here: > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#Fixing_common_warnings > > > A good overview of this issue can be found here: > https://web.dev/samesite-cookies-explained/ > > Mike Conca > Group Product Manager, Firefox Web Technologies > On Thursday, May 23, 2019 at 2:34:14 AM UTC-6, Andrea Marchesini wrote: > > Link to the proposal: > > https://tools.ietf.org/html/draft-west-cookie-incrementalism-00 > > > > Summary: > > "1. Treat the lack of an explicit "SameSite" attribute as > > "SameSite=Lax". That is, the "Set-Cookie" value "key=value" will > > produce a cookie equivalent to "key=value; SameSite=Lax". > > Cookies that require cross-site delivery can explicitly opt-into > > such behavior by asserting "SameSite=None" when creating a > > cookie. > > 2. Require the "Secure" attribute to be set for any cookie which > > asserts "SameSite=None" (similar conceptually to the behavior for > > the "__Secure-" prefix). That is, the "Set-Cookie" value > > "key=value; SameSite=None; Secure" will be accepted, while > > "key=value; SameSite=None" will be rejected." Mike, I am seeing this warning now, even when I am in a first party context: Cookie "xxx” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. The cookies in question are set in the .cfainstitute.org domain and being read only in that same domain. Am I to infer they are going to be rejected anyway, simply because they lack the "secure" attribute? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Update browsing context name on cross site navigation or history traversal
On Fri, Sep 11, 2020 at 10:55 PM Shuran Huang wrote: > Thanks for the pointer. I did not realize it's about the cross-origin > navigation that not switch BrowsingInstance. Just to confirm, is the case for > top-level navigation only or not? Cross-origin navigations of top-level browsing contexts whose opener browsing context is either null or disowned. (It might be that null and disowned can be merged, but currently they are not specification-wise.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 82 starts September 17
Hi all, With Firefox 81 merging to mozilla-release later today, we are nearing the end of the Nightly 82 cycle. In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out 82 Betas to a wider audience with confidence, we'd like to ask that any risky changes be avoided from Thursday September 17 until after the version bump to 83 on September 21. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Julien and the release management team ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype: Allow :is() and :where() to have better selector error recovery.
On Monday, September 14, 2020 at 12:24:13 AM UTC+2, Emilio Cobos Álvarez wrote: > DevTools bug: I'm not sure if it is necessary to have a devtools bug for > this. The selector will serialize as :is(div) rather than :is(div, > :nonsense), for example. Other than that, devtools should just work. If > folks feel strongly otherwise, please file a bug and cc me on it and > I'll take a look, maybe some more work could be done to surface this > better in DevTools, though it wouldn't be trivial right now to expose it > via the regular CSS parse error reporting mechanism (because parsing > will, in fact, succeed). Authors would definitely benefit from knowing that selectors within :is() and :where() are invalid, allowing them to correct those errors. Therefore I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1664739 and https://bugzilla.mozilla.org/show_bug.cgi?id=1664740 for two ways how to expose this info to them. Sebastian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
