On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote:
> Do we have a heuristic for when to /not/ include something from HTML in SVG?
If it doesn't make two features which already exist in both HTML and SVG more
consistent, then I wouldn't include it.
> More or less, these additions to SVG just
Do we have a heuristic for when to /not/ include something from HTML in SVG?
More or less, these additions to SVG just strike me as having solid
potential risk (for both spec-interaction and implementation bugs) and
negligible upside. Do we have people asking for this?
Are there privacy concerns
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 t
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. SVG anchor elements s
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: https://bugzilla.mozilla.org/show_bug.cgi?id=
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 wrote:
> imo, you r
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 d
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 t
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
wrote:
> Sum
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
faile
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
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 this is a goo
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_.
_
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.
Th
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
experience with "thi
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
__
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 pr
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 a
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 precis
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
"subclasses
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 poss
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 Eve
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 supp
*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
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
https://w3c.g
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 createElement() tha
On 02.10.2017 18:03, 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 pairs?
>
> var div = document.createElement("div", null, {"id":"foo",
> "cla
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 nu
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 th
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, obv
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 (presumab
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 relie
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. Howev
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, b
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:
document.write(`http://exampl
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 pairs?
>
> This has de
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 pairs?
This has definitely been proposed before. Worth checking with Anne to
se
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 APIs that would make
them more usable? For example an object argument to createElement() that
con
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. Compar
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 s
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";>`);
>> div.innerHTML = `http:
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 badly-
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 = `http://example
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", "http://exam
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
run
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 to
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, that will work, assum
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 suc
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: https://bugzilla.mozilla.org/show_bug.cgi?id=1382027
>
> Sp
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:
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 progress on supporting th
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 righ
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:
> > An
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: https://bugzilla.mozilla.org/show_bug.cgi?id=13
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:
Al
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
https://lists.m
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
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 p
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?
>
>
>
> 在 2017/2/15 2
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 for web compat.
>
> I
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!
-appearance: none
-webkit
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 happen
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 implements the unprefixed
>
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
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 that
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 for web compat.
I don't think this is a realistic argument. Basically any change we
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
> benign effects in mo
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 population
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 act
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 unpref
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 b
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, 段垚 wrote:
I guess all popula
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?
>
> I was responding to your point a
在 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 of Flash. This is
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 not true.
>>
>
> Wh
在 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, b
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 elaborat
在 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
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 subdirect
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
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 doe
在 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 high
在 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 Flash for non-http(s) contents?
This
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 that's
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 diver
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)
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 c
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?
>>>
>>> This is completely disabling
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 have
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 load
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
在 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 behavior by flipping a pre
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
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 https://github.com/w3c/te
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 documen
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 change is to increase secu
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, yes
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 is not the plan, no
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
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 the
201 - 300 of 748 matches
Mail list logo