Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

On Tue, Apr 10, 2018, at 7:56 AM, Jeff Gilbert wrote: > Can we not put more things into SVG? Making SVG more complicated seems > like it should be an anti-goal for the web platform. I think we should align the features and behavior of HTML and SVG . something I don't see why the

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

Can we not put more things into SVG? Making SVG more complicated seems like it should be an anti-goal for the web platform. On Mon, Apr 9, 2018 at 2:11 PM, wrote: > Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, > hreflang, type and text properties.

Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, hreflang, type and text properties. SVG anchor elements should support these properties too according to the SVG 2 specification and https://github.com/w3c/svgwg/issues/315. Bug:

Re: Intent to implement and ship: Blocking FTP subresources

Good idea. Opened a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1452701 At least in the Chrome bug somebody was complaining that web cam page was broken by this change. Seems like the reloading image was embedded over FTP. On Mon, Apr 9, 2018 at 5:54 PM, Patrick McManus

Re: Intent to implement and ship: Blocking FTP subresources

imo, you really need to add a pref to cover this (I'm not saying make it opt-in, just preffable.). It will break something somewhere and at least you can tell that poor person they can have compat back via config. It also has a very small possibility of breaking enterprises or something we would

Intent to implement and ship: Blocking FTP subresources

Summary: All FTP subresources in HTTPs pages (this also includes blob: etc) will be blocked. Opening FTP links as toplevel documents is still possible. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1404744 Platform coverage: All Target release: Firefox 61 (this already landed, but we forgot

Re: Intent to implement and ship: spec compliance Promise microtask behavior

I just want to give a huge thank you to everyone who worked on this. Its such a monumental task to change such a core feature, especially with new tests that might depend on the old behavior being added all the time. Thank you! Ben On Wed, Feb 28, 2018 at 6:58 AM, Hiroyuki Ikezoe

Intent to implement and ship: spec compliance Promise microtask behavior

Summary: We are about to land bug 1193394 which will change microtask behavior that our microtask behavior complied with the HTML spec. We had fixed all test failures but still it's possible that new failures will appear before the change gets merged into mozilla-central.  If we found any

Re: Intent to implement and ship navigator.webdriver

Also sprach Andreas Tolfsen: > Summary: > I intend to implement and ship a new enumerable, configurable, > read-only "webdriver" attribute on the Navigator object. The > attribute is true when the -marionette flag is passed to Firefox > or the marionette.enabled preference is true. Otherwise it

Re: Intent to implement and ship navigator.webdriver

Also sprach Martin Thomson: > On Tue, Feb 6, 2018 at 3:37 AM, Andreas Tolfsen wrote: >> Motivation: >> To give web authors a way to infer if user agent is controlled by >> automation, so the document can take alternate code paths when under >> test. > > Can you speak more about why

Re: Intent to implement and ship navigator.webdriver

Also sprach Boris Zbarsky: > And in particular, the implementation patches don't match the intent > description (e.g. we implement a configurable property) Making it unforgeable is obviously a rather bad idea. I did mean that the attribute is _configurable_.

Re: Intent to implement and ship navigator.webdriver

Also sprach Boris Zbarsky: > On 2/5/18 11:37 AM, Andreas Tolfsen wrote: >> Standard: >> https://w3c.github.io/webdriver/webdriver-spec.html#interface > > All the IDL snippets in this standard are empty, which makes it > hard to evaluate the standard or how our implementation aligns with > it.

Re: Intent to implement and ship navigator.webdriver

On Tue, Feb 6, 2018 at 3:37 AM, Andreas Tolfsen wrote: > Motivation: > To give web authors a way to infer if user agent is controlled by > automation, so the document can take alternate code paths when under > test. Can you speak more about why this is a good idea? I've poor

Re: Intent to implement and ship navigator.webdriver

On 2/5/18 11:37 AM, Andreas Tolfsen wrote: Standard: https://w3c.github.io/webdriver/webdriver-spec.html#interface All the IDL snippets in this standard are empty, which makes it hard to evaluate the standard or how our implementation aligns with it. -Boris

Re: Intent to implement and ship navigator.webdriver

On 2/5/18 11:47 AM, Boris Zbarsky wrote: All the IDL snippets in this standard are empty, which makes it hard to evaluate the standard or how our implementation aligns with it. And in particular, the implementation patches don't match the intent description (e.g. we implement a configurable

Intent to implement and ship navigator.webdriver

Summary: I intend to implement and ship a new enumerable, non-configurable, read-only "webdriver" attribute on the Navigator object. The attribute is true when the -marionette flag is passed to Firefox or the marionette.enabled preference is true. Otherwise it is false. Motivation: To give web

Re: Intent to implement and ship: constructible EventTarget

On 11/20/17 12:26 PM, Gijs Kruitbosch wrote: I don't see the "events" view in the current debugger in 57/58/59 anymore, but perhaps I'm not looking in the right place. Oh, right, it's not implemented in the new debugger yet... I keep forgetting that I have the new debugger disabled for

Re: Intent to implement and ship: constructible EventTarget

On 20/11/2017 17:13, Boris Zbarsky wrote: On 11/20/17 6:28 AM, Gijs Kruitbosch wrote: Devtools' inspector lets you see which DOM nodes have event listeners attached to them. It would be neat if they could provide the same support in the debugger for instances of EventTarget (or any

Re: Intent to implement and ship: constructible EventTarget

On 11/20/17 6:28 AM, Gijs Kruitbosch wrote: Devtools' inspector lets you see which DOM nodes have event listeners attached to them. It would be neat if they could provide the same support in the debugger for instances of EventTarget (or any "subclasses"). Hmm. So there are at least three

Re: Intent to implement and ship: constructible EventTarget

On 19/11/2017 03:55, Boris Zbarsky wrote: Devtools bug: I don't think devtools need to do anything special here. Devtools' inspector lets you see which DOM nodes have event listeners attached to them. It would be neat if they could provide the same support in the debugger for instances of

Intent to implement and ship: constructible EventTarget

Summary: Make it possible for web pages to do |new EventTarget|, and more importantly to create EventTarget subclasses like |class MyThing extends EventTarget| that can then have DOM events dispatched on them in the normal way, have event listeners registered with all the features browsers

Intent to Implement and Ship: HTMLTextAreaElement.autocomplete

*Summary*: Allows web developers to get the effective/normalized value of the autocomplete attribute in the same way they currently can for and .​ Example: returns "on" for textarea.autocomplete. The return value will respect the pref dom.forms.autocomplete.formautofill, like we already do for

Intent to implement and ship PerformanceResourceTiming.workerStart

The PerformanceResourceTiming API has had a `workerStart` value specified for a couple years now. Its defined to represent the time when we trigger a service worker FetchEvent. It will be zero if service workers are not involved. https://bugzilla.mozilla.org/show_bug.cgi?id=1191943

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 02.10.2017 18:43, Anne van Kesteren wrote: > On Mon, Oct 2, 2017 at 6:09 PM, Boris Zbarsky wrote: >> On 10/2/17 12:03 PM, Daniel Veditz wrote: >>> Fair enough. Could we propose improvements to the APIs that would make >>> them more usable? For example an object argument to

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 02.10.2017 18:03, Daniel Veditz wrote: > ​Fair enough. Could we propose improvements to the API​s that would make > them more usable? For example an object argument to createElement() that > contained attribute/value pairs? > > var div = document.createElement("div", null, {"id":"foo", >

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Wed, Oct 04, 2017 at 12:42:22AM -0400, Boris Zbarsky wrote: On 10/2/17 9:50 PM, Kris Maglione wrote: For the pretty simple micro-benchmark below, here are the in-document and out-of-document numbers for three runs without the subject principal: Sorry, I should have been clearer: I meant

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 10/2/17 9:50 PM, Kris Maglione wrote: For the pretty simple micro-benchmark below, here are the in-document and out-of-document numbers for three runs without the subject principal: Sorry, I should have been clearer: I meant numbers for "inserted into the document" and "not inserted into

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 02, 2017 at 09:07:09PM -0400, Boris Zbarsky wrote: On 10/2/17 5:35 PM, Kris Maglione wrote: So far it doesn't look like there's any significant difference on any talos test from adding [NeedsCallerPrincipal] to setAttribute/setAttributeNS/Attr.value, OK. That's a minimum bar,

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 10/2/17 5:35 PM, Kris Maglione wrote: So far it doesn't look like there's any significant difference on any talos test from adding [NeedsCallerPrincipal] to setAttribute/setAttributeNS/Attr.value, OK. That's a minimum bar, obviously, but I would still like us to measure what the

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 02, 2017 at 11:39:21AM -0700, Kris Maglione wrote: On Mon, Oct 02, 2017 at 11:13:20AM -0400, Boris Zbarsky wrote: Passing along a JSContext would work. We could have something like "null means no scripted caller, otherwise caller's compartment is the part that matters". This

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Sun, Oct 01, 2017 at 12:54:26PM -0700, Luke Crouch wrote: On Friday, September 29, 2017 at 2:32:57 PM UTC-5, Kris Maglione wrote: Security & privacy concerns: This change will allow extensions to inject content into sites which can (and probably will) cause security and privacy issues.

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 02, 2017 at 11:13:20AM -0400, Boris Zbarsky wrote: Passing along a JSContext would work. We could have something like "null means no scripted caller, otherwise caller's compartment is the part that matters". This relies on no one on the setattr path messing with the compartment,

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 02, 2017 at 07:50:41AM -0700, Daniel Veditz wrote: On Fri, Sep 29, 2017 at 8:33 PM, Boris Zbarsky wrote: On 9/29/17 3:32 PM, Kris Maglione wrote: For instance, the following should all capture the caller principal for the `src` URL at call time:

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 2, 2017 at 6:09 PM, Boris Zbarsky wrote: > On 10/2/17 12:03 PM, Daniel Veditz wrote: >> Fair enough. Could we propose improvements to the APIs that would make >> them more usable? For example an object argument to createElement() that >> contained attribute/value

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 10/2/17 12:03 PM, Daniel Veditz wrote: ​Fair enough. Could we propose improvements to the API​s that would make them more usable? For example an object argument to createElement() that contained attribute/value pairs? This has definitely been proposed before. Worth checking with Anne to

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 2, 2017 at 8:17 AM, Boris Zbarsky wrote: > The fact is, direct DOM manipulation with no parser involved is really > annoying to use. > ​Fair enough. Could we propose improvements to the API​s that would make them more usable? For example an object argument to

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 10/2/17 10:50 AM, Daniel Veditz wrote: As long as direct DOM manipulation works, and is easier than overwriting (or removing) the page's CSP, can't we just encourage people to use that mechanism? The fact is, direct DOM manipulation with no parser involved is really annoying to use.

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 9/30/17 12:19 AM, Kris Maglione wrote: I still haven't settled on the details, but I it will probably have to involve capturing the caller principal from SetAttr hooks. Which would involve either changing that machinery to pass along a JS context when invoked by a scripted caller, or using

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Fri, Sep 29, 2017 at 8:33 PM, Boris Zbarsky wrote: > On 9/29/17 3:32 PM, Kris Maglione wrote: > >> For instance, the following should all capture the caller principal for >> the `src` URL at call time: >> >> document.write(`http://example.com/favicon.ico;>`); >>

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Friday, September 29, 2017 at 2:32:57 PM UTC-5, Kris Maglione wrote: > Security & privacy concerns: > > This change will allow extensions to inject content into sites which can > (and probably will) cause security and privacy issues. However, it's > already quite easy for malicious or

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Fri, Sep 29, 2017 at 11:33:08PM -0400, Boris Zbarsky wrote: On 9/29/17 3:32 PM, Kris Maglione wrote: For instance, the following should all capture the caller principal for the `src` URL at call time:    document.write(`http://example.com/favicon.ico;>`);    div.innerHTML =

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 9/29/17 3:32 PM, Kris Maglione wrote: For instance, the following should all capture the caller principal for the `src` URL at call time:    document.write(`http://example.com/favicon.ico;>`);    div.innerHTML = `http://example.com/favicon.ico;>`;    img.setAttribute("src",

Intent to implement and ship: CSP exemptions for content injected by privileged callers

Summary: All content injected into web content pages is currently subject to the same Content Security Policy, regardless of who injected it. For privileged callers, such as extension content scripts, this means that some functionality can behave erratically, depending on the page they're

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

On 7/18/17 11:56 PM, Tom Ritter wrote: Sorry I got the pref name wrong; it's svg.disabled from https://bugzilla.mozilla.org/show_bug.cgi?id=1216893 Ah. So as you note, this pref, when set, makes it so you can't even create an SVGImageElement instance. And then of course you can't pass one

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

On Tue, Jul 18, 2017 at 10:37 PM, Boris Zbarsky wrote: > On 7/18/17 11:21 PM, Tom Ritter wrote: >> >> This will respect the 'svg.in-content.enabled' pref, correct? > > > Respect in what sense? > > What this will do is that _if_ you have an and you drawImage it > to a canvas,

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

On 7/18/17 11:21 PM, Tom Ritter wrote: This will respect the 'svg.in-content.enabled' pref, correct? Respect in what sense? What this will do is that _if_ you have an and you drawImage it to a canvas, that will work, assuming the was loaded. I don't think the pref you mention prevents

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

This will respect the 'svg.in-content.enabled' pref, correct? Can I request that be added as a test? =) -tom On Tue, Jul 18, 2017 at 6:00 PM, Boris Zbarsky wrote: > Summary: allow passing to canvas createPattern and drawImage. > > Bug:

Intent to implement and ship: SVGImageElement as CanvasImageSource

Summary: allow passing to canvas createPattern and drawImage. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1382027 Spec: https://html.spec.whatwg.org/multipage/canvas.html#htmlorsvgimageelement and https://html.spec.whatwg.org/multipage/canvas.html#canvasimagesource Platform coverage:

Re: Intent to implement and ship: Web Authentication

Hi J.C.! Thanks for your extensive answer! Seems like there is a lot of progress going on that wasn't immediately obvious from bugzilla. I am looking forward to seeing this land. Thank you, Tom On Wed, Apr 12, 2017 at 2:46 AM, J.C. Jones wrote: > Tom, > > We're making

Re: Intent to implement and ship: Web Authentication

Tom, We're making progress on supporting the USB U2F HID token attestation format; before the actual U2F/HID code starts appearing in-tree, there's had to be some refactoring to handle things in a proper asynchronous way -- which is nearing review. I'm working on that USB U2F support for OSX

Re: Intent to implement and ship: Web Authentication

So what's our status with regards to implementing FIDO u2f? I really would like to use my security key natively in Firefox. Best, Tom On Sat, Dec 3, 2016 at 5:47 AM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On Friday, December 2, 2016 at 10:27:30 PM UTC+1, JC Jones wrote: > >

Re: Intent to implement and ship: support ::cue pseudo-element from document.

On Wednesday, March 29, 2017 at 11:21:06 PM UTC+13, bec...@mozilla.com wrote: > Summary: > We are going to support ::cue(with no argument) pseudo-element for webvtt. > It allows styling the webvtt subtitle/caption text during video playback. > > Bug:

Intent to implement and ship: support ::cue pseudo-element from document.

Summary: We are going to support ::cue(with no argument) pseudo-element for webvtt. It allows styling the webvtt subtitle/caption text during video playback. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1318542 Spec: https://w3c.github.io/webvtt/#the-cue-pseudo-element Platform coverage:

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 3/22/17 3:27 PM, Boris Zbarsky wrote: On 3/22/17 2:38 PM, Mats Palmgren wrote: Does that sound reasonable? Yes, thank you! Seconded. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 3/22/17 2:38 PM, Mats Palmgren wrote: Does that sound reasonable? Yes, thank you! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/17/2017 03:22 AM, Boris Zbarsky wrote: I thought about this a fair bit the last few days, and I think it would be a mistake to tie shipping appearance/-webkit-appearance to the removal of -moz-appearance. We should ship the no-prefix version and the -webkit version. Then we should get

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

At this point it seems unlikely that I will have time to fix this for Firefox 54, so most-likely it will be Firefox 55. --BDS On Tue, Feb 14, 2017 at 8:54 PM, 段垚 wrote: > Seems I failed to convince you to change the plan. > > So the last question is: when will this happen? >

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On Thu, Feb 16, 2017 at 2:57 PM, L. David Baron wrote: > On Thursday 2017-02-16 13:20 -0500, Benjamin Smedberg wrote: > > I'm surprised and disheartened that "land it and see what breaks" is > > considered an acceptable strategy for pretty much any commit, but > > especially

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

Mats, and others, Le 17 févr. 2017 à 17:38, Karl Dubost a écrit : > TLDR: removing -moz-appearance will break some sites. At least Japan airlines. Let me rephrase this in a way which is more interesting for the Web compatibility stand point of view. SHIP: OK!

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/16/17 8:22 PM, Boris Zbarsky wrote: I'm 99% sure there are pages (including some produced by Google and Facebook, last I checked) that do server-side sniffing and send only -moz-appearance to Firefox and only -webkit-appearance to Chrome and "appearance" to no one at all. Yeah, this

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

Sorry to not have chimed in before, but needed to do a bit of research in webcompat bugs. TLDR: removing -moz-appearance will break some sites. At least Japan airlines. Le 11 févr. 2017 à 07:27, Mats Palmgren a écrit : > Status in other implementations: No other UA

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/16/17 6:54 PM, Mats Palmgren wrote: I don't think removing -moz-appearance even has the potential of being "critical". All that happens is that you get native styling instead (at worst). There shouldn't be any loss of function. That depends. It's not hard to come up with examples where

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/16/2017 07:20 PM, Benjamin Smedberg wrote: It has happened repeatedly over the past two years that we discovered critical issues that affect websites only after we ship to release. I don't think removing -moz-appearance even has the potential of being "critical". All that happens is

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On Thu, Feb 16, 2017 at 7:23 AM, Mats Palmgren wrote: > On 02/11/2017 04:59 AM, Boris Zbarsky wrote: > >> The biggest worry for me is that inline style is never a "chrome sheet" >> in this sense. >> > > That's a valid concern, but I think ignoring -moz-appearance has fairly >

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

I'm surprised and disheartened that "land it and see what breaks" is considered an acceptable strategy for pretty much any commit, but especially for web compat. We *don't* see what breaks fast enough or before things hit the release population. We cannot currently rely on our prerelease

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/16/2017 04:27 PM, Boris Zbarsky wrote: On 2/16/17 10:23 AM, Mats Palmgren wrote: That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. Well, as in things just look wrong, is all, right? Right. But as I said, at least in some cases it

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/16/17 10:23 AM, Mats Palmgren wrote: That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. Well, as in things just look wrong, is all, right? And as Jet pointed out to me, just landing it and see what breaks is standard procedure for

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/11/2017 04:59 AM, Boris Zbarsky wrote: The biggest worry for me is that inline style is never a "chrome sheet" in this sense. That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. And as Jet pointed out to me, just landing it and see what

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

Seems I failed to convince you to change the plan. So the last question is: when will this happen? 在 2017/2/15 2:54, Till Schneidereit 写道: On Tue, Feb 14, 2017 at 12:00 PM, 段垚 wrote: 在 2017/2/14 18:10, Till Schneidereit 写道: On Tue, Feb 14, 2017 at 12:14 AM, 段垚

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tue, Feb 14, 2017 at 12:00 PM, 段垚 wrote: > > > 在 2017/2/14 18:10, Till Schneidereit 写道: > >> On Tue, Feb 14, 2017 at 12:14 AM, 段垚 wrote: >> >> I guess all popular softwares have exploits being traded. How this fact >>> invalidates my argument? >

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

在 2017/2/14 18:10, Till Schneidereit 写道: On Tue, Feb 14, 2017 at 12:14 AM, 段垚 wrote: I guess all popular softwares have exploits being traded. How this fact invalidates my argument? I was responding to your point about the threat declining because of the declining usage

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tue, Feb 14, 2017 at 12:14 AM, 段垚 wrote: > I guess all popular softwares have exploits being traded. How this fact >>> invalidates my argument? >>> >> I was responding to your point about the threat declining because of the >> declining usage of Flash. This is demonstrably

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

在 2017/2/14 2:03, Ehsan Akhgari 写道: On 2017-02-13 11:50 AM, 段垚 wrote: 在 2017/2/14 0:24, Ehsan Akhgari 写道: On 2017-02-10 7:51 PM, 段垚 wrote: 在 2017/2/11 2:26, t...@ritter.vg 写道: On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote: I thought I enumerated the harm at first,

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On 2017-02-13 11:50 AM, 段垚 wrote: > > > 在 2017/2/14 0:24, Ehsan Akhgari 写道: >> On 2017-02-10 7:51 PM, 段垚 wrote: >>> >>> 在 2017/2/11 2:26, t...@ritter.vg 写道: On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote: > I thought I enumerated the harm at first, but I'll

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

在 2017/2/14 0:24, Ehsan Akhgari 写道: On 2017-02-10 7:51 PM, 段垚 wrote: 在 2017/2/11 2:26, t...@ritter.vg 写道: On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote: I thought I enumerated the harm at first, but I'll elaborate a little. 1) Flash doesn't know about and breaks our

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On 2017-02-10 7:51 PM, 段垚 wrote: > > > 在 2017/2/11 2:26, t...@ritter.vg 写道: >> On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote: >>> I thought I enumerated the harm at first, but I'll elaborate a little. >>> >>> 1) Flash doesn't know about and breaks our "current and

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/10/17 8:03 PM, Mats Palmgren wrote: I'm guessing Firefox add-ons might not bother with anything but -moz-appearance though, but I assume those counts as chrome sheets, so the property will continue to work there as before. (Please correct me if I'm wrong about that.) "Chrome sheets", for

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/11/2017 12:28 AM, Justin Dolske wrote: Do we have any data on existing content usage of -moz-appearance? Or is this a "ship it and see what breaks" kind of thing? I'm not aware of any data that would be useful here. Data on how often -moz-appearance is used isn't very useful since it

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

在 2017/2/11 2:26, t...@ritter.vg 写道: On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote: I thought I enumerated the harm at first, but I'll elaborate a little. 1) Flash doesn't know about and breaks our "current and subdirectory only" file: origin policy. 2) Flash is a

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

在 2017/2/10 22:34, Benjamin Smedberg 写道: On Fri, Feb 10, 2017 at 12:36 AM, 段垚 wrote: 在 2017/2/10 1:28, Benjamin Smedberg 写道: On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote: Is this just preventing auto-loading (like "click to play") or completely disable

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

Do we have any data on existing content usage of -moz-appearance? Or is this a "ship it and see what breaks" kind of thing? I have the vague recollection that this is something that might have non-trivial usage (especially and specifically "-moz-appearance: none"), so just want to make sure

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

Makes sense Mats, exactly as you divided it up. Thanks for pushing this. Note: the 'appearance' property was previously in a CSS3 UI CR: * https://www.w3.org/TR/2004/CR-css3-ui-20040511/#appearance Where it was stable for nearly 8 years but dropped subsequently due to lack of interop (actual

Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

Summary: add support for the CSS UI property 'appearance:none | auto' with '-webkit-appearance' as an alias. Unship '-moz-appearance'. 'appearance:none' works exactly as '-moz-appearance:none' -- it turns off the native theme for elements that have one. 'appearance:auto' (the initial value)

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote: > I thought I enumerated the harm at first, but I'll elaborate a little. > > 1) Flash doesn't know about and breaks our "current and subdirectory only" > file: origin policy. > > 2) Flash is a high-risk attack surface: if you

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Fri, Feb 10, 2017 at 12:36 AM, 段垚 wrote: > > 在 2017/2/10 1:28, Benjamin Smedberg 写道: > >> On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote: >> >> Is this just preventing auto-loading (like "click to play") or completely >>> disable Flash for non-http(s) contents?

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

I thought I enumerated the harm at first, but I'll elaborate a little. 1) Flash doesn't know about and breaks our "current and subdirectory only" file: origin policy. 2) Flash is a high-risk attack surface: if you can get somebody to download a SWF they can probably own your system. We don't

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On 10.02.2017 01:09, Xidorn Quan wrote: > On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote: >> Will this also prevent loading downloaded .swf files into Firefox? This >> is >>> useful for running Flash games, which tend to work best in the browser >>> (some media players also support

Intent to implement and ship: animationcancel event

Summary: Adds a new event that fires when an animation is terminated without finishing normally (e.g. element is made display:none, animation-name property is updated etc.). This parallels the recently added transitioncancel event and allows authors to know that they should not keep waiting for an

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

在 2017/2/10 1:28, Benjamin Smedberg 写道: On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote: Is this just preventing auto-loading (like "click to play") or completely disable Flash for non-http(s) contents? This is completely disabling this content. Can users get back old

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote: > Will this also prevent loading downloaded .swf files into Firefox? This > is > > useful for running Flash games, which tend to work best in the browser > > (some media players also support loading Flash files, but their hotkeys > > tend

Re: Intent to implement and ship: self.origin

On 2/9/17 5:45 AM, Mike West wrote: I look forward to stealing your tests. :) Yep, sounds good. I put up patches in https://bugzilla.mozilla.org/show_bug.cgi?id=1306170 with the test bits; in fact most of the patches are changes to the tests. Note that you'll want

Re: Intent to implement and ship: document.origin

On 2/9/17 5:44 AM, Mike West wrote: Perhaps we could deprecate `document.origin` and ship `self.origin` in Blink instead of y'all shipping `document.origin`? It seems like we want to encourage folks to use `self.origin` going forward... So specifically, should I be asking Anne to remove

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tue, Feb 7, 2017 at 5:19 PM, Chris Peterson wrote: > On 2/7/2017 1:15 PM, Benjamin Smedberg wrote: > >> I intend to ship a change which will prevent Flash from loading from >> file:, >> ftp:, or any other URL scheme other than http: or https:. The purpose of >> this

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

Will this also prevent loading downloaded .swf files into Firefox? This is > useful for running Flash games, which tend to work best in the browser > (some media players also support loading Flash files, but their hotkeys > tend to conflict). It will prevent them from loading via File > Open,

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote: > Is this just preventing auto-loading (like "click to play") or completely > disable Flash for non-http(s) contents? > This is completely disabling this content. > > Can users get back old behavior by flipping a preference? > That

Re: Intent to implement and ship: document.origin

On 2/9/17 5:44 AM, Mike West wrote: Perhaps we could deprecate `document.origin` and ship `self.origin` in Blink instead of y'all shipping `document.origin`? Given the lack of support in Edge and the incompatible support in WebKit, I can probably live with that. Especially if y'all remove it

Intent to implement and ship: self.origin

Summary: self.origin returns the Unicode serialization of the origin of the settings object of the global represented by "self" (a Window or WorkerGlobalScope). This gives scripts a consistent way of getting their origin in both situations. Note that unlike location.origin this represents

Re: Intent to implement and ship: document.origin

I would like to revive this intent. At this point estimated release would be 54, and Blink has shipped this a while ago. The state of things here is as follows: 1) location.origin still exists and sites use it, so we can't remove it. But we can deprecate it if we want. 2)

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

Is this just preventing auto-loading (like "click to play") or completely disable Flash for non-http(s) contents? Can users get back old behavior by flipping a preference? We have developed a Firefox based tool to edit/view local EPub files, which may contain Flash. If this feature can't be

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tuesday, February 7, 2017 at 10:16:27 PM UTC+1, Benjamin Smedberg wrote: > I intend to ship a change which will prevent Flash from loading from file:, > ftp:, or any other URL scheme other than http: or https:. The purpose of > this change is to increase security and limit Flash to well-tested

<    1   2   3   4   5   6   7   >