Hi all,
In bug 1588737 I plan to remove access to the -moz-touch-enabled media
feature.
This is a non-standard media-query feature that predates the standard
hover and any-hover media features. It seems that Modernizr (a fairly
popular library to do feature detection) bogusly uses it to assu
On 2019-10-16 7:15 a.m., Paul Zühlcke wrote:
I plan to land a patch next week which will disable OriginAttribute
stripping in the permission manager. This will result in private browsing
windows and containers having isolated permissions.
Are we still planning to strip origin attributes before
Right, I can see the threat model being similar, but technically we're
marrying two separate things under the same UI and more importantly the
same permission name. This will instantly cause trouble once one of the two
features changes its requirements or behavior in a way that's incompatible
with
On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren wrote:
> I intend to enable CSS subgrid by default for v71.
>
> *Summary: *
> The CSS Grid 2 subgrid feature allows nested grids to participate in the
> sizing of their parent's tracks, on a per-axis basis.
>
> *Bug to turn on by
On Thu, Oct 17, 2019 at 1:35 PM Matthew N. wrote:
> On 2019-10-16 7:15 a.m., Paul Zühlcke wrote:
> > I plan to land a patch next week which will disable OriginAttribute
> > stripping in the permission manager. This will result in private browsing
> > windows and containers having isolated permiss
I wrote another mini tool for my own purposes that I felt might be of
use to more people.
Periodically, I want to gather some sort of data from nontrivial browser
runs. So I'll stick some printfs into the code and do a try push -- most
often to run Talos jobs, since I naively think of them as
I wrote a similar thing, not nearly as friendly, that takes a taskgroupid:
https://gist.github.com/tomrittervg/9e99de9b3c517b8ba4e87d2a86985616
It seems like there should be some better platform for communicating these
types of tools.
-tom
PS: Other gists I have:
https://gist.github.com/tomritte
On 10/17/19 5:35 PM, ikilpatr...@chromium.org wrote:
On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren
wrote:
*Secure contexts:* N/A
Replying as requested from:
https://twitter.com/ecbos_/status/1184690249324290048
Well, I just copy-pasted the email-template TYLin used in hi
On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren wrote:
> On 10/17/19 5:35 PM, ikilpatr...@chromium.org wrote:
> > On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren
> > wrote:
> >> *Secure contexts:* N/A
> >
> > Replying as requested from:
> > https://twitter.com/
On Thu, Oct 17, 2019 at 12:59 PM Tom Ritter wrote:
> I wrote a similar thing, not nearly as friendly, that takes a taskgroupid:
> https://gist.github.com/tomrittervg/9e99de9b3c517b8ba4e87d2a86985616
>
> It seems like there should be some better platform for communicating these
> types of tools.
>
On 10/17/19 8:12 PM, ikilpatr...@chromium.org wrote:
On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren
wrote:
As far as I know, we never constrain new CSS features to secure
contexts. At least not on the property/value level.
According to
https://blog.mozilla.org/security/2018/
On Thursday, October 17, 2019 at 12:47:27 PM UTC-7, Mats Palmgren wrote:
> On 10/17/19 8:12 PM, ikilpatr...@chromium.org wrote:
> > On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren
> > wrote:
> >> As far as I know, we never constrain new CSS features to secure
> >> contexts. At lea
On Thu, Oct 17, 2019 at 1:05 PM wrote:
>
> These features (broadly speaking) are different however. According to the
> above policy:
> "Exceptions to requiring secure contexts"
> " - other browsers already ship the feature insecurely"
>
> Most (all?) of the non-trivial features above have shipped
On Thursday, October 17, 2019 at 3:15:49 PM UTC-7, Sean Voisen wrote:
> On Thu, Oct 17, 2019 at 1:05 PM wrote:
>
> >
> > These features (broadly speaking) are different however. According to the
> > above policy:
> > "Exceptions to requiring secure contexts"
> > " - other browsers already ship th
On 10/17/19 10:02 PM, ikilpatr...@chromium.org wrote:
On Thursday, October 17, 2019 at 12:47:27 PM UTC-7, Mats Palmgren wrote:
On 10/17/19 8:12 PM, ikilpatr...@chromium.org wrote:
On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren
wrote:
As far as I know, we never constrain new
On 10/18/19 12:31 AM, ikilpatr...@chromium.org wrote:
I think one interesting part here is that (from my knowledge) this
policy actually hasn't been applied yet, due to the "other browsers
shipping insecurely" exception.
Do other vendors apply the same policy for new CSS features?
For example,
On 10/18/19 12:31 AM, ikilpatr...@chromium.org wrote:
Again "multiple dipslay values" are probably in the "trivial" feature
bucket (if that exists).
FYI, those weren't just syntax changes - we also added layout support
for 'inline list-item' and 'block ruby' for example, which I wouldn't
call t
On 10/18/19 12:31 AM, ikilpatr...@chromium.org wrote:
::marker (which seems like it was only shipped recently) probably should have
been restricted to secure contexts by this policy?
FWIW (regardless of my opinion about the policy which I've stated on
another post) Safari does ship ::marker s
On Fri, Oct 18, 2019, at 9:31 AM, ikilpatr...@chromium.org wrote:
> I'd argue that the color example is a "trivial" feature, unlike
> subgrid. But the original framer of the policy would have a better
> understanding of what that meant.
>
> FWIW most new CSS features are placed behind values/etc
19 matches
Mail list logo
