Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[Boris Zbarsky]

On 3/21/17 7:18 PM, zbranie...@mozilla.com wrote:

Is there a reason we should use RegisterCallback over AddStrongObserver?


It doesn't require creating a separate object to act as an observer.  Of 
course it creates one under the hood for you, so this is mostly a matter 
of whether calling code ends up simpler or not, not of efficiency.



I have a fresh API where I'm using AddStrongObserver at the moment, but would 
be happy to switch if that will be cheaper / more future-compatible.


Are you properly handling the fact that AddStrongObserver watches all 
prefs starting with the prefix you pass it?  ;)


-Boris

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

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[Boris Zbarsky]

On 3/21/17 4:34 PM, Eric Rahm wrote:

This doesn't affect the behavior of |Preferences::AddStrongObserver| which
does prefix matching, correct?


That's correct.  Same for AddWeakObserver.

It's a little harder to misuse because it doesn't have a closure arg (so 
you can't just associate the totally wrong value with the closure in 
some way, which was the main failure mode for RegisterCallback).


But just for fun, start a debug build, open "about:config", create a new 
preference called "intl.accept_languages_are_confusing" with any value 
you want, and watch the nice MOZ_ASSERT failure in 
nsGlobalWindow::Observe on this line:


MOZ_ASSERT(!NS_strcmp(aData, u"intl.accept_languages"));

So maybe we should push the exact/prefix match business down into the 
pref observer API.  :(


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

Re: Please do NOT hand-edit web platform test MANIFEST.json files

[Boris Zbarsky]

On 3/21/17 6:41 PM, Jeff Gilbert wrote:

JSON allows comments if all the JSON processors we use handle comments. :)


JSON.parse in JS does not.

The Python "json" module does not as far as I can tell.

What JSON processors are you thinking of?

-Boris

P.S.  The Python "json" module is most relevant here, since it's the 
thing actually being used to deal with MANIFEST.json.

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

Re:

[jessi3py]

On Wednesday, March 22, 2017 at 7:31:11 AM UTC+8, Karl Dubost wrote:
> Eric,
> 
> Le 21 mars 2017 à 23:38, Eric Shepherd  a écrit :
> > We’re updating the  element’s documentation to not suck (yay!)
> 
> Thanks!
> 
> Test: http://codepen.io/webcompat/pen/bqvarY (datetime, datetime-local)
> Results: http://imgur.com/a/q9cNr (Gecko, Blink, WebKit)
> 
> Summary: only Blink provides (as of now) a datetime-local type with a 
> specific UI.
>  
> Comment 93 gives plenty of followup bugs for the future of this input.
> https://bugzilla.mozilla.org/show_bug.cgi?id=825294#c93
> 
> 
> -- 
> Karl Dubost, mozilla  Webcompat
> http://www.la-grange.net/karl/moz

WHATWG has dropped support for input type=datetime [1] in favor of using 
type=datetime-local with a separate drop-down for the time zone (or some 
similar UI). W3C still has concerns about input type=datetime-local [2], thou 
I'm not sure what the final consensus is.

As for browser support, Chrome, Opera, and Microsoft Edge support 
type=datetime-local but not type=datetime. Firefox supports 
type=datetime-local, but it is under the pref "dom.forms.datetime.others", and 
has no specific UI for it yet (it's just a normal text box). A detailed plan 
for shipping each of the date/time input types with specific UI in Firefox can 
be found here [3].


[1] https://github.com/whatwg/html/issues/336
[2] https://lists.w3.org/Archives/Public/public-html/2014Feb/0003.html
[3] https://wiki.mozilla.org/TPE_DOM/Date_time_input_types#Roadmap
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re:

[Karl Dubost]

Eric,

Le 21 mars 2017 à 23:38, Eric Shepherd  a écrit :
> We’re updating the  element’s documentation to not suck (yay!)

Thanks!

Test: http://codepen.io/webcompat/pen/bqvarY (datetime, datetime-local)
Results: http://imgur.com/a/q9cNr (Gecko, Blink, WebKit)

Summary: only Blink provides (as of now) a datetime-local type with a specific 
UI.
 
Comment 93 gives plenty of followup bugs for the future of this input.
https://bugzilla.mozilla.org/show_bug.cgi?id=825294#c93


-- 
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: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[zbraniecki]

Is there a reason we should use RegisterCallback over AddStrongObserver?

I have a fresh API where I'm using AddStrongObserver at the moment, but would 
be happy to switch if that will be cheaper / more future-compatible.

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

Re: Please do NOT hand-edit web platform test MANIFEST.json files

[Jeff Gilbert]

JSON allows comments if all the JSON processors we use handle comments. :)

On Tue, Mar 21, 2017 at 8:52 AM, James Graham  wrote:
> On 20/03/17 22:15, gsquel...@mozilla.com wrote:
>
>> Sorry if it's a silly suggestion:
>> Could the current tool insert some helpful reminders *everywhere* in the
>> generated file (so it's can't be missed)?
>> E.g., every 2nd line would read: "// PSA: This file is auto-generated by
>> ./mach wpt-manifest-update, please don't edit!" ;-)
>
>
> It is of course possible but it's not trivial since JSON doesn't allow
> comments, so there would have to be some preprocessing magic and so on.
> Probably better to spend the time on a good solution.
>
>
> ___
> 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: The future of commit access policy for core Firefox

[Gregory Szorc]

On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor  wrote:

> (please direct followups to dev-planning, cross-posting to governance,
> firefox-dev, dev-platform)
>
>
> Nearly 19 years after the creation of the Mozilla Project, commit access
> remains essentially the same as it has always been.  We've evolved the
> vouching process a number of times, CVS has long since been replaced by
> Mercurial & others, and we've taken some positive steps in terms of
> securing the commit process.  And yet we've never touched the core idea of
> granting developers direct commit access to our most important
> repositories.  After a large number of discussions since taking ownership
> over commit policy, I believe it is time for Mozilla to change that
> practice.
>
> Before I get into the meat of the current proposal, I would like to
> outline a set of key goals for any change we make.  These goals have been
> informed by a set of stakeholders from across the project including the
> engineering, security, release and QA teams.  It's inevitable that any
> significant change will disrupt longstanding workflows.  As a result, it is
> critical that we are all aligned on the goals of the change.
>
>
> I've identified the following goals as critical for a responsible commit
> access policy:
>
>- Compromising a single individual's credentials must not be
>sufficient to land malicious code into our products.
>- Two-factor auth must be a requirement for all users approving or
>pushing a change.
>- The change that gets pushed must be the same change that was
>approved.
>- Broken commits must be rejected automatically as a part of the
>commit process.
>
>
> In order to achieve these goals, I propose that we commit to making the
> following changes to all Firefox product repositories:
>
>- Direct commit access to repositories will be strictly limited to
>sheriffs and a subset of release engineering.
>   - Any direct commits by these individuals will be limited to fixing
>   bustage that automation misses and handling branch merges.
>- All other changes will go through an autoland-based workflow.
>   - Developers commit to a staging repository, with scripting that
>   connects the changeset to a Bugzilla attachment, and integrates with 
> review
>   flags.
>   - Reviewers and any other approvers interact with the changeset as
>   today (including ReviewBoard if preferred), with Bugzilla flags as the
>   canonical source of truth.
>   - Upon approval, the changeset will be pushed into autoland.
>   - If the push is successful, the change is merged to
>   mozilla-central, and the bug updated.
>
> I know this is a major change in practice from how we currently operate,
> and my ask is that we work together to understand the impact and concerns.
> If you find yourself disagreeing with the goals, let's have that discussion
> instead of arguing about the solution.  If you agree with the goals, but
> not the solution, I'd love to hear alternative ideas for how we can achieve
> the outcomes outlined above.
>

(Responding to several topics from the top post because I don't want to
spam with multiple replies.)

I think a lot of people are conflating "push access" with "ability to land
something." The distinction is the former grants you privileges to `hg
push` directly to repos on hg.mozilla.org and the latter allows delegation
of this ability. It is easy to conflate them because today "push access"
(level 3) gives you permission to trigger the landing (via the autoland
service via MozReview). But this is only because it was convenient to
implement this way. I want to explicitly state that we're moving towards
N=~10 people having raw push access to the Firefox repos with the majority
of landings occurring via autoland (via Conduit via MozReview/Bugzilla).
This reduces our attack surface area (less exposure to compromised SSH
keys), establishes better auditing (history of change will be on
Bugzilla/MozReview and not on a random local machine), eliminates potential
for bugs or variance with incorrect rebasing done on local machines, and
allows us to do extra things as part of the landing/rebase, such as
automatically reformat code to match unified code styles, do binding
generation, etc. They say all problems in computer science can be solved by
another level of indirection. Deferred landing (autoland) is such an
indirection and it solves a lot of problems. It will be happening. Most of
us will lose access to push directly to the Firefox repos. We won't be
losing ability to initiate a push, however. For the record, I'm not in
favor of making this change until the tooling is such that it won't be a
significant workflow/productivity regression. This is a reason why it
hasn't been made yet.

A handful have commented on whether a rebase invalidates a previous r+.
This is a difficult topic. Strictly speaking, a rebase invalidates
everything because a 

Re: Revocation protocol idea

[Eric Rescorla]

There seem to be three basic ideas here:

0. Blacklisting at the level of API rather than site.
1. Some centralized but democratic  mechanism for building a list of
misbehaving sites.
2. A mechanism for distributing the list of misbehaving sites to clients.

As Jonathan notes, Firefox already has a mechanism for doing #2, which is
to say
"Safe Browsing". Now, Safe Browsing is binary, either a site is good or
bad, but
specific APIs aren't disabled, but it's easy to see how you would extend it
to that
if you actually wanted to provide that function. I'm not sure that's
actually
very attractive--it's hard enough for users to understand safe browsing.
Safe
Browsing is of course centralized, but that comes with a number of
advantages
and it's not clear what the advantage of decentralized blacklist
dissemination
is, given the networking realities.

You posit a mechanism for forming the list of misbehaving sites, but
distributed
reputation is really hard, and it's not clear that Google is actually doing
a bad
job of running Safe Browsing, so given that this is a fairly major unsolved
problem,
I'd be reluctant to set out to build a mechanism like this without a pretty
clear
design.

-Ekr







On Tue, Mar 21, 2017 at 2:40 PM, Salvador de la Puente <
sdelapue...@mozilla.com> wrote:

> Hi Jonathan
>
> In the short and medium terms, it scales better than a white list and

distributes the effort of finding APIs misuses. Mozilla and other vendor
> browser could still review the code of the site and add its vote in favour
> or against the Web property.
>
> In the long term, the system would help finding new security threats such a
> tracking or fingerprinting algorithms by encouraging the honest report of
> evidences, somehow.
>
> With this system, the threat is considered the result of both potential
> risk and chances of actual misuse. The revocation protocol reduces
> threatening situations by minimising the number of Web properties abusing
> the APIs.
>
> As a side effect, it provides the infrastructure for a real distributed and
> cross browser database which can be of utility for other unforeseen uses.
>
> What do you think?
>
>
> El 8 mar. 2017 10:54 p. m., "Jonathan Kingston" 
> escribió:
>
> Hey,
> What would be the advantage of using this over the safesite list? Obviously
> there would be less broken sites on the web as we would be permitting the
> site to still be viewed by the user rather than just revoking the
> permission but are there other advantages?
>
> On Sun, Mar 5, 2017 at 4:23 PM, Salvador de la Puente <
> sdelapue...@mozilla.com> wrote:
>
> > Hi, folks.
> >
> > Some time ago, I've started to think about an idea to experiment with new
> > powerful Web APIs: a sort of "deceptive site" database for harmful uses
> of
> > browsers APIs. I've been curating that idea and come up with the concept
> of
> > a "revocation protocol" to revoke user granted permissions for origins
> > abusing those APIs.
> >
> > I published the idea on GitHub [1] and I was wondering about the utility
> > and feasibility of such a system so I would thank any feedback you want
> to
> > provide.
> >
> > I hope it will be of interest for you.
> >
> > [1] https://github.com/delapuente/revocation-protocol
> >
> > --
> > 
> > ___
> > 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: Revocation protocol idea

[Salvador de la Puente]

Hi Jonathan

In the short and medium terms, it scales better than a white list and
distributes the effort of finding APIs misuses. Mozilla and other vendor
browser could still review the code of the site and add its vote in favour
or against the Web property.

In the long term, the system would help finding new security threats such a
tracking or fingerprinting algorithms by encouraging the honest report of
evidences, somehow.

With this system, the threat is considered the result of both potential
risk and chances of actual misuse. The revocation protocol reduces
threatening situations by minimising the number of Web properties abusing
the APIs.

As a side effect, it provides the infrastructure for a real distributed and
cross browser database which can be of utility for other unforeseen uses.

What do you think?


El 8 mar. 2017 10:54 p. m., "Jonathan Kingston" 
escribió:

Hey,
What would be the advantage of using this over the safesite list? Obviously
there would be less broken sites on the web as we would be permitting the
site to still be viewed by the user rather than just revoking the
permission but are there other advantages?

On Sun, Mar 5, 2017 at 4:23 PM, Salvador de la Puente <
sdelapue...@mozilla.com> wrote:

> Hi, folks.
>
> Some time ago, I've started to think about an idea to experiment with new
> powerful Web APIs: a sort of "deceptive site" database for harmful uses of
> browsers APIs. I've been curating that idea and come up with the concept of
> a "revocation protocol" to revoke user granted permissions for origins
> abusing those APIs.
>
> I published the idea on GitHub [1] and I was wondering about the utility
> and feasibility of such a system so I would thank any feedback you want to
> provide.
>
> I hope it will be of interest for you.
>
> [1] https://github.com/delapuente/revocation-protocol
>
> --
> 
> ___
> 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: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[Eric Rahm]

This doesn't affect the behavior of |Preferences::AddStrongObserver| which
does prefix matching, correct?

-e

On Tue, Mar 21, 2017 at 12:07 PM, Boris Zbarsky  wrote:

> I have just landed a change[1] which changes 
> Preferences::RegisterCallback/RegisterCallbackAndCall
> to do an exact, not prefix, match on the passed-in string.
>
> So if you do:
>
>   Preferences::RegisterCallback(MyFunc, "foo");
>
> and the preference named "foobar" changes, MyFunc will no longer be
> called.  Most consumers did not expect this behavior, and a number were
> buggy as a result.
>
> The old behavior is still available via a new
> RegisterPrefixCallback/RegisterPrefixCallbackAndCall/UnregisterPrefixCallback
> API.  These can be used to observe all preferences whose names start with
> the given string.
>
> One caveat: It's very important to correctly pair up the registration and
> unregistration functions.  If you RegisterPrefixCallback but then
> UnregisterCallback, it will not actually unregister the callback.
>
> -Boris
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1348331
> ___
> 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: Heads Up: /storage upgraded from version 1.0 to 2.0

[rnewman]

On Thursday, March 16, 2017 at 12:16:24 PM UTC-7, Benjamin Smedberg wrote:

> users that reverted to an older version, staying on the release channel:
> 2.19%

Benjamin, two further questions, one of which I think you can answer, and one 
you probably can't:

- As Dolske asked: what proportion downgraded more than a single version (e.g., 
hopping from 51 back to 47)?
- What proportion downgrade across a storage version boundary at all?

Supporting downgrades of a single version has possible solutions that 
supporting multiple version downgrades does not.

And if it turns out that -- whether by luck or design -- we tend not to ship 
features that annoy/break users at the same time as storage version changes, 
then that changes the math.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[Boris Zbarsky]

I have just landed a change[1] which changes 
Preferences::RegisterCallback/RegisterCallbackAndCall to do an exact, 
not prefix, match on the passed-in string.


So if you do:

  Preferences::RegisterCallback(MyFunc, "foo");

and the preference named "foobar" changes, MyFunc will no longer be 
called.  Most consumers did not expect this behavior, and a number were 
buggy as a result.


The old behavior is still available via a new 
RegisterPrefixCallback/RegisterPrefixCallbackAndCall/UnregisterPrefixCallback 
API.  These can be used to observe all preferences whose names start 
with the given string.


One caveat: It's very important to correctly pair up the registration 
and unregistration functions.  If you RegisterPrefixCallback but then 
UnregisterCallback, it will not actually unregister the callback.


-Boris

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1348331
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do NOT hand-edit web platform test MANIFEST.json files

[James Graham]

On 20/03/17 22:15, gsquel...@mozilla.com wrote:


Sorry if it's a silly suggestion:
Could the current tool insert some helpful reminders *everywhere* in the 
generated file (so it's can't be missed)?
E.g., every 2nd line would read: "// PSA: This file is auto-generated by ./mach 
wpt-manifest-update, please don't edit!" ;-)


It is of course possible but it's not trivial since JSON doesn't allow 
comments, so there would have to be some preprocessing magic and so on. 
Probably better to spend the time on a good solution.


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

dev-platform@lists.mozilla.org

[Eric Shepherd]

We’re updating the  element’s documentation to not suck (yay!) and I’ve 
run into this: the WHATWG spec doesn’t currently list “datetime” as a valid 
type; only “datetime-local” is listed. Normally, MDN treats WHATWG as 
canonical, rather than W3C, but we do peek at that as well.

I’m pretty certain that this is correct; that “datetime” is deprecated. 
However, I do want to confirm things, since something odd turned up: W3C’s HTML 
5.1 spec doesn’t include “datetime”, it’s present in the latest 5.2 draft. So 
apparently it was only recently even added to HTML by W3C. What’s the actual 
status of datetime?

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network 
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy

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