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
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 total
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 relev
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:
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 n
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 lis
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
>> g
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 evol
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
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 hel
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 prefi
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 down
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
call
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-upda
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 certai
15 matches
Mail list logo
