Re: Use of 'auto'

On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey m...@kylehuey.com wrote: auto len = aArray.Length(); auto display = GetStyleDisplay()-mDisplay; It can save having to look up whether aArray.Length() returns size_t (I sure hope it does, though) or whether mDisplay is uint8_t or uint16_t. I have

Re: Use of 'auto'

On Tue, Jun 2, 2015 at 1:59 PM, L. David Baron dba...@dbaron.org wrote: My assumption was that this would be for cases where neither the reader nor writer is likely to care about which integral type it is, and also cases that are near the threshold for whether to repeat (in source code or

Re: The War on Warnings

On Wed, Jun 3, 2015 at 6:14 PM, Eric Rahm er...@mozilla.com wrote: I generated this list by grabbing the logs for a recent m-c linux64 debug run, normalizing out PIDs and timestamps and then doing some sort/uniq-fu to get counts of unique lines. If your tool could be turned into a web page

Re: Revisiting modelines in source files

On Wed, Jun 17, 2015 at 4:57 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: (At this point I expect people to push back against my claims that the automated tools aren't up to snuff. If you really think automated tools can do a good enough job, please run one and submit patches fixing

Re: Secure contexts required for new web platform features

On Wed, Jul 1, 2015 at 8:16 AM, Boris Zbarsky bzbar...@mit.edu wrote: we'd need to decide what https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy step 5 should mean in our particular case Colloquially: would you show a lock? Unfortunately, conveying the nuance

Re: Intent to Ship: Push API

On Tue, Aug 11, 2015 at 3:07 AM, Julien Wajsberg jwajsb...@mozilla.com wrote: Can you share what the plan is for Fx/Android and Firefox OS ? Firefox OS can (and likely will) use the same basic technology, though the UX story there is incomplete. Fennec needs extra work in order to integrate

Re: Intent to migrate the permissions database to use origins instead of host names

On Tue, Jun 30, 2015 at 4:18 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: I personally am not sure if that is a sound idea for all permission types. It's probably the right thing for geolocation, but not for cookies. As I understand it, the key for permission manager is a simple string.

Re: Use of 'auto'

On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking jo...@sicking.cc wrote: How would you make a factory function like the above fail? Don't allow for the possibility. If Foo::Create() is directly analogous to new Foo(), then it can't fail. Leave the failing for later method calls.

Re: Fingerprinting of battery status?

On Tue, Aug 4, 2015 at 9:33 AM, Jonas Sicking jo...@sicking.cc wrote: So disabling the API, or fudging its return values, in private browsing windows sounds like a good idea. The same applies to features like device orientation, proximity/light sensors, network information (wifi vs. mobile

Re: Fingerprinting of battery status?

On Tue, Aug 4, 2015 at 8:24 AM, Tim Taubert ttaub...@mozilla.com wrote: Can we just reduce the accuracy of the API? Only give battery level at certain broad breakpoints? The authors of the cited paper [1] filed a bug report and we fixed that for 38 [2]. I should think that more aggressive

Re: New policy: 48-hour backouts for major Talos regressions

On Fri, Aug 14, 2015 at 2:56 PM, Vladan D vdje...@mozilla.com wrote: Tests are reliable if they detect regressions, aren't very noisy, and if they measure things that have a real impact on actual Firefox user experience. Do we track false positives on these? I say that because I got a mail

Re: New policy: 48-hour backouts for major Talos regressions

On Fri, Aug 14, 2015 at 3:44 PM, Vladan Djeric vdje...@mozilla.com wrote: Is this the ts_paint regression you're referring to? https://groups.google.com/forum/#!searchin/mozilla.dev.tree-alerts/ts_paint/mozilla.dev.tree-alerts/FArVsa8guXg/FfY91JK7AAAJ Yeah. I only ask because in exercising

Re: Can we make a plan to retire Universal Mac builds?

On Wed, Aug 5, 2015 at 3:59 PM, Matthew N. ma...@mozilla.com wrote: If we have data on CPU architecture I don't think the OS version is relevant unless I'm missing something. My understanding is that OS version is all that matters. 64-bit apps require a 64-bit OS. (Such an OS requires a

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

On Tue, Jul 14, 2015 at 10:06 AM, Gregory Szorc g...@mozilla.com wrote: That being said, every other organizations in the world is using the same or similar tools and is faced with similar challenges. Lack of a commit-skipping feature doesn't hinder other organizations from performing major

Re: Intent to implement W3C Manifest for web application

I'd rather see us solve the individual problems that manifests aim to solve using some combination of meta tags, link relations and plain-ol' DOM/JS APIs. The manifest is no better than the former two. It already replicates features that these provide when it comes to icons. In particular, the

Re: Intent to implement W3C Manifest for web application

On Wed, Jul 15, 2015 at 4:12 AM, mar...@marcosc.com wrote: some people believe that web applications should be installable I don't subscribe to that theory. The web is comprised of pages, not apps. (I mostly agree with Alex, but not regarding the perceived need for app discoverability; I hear

Re: Collecting web platform features implementation status

On Thu, Jul 16, 2015 at 12:26 PM, Anthony Ricaud anth...@ricaud.me wrote: In order to get accurate data and update it regularly, we need your help. Please go to the following etherpad and insert any information that can help us: https://etherpad.mozilla.org/gecko-web-platform-dashboard That's

Re: Collecting web platform features implementation status

On Thu, Jul 16, 2015 at 5:44 PM, Benjamin Kelly bke...@mozilla.com wrote: FWIW, I've sent an intent to implement for the Streams API, but I won't be able to actually start work until Q4. I just listed that as favorable for now. Not sure if we need a clearer we intend to implement this but

Re: Intent to Implement and Ship: Permissions API

On Tue, Aug 25, 2015 at 2:12 AM, Anne van Kesteren ann...@annevk.nl wrote: 3) It seems the API is evolving in ways to also request permission without then directly using that permission. It's not clear that is a good idea. This is something that is already doable. If a webpage calls

Re: Please do not use the Date type in Web IDL APIs

WFM. I'll see what I can do about fixing RTCCertificate. I think that the breakage should be minimal if I just change it. On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 10/16/15 2:00 PM, Martin Thomson wrote: >> >> On Fri, Oct 16, 2015 at 9

Re: Please do not use the Date type in Web IDL APIs

On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky wrote: > I'm not sure what custom code you're talking about. What exactly are you > proposing? Date is fundamentally just an integer when you get down to it. Treat it like one. An integer value is copied when you return it, so

Re: Please do not use the Date type in Web IDL APIs

On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky wrote: > You should _especially_ not create attributes of type Date. Well, that's interesting. I think that I might have to eat crow: https://github.com/w3c/webrtc-pc/issues/324 I didn't read all the discussion, but what is

Re: PSA: Local static analysis builds on Linux and Mac OS X

On Wed, Oct 14, 2015 at 6:32 PM, Gregory Szorc wrote: > As you stated, this helps detect errors earlier during development, which > is a huge win. Is there a good reason configure doesn't enable the clang > plugin by default? Yes please. If the checks are expensive,

Extrapolating from telemetry

I want to get some very rough numbers for our entire userbase, but I don't know how to go from "number of users who opted in to telemetry" to "all users". Do we have any information on the proportion of users opt in to telemetry? ___ dev-platform

Re: MD5 - Re: On the future of and application/x-x509-*-cert MIME handling

Henry, I would rather you attempt to address Ryan's point 5, namely: 5) just generates keys, and relies on application/x-x509-*-cert to install certificates. This MIME handling, unspecified but implemented by major browsers, represents yet-another-way for a website to make persistent

Intent to implement and ship

WebRTC was shipped with a prefix. Bug 1155923 moves our codebase to non-prefixed names, but includes a patch to restore aliases with the prefix. Thus we will expose `RTCPeerConnection` and use that ourselves, but permit legacy code to use `mozRTCPeerConnection`. Maybe some day we can remove the

Re: Intent to implement and ship

On Tue, Aug 25, 2015 at 2:16 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-08-25 4:07 PM, Martin Thomson wrote: WebRTC was shipped with a prefix. Bug 1155923 moves our codebase to non-prefixed names, but includes a patch to restore aliases with the prefix. Thus we will expose

Re: On the future of and application/x-x509-*-cert MIME handling

sle...@chromium.org> wrote: > [No idea if these will show up on the lists since I'm not subscribed] > > On Fri, Sep 11, 2015 at 9:30 PM, Martin Thomson <m...@mozilla.com> wrote: > >> I have some questions, to which I was unable to find answers for in >> the (numerous and lo

Re: On the future of and application/x-x509-*-cert MIME handling

I have some questions, to which I was unable to find answers for in the (numerous and long) threads on this subject. 1. When we download and install a client cert, what checking do we do? Do we insist upon it meeting the same algorithm requirements we have for servers with respect to use of

Re: WebUSB

On Fri, Dec 4, 2015 at 8:04 PM, Robert O'Callahan wrote: > However, for USB the "Web driver" approach seems better than that, to me. > It makes it easy to update the vendor library to fix security bugs and > update the API. If the Web API is baked into the device firmware

Re: WebUSB

On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan wrote: > On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla wrote: > >> (4) Have the APIs hidden behind access controls that need to be enabled by >> an extension >> (but a trivial one). Perhaps you think this is

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

On Thu, Dec 31, 2015 at 5:40 PM, Daniel Holbert wrote: > Summary: > A good chunk of the web today (and particularly the mobile web) > effectively relies on -webkit prefixed CSS properties & features. We > wish we lived in a world where web content always included >

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

On Fri, Jan 1, 2016 at 8:15 AM, Daniel Holbert wrote: > (3) False positives: There are many "legitimate" ways that authors can > use prefixed properties Yep, you convinced me with this. ___ dev-platform mailing list

Re: Generating Visual Studio project files by default

On Tue, May 24, 2016 at 7:29 PM, Jeff Gilbert wrote: > What's the build-time impact of this? The implicit question being, if this impact is non-zero, can I turn it off? Also, does it make any sense to do this on try machines? ___

Re: Proposed W3C Charter: Web of Things Interest Group

On Thu, Jun 23, 2016 at 3:19 AM, Anne van Kesteren wrote: > We should just let them do their thing and do our thing elsewhere. This seems like a reasonable plan. Unless and until someone thinks that a course correction is feasible, or decides that it's worth trying.

Re: Does SSE2 usage still need to be conditional?

On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic wrote: > Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit > Windows. If I’m reading the data correctly, more than half. A small > percentage of those don’t have SSE2. Do we have any, say

Re: How to remove #ifdef XP_MACOSX in xul files?

sed -i~ -e '/#ifdef XP_MACOSX/d' xul files I think that we need more information on what it is that you intend to do if we are to make a sensible suggestion. On Mon, Feb 1, 2016 at 5:23 PM, Yonggang Luo wrote: > How to remove #ifdef XP_MACOSX in xul files? >

Re: Does SSE2 usage still need to be conditional?

On Thu, Feb 4, 2016 at 2:21 AM, Milan Sreckovic wrote: > 99.77% of the users on all channels have SSE2 support; > 51.7% of all users are on 32-bit Windows; > 0.44% of all users on 32-bit Windows do not have SSE2 support. Those numbers wouldn't justify a change to me.

Re: Does SSE2 usage still need to be conditional?

On Wed, Feb 3, 2016 at 12:54 AM, Benjamin Smedberg wrote: >> Do we have any, say telemetry, that would move this from speculation >> into numbers? Sure, numbers aren't necessarily perfect, but I'm sure >> that they would help. > > Milan is quoting numbers from telemetry

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

On Mon, Feb 15, 2016 at 12:30 PM, Valentin Gosu wrote: >> Thumbnails, or columns on the right for each selected browser with >> median (or mean), with the best (for that site) in green, the worst in >> red would allow eyeballing the results and finding interesting >>

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

On Mon, Feb 15, 2016 at 1:12 PM, Martin Thomson <m...@mozilla.com> wrote: > On Mon, Feb 15, 2016 at 12:30 PM, Valentin Gosu <valentin.g...@gmail.com> > wrote: >>> Thumbnails, or columns on the right for each selected browser with >>> median (or mean), wi

Re: Returning dictionaries in WebIDL

, there are some people who consider the fact that a dictionary becomes outside the control of the browser to be a feature. That is partly why WebRTC is how it is. On Mon, Feb 15, 2016 at 10:11 AM, Cameron McCormack <c...@mcc.id.au> wrote: > Martin Thomson: >> I know that this is no

Returning dictionaries in WebIDL

I know that this is not good practice, but is there something written down somewhere explaining why? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

Now that is a frightening observation. Is this creating a more persistent (pernicious?) tracking mechanism? In that case, credentials stored by a site should last no longer than cookies. Credentials created by a user maybe can live longer. On 12 Mar 2016 04:41, "Anne van Kesteren"

Re: Are we in favour of implementing the client hints header?

On Wed, Mar 9, 2016 at 6:42 AM, Jonas Sicking wrote: > I know there's some concern that always sending CH with all requests > would generate too much header traffic which would be wasteful. We could limit the feature to h2. (Which would also address the other request, which

Re: Intent to implement: W3C WebAppSec credentialmanagement API

On 12 Mar 2016 7:28 PM, "Anne van Kesteren" wrote: > It should be identical to password manager integration. But it is not, though I suppose that a password manager might be exploited to store state. I hope that isn't possible... (note to self, attempt this attack) > > In

Re: Intent to implement: W3C WebAppSec credentialmanagement API

I don't think that there was any misunderstanding in what it is that is being proposed, just disagreement about cost-benefit. On Mon, Mar 14, 2016 at 8:02 PM, Mike West wrote: > Websites use passwords today. While I agree that we can and should be > working on something better,

Re: Intent to implement: W3C WebAppSec credentialmanagement API

On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker wrote: > no password generation help by the UA I agree with MattN here, not doing this eliminates much of the advantage of having a password manager. Or do you have a plan to rely on sites doing that with

Re: Old XUL, deprecated Error Console

On Wed, Mar 23, 2016 at 10:59 PM, Philip Chee wrote: > Thunderbird cannot migrate (easily). The only functionality in Devtools > that they currently can use is the Debugger (as a remote client). If they are alone, then maybe they might consider adoption.

Re: Intent to implement: DOM Push API in Firefox for Android

This is great. As I said elsewhere, I don't think that we can pref this on until bug 1252650 lands. It turns out that "gecko not running" is pretty much the only interesting state for push. On Thu, Mar 3, 2016 at 5:06 AM, Nicholas Alexander wrote: > Summary: "The Push

Re: Proposing preferring Clang over GCC for developer buidls

On Thu, Mar 3, 2016 at 10:45 AM, Mike Hommey wrote: > More importantly, changing the official toolchain has implications on > performance. Without any real evidence for this, I'm told that GCC still produces better (i.e., faster) output. But we could switch try builds to

Re: Announcing MozillaBuild 2.2.0 Release

On Wed, Mar 30, 2016 at 12:41 PM, Xidorn Quan wrote: > I'd suggest you use https instead, it seems to work with ftp.mozilla.org :) Indeed. Don't drop the scheme entirely either, since Firefox attempts to use FTP, which isn't available on that server.

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Fri, Apr 22, 2016 at 1:05 AM, Nicholas Nethercote wrote: > The third example I looked at was CycleCollectedJSRuntime. Again > problems, specifically this line in Init(): > > mOwningThread->SetScriptObserver(this); Others have already said what I would have here

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

On Tue, Apr 26, 2016 at 6:08 PM, Jonas Sicking wrote: > Limiting this to aurora builds might make the most sense here since > that's what we're pushing as the build that developers should use. I'm OK with that; that's why I asked here.

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan wrote: > Could we probably restrict it to non-release builds (aurora and nightly) > rather than restrict them to debug builds only? Debug builds are harder to > get, and are slow. That was suggested, but we decided against it in

Intent to (sort of) unship SSLKEYLOGFILE logging

In NSS, we have landed bug 1183318 [1], which I expect will be part of Firefox 48. This disables the use of the SSLKEYLOGFILE environment variable in optimized builds of NSS. That means all released Firefox channels won't have this feature as it rides the trains. This feature is sometimes used

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On 17 Apr 2016 2:37 AM, "Haik Aftandilian" wrote: > > Sites might depend on a combination of https and non-https cookies and then > act strangely when a user returns to the site with only the https cookies. This is also known as a security vulnerability. See

Re: Proposal: use nsresult& outparams in constructors to represent failure

I prefer the fallible, if failed return null else return new pattern myself also. With a little RAII, it keeps manual cleanup to a minimum. On Thu, Apr 21, 2016 at 8:24 PM, Nicholas Nethercote wrote: > - It doesn't appear to work with stack-allocated objects? The

Re: Checkin-needed requests - Please include complete information in the commit message :)

Is now the right time to start talking about retiring checkin-needed, or is it still heavily used? On Sat, Jul 9, 2016 at 4:58 AM, Gregory Szorc wrote: > On Fri, Jul 8, 2016 at 11:39 AM, Felipe G wrote: > >> Is there a way to make the checkin-needed flag

Re: Checkin-needed requests - Please include complete information in the commit message :)

On Mon, Jul 11, 2016 at 2:18 PM, Xidorn Quan wrote: > Isn't it still necessary for people who don't yet have permission to > push? That suggests to me that there are missing safeguards on autoland. Otherwise we could just enable it even for those with try access. > I also use

Re: MXR permanently offline, please transition to DXR

On Fri, Jul 1, 2016 at 9:55 AM, Robert O'Callahan wrote: > In theory responses 301 and 308 mean "permanent redirect" so the browser > could do that for those responses. Those would only work for as long as the 3xx is remembered, and it wouldn't work for /x if you have only

Re: Exposing SSLStatus to WebExtensions (and possibly extending it)

I think that it is reasonable to expose this sort of information to web extensions, and - for some things - possibly even to the web. I don't think that we should start with nsISSLStatus directly. Though it does have some relevant values, we should be careful to specify - and justify -

Re: Should &&/|| really be at the end of lines?

On Fri, Feb 17, 2017 at 10:39 AM, Robert O'Callahan wrote: >> Using clang-format on the entire tree has the massive value of: > > Also, it's very liberating not having to think about formatting while > writing code, knowing it will be automatically fixed up later. This is >

Re: Should &&/|| really be at the end of lines?

On Mon, Feb 20, 2017 at 3:18 AM, smaug wrote: > I don't care too much about &&/|| coding style, though the current style > does feel easier to > read, per the reasoning dmajor gave. I suspect that a lot of people think this way. While it's tempting to suggest that arguments

Re: Intent to Implement and Ship: Large-Allocation Header

On Thu, Jan 19, 2017 at 9:21 AM, Michael Layzell wrote: > Security & Privacy Concerns: none I doubt that this is true. You have provided a way for sites to gain a whole process to themselves, on request. Denial of service seems like something that would need to be

Re: Intent to Implement and Ship: Large-Allocation Header

On Thu, Jan 19, 2017 at 10:17 AM, Michael Layzell wrote: > @Martin There is a pref (dom.ipc.processCount.webLargeAllocation - default > 2) which controls the maximum number of processes which may be allocated to > Large-Allocation processes. Any requests past that number

Re: Intent to put Permission API's .revoke() method behind a pref

Sounds like a good plan. (For those who might be wondering: .request() was never exposed.) On Wed, Aug 17, 2016 at 2:48 PM, wrote: > Summary: It seems we prematurely shipped the .revoke() method on the > Permissions API before it was stable or deciding if we even wanted it

Re: Intent to put Permission API's .revoke() method behind a pref

On Wed, Aug 17, 2016 at 5:34 PM, Anne van Kesteren wrote: > Interesting, I guess I didn't realize that covered more than just > query(). If we ship a subset of an API it probably would help to be > clear, indeed. Well, it only mentioned .query() explicitly, but then said "other

Re: Intent to put Permission API's .revoke() method behind a pref

On Wed, Aug 17, 2016 at 5:02 PM, Anne van Kesteren wrote: > The main problem with query as I see it is that since we haven't > agreed on what permissions are keyed on, an application cannot really > do anything with the answer it gets from query. E.g., communicating > the answer

Intent to ship: TLS 1.3 draft

As of Firefox 52 I intend to turn TLS 1.3 on by default. TLS 1.3 has been developed using the existing security.tls.version.max preference to control maximum version. TLS 1.3 is the next version of TLS, the protocol that secures the web. TLS 1.3 removes old and unsafe cryptographic primitives, it

Re: Windows XP and Vista Long Term Support Plan

On Sat, Oct 22, 2016 at 8:16 PM, wrote: > My concern is that by killing digital certificate updates and TLS updates, > still in use machines whose main purpose is Internet access are essentially > bricked. Yep, I just designated a relatives machine to recycling on

Re: Proposed W3C Charter: Automotive Working Group

I'm not going to respond in detail, but I think that this quote cuts to the nub. On Thu, Nov 24, 2016 at 10:09 PM, wrote: > [W3C Auto] A number of Automotive Manufacturers and Tier 1 suppliers have > contributed to the ideas in the specification which focusses on exposing >

Re: W3C Proposed Recommendation: Webmention

On Fri, Nov 4, 2016 at 1:25 PM, L. David Baron wrote: > W3C Editor's draft: https://webmention.net/draft/ Wow, that is an extraordinarily wordy document for something that does so little. It's the first I've heard of this, but it's remarkably similar to (albeit much

Re: Removing navigator.buildID?

On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor wrote: > Taking a step back: is fingerprinting really a solvable problem in > practice? At this point, are there a significant fraction of users > who can't be fingerprinted pretty reliably? Inevitably, the more > features we add to

Re: Proposed W3C Charter: Web of Things Working Group

On Tue, Oct 11, 2016 at 12:52 PM, L. David Baron wrote: > My initial reaction would be to worry about whether there's > properly-incubated material here that's appropriate to charter a > working group for, or whether this is more of a (set of?) research > projects. W3C has an

Re: Proposed W3C Charter: Web of Things Working Group

On Thu, Oct 13, 2016 at 6:21 AM, Benjamin Francis wrote: > Much more compelling is the member submission from EVRYTHNG which also forms > the basis of the book, Building the Web of Things. Yes, that is a much clearer articulation of a vision. It starts going off the rails

Re: Proposed W3C Charter: Web of Things Working Group

On Thu, Oct 13, 2016 at 11:26 AM, Tantek Çelik wrote: > Security is the number one problem for anything "ot" (iot, wot, > wotever), I agree with this sentiment, but I don't think that we need to insist that a new W3C group solve these issues. I'm very much concerned with

Re: Proposed W3C Charter: Automotive Working Group

This seems to be a more specific instance of WoT. As such, the goals are much clearer here. While some of the concerns with the WoT charter apply (security in particular!), here are a few additional observations: Exposing the level of information that they claim to want to expose needs more

Re: Proposed W3C Charter: Verifiable Claims Working Group

On Tue, Dec 13, 2016 at 5:56 AM, Eric Rescorla wrote: > Following up to myself: if the plan is really that people will have a > single identity that they then present to everyone and that claims hang > off, I think W3C should not standardize that. A lot hinges on the nature of

Re: Intent to ship: NetworkInformation

On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky wrote: > 2) Figure out a way to map the one bit of information we actually want to > expose into some sort of values that look like the existing API. Change the > spec as needed to allow tweaks we want to make here (e.g. to allow

Re: Intent to implement: HTML5 element

On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky wrote: > Note that I expect that this spec was written before Promise was a thing. > The setup where we return a value in an attribute of the element (!) is > pretty bizarre... Is this irredeemable? I mean, the attribute is

Re: Intent to implement: HTML5 element

On Fri, Dec 23, 2016 at 6:20 PM, Boris Zbarsky wrote: >> I mean, the attribute is probably a lost cause > > Why? Is there significant usage, or at least wide implementation, of that > part of the API already? The original intent said that only Chrome is > shipping this. Fair

Re: Intent to ship: NetworkInformation

On Mon, Dec 19, 2016 at 8:23 PM, Gervase Markham wrote: > We already do network change detection now, ISTR; could we pop a > doorhanger when we get a network change event, of the form of something > like "maintain 'expensive data' status Y/N?"...? No more doorhangers please. I

Re: Phabricator Update, July 2017

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 exist with patches attached, that would be greatly appreciated. I would also assume

Re: Phabricator Update, July 2017

On Wed, Jul 12, 2017 at 6:41 AM, Mark Côté wrote: > * MozReview and Splinter turned off in early December. Is this bugzilla-wide? I know that other project use splinter still. Will those projects be able to use phabricator for their projects? For instance, NSS uses a

Re: Extensions and Gecko specific APIs

On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholt wrote: > On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: >> Should we moz-prefix moz-specific extensions? > > We have been trying not to do that for Web-exposed APIs but maybe the > extensions case

Re: Ambient Light Sensor API

On Wed, Apr 26, 2017 at 10:26 PM, Eric Rescorla wrote: >> Surely we can avoid this problem without being so >> drastic? > > > Perhaps, but actually designing such security measures is expensive, so > absent some argument that this is in wide use, probably doesn't > pass a

Re: Ambient Light Sensor API

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 restriction doesn't really help here. Critically, rate limit access much more than the 60Hz

Re: Ambient Light Sensor API

On Fri, Apr 28, 2017 at 1:56 PM, Ehsan Akhgari wrote: >> While it does not address the attack, it should be limited to secure >> context, if we keep the API. It's actually in the spec. > > Why is that an advantage? Any attacker can use a secure context. The word >

Re: Restricting the Notifications API to secure contexts

More than fine, this is an overdue change :) Notifications being available on http:// origins is a source of a small amount of pain for web push, because the two share the same permission. On Tue, Aug 8, 2017 at 2:24 AM, Eric Rescorla wrote: > This seems fine. > > -Ekr > > > On

Re: Intent to ship: SharedArrayBuffer and Atomics

On Thu, May 11, 2017 at 5:57 PM, Lars Hansen wrote: > We do think there are > architectural improvements that hardware manufacturers, operating systems, > and browsers can make [19], and we intend to investigate them. I think that the work you cite is promising. However,

Re: Improving visibility of compiler warnings

On Sat, May 20, 2017 at 4:55 AM, Kris Maglione wrote: > Can we make some effort to get clean warnings output at the end of standard > builds? A huge chunk of the warnings come from NSS and NSPR, and should be > easily fixable. Hmm, these are all -Wsign-compare issues bar

Re: Improving visibility of compiler warnings

On Thu, May 25, 2017 at 6:03 AM, Nathan Froyd wrote: > Where does NSS do this? Cloning the NSS tree and grepping for > sign-compare turns up no disabling of -Wsign-compare, except perhaps > in XCode for gtest itself. My bad, -Wsign-compare is in -Wextra, and we don't enable

Re: Intent to ship: NetworkInformation

On Sat, May 20, 2017 at 2:05 AM, Ben Kelly wrote: > Can the people who have concerns about the NetworkInformation API please > provide the feedback to google on this blink-dev thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/UVfNMH50aaQ/FEQNujAuBgAJ In short,

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 12:07 PM, L. David Baron wrote: > I think I do this because (b) has the disadvantage that more code > changes require touching additional lines, which is both changes > blame and is extra work (although it's not extra work if we're using > clang-format

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 5:21 PM, Sylvestre Ledru wrote: > Could you report a bug? We wrote a few patches upstream to improve > the support of our coding style. This isn't a bug either, but I've noticed that alignment anywhere can cause collateral changes. `clang-format

Re: Coding style: Placement of binary operators when breaking a long line

On Fri, Sep 8, 2017 at 1:08 AM, Ehsan Akhgari wrote: > The great majority of code changing is quite expected for any project > switching to clang-format, since as it turns out automated tools are much > better at doing this grunt work than humans are. The reason projects

Re: Device Memory header and JS API

On Fri, Sep 8, 2017 at 5:32 AM, Tom Ritter wrote: > On Thu, Sep 7, 2017 at 1:09 PM, Shubhie Panicker via dev-platform > wrote: >> Curious - are there concerns with implementing Client Hints in general? > > Yes. But the fingerprinting team

Re: Device Memory header and JS API

Why do the numbers need to be standardized? Could we give browsers the ability to change the value in response to their understanding of the current situation. Surely an Android device is easily identifiable as such, so we could choose values that reflect our Android population at the current

Re: Follow up on clang-format

On Tue, Sep 26, 2017 at 10:49 PM, Sylvestre Ledru wrote: >> clang-format messes up really badly many macros. >> For example nsElementTable.cpp becomes unreadable. > > Yeah, for this kind of structure & presentation layout, we should just ignore the formatting on these. > > It

<    1   2   3   >