Re: Intent to ship: CSS subgrid
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 since long time ago. -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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, Safari recently shipped a bunch of color scheme features: https://webkit.org/blog/8840/dark-mode-support-in-webkit/ Are those restricted to secure contexts? I'd argue that if other vendors don't apply the same policy then our policy is pointless since it comes down to chance whether another vendor shipped it for non-secure contexts first. And even if we did follow our own policy when we're first, if another vendor then ships it insecurely we'd have to enable it for non-secure contexts too for web-compat reasons. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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 CSS features to secure contexts. At least not on the property/value level. According to https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ you should be? "Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc." True, but we have never applied that policy for CSS features as far as I know. Just recently we've added 'column-span', the ::marker pseudo, new 'display' syntax with values like 'inline list-item', 'block ruby' etc, 'clip-path: path()', and a long list of other CSS features since 2018. 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 in other browsers insecurely before shipping in Firefox, hence the above exception applies. "subgrid" is different as Firefox is shipping this feature first. As far as I know we don't even have a mechanism that I could have used to restrict subgrid to secure contexts. And to be clear: I have no intention of blocking subgrid on waiting for such a mechanism. This should just involve passing a isSecureContext flag into the your CSS parser? Kinda. For this case that'd probably be enough, since you are not introducing a new property... The general case (handle different properties being exposed differently in different contexts) is quite a bit more work, since stuff like serialization of shorthands in a declaration block could change depending on whether you're in a secure context or not, for example. I'm not particularly convinced of the value of restricting subgrid to secure contexts (specially given no other CSS feature like that actually is, and that it makes the feature harder to use by stuff like frameworks or what not). But if people like Anne or Boris think it's valuable I'm ok making this change. As people have pointed out, the policy is a bit ambiguous as this could be seen as extending an existing feature or a new feature. AFAICT, modulo paint() in Chrome, which has an associated [SecureContext] JS API, nobody has shipped such a restriction for any new CSS feature whatsoever. For new features we've implemented: * @supports selector(): https://groups.google.com/d/msg/mozilla.dev.platform/JNLPcIZRd2w/r6Boq0h2BQAJ (I included my rationale for not doing this) * The syntax changes to the display property: https://groups.google.com/d/msg/mozilla.dev.platform/0WFI1WvBbic/2yVDD9_UCwAJ * clip-path: path(): https://groups.google.com/d/msg/mozilla.dev.platform/RM5O36MZ4x4/FV5Tp9y4EQAJ * Various text-decoration bits: https://groups.google.com/d/msg/mozilla.dev.platform/Xsts-2ORpRY/j96vHsIRAAAJ I guess the last two were implemented by safari at that point so we have that escape hatch. Chromium hasn't been doing any better either, which I guess it's not necessarily an excuse... From a quick test, CSS.registerProperty and all of Typed OM is available in non-secure contexts. If people decide that following that post to the letter for the specific case of subgrid is worth it I'm happy to do that, but in general (and based on the above data) I think the post you linked too aggressive, and having a hard mode switch between secure / non-secure contexts, specially for "regular" CSS features that don't have associated Javascript APIs, doesn't sound particularly appealing to me. And finally, thanks for starting this discussion Ian, I think it's worth clarifying the situation here. -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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 the feature insecurely" > > > > Most (all?) of the non-trivial features above have shipped in other > > browsers insecurely before shipping in Firefox, hence the above exception > > applies. > > > > But it also says: "In contrast, a new CSS color keyword would likely not be > restricted to secure contexts." Given that this is a new value for > grid-template-*, and not a new CSS property, I'd argue it doesn't apply. 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, so I don't believe that is the distinction in the policy. > > > "subgrid" is different as Firefox is shipping this feature first. > > > > I believe we were also first to ship the support for multiple display > values, but again those are values. And I think we're the first on > ::marker. These were not restricted. Again "multiple dipslay values" are probably in the "trivial" feature bucket (if that exists). ::marker (which seems like it was only shipped recently) probably should have been restricted to secure contexts by this policy? > > > > As far as I know we don't even have a mechanism that I could > > > have used to restrict subgrid to secure contexts. And to be > > > clear: I have no intention of blocking subgrid on waiting for > > > such a mechanism. > > > > This should just involve passing a isSecureContext flag into the your CSS > > parser? > > > > There's also the consideration as to whether allowing grid in non-secure > contexts, but NOT subgrid, even makes sense. I think it would oddly > fracture support for grid layouts as a whole (or at least potentially make > things confusing for developers — it's certainly more confusing than just > restricting access to a single property like backdrop-filter or something). > Perhaps we should ask what the value of restricting only subgrid to secure > contexts even brings. If part of the spirit of the policy (at least the > part that applies here) is to quicken adoption of secure contexts, is the > value of subgrid's contribution to this endeavor worth the trade-off of > potential user confusion? For almost any CSS feature you could make a similar argument I believe. 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. But all good questions! > > > Given this shouldn't a "...Mozilla’s Distinguished Engineers to judge the > > outcome..."? > > > > It's an interesting test of the policy. Thanks for bringing it up :) No problem! I trust the Mozilla community will decide on a reasonable outcome, and update the policy if necessary. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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 in other > browsers insecurely before shipping in Firefox, hence the above exception > applies. > But it also says: "In contrast, a new CSS color keyword would likely not be restricted to secure contexts." Given that this is a new value for grid-template-*, and not a new CSS property, I'd argue it doesn't apply. > "subgrid" is different as Firefox is shipping this feature first. > I believe we were also first to ship the support for multiple display values, but again those are values. And I think we're the first on ::marker. These were not restricted. > > As far as I know we don't even have a mechanism that I could > > have used to restrict subgrid to secure contexts. And to be > > clear: I have no intention of blocking subgrid on waiting for > > such a mechanism. > > This should just involve passing a isSecureContext flag into the your CSS > parser? > There's also the consideration as to whether allowing grid in non-secure contexts, but NOT subgrid, even makes sense. I think it would oddly fracture support for grid layouts as a whole (or at least potentially make things confusing for developers — it's certainly more confusing than just restricting access to a single property like backdrop-filter or something). Perhaps we should ask what the value of restricting only subgrid to secure contexts even brings. If part of the spirit of the policy (at least the part that applies here) is to quicken adoption of secure contexts, is the value of subgrid's contribution to this endeavor worth the trade-off of potential user confusion? > Given this shouldn't a "...Mozilla’s Distinguished Engineers to judge the > outcome..."? > It's an interesting test of the policy. Thanks for bringing it up :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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 least not on the property/value level. > > > > According to > > https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ > > you should be? > > > > "Effective immediately, all new features that are web-exposed are to be > > restricted to secure contexts. Web-exposed means that the feature is > > observable from a web page or server, whether through JavaScript, CSS, > > HTTP, media formats, etc." > > True, but we have never applied that policy for CSS features > as far as I know. Just recently we've added 'column-span', > the ::marker pseudo, new 'display' syntax with values like > 'inline list-item', 'block ruby' etc, 'clip-path: path()', > and a long list of other CSS features since 2018. 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 in other browsers insecurely before shipping in Firefox, hence the above exception applies. "subgrid" is different as Firefox is shipping this feature first. > As far as I know we don't even have a mechanism that I could > have used to restrict subgrid to secure contexts. And to be > clear: I have no intention of blocking subgrid on waiting for > such a mechanism. This should just involve passing a isSecureContext flag into the your CSS parser? > > > Or does the policy wrong and needs to be updated? > > Maybe, but that's not for me to decide. > > The issue you raise is a good one, but it's not really related > to subgrid specifically. Perhaps it would be better if you > start a new thread regarding how that policy applies (or not) > to CSS features in general? See above - I believe it actually is only related to this feature, as it is shipping in Firefox first. Given this shouldn't a "...Mozilla’s Distinguished Engineers to judge the outcome..."? > > /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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/01/15/secure-contexts-everywhere/ you should be? "Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc." True, but we have never applied that policy for CSS features as far as I know. Just recently we've added 'column-span', the ::marker pseudo, new 'display' syntax with values like 'inline list-item', 'block ruby' etc, 'clip-path: path()', and a long list of other CSS features since 2018. As far as I know we don't even have a mechanism that I could have used to restrict subgrid to secure contexts. And to be clear: I have no intention of blocking subgrid on waiting for such a mechanism. Or does the policy wrong and needs to be updated? Maybe, but that's not for me to decide. The issue you raise is a good one, but it's not really related to subgrid specifically. Perhaps it would be better if you start a new thread regarding how that policy applies (or not) to CSS features in general? /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Taskcluster log fetching
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. > While it requires a level of polish that not everyone has time for, I'd encourage developers who have scripts like these to think about how they might be integrated into `mach`. Either as a top-level command, a subcommand, or even just behind a flag on an existing command. If you think you have something that would be useful to a wider audience, I'm happy to provide feedback on where / how it can be integrated. Even if you don't have time, getting a bug on file (with a link to your repo) would be helpful. Moving it into mach might even make a good contributor project. For instance, in this case a more general purpose `mach taskgraph fetch-artifacts` command could be useful. There are already helper functions to download artifacts in-tree, so no scraping required. -Andrew > -tom > > PS: Other gists I have: > https://gist.github.com/tomrittervg/90329fea97486bfc9e4e8a4c8d51cc06 - > parse the output of MOZ_LOG="nsStandardURL:5" > https://gist.github.com/tomrittervg/adb8688426a9a5340da96004e2c8af79 - for > MMLog:5 > https://gist.github.com/tomrittervg/3cc0f08995a7cb71a2c66317204c0340 - for > searching through my old try pushes looking for something specific > https://gist.github.com/tomrittervg/ea852876f657ff7ca8684b2415be694f - for > printing a stack with MOZ_LOG > All of these are ugly half-developed one-offs but may be illustrative. > > -tom > > On Thu, Oct 17, 2019 at 4:43 PM Steve Fink wrote: > > > 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 best > > representing "typical" browser usage. That injects my printouts into a > > whole mess of log files, which I can then go clickety click click for > > half an hour to download individually. (In practice, I'm lazy, so I > > download 3-4 and start working on processing them, then never get around > > to grabbing the ones from the other jobs. Thus wasting 90% of the > > resources burned by the push.) > > > > So now I have a `get-taskcluster-logs` script that will pull them all > > down into a directory in one go: > > > > get-taskcluster-logs -r > > > > or > > > > get-taskcluster-logs '' > > > > Much nicer. It is now much, much faster to get to the point where I kick > > myself for not injecting the pid or some other identifier in my log > > messages, because I notice that all of the different processes' outputs > > are smushed together. But that's another story. > > > > For details, see > > https://github.com/hotsphink/sfink-tools/blob/master/README.md or just > > grab the script directly from > > > > > https://raw.githubusercontent.com/hotsphink/sfink-tools/master/bin/get-taskcluster-logs > > > > Or checkout the whole repo at > > > > (hg) https://hg.sr.ht/~sfink/sfink-tools > > > > (git) https://github.com/hotsphink/sfink-tools/ > > > > > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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/ecbos_/status/1184690249324290048 > > Well, I just copy-pasted the email-template TYLin used in his > intent-to-ship for 'column-span' earlier, so I assumed "N/A" is > the correct term... :-) > > Anyway, I don't think we constrain new CSS properties/values to secure > contexts in general. As far as I know, we don't even have a mechanism > for doing so. So "N/A" seems appropriate. > > > > Subgrid is a new feature to CSS behind a new display value [...] > > No, 'subgrid' is not a new 'display' value. It's a new value for > the 'grid-template-rows/columns' properties: > https://drafts.csswg.org/css-grid-2/#subgrid-per-axis My bad, but the same principle applies. > > > Does > > https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ > > apply here? > > 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/01/15/secure-contexts-everywhere/ you should be? "Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. " Or does the policy wrong and needs to be updated? > > /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
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 his intent-to-ship for 'column-span' earlier, so I assumed "N/A" is the correct term... :-) Anyway, I don't think we constrain new CSS properties/values to secure contexts in general. As far as I know, we don't even have a mechanism for doing so. So "N/A" seems appropriate. Subgrid is a new feature to CSS behind a new display value [...] No, 'subgrid' is not a new 'display' value. It's a new value for the 'grid-template-rows/columns' properties: https://drafts.csswg.org/css-grid-2/#subgrid-per-axis Does https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ apply here? As far as I know, we never constrain new CSS features to secure contexts. At least not on the property/value level. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Taskcluster log fetching
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/tomrittervg/90329fea97486bfc9e4e8a4c8d51cc06 - parse the output of MOZ_LOG="nsStandardURL:5" https://gist.github.com/tomrittervg/adb8688426a9a5340da96004e2c8af79 - for MMLog:5 https://gist.github.com/tomrittervg/3cc0f08995a7cb71a2c66317204c0340 - for searching through my old try pushes looking for something specific https://gist.github.com/tomrittervg/ea852876f657ff7ca8684b2415be694f - for printing a stack with MOZ_LOG All of these are ugly half-developed one-offs but may be illustrative. -tom On Thu, Oct 17, 2019 at 4:43 PM Steve Fink wrote: > 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 best > representing "typical" browser usage. That injects my printouts into a > whole mess of log files, which I can then go clickety click click for > half an hour to download individually. (In practice, I'm lazy, so I > download 3-4 and start working on processing them, then never get around > to grabbing the ones from the other jobs. Thus wasting 90% of the > resources burned by the push.) > > So now I have a `get-taskcluster-logs` script that will pull them all > down into a directory in one go: > > get-taskcluster-logs -r > > or > > get-taskcluster-logs '' > > Much nicer. It is now much, much faster to get to the point where I kick > myself for not injecting the pid or some other identifier in my log > messages, because I notice that all of the different processes' outputs > are smushed together. But that's another story. > > For details, see > https://github.com/hotsphink/sfink-tools/blob/master/README.md or just > grab the script directly from > > https://raw.githubusercontent.com/hotsphink/sfink-tools/master/bin/get-taskcluster-logs > > Or checkout the whole repo at > > (hg) https://hg.sr.ht/~sfink/sfink-tools > > (git) https://github.com/hotsphink/sfink-tools/ > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Taskcluster log fetching
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 best representing "typical" browser usage. That injects my printouts into a whole mess of log files, which I can then go clickety click click for half an hour to download individually. (In practice, I'm lazy, so I download 3-4 and start working on processing them, then never get around to grabbing the ones from the other jobs. Thus wasting 90% of the resources burned by the push.) So now I have a `get-taskcluster-logs` script that will pull them all down into a directory in one go: get-taskcluster-logs -r or get-taskcluster-logs '' Much nicer. It is now much, much faster to get to the point where I kick myself for not injecting the pid or some other identifier in my log messages, because I notice that all of the different processes' outputs are smushed together. But that's another story. For details, see https://github.com/hotsphink/sfink-tools/blob/master/README.md or just grab the script directly from https://raw.githubusercontent.com/hotsphink/sfink-tools/master/bin/get-taskcluster-logs Or checkout the whole repo at (hg) https://hg.sr.ht/~sfink/sfink-tools (git) https://github.com/hotsphink/sfink-tools/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to prototype: Web Speech API
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 the other, which I think is not unimaginable here. Hence my recommendation to avoid using the same permission name right now and using a separate UI as soon as that can be prioritized. On Wed, Oct 16, 2019, 19:43 Daniel Veditz wrote: > On Wed, Oct 16, 2019 at 4:40 AM Johann Hofmann > wrote: > >> as far as I can see the presented origin does not in fact get access to >> the user's microphone > > > The site doesn't get raw audio, but does get text representing what the > browser thinks it heard. It's the same kind of privacy risk as raw audio > for most people (though less opportunity for creative abuses like trying to > track what TV show you're watching). > > -Dan Veditz > > > > >> and it's a bit >> unclear what "Remember this decision" actually does. It makes no sense to >> set the "microphone" permission on that site, in the same way that it >> makes >> no sense to derive from a permanent "microphone" permission for some site >> that the user intends to submit their voice data to a third party. I feel >> like this feature needs to store a separate permanent permission. >> >> A perfect permissions UX may not be achievable or intended for an MVP of >> this feature, so I would recommend at least hiding the checkbox (to avoid >> setting the "microphone" permission) and prompting every time until a >> better solution can be found. >> >> Let me know if you need any help with that :) >> >> Johann >> >> On Tue, Oct 15, 2019 at 12:27 PM Henri Sivonen >> wrote: >> >> > On Tue, Oct 15, 2019 at 2:56 AM Andre Natal wrote: >> > > Regarding the UI, yes, the experience will be exactly the same in our >> > case: the user will get a prompt asking for permission to open the >> > microphone (I've attached a screenshot below [3]) >> > ... >> > > [3] >> > >> https://www.dropbox.com/s/fkyymiyryjjbix5/Screenshot%202019-10-14%2016.13.49.png?dl=0 >> > >> > Since the UI is the same as for getUserMedia(), is the permission bit >> > that gets stored the same as for getUserMedia()? I.e. if a site >> > obtains the permission for one, can it also use the other without >> > another prompt? >> > >> > If a user understands how WebRTC works and what this piece of UI meant >> > for WebRTC, this UI now represents a different trust decision on the >> > level of principle. How intentional or incidental is it that this >> > looks like a getUserMedia() use (audio goes to where the site named in >> > the dialog decides to route it) instead of surfacing to the user that >> > this is different (audio goes to where the browser vendor decides to >> > route it)? >> > >> > -- >> > Henri Sivonen >> > hsivo...@mozilla.com >> > ___ >> > dev-platform mailing list >> > dev-platform@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-platform >> > >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: @media (-moz-touch-enabled)
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 assume that touch events are enabled on a given device, which confuses websites like the one in the bug. There's no reason these days to use it, and even our frontend doesn't even use it anymore, so I'm going to try to disable it for Nightly / Early beta for now, and assuming there's no compat fallout I'll disable it everywhere eventually (I'll send a follow-up email to this list when that happens). Let me know if there's any concerns with doing this. Thanks, -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
