___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 02/12/2017 08:52 PM, Jared Wein wrote:
The original email looks to be related to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1338891
and
https://bugzilla.mozilla.org/show_bug.cgi?id=1338902
though I agree that the message could have been explained a little better.
Sorry about that. I tho
On 02/15/2017 12:41 AM, Botond Ballo wrote:
But yes, don't implement probes as JS event listener when the event is some
rather commonly dispatched.
Same applies to observer service observers etc.
In bug 1238137, I added a SCROLL_INPUT_METHODS telemetry ping in
autoscrollLoop. Is that also inapp
On 02/16/2017 08:05 PM, smaug wrote:
On 02/16/2017 07:24 PM, Henri Sivonen wrote:
It seems that we already have MFBT code that has lower case methods
begin/end/cbegin/cend, etc., for compatibility with C++ standard
library iteration:
https://dxr.mozilla.org/mozilla-central/source/mfbt
On 02/16/2017 07:24 PM, Henri Sivonen wrote:
It seems that we already have MFBT code that has lower case methods
begin/end/cbegin/cend, etc., for compatibility with C++ standard
library iteration:
https://dxr.mozilla.org/mozilla-central/source/mfbt/ReverseIterator.h#136
I guess these methods sho
On 02/18/2017 07:08 PM, Eric Rescorla wrote:
I'd also note that if we're not going to use "this is what we have done
historically"
as a guide, then it seems like much bigger changes are on the table and we
would probably be better off adopting some other well-defined coding
standard
wholesale (e
On 02/21/2017 07:03 AM, Brian Birtles wrote:
As of Firefox 54, I intend to turn on, by default, the code that makes
Event.timeStamp a DOMHighResTimeStamp. This makes this member a double
whose value is the number of milliseconds since the time origin.
This has been developed behind the dom.event
Hi,
Preferences::GetBool is a slow hashtable lookup and has been showing up in
performance profiles in many places.
Please use Preferences::AddBoolVarCache. Same with other pref types.
Or if the pref needs to be read just once, store the value in some static
variable or so.
-Olli
___
ation matches the one you
requested a cache for. So if you have prefs "blah.foo" and
"blah.foo.bar", changing blah.foo.bar will write garbage into your cache for
blah.foo.
https://bugzilla.mozilla.org/show_bug.cgi?id=1208744
~ Gijs
On 22/02/2017 11:18, smaug wrote:
Hi,
Prefe
every DOM change
Definitely use cache
* every page load
This happens rarely, so probably doesn't matter
etc.
I wonder, if everybody uses Add*VarCache, doesn't it cause another performance
problem when a pref is changed?
On 2017/02/22 20:18, smaug wrote:
Hi,
Preferences::GetBool
On 03/07/2017 05:29 AM, Ben Kelly wrote:
On Mon, Mar 6, 2017 at 5:42 PM, Nicholas Nethercote
wrote:
On Tue, Mar 7, 2017 at 9:22 AM, Ben Kelly wrote:
These measurements are for full content processes. Many of the processes
in the above do not need all the chrome script we load in content pr
On 03/11/2017 08:23 AM, Nicholas Nethercote wrote:
On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance <
governa...@lists.mozilla.org> wrote:
I'd be ok to do a quick r+ if interdiff was working well.
Depending on the relative timezones of the reviewer and reviewee, that
could de
On 03/12/2017 10:40 PM, Ehsan Akhgari wrote:
On 2017-03-11 9:23 AM, smaug via governance wrote:
On 03/11/2017 08:23 AM, Nicholas Nethercote wrote:
On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance <
governa...@lists.mozilla.org> wrote:
I'd be ok to do a quick r+ if interdiff
On 03/10/2017 12:59 AM, Bobby Holley wrote:
At a high level, I think the goals here are good.
However, the tooling here needs to be top-notch for this to work, and the
standard approach of flipping on an MVP and dealing with the rest in
followup bugs isn't going to be acceptable for something so
On 03/10/2017 12:43 AM, Ben Kelly wrote:
On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote:
On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote:
I review a large number of patches on a typical day, and usually I have
to
spend a fair amount of time to just understand what the patch
A bit off topic
On 03/13/2017 04:37 PM, David Burns wrote:
Regarding burden on reviewers, the comments in this thread just highlight
how broken our current process is by having to flag individual people for
reviews. This leads to the a handful of people doing 50%+ of reviews on the
code.
Unfor
On 04/05/2017 07:34 PM, Tom Ritter wrote:
On Tue, Apr 4, 2017 at 10:29 PM, wrote:
Security & Privacy Concerns: none
It looks like this exposes pointerType, which reveals whether the user
is using a mouse, pen, or touch input.
Note, that is already available through old moz-prefixed API (w
On 04/17/2017 06:16 PM, Boris Zbarsky wrote:
A quick reminder to patch authors and reviewers.
Changesets should have commit messages. The commit message should describe not just the
"what" of the change but also the "why". This is especially
true in cases when the "what" is obvious from the d
On 04/18/2017 02:36 AM, Gregory Szorc wrote:
On Mon, Apr 17, 2017 at 4:10 PM, smaug wrote:
On 04/17/2017 06:16 PM, Boris Zbarsky wrote:
A quick reminder to patch authors and reviewers.
Changesets should have commit messages. The commit message should
describe not just the "what&qu
On 04/18/2017 03:12 AM, gsquel...@mozilla.com wrote:
On Tuesday, April 18, 2017 at 11:58:11 AM UTC+12, smaug wrote:
On 04/18/2017 02:36 AM, Gregory Szorc wrote:
On Mon, Apr 17, 2017 at 4:10 PM, smaug wrote:
On 04/17/2017 06:16 PM, Boris Zbarsky wrote:
A quick reminder to patch authors and
On 04/18/2017 04:24 PM, Ehsan Akhgari wrote:
On 2017-04-18 12:30 AM, Mike Hommey wrote:
I've yet to see that to happen. What is crucial is fast way to browse
through the blame in time. So commit messages should be short and
descriptive. Telling what and why. (I very often need to go back to CVS
On 04/20/2017 05:15 AM, Bevis Tseng wrote:
A soft reminder of using AbstractThread::GetCurrent()/MainThread()
after some design change for Quantum-DOM.
If this message/callback is to be handled on *the main thread of the
content process*, please use the replacement called AbstractMainThreadFor
On 04/25/2017 08:20 PM, Boris Zbarsky wrote:
On 4/25/17 1:07 PM, Alexander Surkov wrote:
I bet there's always room for improvements, and I hope this was a counterpoint
for the example only, not for the bug organization approach.
Sort of.
It was a counterpoint to "just check the bug; all the
On 04/25/2017 04:38 PM, Ehsan Akhgari wrote:
On 04/24/2017 06:04 PM, Martin Thomson wrote:
I think that 60Hz is too high a rate for this.
I suggest that we restrict this to top-level, foreground, and secure
contexts. Note that foreground is a necessary precondition for the
attack, so that rest
On 05/09/2017 01:55 PM, Mike Hommey wrote:
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
I think references help to encode that a bit more in the type system,
and help reasoning about the code without having to look
On 05/09/2017 04:52 PM, smaug wrote:
On 05/09/2017 01:55 PM, Mike Hommey wrote:
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
I think references help to encode that a bit more in the type system,
and help reasoning
FWIW, I just yesterday suggested in #whatwg that the platform should have
something like IdlePromise or AsyncPromise.
And there is the related spec bug
https://github.com/whatwg/html/issues/512#issuecomment-171498578
On 05/18/2017 04:22 AM, Mark Hammond wrote:
Given our recent performance pus
On 05/18/2017 09:25 PM, Domenic Denicola wrote:
On Thursday, May 18, 2017 at 4:34:37 AM UTC-4, smaug wrote:
FWIW, I just yesterday suggested in #whatwg that the platform should have
something like IdlePromise or AsyncPromise.
And there is the related spec bug
https://github.com/whatwg/html
On 06/16/2017 02:32 AM, Jim Porter wrote:
On 6/15/17 4:12 PM, Kartikaya Gupta wrote:
Not quite. For e10s, mouse events are sent across the process boundary
using the PBrowser ipdl protocol. On the parent side they go into
EventStateManager::DispatchCrossProcessEvent [1] which picks up the
TabPar
On 06/27/2017 12:12 AM, Armen Zambrano Gasparnian wrote:
Asking around, looking on dxr or MDN did not yield something easily.
I don't want to have to use Marionette in this specific automation context.
Thanks in advance,
Armen
Do you mean fullscreen in chrome level, or running web pages in f
On 07/04/2017 04:47 PM, Dexter wrote:
Hi everyone!
Could you tell me please, how I can clearly convert char (&name)[N] to
nsACString?
I tried this:
char* cname = new char[N];
memcpy(cname, &name, N);
nsAutoString strName;
strName.AssignWithConversion(cname, N);
I can't find out how to get ns
On 07/10/2017 01:29 PM, Nicholas Nethercote wrote:
Hi,
Firefox now has multiple Rust components, and it's on track to get a bunch
more. See https://wiki.mozilla.org/Oxidation for details.
I think this is an excellent trend, and I've been thinking about how to
accelerate it. Here's a provocative
On 07/10/2017 09:04 PM, zbranie...@mozilla.com wrote:
One more thought. There's a project that fitzgen told me about that aims to
allow for components to communicate between JS and Rust using Streams.
If we could get to the point where instead of WebIDL/XPIDL we could just plug
streams between
On 07/10/2017 01:29 PM, Nicholas Nethercote wrote:
Hi,
Firefox now has multiple Rust components, and it's on track to get a bunch
more. See https://wiki.mozilla.org/Oxidation for details.
I think this is an excellent trend, and I've been thinking about how to
accelerate it. Here's a provocative
On 07/11/2017 04:27 PM, Ben Kelly wrote:
On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote
wrote:
On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley
wrote:
If I were the owner of that module I would consider implementing a policy
something like the following:
"When a person writes a new c
On 07/12/2017 04:20 PM, Ben Kelly wrote:
On Tue, Jul 11, 2017 at 11:49 PM, Martin Thomson wrote:
On Wed, Jul 12, 2017 at 1:34 PM, Byron Jones wrote:
instead of disabling splinter for phabricator backed products, we could
make
it a read-only patch viewer.
Given the number of bugs that exi
Hi all,
recently in couple of bugs there has been requests to add Gecko specific APIs
for extensions.
It isn't clear to me why, and even less clear to me is what the plan is there.
I thought WebExtensions should work in several browsers, but the more we add
Gecko specific APIs, the less likely
are quickly
going to hit a point where "I don't feel like learning Rust" is not
going to cut it anymore.
Indeed.
On Tue, Jul 11, 2017 at 4:37 PM, smaug wrote:
How is the performance when crossing Rust <-> C++ boundary? We need to make
everything faster, not slower.
If
On 05/23/2014 04:29 AM, Anthony Jones wrote:
Some of you may remember the discussion on clang-format and the `mach
clang-format` command. What we have in place right now is very temporary
but it is functional enough to give it a try. I have not put the effort
into upstreaming my changes. Dependin
On 10/11/2017 09:55 PM, Andreas Tolfsen wrote:
+tools-marionette
Also sprach Chris Cooper:
Many of the build peers have long review queues.
Is having a long review queue the actual issue? Isn't (too) high throughput
at least equally bad issue. Does the new setup somehow try to ensure
reviews
On 10/18/2017 08:08 AM, Jet Villegas wrote:
SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for
oldest fixed bug?
whoohoo, didn't realize it was that old.
One day I'll start reading the bugs I review ;)
That is, do I owe you another steak? :-)
On Wed, Oct 18, 2017
Sounds very reasonable.
(Hoping the r=documentation flag won't be misused ;))
On 10/19/2017 04:37 PM, Andreas Tolfsen wrote:
Some time ago there was a discussion on dev-builds@ regarding
the state of our in-tree source code documentation. The main
focus was that MDN, moving forward, will main
On 10/21/2017 11:45 PM, Yura Zenevich wrote:
I would also like to bring to the team's attention another force worth
being on the radar (in terms of "forces on the system") - accessibility.
One theme that seems to consistently happen with re-writes such as the ones
from xul to React is regressions
On 10/21/2017 01:14 PM, Philipp Kewisch wrote:
On 10/20/17 7:47 PM, Dave Townsend wrote:
For some time now we've been talking about moving away from XUL and XBL.
The browser architecture team has been hard at work figuring out how to go
about doing that and we're ready to share the first of our
And let's be careful with the new C++ features, pretty please.
We managed to not be careful when we started to use auto, or ranged-for or
lambdas.
I'd prefer to not fix more security critical bugs or memory leaks just because
of fancy hip and cool
language features ;)
-Olli
On 10/30/2017 05
On 10/30/2017 04:52 PM, Simon Sapin wrote:
On 30/10/17 15:05, smaug wrote:
And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory
judgment would
hurt the quality of the code.
+1
On Mon, Oct 30, 2017 at 8:03 AM, smaug wrote:
On 10/30/2017 04:52 PM, Simon Sapin wrote:
On 30/10/17 15:05, smaug wrote:
And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use aut
This has been an issue forever, and there aren't really good tools on any
browser, as far as
I know, for web devs to debug their leaks.
Internally we do have useful data (CC and GC graphs and such), but would need
quite some ux skills to design some good
UI to deal with leaks. Also, the data to
On 11/02/2017 10:01 PM, Kris Maglione wrote:
On Thu, Nov 02, 2017 at 05:37:30PM +0200, smaug wrote:
This has been an issue forever, and there aren't really good tools on any
browser, as far as
I know, for web devs to debug their leaks.
Internally we do have useful data (CC and GC graph
On 11/02/2017 09:58 PM, Kris Maglione wrote:
Related: I've been thinking for a long time that we need better tools for
tracking what sites/usage patterns are responsible for the time we spend in
CC (and possibly GC, but I think that tends to be less of a problem).
I've noticed, in particular, t
On 11/17/2017 12:55 AM, Chung-Sheng Fu wrote:
Content Security Policy suggests Security Policy Violation DOM Events [1].
In case any of the directives within a policy are violated, such a
SecurityPolicyViolationEvent is generated and sent out to a reporting
endpoint associated with the policy. We
On 11/23/2017 11:54 PM, Botond Ballo wrote:
I think it makes sense to hide a 'new' call in a Make* function when
you're writing an abstraction that handles allocation *and*
deallocation.
So MakeUnique makes sense, because UniquePtr takes ownership of the
allocated object, and will deallocate it
On 11/24/2017 06:35 PM, Eric Rescorla wrote:
On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote:
On 11/23/2017 11:54 PM, Botond Ballo wrote:
I think it makes sense to hide a 'new' call in a Make* function when
you're writing an abstraction that handles allocation *and*
de
On 11/27/2017 01:05 PM, Nicolas B. Pierron wrote:
On 11/26/2017 12:45 AM, smaug wrote:
On 11/24/2017 06:35 PM, Eric Rescorla wrote:
On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote:
On 11/23/2017 11:54 PM, Botond Ballo wrote:
I think it makes sense to hide a 'new' call in a Make
This is basically an after the fact notification that
we're in progress of implementing Shadow DOM again, this time v1[1].
While doing this, the v0 implementation, which was never exposed to the web,
will be removed.
v1 is luckily way simpler, so this all should simplify various bits in DOM.
FF6
On 11/27/2017 02:20 PM, smaug wrote:
This is basically an after the fact notification that
we're in progress of implementing Shadow DOM again, this time v1[1].
While doing this, the v0 implementation, which was never exposed to the web,
will be removed.
v1 is luckily way simpler, so thi
t cringe back from
it. Sure, prove it out. But we really don't need more moz-specific
constructs. We should choose our deviations carefully.
On Mon, Nov 27, 2017 at 3:24 AM, smaug wrote:
On 11/27/2017 01:05 PM, Nicolas B. Pierron wrote:
On 11/26/2017 12:45 AM, smaug wrote:
On 11/24/2017
On 11/28/2017 06:33 AM, Boris Zbarsky wrote:
On 11/27/17 7:45 PM, Eric Rescorla wrote:
As for the lifetime question, can you elaborate on the scenario you are
concerned about.
Olli may have a different concern, but I'm thinking something like this:
for (auto foo : myFoos) {
foo->bar();
time since the end
of last year to push this forward by providing a correct microtask
scheduling (Thanks Olli(:smaug) for the major work of the new scheduling
patch) and fixing the test failures in our implementation discovered by the
scheduling change.
Good news is that we have all WPT gre
Great work on wpt!
On 12/15/2017 05:38 PM, James Graham wrote:
Following the summary of what we achieved in wpt in the last year, I'd
like to solicit input from the gecko community to inform the
priorities of various pieces of wpt work for the next year.
In order to maximise the compatibility b
On 01/04/2018 12:30 AM, Ben Kelly wrote:
On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote:
So after validating my approach in that bug (which is almost ready) I've
thought that it might be time to give the observer service the same
treatment. First of all we'd have a list of topics (I've
On 01/16/2018 11:41 PM, Mike Hommey wrote:
On Tue, Jan 16, 2018 at 10:02:12AM -0800, Ralph Giles wrote:
On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard
wrote:
But I would be interested in knowing how long that same Lenovo P710 takes
to compile *today*….
On my Lenovo P710 (2x2x6 core Xeo
On 02/09/2018 10:39 PM, James Graham wrote:
On 09/02/2018 19:59, Josh Bowman-Matthews wrote:
On 2/9/18 1:26 PM, James Graham wrote:
* One bug per PR we downstream, filed in a component determined by the files
changed in the PR.
What does this mean exactly? What is the desired outcome of thes
On 03/19/2018 09:30 PM, Kris Maglione wrote:
On Mon, Mar 19, 2018 at 08:49:10PM +0200, Henri Sivonen wrote:
It appears that currently we allow atomicizing invalid UTF-16 string,
which are impossible to look up by UTF-8 key and we don't allow
atomicizing invalid UTF-8.
I need to change some thin
Hi all,
just some random notes about Phabricator.
I've been reviewing now a bunch of patches in Phabricator and the initial
feeling from
reviewer's point of view is that it is ok. Not great, but ok.
MozReview's interdiff, when it works, is easier to use or at least to discover
than Phabricator
On 04/24/2018 09:25 AM, Andreas Tolfsen wrote:
Also sprach Bobby Holley:
For reasons outlined in bug 1450827, the DOM peers have decided to
deprecate support for JS-implemented WebIDL APIs. This means that
new additions of |JSImplementation="foo"| are no longer permitted.
Out of curiosity, a
On 04/25/2018 08:38 PM, Bobby Holley wrote:
On Wed, Apr 25, 2018 at 10:21 AM, Ted Mielczarek wrote:
On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote:
At minimum we should make --enable-profiling build with rust-opt.
This sounds reasonable, although the quirk is that we default
--enab
On 04/27/2018 12:14 AM, Ben Kelly wrote:
Hi all,
I just pushed another helper class that I thought others might find useful.
CopyableErrorResult is a specialized form of ErrorResult. Its intended to
allow slightly more rich error values to be passed through things like ipdl
structure and MozPr
On 06/20/2018 04:14 PM, Andrea Marchesini wrote:
Summary: The Clear-Site-Data header allows a secure origin to send a header
requesting the deletion of its own browsing data.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1268889
Link to standard: https://w3c.github.io/webappsec-clear-site-
On 06/29/2018 05:58 PM, Boris Zbarsky wrote:
On 6/29/18 10:30 AM, Nathan Froyd wrote:
Given the language-required qualification for
`enum class` and a more Rust-alike syntax, I would feel comfortable
with saying CamelCase `enum class` is the way to go.
For what it's worth, I agree. The point
On 07/12/2018 11:08 PM, Randell Jesup wrote:
I do hope that the 100 process figures scenario that was given is a worse case
scenario though...
It's not. Worst case is a LOT worse.
Shutting down threads/threadpools when not needed or off an idle timer
is a Good thing. There may be some perf
Hi bholley,
looks great, but a question
The example
mProducer->RequestFoo()
->Then(mThread, __func__,
[...] (ResolveType aVal) { ... },
[...] (RejectType aVal) { ... });
uses C++ lambdas. Do we have some static analysis or such in place to protect
that
On 08/15/2015 10:24 AM, Jonas Sicking wrote:
On Sun, Aug 9, 2015 at 11:59 AM, L. David Baron wrote:
The W3C is proposing revised charters for:
Web Platform Working Group:
http://www.w3.org/2015/07/web-platform-wg.html
https://lists.w3.org/Archives/Public/public-new-work/2015Jul/0020.h
On 09/11/2015 04:53 AM, L. David Baron wrote:
On Tuesday 2015-09-08 17:33 -0700, Tantek Çelik wrote:
Follow-up on this, since we now have two days remaining to respond to these
proposed charters.
If you still have strong opinions about the proposed Web Platform and Timed
Media Working Groups ch
On 09/15/2015 06:53 PM, Boris Zbarsky wrote:
On 9/15/15 11:11 AM, Ben Hearsum wrote:
I'm pretty sure https://github.com/mozilla/gecko-dev has full history.
Though note that it doesn't have working blame for a lot of files in our source
tree (and especially the ones you'd _want_ to get blame f
On 09/18/2015 06:30 AM, Zibi Braniecki wrote:
Hi,
One of the major use cases for MutationObserver is all kinds of libraries that
either shim APIs or provide intrinsic modifications to DOM experience.
Examples of such libraries may be:
* A library that provides Date/Time pickers only caring ab
On 09/22/2015 09:49 AM, Zibi Braniecki wrote:
There seem to be an interesting section in Promises doc from 2001 about
multi-state promises -
https://www.w3.org/2001/tag/doc/promises-guide#state-transitions
That document is from 2015 ;)
One of the things that we are working on is a spec fo
On 10/09/2015 03:46 AM, zbranie...@mozilla.com wrote:
We're about to start working on another API for the next Firefox OS, this time
for DOM Intl, that will operate on `data-intl-format`,
`data-intl-value` and `data-intl-options`.
It would be much easier for us to keep l10n and intl separately
On 10/26/2015 10:21 AM, Amit Zur wrote:
MDN says keyCode is deprecated and web developers should favor `key` instead.
But sendKeyEvent doesn't support key property on the event.
I found bug #1214993 but the solution there is a workaround for the home button
for TV.
Can we expect this to be fix
On 11/28/2015 11:36 AM, Anne van Kesteren wrote:
On Sat, Nov 28, 2015 at 9:09 AM, Ian Young wrote:
Maybe a
Mozillian could drop in and give us an explanation of how the W3C
process influences what gets implemented and when?
Well, it doesn't really, many things are standardized by the W3C that
On 11/28/2015 11:36 AM, Anne van Kesteren wrote:
On Sat, Nov 28, 2015 at 9:09 AM, Ian Young wrote:
Maybe a
Mozillian could drop in and give us an explanation of how the W3C
process influences what gets implemented and when?
Well, it doesn't really, many things are standardized by the W3C that
On 12/02/2015 07:25 AM, ryan.sle...@gmail.com wrote:
On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
Oh well. Bummer.
/ Jonas
If it cheers you up any, the 2.0 API that replaces the U2F API uses promises -
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
R
On 12/02/2015 03:23 AM, Richard Barnes wrote:
The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1]. Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to crea
On 12/02/2015 11:37 PM, Frederic Martin wrote:
As I said in the other email,
I don't understand how this could be implemented when the spec has left the
>key piece undefined, as far as I see.
You are completely right ! For now, FIDO 2 is currently being written (far far
far from finished) and
wouldn't be an
instance of u2f, but one would just call those static methods
on the u2f interface.
(Nit, the convention is that interfaces start with a capital letter. For some
odd reason 'u2f' doesn't follow that.)
-Olli
On 12/02/2015 11:20 PM, smaug wrote:
On
On 12/04/2015 06:56 PM, smaug wrote:
Looks like the spec could be made implementable by fixing
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api
"provide a namespace object u2f of the following interface" do
On 01/03/2016 06:35 PM, David Rajchenbach-Teller wrote:
Accessing XPCOM in a worker will most likely break the garbage-collector
in novel and interesting ways,
Why would it? Our workers are full of xpcom stuff.
One needs to be careful what to touch sure, and deal with CC and GC handling
like i
On 01/03/2016 06:55 PM, David Rajchenbach-Teller wrote:
Well, XPConnect is designed for the main thread, and many of the things
it does assume that everything takes place on the main thread.
An example, from the topic of my head: whenever objects cross between
JavaScript and C++ through XPConnec
On 01/04/2016 07:43 PM, Robert Kaiser wrote:
Gregory Szorc schrieb:
If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let
me know by replying to this message. Your feedback will be used to drive
what impro
On 01/18/2016 06:03 PM, Honza Bambas wrote:
On 1/15/2016 21:02, Ehsan Akhgari wrote:
On 2016-01-15 2:21 PM, Bobby Holley wrote:
Has anyone measured recently whether there's still a significant perf
win to making IIDs 32-bit? If we stop using them as a versioning tool,
we could potentially relax
On 01/24/2016 04:48 AM, Mike Hommey wrote:
On Sat, Jan 23, 2016 at 09:33:15PM -0500, Boris Zbarsky wrote:
Sure. And the "r+ with these changes, and feel free to land, but I want to
see the interdiff" mode is supported with Autoland because the interdiff
would be available in mozreview post-fact
On 01/23/2016 09:41 PM, Ehsan Akhgari wrote:
Related to this, I always found it a bit surprising we perform so much
activity on the patch author side before submission. Part of me thinks
reviewers should take one quick glance at the interdiff before the final
version lands and should be gate
On 01/31/2016 08:35 PM, Axel Hecht wrote:
I'm also generally concerned how UX bugs or crashes would fit into these
buckets. UX bugs, and possibly any other flavor of ideation, have the
majority of work associated with "should we do this or not". And crashes as a
single crash stack are hardly ev
On 02/01/2016 11:46 PM, Justin Dolske wrote:
On 2/1/16 9:51 AM, Kartikaya Gupta wrote:
Oh, I should also mention that currently many (if not all) Windows
touchscreen devices have e10s disabled by default, because a
touchscreen seems to trigger the accessibility code which disables
e10s. And if e
On 03/02/2016 05:34 PM, Matt Brubeck wrote:
I think that Mozilla should comment in favor of the PEWG charter. Mozilla has
been participating in the WG and it is doing important work for interop and
performance of pointer input handling.
+1
___
dev
On 04/08/2016 06:10 PM, Kartikaya Gupta wrote:
Is there a recommendation for what enum values in C++ code should be
styled as? The coding style doesn't say and we use a variety of things
in existing code, so I was wondering if we should settle on something
for new enums being added to the code, a
On 04/08/2016 07:38 PM, Nick Fitzgerald wrote:
On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas <
birunt...@mohanathas.com> wrote:
On 8 April 2016 at 18:10, Kartikaya Gupta wrote:
Others?
enum class OptionD {
SentenceCaseValues,
ThisWontBeConfusedWithOtherThings
// ... because
On 04/10/2016 05:50 PM, Aryeh Gregor wrote:
On Fri, Apr 8, 2016 at 8:35 PM, smaug wrote:
enum classes are great, but I'd still use prefix for the values. Otherwise the
values look like types - nested classes or such.
(Keeping my reviewer's hat on, so thinking about readability h
nough prefix that it
shouldn't be too much of a burden.
I realize not everybody is going to be happy with this but I don't
want this discussion to drag on to the point where it's a net loss of
productivity no matter what we end up doing. I'll update the style
guide.
Thanks al
s a small enough prefix that it
shouldn't be too much of a burden.
I realize not everybody is going to be happy with this but I don't
want this discussion to drag on to the point where it's a net loss of
productivity no matter what we end up doing. I'll update the style
guide.
T
1 - 100 of 277 matches
Mail list logo
