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

[Cameron McCormack]

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 strike me as having solid
> potential risk (for both spec-interaction and implementation bugs) and
> negligible upside. Do we have people asking for this?

I don't know of people asking for this, but I would hope that we could share 
the implementations of these properties between HTMLAnchorElement and 
SVGAElement.  The closer the two  elements are in behavior, and the more we 
can share implementation between them, the lower the risk for bugs between the 
two.  (Ignoring the general risk of bugs from touching code at all.)

> Are there privacy concerns from embedding pings (et al) in images? I
> suppose we better have been handling CORS requests from within SVGs
> properly already, so it should Just Work?

SVG as images don't have scripting and can't be interacted with to activate 
links, so I don't think it's a concern there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jeff Gilbert]

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 from embedding pings (et al) in images? I
suppose we better have been handling CORS requests from within SVGs
properly already, so it should Just Work?

On Mon, Apr 9, 2018 at 6:26 PM, Cameron McCormack  wrote:
> 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 two DOM objects for the HTML  and SVG  should 
> behave substantially differently.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Cameron McCormack]

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 two DOM objects for the HTML  and SVG  should behave 
substantially differently.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jeff Gilbert]

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 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=1451823
>
> Platform coverage: All
> Target release: Firefox 61
> Preference behind which this will be implemented: None
> Is this feature enabled by default in sandboxed iframes: Yes, enabled 
> everywhere
> DevTools bug: None
> Do other browser engines implement this? Microsoft are working on an 
> implementation for Edge. They have created web platform tests for this.
> web-platform-tests: https://github.com/w3c/web-platform-tests/pull/10275
> Secure contexts: n/a
> ___
> 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 implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[longsonr]

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=1451823

Platform coverage: All
Target release: Firefox 61
Preference behind which this will be implemented: None
Is this feature enabled by default in sandboxed iframes: Yes, enabled everywhere
DevTools bug: None
Do other browser engines implement this? Microsoft are working on an 
implementation for Edge. They have created web platform tests for this.
web-platform-tests: https://github.com/w3c/web-platform-tests/pull/10275
Secure contexts: n/a 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Blocking FTP subresources

[Tom Schuster]

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 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 discover late, and we would want to be able to push a pref to fix
> that.
>
>
> On Mon, Apr 9, 2018 at 9:13 AM, Tom Schuster  wrote:
>>
>> 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 to send
>> this, sorry!)
>> Preference behind which this will be implemented: None
>> Is this feature enabled by default in sandboxed iframes: Yes, enabled
>> everywhere
>> DevTools bug: None
>> Do other browser engines implement this?
>> Chrome shipped in M62?
>> web-platform-tests: No
>> Secure contexts: n/a
>> ___
>> 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 implement and ship: Blocking FTP subresources

[Patrick McManus]

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 discover late, and we would want to be able to push a pref to fix
that.


On Mon, Apr 9, 2018 at 9:13 AM, Tom Schuster  wrote:

> 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 to send
> this, sorry!)
> Preference behind which this will be implemented: None
> Is this feature enabled by default in sandboxed iframes: Yes, enabled
> everywhere
> DevTools bug: None
> Do other browser engines implement this?
> Chrome shipped in M62?
> web-platform-tests: No
> Secure contexts: n/a
> ___
> 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 implement and ship: Blocking FTP subresources

[Tom Schuster]

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 to send
this, sorry!)
Preference behind which this will be implemented: None
Is this feature enabled by default in sandboxed iframes: Yes, enabled everywhere
DevTools bug: None
Do other browser engines implement this?
Chrome shipped in M62?
web-platform-tests: No
Secure contexts: n/a
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ben Kelly]

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:

> 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
> failed tests we will disable it temporarily and file a bug to enable it
> respectively.  If new test you have locally started failing after this
> change,
> the document that Bevis wrote [1] would be helpful to make the test pass
> with
> the new behavior.  Bevis' original message [2] has some background of
> this, so
> it would be also helpful to understand this change.
>
> Big thanks to Olli who started the initial work and Bevis who took over
> his work
> and :arai who had been fixing tests that failed by the microtask change in
> various
> areas.  And big thanks to everyone involved!
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1193394
> Standard: https://html.spec.whatwg.org/multipage/webappapis.html#enque
> uejob(queuename,-job,-arguments)
> Platform coverage: All
> Target release: Firefox 60
> Preference: None. We tried to add a pref but didn't add since it will make
>  things more complicated and hard to maintain.
>  See https://bugzilla.mozilla.org/show_bug.cgi?id=1420816#c9 for the
> detail.
> DevTools bug: None
> web-platform-tests: There are test cases that this change makes the tests
> pass.
> Do other browser engines implement this?: Chrome and Safari as per the
> result of
>  a wpt [3].
>
> [1] https://docs.google.com/presentation/d/1momsC3suU8m-CrdZyYD_
> 6QATATehjzZHbkGmL6KsmSk/edit#slide=id.g28ecd2197a_0_269
> [2] https://groups.google.com/forum/#!msg/mozilla.dev.platform/
> naB6gaevSSo/w-29kbpUBQAJ
> [3] https://wpt.fyi/html/webappapis/scripting/event-loops/task_
> microtask_ordering.html
>
> ___
> 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 implement and ship: spec compliance Promise microtask behavior

[Hiroyuki Ikezoe]

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
failed tests we will disable it temporarily and file a bug to enable it
respectively.  If new test you have locally started failing after this 
change,
the document that Bevis wrote [1] would be helpful to make the test pass 
with
the new behavior.  Bevis' original message [2] has some background of 
this, so

it would be also helpful to understand this change.

Big thanks to Olli who started the initial work and Bevis who took over 
his work
and :arai who had been fixing tests that failed by the microtask change 
in various

areas.  And big thanks to everyone involved!

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1193394
Standard: 
https://html.spec.whatwg.org/multipage/webappapis.html#enqueuejob(queuename,-job,-arguments)

Platform coverage: All
Target release: Firefox 60
Preference: None. We tried to add a pref but didn't add since it will make
 things more complicated and hard to maintain.
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1420816#c9 for the 
detail.

DevTools bug: None
web-platform-tests: There are test cases that this change makes the 
tests pass.
Do other browser engines implement this?: Chrome and Safari as per the 
result of

 a wpt [3].

[1] 
https://docs.google.com/presentation/d/1momsC3suU8m-CrdZyYD_6QATATehjzZHbkGmL6KsmSk/edit#slide=id.g28ecd2197a_0_269
[2] 
https://groups.google.com/forum/#!msg/mozilla.dev.platform/naB6gaevSSo/w-29kbpUBQAJ
[3] 
https://wpt.fyi/html/webappapis/scripting/event-loops/task_microtask_ordering.html


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[Andreas Tolfsen]

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 is
> false.

We decided to also throw in a preference dom.webdriver.enabled that
controls the exposure of the navigator.webdriver attribute.  When
flipped to false it will remove the attribute.

I intend to land the patches on https://bugzil.la/1169290 soon.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[Andreas Tolfsen]

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 good idea?  I've poor
> experience with "this code is now under test" in the past.  You
> create the risk that code becomes split into two: code that works
> as tested, and code that doesn't work because it isn't tested.
> 
> (Not an objection, there's definitely value in consistency between
> implementations.)

As far as I’m aware the interface was added to the spec at the
explicit request of web authors.

I share your concern of code that gets written for “test only”
environments and that later fails to work in reality.  Another
aspect is that it is also important for test environments to induce
reproducibility.

One part to mitigating instability in tests is to eliminate sources
of indeterministic variance.  For example it might be reasonable
to want to replace Math.random with a PRNG with a fixed seed during
testing.

The most important characteristic of navigator.webdriver is that
it provides consistency.  With navigator.webdriver there’s _one
way_ to indicate to a document that it is under test, and you no
longer need an in-house standard on how to do that.

Sufficiently advanced test environments typically have the ability
to serve entirely custom versions of web apps, but as more application
code lives in the browser (in JS), it becomes vital to have a good
standard for testing also in the web platform layer.

Without exposing this attribute on the navigator object, it becomes
hard to make decisions about code that executes before the document
finishes loading.  By the point WebDriver returns control to the
user after loading a document, it may be too late to invoke
executeScript("window.isTest = true").

Whatever the web author uses navigator.webdriver for, if their test
strategy to begin with is not sound, then there is little we can
do to protect them from using the attribute as a foot-gun.  They
might want to test that their site still works in production before
publishing.

In the Blink intent-to-ship thread [1] they cite anti-abuse use
cases for navigator.webdriver, where a foreign website you don’t
own could use it to block unsolicited bots/crawlers.  As I also
mention in the commit message [2], this is not what the attribute
is designed for.

For better or worse (though probably the better!) the source code
of all the major browser engines are available for anyone to
scrutinise, and given the ability to compile custom browsers it is
not really a technically sound argument to make that navigator.webdriver
can realistically be used as an anti-abuse measure.

  [1] 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/6GysDZCWwB8/rXbGoRohBgAJ
  [2] https://reviewboard.mozilla.org/r/216250/diff/4#index_header

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[Andreas Tolfsen]

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_.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[Andreas Tolfsen]

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.

Through a series of unfortunate events, it appears a new version
of ReSpec was released in close proximity to my intent-to-ship
email.  That broke parsing of the WebIDL interface, but I didn’t
notice because I had it cached in my local browsing session.

In any case the interface is now back in the spec, but I will quote
it here for posterity:

> Navigator includes NavigatorAutomationInformation;
> 
> interface mixin NavigatorAutomationInformation {
>   readonly attribute boolean webdriver;
> };

Sorry about that.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[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 good idea?  I've poor
experience with "this code is now under test" in the past.  You create
the risk that code becomes split into two: code that works as tested,
and code that doesn't work because it isn't tested.

(Not an objection, there's definitely value in consistency between
implementations.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[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.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship navigator.webdriver

[Boris Zbarsky]

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 property)


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship navigator.webdriver

[Andreas Tolfsen]

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 authors a way to infer if user agent is controlled by
automation, so the document can take alternate code paths when under
test.

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1169290

Standard:
https://w3c.github.io/webdriver/webdriver-spec.html#interface

Estimated target release:
60

Testing:
Covered by WPT.

Do other engines have this?
Blink [1], Edge, and WebKit [2] have this.  Blink only exposes the
attribute during automation, but we expect them to unconditionally
expose it given a recent specification change [3].

  [1] 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/6GysDZCWwB8/rXbGoRohBgAJ
  [2] 
https://git.webkit.org/?p=WebKit.git;a=commit;h=ce5ef8d5e72fb49cf2a0b72e2a5a8fb551c57f5a
  [3] 
https://github.com/w3c/webdriver/commit/a224627dcea6448367523bf0420de3d547946300

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: constructible EventTarget

[Boris Zbarsky]

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 precisely that 
reason.  :(


I can't find any existing open issues on this, though I was sure there 
were some.  Ah, well, filed 
https://github.com/devtools-html/debugger.html/issues/4750


I was thinking more of these, ie the watch expressions and/or variables 
(locals/scopes) view and the console.


Filed https://github.com/devtools-html/debugger.html/issues/4751 for the 
former and https://bugzilla.mozilla.org/show_bug.cgi?id=1419089 for the 
latter.


This would be useful even without these "custom" EventTargets, because 
it could be used for XHR objects and whatnot...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: constructible EventTarget

[Gijs Kruitbosch]

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").


Hmm.  So there are at least three possible things you might be asking 
for here:


1)  In the existing debugger "events" view, include EventTargets other 
than windows and nodes.


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. If it still 
exists, yes, that would be nice.


2)  When examining an object that happens to be an EventTarget in the 
console, provide some UI to see its event listeners (similar to the "ev" 
marker on nodes in the inspector).


3)  When examining an object that happens to be an EventTarget in the 
debugger (e.g. in the watch expression window?  Where else?) provide 
some UI to see its event listeners.


Was it one of those?  Or something else?


I was thinking more of these, ie the watch expressions and/or variables 
(locals/scopes) view and the console.


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: constructible EventTarget

[Boris Zbarsky]

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 possible things you might be asking 
for here:


1)  In the existing debugger "events" view, include EventTargets other 
than windows and nodes.


2)  When examining an object that happens to be an EventTarget in the 
console, provide some UI to see its event listeners (similar to the "ev" 
marker on nodes in the inspector).


3)  When examining an object that happens to be an EventTarget in the 
debugger (e.g. in the watch expression window?  Where else?) provide 
some UI to see its event listeners.


Was it one of those?  Or something else?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: constructible EventTarget

[Gijs Kruitbosch]

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 EventTarget (or any "subclasses").


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: constructible EventTarget

[Boris Zbarsky]

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 support (e.g. { once: true }), etc.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1379688

Spec: https://dom.spec.whatwg.org/#dom-eventtarget-eventtarget

Target release: 59

Preference behind which this is implemented: None.

Enabled in sandboxed iframes: Yes.

Devtools bug: I don't think devtools need to do anything special here.

Support in other browsers:

  * Chrome: intent to ship thread is at 
 
and the code landed (see 
).

  * Safari: no signals.
  * Edge: no signals.

Tests: We have web platform tests for this.

Spec stability: Pretty stable.  This is a very simple feature with a 
simple spec, since it's just exposing an underlying well-specced and 
well-tested primitive.


Security/privacy concerns: None that I know of.

Use cases: See summary.

Example use: 
https://github.com/w3c/web-platform-tests/blob/b0efb74111af13f7abf3b3b1860667f98746b07f/dom/events/EventTarget-constructible.any.js#L27-L61


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: HTMLTextAreaElement.autocomplete

[Matthew N.]

*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  and  meaning it will only return
"on"/"off" if Form Autofill isn't available to support the other values.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1020698
*Link to standard*:
https://html.spec.whatwg.org/#the-textarea-element:attr-fe-autocomplete
*Platform coverage*: All but iOS
*Estimated or target release*: Firefox 59
*Preference behind which this will be implemented*: None (it's simply
exposing shared logic for  and  on 
*Is this feature enabled by default in sandboxed iframes*
​:​
Yes
*DevTools bug*: N/A since it's just a
​fairly basic DOM property. In theory devtools could use the internal
getAutocompleteInfo API to show the browsers' interpretation of the parsed
attribute.
*Do other browser engines implement this*
​:​
According to https://wpt.fyi/html/dom/interfaces.html's
"HTMLTextAreaElement interface: attribute autocomplete" row:
* Safari: Shipped 
​ in unknown version 
* Chrome: N
​ot yet

​​
​ , but​
​i​
nten
​ding​
to
​i​
mplement and
​s​
hip

* Edge: No
*Tests -*
*​*
* Is this feature fully tested by web-platform-tests*
​:​
​ https://wpt.fyi/html/dom/interfaces.html has basic interface tests and ​
https://wpt.fyi/html/semantics/forms/the-form-element/form-autocomplete.html
tests the common parsing logic (not specific to )

​Thanks,
Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship PerformanceResourceTiming.workerStart

[Ben Kelly]

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.github.io/resource-timing/#dom-performanceresourcetiming-workerstart

This will be available on all platforms.

I'm targeting it for release in FF58.

It is not behind a pref.  The property will always be there.  If SW are
disabled then the value will always be zero.

We have some work going on to try to display service worker timing
information in devtools:

https://bugzilla.mozilla.org/show_bug.cgi?id=1353798

Chrome has implemented workerStart for a while and there is a WPT test.

There are some spec/compat questions to clarify:

https://github.com/w3c/resource-timing/issues/118
https://github.com/w3c/resource-timing/issues/119

But I don't think those need to block shipping the property.  We can adjust
the values as the spec is clarified.  Also, one of the reasons I am
implementing this now is so we can enable the WPT test.  Our
PerformanceResourceTiming code is completely broken for SW in e10s right
now and we missed it because the test is not passing.  (This will be fixed
in FF58 as well.)

The WPT test is here and is being expanded slightly with our implementation:

https://searchfox.org/mozilla-central/source/testing/web-platform/tests/service-workers/service-worker/resource-timing.https.html

Please let me know if there are questions or concerns.  Thanks.

Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Frederik Braun]

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() that
>>> contained attribute/value pairs?
>>
>> This has definitely been proposed before.  Worth checking with Anne to see
>> what the status is.  Specifically, did it die, and if so why? Because I,
>> too, think this would be an interesting avenue to explore...
> 
> See https://github.com/whatwg/dom/issues/150. There's not really any
> dominant pattern that's succeeded here in libraries that we could
> adopt. You typically end up looking at templating and that has its own
> host of issues. The other thing that would solve some of this is
> browser-backed sanitization, but that's also a hard problem to solve
> nobody has been willing to tackle and get standardized.
> 
> 

Some folks are Google are working on a solution based on Types:


I've tried providing feedback here and there, but they are moving fast
and I'm not included in all of their conversations, since they are not
public (despite their good history of working with W3C WebAppSec). :(
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Frederik Braun]

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",
> "class":"bar"});
>   parent.prepend(div);
> 
> (the null is for the existing custom elements options param)

Well, you _could_ write something like

var div = Object.assign(document.createElement("div"), {
id: "foo",
className: "bar",
});
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kris Maglione]

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 numbers for "inserted into 
the document" and "not inserted into the document".


Well, on the upside, if I hadn't misread you, I wouldn't have 
thought to check the cross-document case (which is pretty 
relevant to subject principal checks), but would have thought to 
check inserted vs. non-inserted, so I think it came out for the 
best :)


I just did a bit of testing with a non-inlined no-op function and it 
looks like the overhead of NeedsSubjectPrincipal is on the order of 
maybe 1-2ns.  Looks like the actual implementation we end up using 
mostly consists of reinterpret_cast, which is nice and fast.  ;) 
There's one memory read from the JSContext to get the compartment, and 
one memory read from the compartment to get the principal; as long a 
those hit cache all is good.


I'd be pretty surprised if we ever manage to get to that point 
without both locations being in the cache. We check compartment 
flags all over the place when JS is running. Maybe just after a 
block of pure JIT code that touched a huge amount of memory...


So, yeah, it doesn't seem like it should be an issue in 
practice.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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 the document".


Without inserting the div into the document, the numbers were closer to 
500ns, with or without the subject principal, in- or out-of-document.


Gotcha.

I just did a bit of testing with a non-inlined no-op function and it 
looks like the overhead of NeedsSubjectPrincipal is on the order of 
maybe 1-2ns.  Looks like the actual implementation we end up using 
mostly consists of reinterpret_cast, which is nice and fast.  ;) 
There's one memory read from the JSContext to get the compartment, and 
one memory read from the compartment to get the principal; as long a 
those hit cache all is good.



I haven't tested a sandbox with X-rays


Yeah, not going to be a big factor there.

Sounds to me like just using NeedsSubjectPrincipal is fine here.  Thank 
you for checking this stuff!


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kris Maglione]

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, obviously, but I would still like us to 
measure what the (presumably nonzero) impact is, so we know what we're 
dealing with.  In particular, setAttribute may simply not be a huge 
part of most talos tests.


What I'd like to see is how long setAttribute() with some meaningless 
name like "testing" takes with/without this change on an 
HTMLDivElement in both the "in document" and "out of document" cases.  
Just a silly microbenchmark is ok for this purpose; it at least gives 
us an idea of what happens in the L2-cache-hit case.


For the pretty simple micro-benchmark below, here are the 
in-document and out-of-document numbers for three runs without 
the subject principal:


1260ns 1820ns
1260ns 1870ns
1014ns 1332ns

and three runs with:

1002ns 1470ns
1280ns 1722ns
1207ns 1898ns

The difference between the two is within the noise.


Without inserting the div into the document, the numbers were 
closer to 500ns, with or without the subject principal, in- or 
out-of-document.


I haven't tested a sandbox with X-rays, but I'm willing to bet 
X-ray overhead completely overwhelms any other meaningful metric 
in that case.




 
 
   "use strict";

   function run(doc) {
 let div = document.createElement("div");
 doc.body.appendChild(div);

 let iterations = 1024 * 1024;

 let start = performance.now();
 for (let i = 0; i < iterations; i++) {
   div.setAttribute("data-num", i);
 }
 let end = performance.now();
 let delta = (end - start) * 1000 * 1000;

 doc.body.appendChild(document.createTextNode(`Per-iteration: 
${Math.round(delta / iterations)}ns`));
   }

   let iframe = document.querySelector("iframe");
   iframe.addEventListener("load", () => {
 run(iframe.contentDocument);
   }, {once: true});

   window.addEventListener("load", () => {
 run(document);
   }, {once: true});
 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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 (presumably nonzero) impact is, so we know what we're 
dealing with.  In particular, setAttribute may simply not be a huge part 
of most talos tests.


What I'd like to see is how long setAttribute() with some meaningless 
name like "testing" takes with/without this change on an HTMLDivElement 
in both the "in document" and "out of document" cases.  Just a silly 
microbenchmark is ok for this purpose; it at least gives us an idea of 
what happens in the L2-cache-hit case.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kris Maglione]

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 relies on no one on the setattr path 
messing with the compartment, but that shouldn't be too hard to 
ensure, especially since we only have a few attributes on a few 
elements for which this is relevant...


I'd love it if we could pass along something that couldn't be 
abused/misused like a JSContext.  We could make up a wrapper class, 
but no matter what we do we'd have the fundamental tradeoff that 
either we grab the principal eagerly, and pay the cost for all the 
cases where it doesn't matter, or we grab it lazily and run the risk 
of thing changing under us.  We should probably measure how 
expensive setAttribute is and how expensive grabbing the principal 
from a JSContext (e.g. by marking the method as 
[NeedsCallerPrincipal]) is...


OK, I'll try a talos run with [NeedsCallerPrincipal] added to 
setAttribute and see where that comes out. If it looks good, I'll 
investigate that route some more. Otherwise, I'll probably go with a 
JSContext wrapper and retrieve the principal on demand.


So far it doesn't look like there's any significant difference 
on any talos test from adding [NeedsCallerPrincipal] to 
setAttribute/setAttributeNS/Attr.value, so I'm going to go that 
route for now. If it turns out to be a problem later, I'll 
refactor it to pass a context object that lazily extracts the 
principal.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kris Maglione]

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. However, it's
already quite easy for malicious or badly-implemented extensions to
create similar issues, and I don't think this change significantly
increases the risk. It may even mitigate it in some cases, since the
alternative of loading or evaling third-party scripts into the content
script sandbox would give them direct access to elevated privileges.

Per the CSP spec, those injections are assumed to be at the user's
behest, and should therefore take priority over the page author's
preferences.


+1 on this part.

As an add-on author, when I need to inject something the page CSP doesn't 
allow, I can already over-write the page CSP to allow it. But that feels more 
dangerous!


Yes, I'll admit that's one of my motivations. Whenever we try to prevent 
extensions from doing things for security or performance reasons, extensions 
authors tend to just find another way to do it with worse security and 
performance characteristics...


I filed bug 1273281 about preventing extensions from changing security headers 
without a special permission, but for now, many extensions still do such 
things.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kris Maglione]

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, but that shouldn't be too hard to ensure, 
especially since we only have a few attributes on a few elements for 
which this is relevant...


I'd love it if we could pass along something that couldn't be 
abused/misused like a JSContext.  We could make up a wrapper class, 
but no matter what we do we'd have the fundamental tradeoff that 
either we grab the principal eagerly, and pay the cost for all the 
cases where it doesn't matter, or we grab it lazily and run the risk 
of thing changing under us.  We should probably measure how expensive 
setAttribute is and how expensive grabbing the principal from a 
JSContext (e.g. by marking the method as [NeedsCallerPrincipal]) is...


OK, I'll try a talos run with [NeedsCallerPrincipal] added to 
setAttribute and see where that comes out. If it looks good, 
I'll investigate that route some more. Otherwise, I'll probably 
go with a JSContext wrapper and retrieve the principal on 
demand.


The question of how to handler parser-generated nodes is tougher. 
Just using SubjectPrincipal() is one obvious approach, but the 
security characteristics of that worry me (what if the parser gets 
invoked by system code while some JS caller is blocked?).


Yes, that is the fundamental problem with SubjectPrincipal().

But even worse, depending on what you're trying to solve, using 
SubjectPrincipal() from SetAttr() doesn't even work right.  Consider 
this case:


 document.write("");

The SetAttr call for the  happens async, after the 

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

[Kris Maglione]

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://example.com/favicon.ico";>`);
div.innerHTML = `http://example.com/favicon.ico";>`;
img.setAttribute("src", "http://example.com/favicon.ico";);
img.src = "http://example.com/favicon.ico";;


Do you _need_ to make all those ways work? I'm especially worried about
the parser ones. 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?


We do if we want Chrome parity, yes.

But I also have another motivation for wanting to make this as comprehensive 
as possible. I'd like to make web-accessible extension URLs loadable only by 
extension callers, to reduce the fingerprinting risk. Web content would still 
be able to fingerprint based on content injected into pages, but they wouldn't 
be able to poll for extension IDs.


There's already some risk of breaking extensions that inject scripts into the 
page context if we do that. The risk goes up a lot more if we also don't 
support things like innerHTML and insertAdjacentHTML.


document.write, though... To be honest, I'd be perfectly happy to forbid 
content scripts from using document.write altogether, if I could get away with 
it.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Anne van Kesteren]

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 definitely been proposed before.  Worth checking with Anne to see
> what the status is.  Specifically, did it die, and if so why? Because I,
> too, think this would be an interesting avenue to explore...

See https://github.com/whatwg/dom/issues/150. There's not really any
dominant pattern that's succeeded here in libraries that we could
adopt. You typically end up looking at templating and that has its own
host of issues. The other thing that would solve some of this is
browser-backed sanitization, but that's also a hard problem to solve
nobody has been willing to tackle and get standardized.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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 
see what the status is.  Specifically, did it die, and if so why? 
Because I, too, think this would be an interesting avenue to explore...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Daniel Veditz]

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 createElement() that
contained attribute/value pairs?

  var div = document.createElement("div", null, {"id":"foo",
"class":"bar"});
  parent.prepend(div);

(the null is for the existing custom elements options param)

Wordier than your parent.prepend("") example, but
safer from developers trying to get clever with it. Such a short example
isn't going to fall victim to CSP blockage. In a longer example with src
URLs the overhead might not be too bad.

-
​Dan Veditz​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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.  Compare these two snippets:


  var div = document.createElement("div");
  div.id = "foo";
  div.className = "bar";
  parent.prepend(div);

and:

  parent.prepend("");

That said, I am sympathetic to the concern about innerHTML in 
particular.  Specifically, if an extension does:


  parent.innerHTML += "";

instead of doing:

  parent.append("");

and we exempt the former from CSP, then the extension just introduced 
XSS into the page without even noticing...


So to be honest, my gut feeling is that we should not try to make 
innerHTML or document.write() work here, but it would be nice to make 
the ParentNode.append/prepend methods and maybe createContextualFragment 
work...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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 something like 
SubjectPrincipal(). I'd definitely like to hear opinions on the best 
approach here.


I'd really rather we didn't use SubjectPrincipal() here.  It's too hard 
to reason about, and we have better options.


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, but that shouldn't be too hard to ensure, 
especially since we only have a few attributes on a few elements for 
which this is relevant...


I'd love it if we could pass along something that couldn't be 
abused/misused like a JSContext.  We could make up a wrapper class, but 
no matter what we do we'd have the fundamental tradeoff that either we 
grab the principal eagerly, and pay the cost for all the cases where it 
doesn't matter, or we grab it lazily and run the risk of thing changing 
under us.  We should probably measure how expensive setAttribute is and 
how expensive grabbing the principal from a JSContext (e.g. by marking 
the method as [NeedsCallerPrincipal]) is...


The question of how to handler parser-generated nodes is tougher. Just 
using SubjectPrincipal() is one obvious approach, but the security 
characteristics of that worry me (what if the parser gets invoked by 
system code while some JS caller is blocked?).


Yes, that is the fundamental problem with SubjectPrincipal().

But even worse, depending on what you're trying to solve, using 
SubjectPrincipal() from SetAttr() doesn't even work right.  Consider 
this case:


  document.write("");

The SetAttr call for the  happens async, after the 

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

[Daniel Veditz]

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://example.com/favicon.ico";>`;
>> img.setAttribute("src", "http://example.com/favicon.ico";);
>> img.src = "http://example.com/favicon.ico";;
>>
>
> What is the plan to do this, concretely?  Changing img.src to thread
> through a principal is not too bad but doing it for setAttribute would be a
> bit of a performance annoyance, and threading them through the parser would
> be _quite_ annoying.
>

​Do you _need_ to make all those ways work? I'm especially worried about
the parser ones. 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?

innerHTML ("Satan's candy"), in particular, is often misused and leads to
XSS​. It's the very last thing I'd want to give a "get out of CSP free"
pass.

-
​Dan Veditz​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Luke Crouch]

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-implemented extensions to 
> create similar issues, and I don't think this change significantly 
> increases the risk. It may even mitigate it in some cases, since the 
> alternative of loading or evaling third-party scripts into the content 
> script sandbox would give them direct access to elevated privileges.
> 
> Per the CSP spec, those injections are assumed to be at the user's 
> behest, and should therefore take priority over the page author's 
> preferences.

+1 on this part.

As an add-on author, when I need to inject something the page CSP doesn't 
allow, I can already over-write the page CSP to allow it. But that feels more 
dangerous!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kris Maglione]

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.com/favicon.ico";>`;
   img.setAttribute("src", "http://example.com/favicon.ico";);
   img.src = "http://example.com/favicon.ico";;


What is the plan to do this, concretely?  Changing img.src to thread 
through a principal is not too bad but doing it for setAttribute would 
be a bit of a performance annoyance, and threading them through the 
parser would be _quite_ annoying.


The other option is to basically use something like 
SubjectPrincipal(), but we're trying to remove existing uses of that, 
because the action-at-a-distance makes it hard to reason about its 
security properties.


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 something like SubjectPrincipal(). I'd definitely like to 
hear opinions on the best approach here.


The question of how to handler parser-generated nodes is 
tougher. Just using SubjectPrincipal() is one obvious approach, 
but the security characteristics of that worry me (what if the 
parser gets invoked by system code while some JS caller is 
blocked?). So I think it will probably require some sort of 
special activation records that we can check (and sanity check) 
from the attribute hooks. But I've barely begun looking into 
this part yet.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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://example.com/favicon.ico";);
    img.src = "http://example.com/favicon.ico";;


What is the plan to do this, concretely?  Changing img.src to thread 
through a principal is not too bad but doing it for setAttribute would 
be a bit of a performance annoyance, and threading them through the 
parser would be _quite_ annoying.


The other option is to basically use something like SubjectPrincipal(), 
but we're trying to remove existing uses of that, because the 
action-at-a-distance makes it hard to reason about its security properties.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Kris Maglione]

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 
running on.


The plan here is to apply a separate CSP to content injected by certain 
privileged callers, rather than subjecting it to page CSP. Content from 
system URLs (like moz-extension:) is already immune to CSP. This change 
will extend that immunity to any content injected by those callers.



Implementation plan:

Implementing this will require that we record the caller principal 
whenever content that loads a URL is injected into a page, and use that 
principal as the triggering principal for the load.


My plan is to add a special attribute to principals, specifying that 
their CSP should override the CSP of document principals that they 
subsume. Initially, this flag would only apply to expanded principals 
used in extension content scripts.


The exact mechanics of capturing the triggering principal will need to 
vary, but in general, it should happen any time a particular source 
attribute is set. 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://example.com/favicon.ico";);
   img.src = "http://example.com/favicon.ico";;

Other alterations to the node should retain the existing principals for 
existing attributes. For example:


   img.setAttribute("src", "http://example.com/favicon.ico";);

   window.wrappedJSObject.img = img;
   window.wrappedJSObject.eval("document.body.appendChild(img)");

should retain the principal from the original setAttribute call, even 
though the last insertion happens with a content caller principal.



Scripts injected in this way will not gain any special immunity to CSP. 
For instance, this call will succeed regardless of site CSP:


   document.createElement("script");
   script.setAttribute("src", "https://cdn.framework.org/framework.js";);
   document.head.appendElement(script);

but any attempts by that script to inject content that violates CSP will 
fail, as will any attempts to inject content via that framework 
(e.g., `window.wrappedJSObject.$("head").append("

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

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 
drawImage, since you don't have it to start with.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Tom Ritter]

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, assuming the  was loaded.
>
> I don't think the pref you mention prevents such loading (or has any other
> effects that I can see), fwiw...

Sorry I got the pref name wrong; it's svg.disabled from
https://bugzilla.mozilla.org/show_bug.cgi?id=1216893

The way the pref was implemented:
 // If the svg.disabled pref. is true, convert all SVG nodes into
 // disabled SVG nodes by swapping the namespace.

I'm unsure if that would neuter the drawImage() call or not. The
ultimate goal of the pref is to disable all SVG-related code paths.

-tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

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 such loading (or has any 
other effects that I can see), fwiw...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Tom Ritter]

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
>
> Spec:
> https://html.spec.whatwg.org/multipage/canvas.html#htmlorsvgimageelement and
> https://html.spec.whatwg.org/multipage/canvas.html#canvasimagesource
>
> Platform coverage: all
>
> Target release: 56
>
> Preference: None.
>
> Support in other engines: Chrome is adding support; see
> .
> I don't know about Safari or Edge.
>
> Tests: Still figuring this out.  If there aren't any, I'll add some.
>
> -Boris
> ___
> 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 implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

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: all

Target release: 56

Preference: None.

Support in other engines: Chrome is adding support; see 
. 
 I don't know about Safari or Edge.


Tests: Still figuring this out.  If there aren't any, I'll add some.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[Tom Schuster]

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 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 right now; Linux support is
> also looking pretty OK, and we're planning to get Windows this quarter, too.
>
> Independently, we're waiting on updating our Web Authentication
> implementation from the WD-02 version currently in-tree, expecting a
> significant refactor to happen aligning the way you use Web Authentication
> with the W3C Credential Management specification. There's ongoing
> discussion [1] and currently one pull request [2] to do that. That's
> primarily why we haven't moved forward to the WD-04 draft yet - and we're
> working on the HID support.
>
> That said, we're still planning on exposing the USB U2F security key-type
> devices only through the W3C Web Authentication API by default -- the older
> FIDO U2F API that is currently hidden behind the `security.webauth.u2f`
> preference [3] we're currently planning to keep hidden. It doesn't
> implement the "Low-level MessagePort API", which makes a some sites that
> depend on Chrome's u2f-api.js behave oddly.
>
>
> [1] https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0162.html
> [2] https://github.com/w3c/webauthn/pull/384
> [3] (and also the `security.webauth.u2f_enable_softtoken` preference,
> since there's no USB support in-tree yet)
>
> Cheers,
> J.C.
>
> On Tue, Apr 11, 2017 at 5:05 AM, Tom Schuster  wrote:
>
>> 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:
>> > > Anders,
>> > >
>> > > The first target I'm working on is Desktop, though I've plans in 2017
>> to
>> > > support WebAuthn on Android and iOS [1], too. WebAuthn already has
>> > > definitions suitable for Android's Key Attestation [2] and SafetyNet
>> > > formats [3], so they'll need implementations that tie into the
>> > > dom::WebAuthentication class.
>> >
>> > That's great news!
>> >
>> > Regards,
>> > Anders
>> >
>> > >
>> > > Cheers,
>> > > J.C.
>> > >
>> > > [1] https://wiki.mozilla.org/Security/CryptoEngineering#
>> > Web_Authentication
>> > > [2] https://w3c.github.io/webauthn/#android-key-attestation
>> > > [3] https://w3c.github.io/webauthn/#android-safetynet-attestation
>> > >
>> > > On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
>> > > anders.rundgren@gmail.com> wrote:
>> > >
>> > > > On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren
>> > wrote:
>> > > > > It is a pity that external tokens have become the
>> > > > > focus when the majority will rather rely on embedded
>> > > > > security solutions which nowadays is a standard feature
>> > > > > in Android and Windows platforms.
>> > > >
>> > > > Slight clarification to the above: The IoT folks pretty much build
>> > 100% on
>> > > > embedded security with car-keys as an obvious exception.
>> > > >
>> > > > On mobile I would say that over 99% of all existing security
>> solutions
>> > > > based on cryptographic keys are relying on embedded (or "App level")
>> > keys
>> > > > with Apple Pay as the most advanced example.
>> > > >
>> > > > That is, the token vendors and security folks do not represent the
>> > actual
>> > > > market comprising of end-users and service providers.
>> > > >
>> > > > Maybe this is a project primarily targeting the desktop?
>> > > > ___
>> > > > 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
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[J.C. Jones]

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 right now; Linux support is
also looking pretty OK, and we're planning to get Windows this quarter, too.

Independently, we're waiting on updating our Web Authentication
implementation from the WD-02 version currently in-tree, expecting a
significant refactor to happen aligning the way you use Web Authentication
with the W3C Credential Management specification. There's ongoing
discussion [1] and currently one pull request [2] to do that. That's
primarily why we haven't moved forward to the WD-04 draft yet - and we're
working on the HID support.

That said, we're still planning on exposing the USB U2F security key-type
devices only through the W3C Web Authentication API by default -- the older
FIDO U2F API that is currently hidden behind the `security.webauth.u2f`
preference [3] we're currently planning to keep hidden. It doesn't
implement the "Low-level MessagePort API", which makes a some sites that
depend on Chrome's u2f-api.js behave oddly.


[1] https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0162.html
[2] https://github.com/w3c/webauthn/pull/384
[3] (and also the `security.webauth.u2f_enable_softtoken` preference, since
there's no USB support in-tree yet)

Cheers,
J.C.

On Tue, Apr 11, 2017 at 5:05 AM, Tom Schuster  wrote:

> 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:
> > > Anders,
> > >
> > > The first target I'm working on is Desktop, though I've plans in 2017
> to
> > > support WebAuthn on Android and iOS [1], too. WebAuthn already has
> > > definitions suitable for Android's Key Attestation [2] and SafetyNet
> > > formats [3], so they'll need implementations that tie into the
> > > dom::WebAuthentication class.
> >
> > That's great news!
> >
> > Regards,
> > Anders
> >
> > >
> > > Cheers,
> > > J.C.
> > >
> > > [1] https://wiki.mozilla.org/Security/CryptoEngineering#
> > Web_Authentication
> > > [2] https://w3c.github.io/webauthn/#android-key-attestation
> > > [3] https://w3c.github.io/webauthn/#android-safetynet-attestation
> > >
> > > On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
> > > anders.rundgren@gmail.com> wrote:
> > >
> > > > On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren
> > wrote:
> > > > > It is a pity that external tokens have become the
> > > > > focus when the majority will rather rely on embedded
> > > > > security solutions which nowadays is a standard feature
> > > > > in Android and Windows platforms.
> > > >
> > > > Slight clarification to the above: The IoT folks pretty much build
> > 100% on
> > > > embedded security with car-keys as an obvious exception.
> > > >
> > > > On mobile I would say that over 99% of all existing security
> solutions
> > > > based on cryptographic keys are relying on embedded (or "App level")
> > keys
> > > > with Apple Pay as the most advanced example.
> > > >
> > > > That is, the token vendors and security folks do not represent the
> > actual
> > > > market comprising of end-users and service providers.
> > > >
> > > > Maybe this is a project primarily targeting the desktop?
> > > > ___
> > > > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[Tom Schuster]

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:
> > Anders,
> >
> > The first target I'm working on is Desktop, though I've plans in 2017 to
> > support WebAuthn on Android and iOS [1], too. WebAuthn already has
> > definitions suitable for Android's Key Attestation [2] and SafetyNet
> > formats [3], so they'll need implementations that tie into the
> > dom::WebAuthentication class.
>
> That's great news!
>
> Regards,
> Anders
>
> >
> > Cheers,
> > J.C.
> >
> > [1] https://wiki.mozilla.org/Security/CryptoEngineering#
> Web_Authentication
> > [2] https://w3c.github.io/webauthn/#android-key-attestation
> > [3] https://w3c.github.io/webauthn/#android-safetynet-attestation
> >
> > On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
> > anders.rundgren@gmail.com> wrote:
> >
> > > On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren
> wrote:
> > > > It is a pity that external tokens have become the
> > > > focus when the majority will rather rely on embedded
> > > > security solutions which nowadays is a standard feature
> > > > in Android and Windows platforms.
> > >
> > > Slight clarification to the above: The IoT folks pretty much build
> 100% on
> > > embedded security with car-keys as an obvious exception.
> > >
> > > On mobile I would say that over 99% of all existing security solutions
> > > based on cryptographic keys are relying on embedded (or "App level")
> keys
> > > with Apple Pay as the most advanced example.
> > >
> > > That is, the token vendors and security folks do not represent the
> actual
> > > market comprising of end-users and service providers.
> > >
> > > Maybe this is a project primarily targeting the desktop?
> > > ___
> > > 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 implement and ship: support ::cue pseudo-element from document.

[Chris Pearce]

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=1318542
> 
> Spec: https://w3c.github.io/webvtt/#the-cue-pseudo-element
> 
> Platform coverage:
> All platforms
> 
> Estimated or target release:
> Firefox 55
> 
> Preference:
> media.webvtt.pseudo.enabled, default is true.
> 
> DevTools bug:
> None.
> 
> Do other browser engines implement this?
> Yes, chrome, safari, opera
> 
> Web Developer Use-Cases:
> write the ::cue style block in the document, then ::cue rules will be applied 
> to the .vtt subtitle. Note that the ::cue style block can only appear in 
> document, not in vtt file (not support yet).
> 
> ::cue {
>   ...
> }
> 
> 
>  
> 
> 
> Tests:
> web-platform/tests/webvtt/rendering/cues-with-video/processing-model/selectors/*
> Tests under the folder are disabled now, I'm going to enable/fix them.

Excellent. Thanks Benjamin!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[bechen]

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:
All platforms

Estimated or target release:
Firefox 55

Preference:
media.webvtt.pseudo.enabled, default is true.

DevTools bug:
None.

Do other browser engines implement this?
Yes, chrome, safari, opera

Web Developer Use-Cases:
write the ::cue style block in the document, then ::cue rules will be applied 
to the .vtt subtitle. Note that the ::cue style block can only appear in 
document, not in vtt file (not support yet).

::cue {
  ...
}


 


Tests:
web-platform/tests/webvtt/rendering/cues-with-video/processing-model/selectors/*
Tests under the folder are disabled now, I'm going to enable/fix them.
___
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'.

[Mike Taylor]

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.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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'.

[Mats Palmgren]

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 people to switch to them.  Then we can remove 
-moz-appearance.


Fair enough, I've updated the patches so that both prefs are now enabled
by default.  IOW, we'll ship both appearance/-webkit-appearance:none, and
-moz-appearance with no change in semantics except that it is now trumped
by an appearance/-webkit-appearance:none.

Does that sound reasonable?


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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: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 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.
>>
>> Why? Assume
>>
>   threat_of_flash = exploits_of_flash_per_year *
> usage_of_flash_per_year
>
> If usage_of_flash_per_year is declining but threat_of_flash is
> increasing,
> then exploits_of_flash_per_year must be increasing.
> But the report you cited does not provide such data.
>
> That assumption doesn't hold: malicious uses of Flash don't need
>
 non-malicious ones.

 I agree. So let me ask this question instead: is there any proof that
>>> local-only Flash
>>> exploits are increasing?
>>>
>>> I don't know. I do know that legitimate usage of Flash, be it via file:
>> or
>> otherwise, is steadily declining. That's all that's needed to change the
>> cost/benefit balance here.
>>
>>
>> In fact it seems quite likely that there'll be an inverse relationship:
 less (non-malicious) usage means less testing of potentially exploitable
 code paths, which would increase the threat.

 I would assume Adobe will actively test Flash plugin with local contents
>>> for a reasonablely long time. Do you mean tests in Firefox for local
>>> Flash
>>> contents
>>> will inevitably decrease even if you don't disable it?
>>>
>>> What I'm saying is that testing and hardening against attacks isn't free,
>> so requires investing resources. This entire thread is based on the
>> conclusion that Flash usage has diminished to a point where it's can no
>> longer a good investment of resources to keep doing these activities for
>> this fairly niche-usage of Flash.
>>
>>
>> One solution to this is to decouple the amount of testing done for those
 code paths from how frequently they're used. In practice that's not
 trivial
 because at least some testing comes in the form of investigating crash
 reports from users. Another solution is what's proposed here: disable
 less-well tested configurations altogether.

 Also I think forbidding non-http(s) Flash does not fix thoses exploits
>
>> magically.
>>>
>>> Sure, this is about reducing attack surface, not completely
>>> eliminating
>>>
>> it.
>>
>> Non-http(s) Flash takes only a small fraction of all Flash contents,
>>
> even
> for users who do use non-http(s) Flash.
> I don't think users want to drop their local Flash for a small fraction
> of
> reduced attack surface,
> especially if those local Flash don't have alternatives yet. The more
> practical reaction is trying another browser.
>
> The underlying assumption here is that these usages of Flash are rare
 enough that the incompatibility, while unfortunate, becomes acceptable.
 Note that other browser vendors are planning their own measures for
 restricting Flash usage, too.

 Although usage of local Flash is rare, I'd point out that local Flash
>>> contents usually have higher
>>> value than those on web sites, Because users only save important contents
>>> to disks.
>>> Additionally, local Flash contents are much harder to replace than those
>>> on web sites
>>> because users can hardly contact the author. Please consider more for
>>> users.
>>>
>>> We are doing precisely that, but we believe that our users are better
>> served by us investing resources in tasks that have more impact. Again,
>> the
>> underlying assumption in this entire thread is that our users won't be
>> affected as strongly as you assume, or few enough will.
>> ___
>> 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 implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Benjamin Smedberg]

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 don't think this is a realistic argument.  Basically any change we
> make to Gecko, including implementing new features, can affect Web
> compat.  We have to use judgment about which ones require measuring.
>

I agree that not everything requires measurement. I am saying that we need
a deliberate approach to risk, and that if we primarily relies on our
prerelease users to file bugs, we are not going to have any strong
guarantees of web compatibility.

Agree that this is not just for feature removals: new features may have
little risk if nobody on the web is using them. Or they may be very risky
if Chrome has deployed them and they already have traction, to the point
where web compatibility means implementing bug-for-bug compatibility with
Chrome and altering the specification.

So I want us to approach this from multiple approaches: what kinds of web
crawling automation could help mitigate webcompat risk?  What about
targeted fuzzing?


>
>
> > In this case, I understand the advantage of shipping CSS 'appearance'.
> I'm
> > less sure about what it would cost us to keep supporting -moz-appearance:
> > none, perhaps indefinitely.
>
> The cost is long-term or permanent differences between rendering
> engines, which leads to extra work for Web developers and to
> Web-compatibility problems for us.
>

And yet, that is sometimes (often?) a cost we should be prepared to bear.
The market costs of breaking almost any existing web content is so high
that we cannot afford to do it without knowing, and we should be prepared
to keep our quirks at the cost of extra engineering time and legacy support.

--BDS
___
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'.

[Karl Dubost]

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-appearance: none


UNSHIP: OK with a condition.
-moz-appearance: none

If I check carefully the way the site are currently dropping the arrows on the 
select/option widget is by having -webkit-appearance: button or 
-webkit-appearance: none.

For compatibility we would need this at the same time we unship 
-moz-appearance: none 

-webkit-appearance: button
-moz-appearance: button
appearance: button

-webkit-appearance: button and -moz-appearance: button behaves differently.
See the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1246836


I created a test.
http://www.la-grange.net/2017/02/21/appearance/appearance-test-0001.html

The issue is that when we set 

-moz-appearance: button 

we get a widget with arrows while -webkit-appearance: button deliver a simple 
button.

So if the site does:

-webkit-appearance: button;
-moz-appearance: button;
background: 

The rendering looks broken in Firefox.

and if the site does:

-webkit-appearance: button;
-moz-appearance: none;
appearance: button
background: 

the site will be broken if we unship -moz-appearance: none



-- 
Karl Dubost, mozilla 💡 Webcompat
http://www.la-grange.net/karl/moz





___
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'.

[Mike Taylor]

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 happens, most predominately on the larger sites that serve N 
versions to N devices. One example:


https://bugzilla.mozilla.org/show_bug.cgi?id=418833#c123

--
Mike Taylor
Web Compat, Mozilla
___
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'.

[Karl Dubost]

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 
> 'appearance' as far as I know.  Edge implements '-webkit-appearance:none' but 
> no other values, nor do they implement it unprefixed.  


See also https://github.com/whatwg/compat/issues/6#issuecomment-234159236


Le 17 févr. 2017 à 03:20, Benjamin Smedberg  a écrit :
>   - We cannot rely on prerelease users to file bugs about issues they do
>   encounter. Bugzilla is intimidating in general, and even more intimidating
>   for people who don't speak English fluently.

While this is true, things have improved a bit.

Right now 
* Nightly Desktop ship with the report site issue button which lands on 
https://webcompat.com.
* Nightly Android has it for a long time

In fact, it helped us to detect many breakages and fixed them. :) I intend to 
talk about it in platform lightning talks in SF, if there is such a session.


# About -moz-appearance. A selection of issues with one example for each.


## Case 1 (Double drop down arrows)

Here a case where the site is using:
https://webcompat.com/issues/3295#issuecomment-249768573
-webkit-appearance: none
appearance: none
but not -moz-appearance: none. This is a common pattern it leads to double 
drop-down arrows for Firefox Android. Usually the -webkit-appearance: none is 
using in combination of a background-image.



## Case 2 (background-image appearance sublimation)

There are cases more subtle and difficult.
https://webcompat.com/issues/1006#issuecomment-181650441

In this case the site has this markup
-webkit-appearance: button;
-moz-appearance: button;
appearance: button;

The solution to this would be for the site to either add -moz-appearance: none 
OR for Gecko to change its behaviour so that we do like webkit and drops the 
appearance: button when there is a background-image.
A similar issue here:
https://webcompat.com/issues/1005#issuecomment-120774729



## Case 3

In https://webcompat.com/issues/3836#issuecomment-263342153
They use only -webkit-appearance: none;
select {
font-family: Arial;
outline: none;
-webkit-appearance: none;
   }

Currently what we usually recommend in these cases is to add `-moz-appearance: 
none;`. They were contacted on Nov 2016, still not fixed.



## Case 4

This one was confusing
https://webcompat.com/issues/4177

.nav-search .nav-category input[type="checkbox"] {
background:0;
-moz-appearance:none;
}

but eventually led to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1328474#c7
I need to retest once Mats patch lands in Nightly



## Case 5 (against removing -moz-appearance)

Here we will probably break again Japan Airlines if we remove -moz-appearance: 
none.
They implemented our suggestion to add -moz-appearance: none, which fixed the 
site issue. The site relies on the behaviour explained in Case 2, aka dropping 
the appearance when there is a background-image.

div.domModule table td select {
font-weight: bold;
font-size: 18px;
height: 54px;
border: none;
border-radius: 0px;
-webkit-border-radius: 0px;
background-color: transparent;
background-position: 97% 50%;
width: 100%;
-webkit-appearance: button;
-moz-appearance: none;
appearance: button;
}
div.domModule table td select {
background-image: url(../img/bg_dom_select_arw.png);
background-repeat: no-repeat;
background-size: 14px 14px;
-webkit-background-size: 14px 14px;
}




## Case 6 (another funky one, variation of case #2)

https://webcompat.com/issues/1061


全てから
…



The background image is a sprite (multiple images on a big png which is 
positioned) on the **DIV element**
AND the select has background: none but NO -webkit-appearance: none…

it's working for Webkit devices. FUN!

```
.listview li > a::after, .listview.frontbullet > li > a::after, .listview > li 
> div.additional-info::before, .icon, .search-box > .main > div.target, 
.search-box > .main > button[type="submit"], header > a::before, footer > 
div.go-to-top > a::before, .slide-navigation > .locator > .mark, 
.slide-navigation > a::before, .pager > a::before, .pager > a::after, 
.link-to-help > a::before, span.gift-icon, span.signage-icon, .member-icon, 
.notice.info::before, .notice.success::before, .notice.warning::before, 
.close-btn, .step-label > li::after, .options > label::before {
background-image: url(image/splite.png);
background-repeat: no-repeat;
background-size: 240px 215px;
-webkit-background-size: 240px 215px;
-moz-background-size: 240px 215px;
}
.search-box > .main > div.target {
width: 11

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

[Boris Zbarsky]

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 doing that 
means you can't read any of the labels on the buttons you're supposed to 
click.


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 people to switch to them.  Then 
we can remove -moz-appearance.



I suspect this is the case for -moz-appearance.  If the web author also
wrote -webkit-appearance/appearance:none (as they should)


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.



AFAICT, IE11 (on a Win7 desktop) has no support for 'appearance' at all
(or any prefixed variant thereof), and Edge specifically added support
only for '-webkit-appearance:none'.  And I assume the web still works
in those browsers.


Edge also has a UA string that sniffs as "Chrome" unless you very 
carefully try to disambiguate.  This is not an accident.


-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'.

[Mats Palmgren]

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 you get native styling instead
(at worst).  There shouldn't be any loss of function.  I don't think
an average web user will even notice it.

In the unlikely event that we do want to roll this back, all we need
to do is toggle the preference values, which I believe we can do even
in release builds nowadays by pushing a restart-less system add-on.



It is not hard nowadays to add metrics (telemetry) to measure web
feature usage.


Getting the data we would need in this case is actually a lot harder
than you may think.  It's probably easy to measure "does this web page
have a style rule that declares a valid -moz-appearance value?", but
that's useless in this case, since we really need to know if there's an
'appearance/-webkit-appearance' declaration that "wins" in this style
rule, or in some other rule.  Or if there's a 'border' declaration etc
that also turns off native styling in some cases, or if the element
is a  or something that has no support for native styling to begin
with, etc.

Adding that telemetry machinery to the style system seems rather tricky
to me.  And given the low risk with removing -moz-appearance - doesn't
seem worth implementing to me.  (I think our goal is to remove all
-moz-prefixed CSS properties eventually anyway, at which point this
machinery would have little value.)



In this case, I understand the advantage of shipping CSS 'appearance'.
I'm less sure about what it would cost us to keep supporting
-moz-appearance: none, perhaps indefinitely.


It seems you haven't considered that *removing* a -moz-prefixed property
could actually *improve* web compatibility.  We actually have some
evidence of that for -moz-appearance:none in bug 1328474.

I suspect this is the case for -moz-appearance.  If the web author also
wrote -webkit-appearance/appearance:none (as they should) then there is
no change, and if they didn't they might not have intended to have 'none'
styling in the first place.  It's just that they never tested it in
Firefox.  I get that impression after studying the usage of these
properties in some github projects.

AFAICT, IE11 (on a Win7 desktop) has no support for 'appearance' at all
(or any prefixed variant thereof), and Edge specifically added support
only for '-webkit-appearance:none'.  And I assume the web still works
in those browsers.


/Mats
___
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'.

[L. David Baron]

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
make to Gecko, including implementing new features, can affect Web
compat.  We have to use judgment about which ones require measuring.

> We *know* that -moz-appearance: none has long been a webdev technique used
> to unstyle various form controls [1][2][3][4]. We can also presume that
> sometimes people sniff and hand us different markup than other browsers. So
> we can't simply use data about what other engines have shipped to reason
> about how changes to our own engine will affect site behavior and layout.

This is a good argument that some measuring is needed in this case.

> In this case, I understand the advantage of shipping CSS 'appearance'. I'm
> less sure about what it would cost us to keep supporting -moz-appearance:
> none, perhaps indefinitely.

The cost is long-term or permanent differences between rendering
engines, which leads to extra work for Web developers and to
Web-compatibility problems for us.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
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'.

[Jet Villegas]

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 most cases.  And as Jet pointed out to me, just landing
> it and see what breaks is standard procedure for unprefixing properties:
> https://bugzilla.mozilla.org/show_bug.cgi?id=775235
>
>
That's not exactly what I said:
https://bugzilla.mozilla.org/show_bug.cgi?id=1340014#c2

Our procedure for these legacy properties has been to land the unprefixed
property, and file separate bugs for removing the prefixed version at a
later date. Bug 775235 
is really a collection of those legacy prefix removals, which tend to never
get removed at the later date unless we track them.

We have plenty of evidence that the planet requires -webkit-appearance so
we should ship that ASAP:
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/

If we need more time to evaluate the -moz-appearance removal, let's give it
the time it needs. The Microsoft Edge team has already done the work to
justify landing the unprefixed and -webkit variants.

--Jet
___
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'.

[Benjamin Smedberg]

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 to be an effective signal of web compatibility, for
the following reasons:

   - They are not distributed geographically; some geographies and
   languages are not well represented on beta, and nightly/aurora are even
   more skewed. So we could easily break a market-critical topsite in some
   geography and have little or no testing of that on beta.
   - We cannot rely on prerelease users to file bugs about issues they do
   encounter. Bugzilla is intimidating in general, and even more intimidating
   for people who don't speak English fluently. We have very little
   non-English documentation about filing a good bug. The signal that there is
   a bug might be people ceasing using Firefox, or a forum post in a
   language-specific board.
   - Even when people do file bugs, our bug handling and triage isn't fast
   enough to get these in front of the right person.

It has happened repeatedly over the past two years that we discovered
critical issues that affect websites only after we ship to release.

The two top market concerns in terms of Firefox quality are speed and web
compatibility. I'd encourage teams to measure carefully before taking known
web compatibility risk. It is not hard nowadays to add metrics (telemetry)
to measure web feature usage. Analyzing results is still harder than we
want, but it's self-service and we have training and data engineer partners
available to help you analyze data and make informed decisions.

We *know* that -moz-appearance: none has long been a webdev technique used
to unstyle various form controls [1][2][3][4]. We can also presume that
sometimes people sniff and hand us different markup than other browsers. So
we can't simply use data about what other engines have shipped to reason
about how changes to our own engine will affect site behavior and layout.

In this case, I understand the advantage of shipping CSS 'appearance'. I'm
less sure about what it would cost us to keep supporting -moz-appearance:
none, perhaps indefinitely.

--BDS

[1]
http://stackoverflow.com/questions/6787667/what-is-the-correct-moz-appearance-value-to-hide-dropdown-arrow-of-a-select
[2]
http://stackoverflow.com/questions/4457834/how-to-use-moz-appearance-to-display-a-menulist-button
[3] https://www.w3schools.com/cssref/css3_pr_appearance.asp
[4] https://gist.github.com/joaocunha/6273016



On Thu, Feb 16, 2017 at 10: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 most cases.  And as Jet pointed out to me, just landing
> it and see what breaks is standard procedure for unprefixing properties:
> https://bugzilla.mozilla.org/show_bug.cgi?id=775235
>
> Anyway, I took a quick look at some add-on usage in XUL files:
> https://dxr.mozilla.org/addons/search?q=moz-appearance+file%3A*.xul
>
> Most uses appears to be "-moz-appearance:none" which is reasonably safe
> to ignore, and can be easily amended with a "appearance:none" if needed.
>
> For other values, I installed the first four add-ons that use
> non-none values and analyzed what effect ignoring -moz-appearance
> would have.
>
> "dnsqueries":
> https://dxr.mozilla.org/addons/source/addons/11806/chrome/
> content/dnsqueries.xul#42
> The "-moz-appearance:textfield" has the effect of creating an extra
> border+padding around the input field.  This causes the control to
> have extra height making the whole toolbar have more height than
> needed.  Ignoring this -moz-appearance makes those "problems" go
> away and the toolbar and text control actually looks better (IMO).
> Also, the text control still works with no loss in function.
>
> "RDS Bar":
> https://dxr.mozilla.org/addons/source/addons/14581/chrome/
> content/dialogs/preferences/parameters/weather/window.xul#20
> https://dxr.mozilla.org/addons/source/addons/14581/chrome/
> content/rdstb.xul#3492,3525
> It appears this "weather" button is dead code, I couldn't find a way
> to enable it.
>
> "Print Edit":
> https://dxr.mozilla.org/addons/source/addons/193270/chrome/
> content/printedit-options.xul#123
>  has the effect of adding
> a chevron to the button.  Ignoring it makes it look like a standard
> color picker button (which is an improvement, IMO).
> There is no loss in function.
>
> "Smart Text"
> https://dxr.mozilla.org/addons/source/addons/161982/content/options.xul#16
> The "-moz-appearance:textfield" has the effect of creating an extra
> border+padding around the input field.  However, in this case it appears
> that the  (XHTML) element does count as a chrome sheet so there
>

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

[Mats Palmgren]

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 actually looks better
(to me).


And as Jet pointed out to me, just landing
it and see what breaks is standard procedure for unprefixing properties:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235


For addons we can do better: we can just contact them about it.  Please 
talk to :jorgev.


Will do.

FYI, Kohei-san has posted a heads-up here:
https://www.fxsitecompat.com/en-CA/docs/2017/moz-appearance-property-has-been-removed/


/Mats
___
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'.

[Boris Zbarsky]

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 unprefixing properties:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235


For addons we can do better: we can just contact them about it.  Please 
talk to :jorgev.


-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'.

[Mats Palmgren]

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 breaks is standard procedure for unprefixing properties:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235

Anyway, I took a quick look at some add-on usage in XUL files:
https://dxr.mozilla.org/addons/search?q=moz-appearance+file%3A*.xul

Most uses appears to be "-moz-appearance:none" which is reasonably safe
to ignore, and can be easily amended with a "appearance:none" if needed.

For other values, I installed the first four add-ons that use
non-none values and analyzed what effect ignoring -moz-appearance
would have.

"dnsqueries":
https://dxr.mozilla.org/addons/source/addons/11806/chrome/content/dnsqueries.xul#42
The "-moz-appearance:textfield" has the effect of creating an extra
border+padding around the input field.  This causes the control to
have extra height making the whole toolbar have more height than
needed.  Ignoring this -moz-appearance makes those "problems" go
away and the toolbar and text control actually looks better (IMO).
Also, the text control still works with no loss in function.

"RDS Bar":
https://dxr.mozilla.org/addons/source/addons/14581/chrome/content/dialogs/preferences/parameters/weather/window.xul#20
https://dxr.mozilla.org/addons/source/addons/14581/chrome/content/rdstb.xul#3492,3525
It appears this "weather" button is dead code, I couldn't find a way
to enable it.

"Print Edit":
https://dxr.mozilla.org/addons/source/addons/193270/chrome/content/printedit-options.xul#123
 has the effect of adding
a chevron to the button.  Ignoring it makes it look like a standard
color picker button (which is an improvement, IMO).
There is no loss in function.

"Smart Text"
https://dxr.mozilla.org/addons/source/addons/161982/content/options.xul#16
The "-moz-appearance:textfield" has the effect of creating an extra
border+padding around the input field.  However, in this case it appears
that the  (XHTML) element does count as a chrome sheet so there
is no change in behavior for this add-on since the -moz-appearance is
still honored.  (IMO, it would actually have looked better without it).

While this is a small sample, there were no problems detected.
To the contrary, it actually looks like an improvement IMO.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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, 段垚  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.

Why? Assume

  threat_of_flash = exploits_of_flash_per_year *
usage_of_flash_per_year

If usage_of_flash_per_year is declining but threat_of_flash is
increasing,
then exploits_of_flash_per_year must be increasing.
But the report you cited does not provide such data.

That assumption doesn't hold: malicious uses of Flash don't need

non-malicious ones.


I agree. So let me ask this question instead: is there any proof that
local-only Flash
exploits are increasing?


I don't know. I do know that legitimate usage of Flash, be it via file: or
otherwise, is steadily declining. That's all that's needed to change the
cost/benefit balance here.



In fact it seems quite likely that there'll be an inverse relationship:
less (non-malicious) usage means less testing of potentially exploitable
code paths, which would increase the threat.


I would assume Adobe will actively test Flash plugin with local contents
for a reasonablely long time. Do you mean tests in Firefox for local Flash
contents
will inevitably decrease even if you don't disable it?


What I'm saying is that testing and hardening against attacks isn't free,
so requires investing resources. This entire thread is based on the
conclusion that Flash usage has diminished to a point where it's can no
longer a good investment of resources to keep doing these activities for
this fairly niche-usage of Flash.



One solution to this is to decouple the amount of testing done for those
code paths from how frequently they're used. In practice that's not
trivial
because at least some testing comes in the form of investigating crash
reports from users. Another solution is what's proposed here: disable
less-well tested configurations altogether.


Also I think forbidding non-http(s) Flash does not fix thoses exploits

magically.

Sure, this is about reducing attack surface, not completely eliminating

it.

Non-http(s) Flash takes only a small fraction of all Flash contents,

even
for users who do use non-http(s) Flash.
I don't think users want to drop their local Flash for a small fraction
of
reduced attack surface,
especially if those local Flash don't have alternatives yet. The more
practical reaction is trying another browser.


The underlying assumption here is that these usages of Flash are rare
enough that the incompatibility, while unfortunate, becomes acceptable.
Note that other browser vendors are planning their own measures for
restricting Flash usage, too.


Although usage of local Flash is rare, I'd point out that local Flash
contents usually have higher
value than those on web sites, Because users only save important contents
to disks.
Additionally, local Flash contents are much harder to replace than those
on web sites
because users can hardly contact the author. Please consider more for
users.


We are doing precisely that, but we believe that our users are better
served by us investing resources in tasks that have more impact. Again, the
underlying assumption in this entire thread is that our users won't be
affected as strongly as you assume, or few enough will.
___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[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 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.

 Why? Assume
>>>
>>>  threat_of_flash = exploits_of_flash_per_year *
>>> usage_of_flash_per_year
>>>
>>> If usage_of_flash_per_year is declining but threat_of_flash is
>>> increasing,
>>> then exploits_of_flash_per_year must be increasing.
>>> But the report you cited does not provide such data.
>>>
>>> That assumption doesn't hold: malicious uses of Flash don't need
>> non-malicious ones.
>>
> I agree. So let me ask this question instead: is there any proof that
> local-only Flash
> exploits are increasing?
>

I don't know. I do know that legitimate usage of Flash, be it via file: or
otherwise, is steadily declining. That's all that's needed to change the
cost/benefit balance here.


>
>> In fact it seems quite likely that there'll be an inverse relationship:
>> less (non-malicious) usage means less testing of potentially exploitable
>> code paths, which would increase the threat.
>>
>
> I would assume Adobe will actively test Flash plugin with local contents
> for a reasonablely long time. Do you mean tests in Firefox for local Flash
> contents
> will inevitably decrease even if you don't disable it?
>

What I'm saying is that testing and hardening against attacks isn't free,
so requires investing resources. This entire thread is based on the
conclusion that Flash usage has diminished to a point where it's can no
longer a good investment of resources to keep doing these activities for
this fairly niche-usage of Flash.


>
>> One solution to this is to decouple the amount of testing done for those
>> code paths from how frequently they're used. In practice that's not
>> trivial
>> because at least some testing comes in the form of investigating crash
>> reports from users. Another solution is what's proposed here: disable
>> less-well tested configurations altogether.
>>
>>>
>>> Also I think forbidding non-http(s) Flash does not fix thoses exploits

> magically.
>
> Sure, this is about reducing attack surface, not completely eliminating
 it.

 Non-http(s) Flash takes only a small fraction of all Flash contents,
>>> even
>>> for users who do use non-http(s) Flash.
>>> I don't think users want to drop their local Flash for a small fraction
>>> of
>>> reduced attack surface,
>>> especially if those local Flash don't have alternatives yet. The more
>>> practical reaction is trying another browser.
>>>
>>
>> The underlying assumption here is that these usages of Flash are rare
>> enough that the incompatibility, while unfortunate, becomes acceptable.
>> Note that other browser vendors are planning their own measures for
>> restricting Flash usage, too.
>>
>
> Although usage of local Flash is rare, I'd point out that local Flash
> contents usually have higher
> value than those on web sites, Because users only save important contents
> to disks.
> Additionally, local Flash contents are much harder to replace than those
> on web sites
> because users can hardly contact the author. Please consider more for
> users.
>

We are doing precisely that, but we believe that our users are better
served by us investing resources in tasks that have more impact. Again, the
underlying assumption in this entire thread is that our users won't be
affected as strongly as you assume, or few enough will.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 of Flash.  This is demonstrably not true.


Why? Assume

 threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year

If usage_of_flash_per_year is declining but threat_of_flash is increasing,
then exploits_of_flash_per_year must be increasing.
But the report you cited does not provide such data.


That assumption doesn't hold: malicious uses of Flash don't need
non-malicious ones.
I agree. So let me ask this question instead: is there any proof that 
local-only Flash

exploits are increasing?



In fact it seems quite likely that there'll be an inverse relationship:
less (non-malicious) usage means less testing of potentially exploitable
code paths, which would increase the threat.


I would assume Adobe will actively test Flash plugin with local contents
for a reasonablely long time. Do you mean tests in Firefox for local 
Flash contents

will inevitably decrease even if you don't disable it?



One solution to this is to decouple the amount of testing done for those
code paths from how frequently they're used. In practice that's not trivial
because at least some testing comes in the form of investigating crash
reports from users. Another solution is what's proposed here: disable
less-well tested configurations altogether.



Also I think forbidding non-http(s) Flash does not fix thoses exploits

magically.


Sure, this is about reducing attack surface, not completely eliminating
it.


Non-http(s) Flash takes only a small fraction of all Flash contents, even
for users who do use non-http(s) Flash.
I don't think users want to drop their local Flash for a small fraction of
reduced attack surface,
especially if those local Flash don't have alternatives yet. The more
practical reaction is trying another browser.


The underlying assumption here is that these usages of Flash are rare
enough that the incompatibility, while unfortunate, becomes acceptable.
Note that other browser vendors are planning their own measures for
restricting Flash usage, too.


Although usage of local Flash is rare, I'd point out that local Flash 
contents usually have higher
value than those on web sites, Because users only save important 
contents to disks.
Additionally, local Flash contents are much harder to replace than those 
on web sites

because users can hardly contact the author. Please consider more for users.



I understand that none of this helps you, and that's very unfortunate. I
hope you appreciate that we don't have infinite resources and thus have to
make, sometimes painful, trade-offs. Much as you probably have to in your
own projects.
___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[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 demonstrably not true.
>>
>
> Why? Assume
>
> threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year
>
> If usage_of_flash_per_year is declining but threat_of_flash is increasing,
> then exploits_of_flash_per_year must be increasing.
> But the report you cited does not provide such data.
>

That assumption doesn't hold: malicious uses of Flash don't need
non-malicious ones.

In fact it seems quite likely that there'll be an inverse relationship:
less (non-malicious) usage means less testing of potentially exploitable
code paths, which would increase the threat.

One solution to this is to decouple the amount of testing done for those
code paths from how frequently they're used. In practice that's not trivial
because at least some testing comes in the form of investigating crash
reports from users. Another solution is what's proposed here: disable
less-well tested configurations altogether.

>
>
>> Also I think forbidding non-http(s) Flash does not fix thoses exploits
>>> magically.
>>>
>> Sure, this is about reducing attack surface, not completely eliminating
>> it.
>>
>
> Non-http(s) Flash takes only a small fraction of all Flash contents, even
> for users who do use non-http(s) Flash.
> I don't think users want to drop their local Flash for a small fraction of
> reduced attack surface,
> especially if those local Flash don't have alternatives yet. The more
> practical reaction is trying another browser.


The underlying assumption here is that these usages of Flash are rare
enough that the incompatibility, while unfortunate, becomes acceptable.
Note that other browser vendors are planning their own measures for
restricting Flash usage, too.

I understand that none of this helps you, and that's very unfortunate. I
hope you appreciate that we don't have infinite resources and thus have to
make, sometimes painful, trade-offs. Much as you probably have to in your
own projects.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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, 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 anyone
testing or
defending this effectively.

So we believe that there is significant harm in the current
situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A
malicious flash applet open opened from file:// can read the user's
profile, take all their saved passwords, cookies, etc and steal data,
masquerade as them, and perform all manner of malicious activity.

I agree that this is a problem, but I disagree that Firefox must remove
this behavior now.

* This behavior has existed for decades in all desktop browsers, and the
usage of Flash is declining, which means the threaten is also declining.

That is not true.  It is public knowledge that Flash exploits are traded
as a commodity these days:
.


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.


Why? Assume

threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year

If usage_of_flash_per_year is declining but threat_of_flash is 
increasing, then exploits_of_flash_per_year must be increasing.

But the report you cited does not provide such data.




Also I think forbidding non-http(s) Flash does not fix thoses exploits
magically.

Sure, this is about reducing attack surface, not completely eliminating it.


Non-http(s) Flash takes only a small fraction of all Flash contents, 
even for users who do use non-http(s) Flash.
I don't think users want to drop their local Flash for a small fraction 
of reduced attack surface,
especially if those local Flash don't have alternatives yet. The more 
practical reaction is trying another browser.



___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[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, 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 anyone
> testing or
> defending this effectively.
>
> So we believe that there is significant harm in the current
> situation, and
> very little upside.
 I think #1 is sufficient to remove this behavior, even ignoring #2. A
 malicious flash applet open opened from file:// can read the user's
 profile, take all their saved passwords, cookies, etc and steal data,
 masquerade as them, and perform all manner of malicious activity.
>>> I agree that this is a problem, but I disagree that Firefox must remove
>>> this behavior now.
>>>
>>> * This behavior has existed for decades in all desktop browsers, and the
>>> usage of Flash is declining, which means the threaten is also declining.
>> That is not true.  It is public knowledge that Flash exploits are traded
>> as a commodity these days:
>> .
>>
> 
> 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.

> Also I think forbidding non-http(s) Flash does not fix thoses exploits
> magically.

Sure, this is about reducing attack surface, not completely eliminating it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 "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 anyone testing or
defending this effectively.

So we believe that there is significant harm in the current
situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A
malicious flash applet open opened from file:// can read the user's
profile, take all their saved passwords, cookies, etc and steal data,
masquerade as them, and perform all manner of malicious activity.

I agree that this is a problem, but I disagree that Firefox must remove
this behavior now.

* This behavior has existed for decades in all desktop browsers, and the
usage of Flash is declining, which means the threaten is also declining.

That is not true.  It is public knowledge that Flash exploits are traded
as a commodity these days:
.


I guess all popular softwares have exploits being traded. How this fact 
invalidates my argument?
Also I think forbidding non-http(s) Flash does not fix thoses exploits 
magically.



___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[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 "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 anyone testing or
>>> defending this effectively.
>>>
>>> So we believe that there is significant harm in the current
>>> situation, and
>>> very little upside.
>> I think #1 is sufficient to remove this behavior, even ignoring #2. A
>> malicious flash applet open opened from file:// can read the user's
>> profile, take all their saved passwords, cookies, etc and steal data,
>> masquerade as them, and perform all manner of malicious activity.
> 
> I agree that this is a problem, but I disagree that Firefox must remove
> this behavior now.
> 
> * This behavior has existed for decades in all desktop browsers, and the
> usage of Flash is declining, which means the threaten is also declining.

That is not true.  It is public knowledge that Flash exploits are traded
as a commodity these days:
.
___
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'.

[Boris Zbarsky]

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 purposes of this discussion are sheets whose URI 
starts with "chrome://".


The biggest worry for me is that inline style is never a "chrome sheet" 
in this sense.


-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'.

[Mats Palmgren]

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 doesn't say if that
rule also contains -webkit-appearance / appearance (which is what is
recommended).

So what we did was to look at CSS rules in projects in github, e.g.
https://github.com/search?l=CSS&utf8=%E2%9C%93&q=-webkit-appearance+none&type=Code&ref=searchresults
which makes it quite clear that dropping -moz-appearance in favor of
-webkit-appearance will improve web compat (if we assume these projects
are somewhat representative of the web).

Also note that any failure probably isn't catastrophic.  Say there is
a rule with only -moz-appearance:none, that form control will now
render using the native theme styling instead of the author's style.
(In some cases -moz-appearance:none isn't even needed, since just
setting a border/background turns off the theme anyway.)
So the control should still be visible and usable.

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.)

So I'm not too worried about dropping -moz-appearance.
I think the risk comes mostly from starting to honor rules that only have
-webkit-appearance:none in case that would make the control invisible
or ugly because of incompatibilities in other properties.  I think that
risk is fairly low though.  And Edge did this before us so there's some
evidence it works fine.


/Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 high-risk attack surface: if you can get somebody to download
a SWF they can probably own your system. We don't have anyone testing or
defending this effectively.

So we believe that there is significant harm in the current situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A malicious 
flash applet open opened from file:// can read the user's profile, take all 
their saved passwords, cookies, etc and steal data, masquerade as them, and 
perform all manner of malicious activity.


I agree that this is a problem, but I disagree that Firefox must remove 
this behavior now.


* This behavior has existed for decades in all desktop browsers, and the 
usage of Flash is declining, which means the threaten is also declining.

So I don't see the reason for an immediate removal.

* Flash plugin is still actively maintained by Adobe, so I think you can 
ask them to restrict permissions for local Flash contents.

This would benifit all browsers, not just Firefox.



-tom
___
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 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 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.

Well, this plan seems too aggressive. I'd rather recommend implementing

"click to play" for non-http(s) Flash first and deferring complete removal.

IE requires user's confirmation to load local Flash for a long time.


We are planning on making Flash click-to-play by default for all content.
However, our implementation of click-to-play is based on remembering that
setting per site. This implementation does not work with file: URIs and the
engineering and QA effort to make it work is well beyond what we think is a
reasonable investment.


I think it is OK to not remember that setting for file-urls - just 
require confirmation on each reload.

Is this simpler to implementation?


Flash is a dying technology and this is one low-cost
way we can reduce attack surface and make users safer.

--BDS
___
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 implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Justin Dolske]

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 been considered. Otherwise yay for removing
this from the web. :)

Justin

On Fri, Feb 10, 2017 at 2:27 PM, Mats Palmgren  wrote:

> 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) makes an element have its default appearance.  We are
> currently shipping '-moz-appearance' with a large number of other values,
> such as 'button', 'range', 'radio' etc.  '-moz-appearance' will continue to
> work exactly as is, but will now be restricted to UA and chrome style
> sheets, i.e. it will *not* be available to web content.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333482
>
> Spec: https://drafts.csswg.org/css-ui-4/#appearance-switching
>
> Platfrom coverage: All
>
> Estimated release: 54 (tentatively)
>
> Preferences: layout.css.appearance.enabled for
> 'appearance'/'-webkit-appearance' (enabled by default),
> layout.css.moz-appearance.enabled for '-moz-appearance' (disabled by
> default).  All these properties are available to UA and chrome style sheets
> though, regardless of the preference settings.
>
> Devtools bug: None needed, I think.
>
> Status in other implementations: No other UA implements the unprefixed
> 'appearance' as far as I know.  Edge implements '-webkit-appearance:none'
> but no other values, nor do they implement it unprefixed.  WebKit/Blink
> implements '-webkit-appearance' with a plethora of values, much like we
> currently do for '-moz-appearance'.  I don't know what their plans are for
> 'appearance' and/or restricting the number of supported values.
>
> I think the fact that Edge currently only ships '-webkit-appearance:none'
> proves that's all that is needed for web compat.  I tend to think we should
> also implement the unprefixed property though, because that's what the CSS
> spec says and I don't think it'll have any negative impact in terms of web
> compat (I admit I'm not 100% certain of that though, but we can adjust as
> needed).
>
> Tests: Reftests and mochitests included.
> ___
> 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 implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Tantek Çelik]

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 divergence among implementations)

It was subsequently moved to CSS UI level 4, simplified to two values,
'auto' and 'none':
* https://drafts.csswg.org/css-ui-4/#appearance-switching

Thus this is an intent for the complete implementation of the latest
'appearance' property as specified in css-ui-4.

Though not (currently) in a CR, this property and those two values in
particular have been unchanged for years, and their definitions can be
considered stable.

Thanks,

Tantek



On Fri, Feb 10, 2017 at 2:27 PM, Mats Palmgren  wrote:
> 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) makes an element have its default appearance.  We are currently
> shipping '-moz-appearance' with a large number of other values, such as
> 'button', 'range', 'radio' etc.  '-moz-appearance' will continue to work
> exactly as is, but will now be restricted to UA and chrome style sheets,
> i.e. it will *not* be available to web content.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333482
>
> Spec: https://drafts.csswg.org/css-ui-4/#appearance-switching
>
> Platfrom coverage: All
>
> Estimated release: 54 (tentatively)
>
> Preferences: layout.css.appearance.enabled for
> 'appearance'/'-webkit-appearance' (enabled by default),
> layout.css.moz-appearance.enabled for '-moz-appearance' (disabled by
> default).  All these properties are available to UA and chrome style sheets
> though, regardless of the preference settings.
>
> Devtools bug: None needed, I think.
>
> Status in other implementations: No other UA implements the unprefixed
> 'appearance' as far as I know.  Edge implements '-webkit-appearance:none'
> but no other values, nor do they implement it unprefixed.  WebKit/Blink
> implements '-webkit-appearance' with a plethora of values, much like we
> currently do for '-moz-appearance'.  I don't know what their plans are for
> 'appearance' and/or restricting the number of supported values.
>
> I think the fact that Edge currently only ships '-webkit-appearance:none'
> proves that's all that is needed for web compat.  I tend to think we should
> also implement the unprefixed property though, because that's what the CSS
> spec says and I don't think it'll have any negative impact in terms of web
> compat (I admit I'm not 100% certain of that though, but we can adjust as
> needed).
>
> Tests: Reftests and mochitests included.
> ___
> 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 implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Mats Palmgren]

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) makes an element have its default appearance.  We are 
currently shipping '-moz-appearance' with a large number of other values, 
such as 'button', 'range', 'radio' etc.  '-moz-appearance' will continue 
to work exactly as is, but will now be restricted to UA and chrome style 
sheets, i.e. it will *not* be available to web content.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333482

Spec: https://drafts.csswg.org/css-ui-4/#appearance-switching

Platfrom coverage: All

Estimated release: 54 (tentatively)

Preferences: layout.css.appearance.enabled for 
'appearance'/'-webkit-appearance' (enabled by default), 
layout.css.moz-appearance.enabled for '-moz-appearance' (disabled by 
default).  All these properties are available to UA and chrome style 
sheets though, regardless of the preference settings.


Devtools bug: None needed, I think.

Status in other implementations: No other UA implements the unprefixed 
'appearance' as far as I know.  Edge implements '-webkit-appearance:none' 
but no other values, nor do they implement it unprefixed.  WebKit/Blink 
implements '-webkit-appearance' with a plethora of values, much like we 
currently do for '-moz-appearance'.  I don't know what their plans are for 
'appearance' and/or restricting the number of supported values.


I think the fact that Edge currently only ships '-webkit-appearance:none' 
proves that's all that is needed for web compat.  I tend to think we 
should also implement the unprefixed property though, because that's what 
the CSS spec says and I don't think it'll have any negative impact in 
terms of web compat (I admit I'm not 100% certain of that though, but we 
can adjust as needed).


Tests: Reftests and mochitests included.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[tom]

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 can get somebody to download
> a SWF they can probably own your system. We don't have anyone testing or
> defending this effectively.
> 
> So we believe that there is significant harm in the current situation, and
> very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A malicious 
flash applet open opened from file:// can read the user's profile, take all 
their saved passwords, cookies, etc and steal data, masquerade as them, and 
perform all manner of malicious activity.

-tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 is completely disabling this content.
>>
>>
>> Can users get back old behavior by flipping a preference?
>>>
>>> That is not the plan, no.
>>
>> Well, this plan seems too aggressive. I'd rather recommend implementing
> "click to play" for non-http(s) Flash first and deferring complete removal.
>
> IE requires user's confirmation to load local Flash for a long time.
>

We are planning on making Flash click-to-play by default for all content.
However, our implementation of click-to-play is based on remembering that
setting per site. This implementation does not work with file: URIs and the
engineering and QA effort to make it work is well beyond what we think is a
reasonable investment. Flash is a dying technology and this is one low-cost
way we can reduce attack surface and make users safer.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 anyone testing or
defending this effectively.

So we believe that there is significant harm in the current situation, and
very little upside.

--BDS

On Thu, Feb 9, 2017 at 7:09 PM, 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 loading Flash files, but their hotkeys
> > > tend to conflict).
> >
> > It will prevent them from loading via File > Open, yes (and that is the
> > fundamental change we need to make). If you were to serve them via
> > localhost you could still use them (e.g. with python -m
> > SimpleHTTPServer).
>
> I kind of disagree with this. SimpleHTTPServer is simple for developers
> but not at all for normal users. I think it should be allowed to load a
> top level Flash file. What harm could it do if we allow that?
>
> - Xidorn
> ___
> 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 implement and ship: only allow Flash on HTTP/HTTPS sites

[Frederik Braun]

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 loading Flash files, but their hotkeys
>>> tend to conflict).
>>
>> It will prevent them from loading via File > Open, yes (and that is the
>> fundamental change we need to make). If you were to serve them via
>> localhost you could still use them (e.g. with python -m
>> SimpleHTTPServer).
> 
> I kind of disagree with this. SimpleHTTPServer is simple for developers
> but not at all for normal users. I think it should be allowed to load a
> top level Flash file. What harm could it do if we allow that?
> 

toplevel loads includes opened via window.open and target=_blank, no?

This means HTML/JS from file:, ftp: etc. could still find a way to open
SWF from those non-HTTP/HTTPs sites.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: animationcancel event

[Mantaroh Yoshinaga]

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 animationend event.

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1302648

Link to standard:
https://drafts.csswg.org/css-animations/#eventdef-
animationevent-animationcancel

Platform coverage:
All platforms

Estimated or target release:
Firefox 54

Preference behind which this will be implemented:
No pref

DevTools bug:
No special Devtools handling required.

Do other browser engines implement this?
No.
Blink has a bug on file for implementing transitioncancel[1] which
is marked "Hotlist-Interop" and we expect they will implement
animationcancel at roughly same time.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=642487

Tests:
The working-in-progress patch include tests in web-platform-tests
(testharness.js) format. However, we are still waiting for the CSSWG to
merge their test repository into web-platform-tests before submitting
them there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 behavior by flipping a preference?


That is not the plan, no.

Well, this plan seems too aggressive. I'd rather recommend implementing 
"click to play" for non-http(s) Flash first and deferring complete removal.


IE requires user's confirmation to load local Flash for a long time.


We have developed a Firefox based tool to edit/view local EPub files,
which may contain Flash.

If this feature can't be opt-out , we and our customs will be in trouble.


My mind is filled with questions about how epub+Flash could ever be a good
idea, but I will avoid asking them here.
Epub+Flash is not quite a good idea, it is just because our Flash assets 
can't be replaced in a short term.



Instead, could you work around
this by serving the content and loading it from http://localhost ? That is
what we intend to recommend for developers building Flash websites and
wanting to test locally.
Local http server could trigger security alarm of OS/firewall, which 
confuses users: why a desktop app want to start a server?


Also local http server may be more insecure than direct file access, 
e.g. misconfigured or flawed server may allow

anyone on the net to access your files. So I'd rather not head to this way.


Otherwise, you will have to build your own builds with this restriction
removed.

--BDS
___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[Xidorn Quan]

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 to conflict).
> 
> It will prevent them from loading via File > Open, yes (and that is the
> fundamental change we need to make). If you were to serve them via
> localhost you could still use them (e.g. with python -m
> SimpleHTTPServer).

I kind of disagree with this. SimpleHTTPServer is simple for developers
but not at all for normal users. I think it should be allowed to load a
top level Flash file. What harm could it do if we allow that?

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: self.origin

[Boris Zbarsky]

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/testharness.js/pull/242 and 
https://github.com/w3c/testharness.js/pull/241 too (included in those 
patches).


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.origin

[Boris Zbarsky]

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 document.origin from 
the spec?


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 security and limit Flash to well-tested
>> configuraitons.
>>
>
> Do you want to also block Flash content from loading file: or ftp: URLs?
>

That is not part of this bug. I will consult with Adobe and see whether
that is likely to break anything, and perhaps propose it as a separate
change.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 (and that is the
fundamental change we need to make). If you were to serve them via
localhost you could still use them (e.g. with python -m SimpleHTTPServer).

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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 preference?
>

That is not the plan, no.


>
> We have developed a Firefox based tool to edit/view local EPub files,
> which may contain Flash.
>
> If this feature can't be opt-out , we and our customs will be in trouble.
>

My mind is filled with questions about how epub+Flash could ever be a good
idea, but I will avoid asking them here. Instead, could you work around
this by serving the content and loading it from http://localhost ? That is
what we intend to recommend for developers building Flash websites and
wanting to test locally.

Otherwise, you will have to build your own builds with this restriction
removed.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.origin

[Boris Zbarsky]

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 in 
a reasonably short timeframe.  ;)



It seems like we want to encourage folks to use `self.origin` going forward...


I agree.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: self.origin

[Boris Zbarsky]

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 actual origin of the global, not the origin of the URL 
it's loaded from.  The difference can be substantial in the case of 
sandboxing, for example.


In the window case, this returns the same thing as self.document.origin 
if document.origin is also implemented.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1306170

Spec: https://html.spec.whatwg.org/multipage/webappapis.html#dom-origin

Platfrom coverage: All

Estimated release: 54

Preference: none.

Devtools bug: None needed, I think.

Status in other implementations: no one else implements this yet.  I am 
not aware of either WebKit or Blink bugs to implement this either.  I 
just filed https://bugs.webkit.org/show_bug.cgi?id=168023 and 
https://bugs.chromium.org/p/chromium/issues/detail?id=690195 bug have no 
idea whether they will actually pick them up.


Tests: I will make sure there are some.  ;)

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform