Re: Intent to implement: Prerendering API

On 2014-08-12, 11:39 AM, Jesper Kristensen wrote: This templated prerendereing sounds like a complicated API. Is there any advantage of this over what is possible today with a single page application using history.pushState? Yes, I think so. The idea of single page applications is nice, but it

Re: Intent to implement: Prerendering API

On 2014-08-11, 6:03 PM, Jonas Sicking wrote: Very exited to see this happening. Implementation issues aside, I have two comments: * This is something that we really need on FirefoxOS. I hope that the implementation strategy will work there too? Yes, the majority of the code is going to be sha

Re: Are StaticAuto/RefPtr good?

On 2014-08-08, 12:20 PM, Nathan Froyd wrote: - Original Message - OK, I guess that's better than what we have now... Still I thought the goal of this class is to avoid static initializers, so why do we want a trivial destructor for it in release builds? So the compiler won't generate

Re: Are StaticAuto/RefPtr good?

On 2014-08-08, 11:42 AM, Benjamin Smedberg wrote: On 8/8/2014 11:25 AM, Ehsan Akhgari wrote: The problem I was mentioning is not related to the leak at all. What if one of these destructors runs code that writes something to the disk for example, which we expect to go to the disk before we

Re: Are StaticAuto/RefPtr good?

On 2014-08-06, 1:32 PM, Benjamin Smedberg wrote: On 8/6/2014 1:20 PM, Chris Peterson wrote: I don't understand this sentence, but I strongly oppose automatically clearing Static*Ptr in the static destructor in any build. In the past we have had static comptr cause final release of objects aft

Re: Tree Closure Stats - July 2014

Hmm thanks David, this is interesting data! Looking at the chart, the amount of tree closure in the recent past seemed to have peaked in April and have been declining since. Do you have any idea what we've been doing right? I am always uncomfortable with good results that I don't understand!

Re: Are StaticAuto/RefPtr good?

On 2014-08-04, 7:09 PM, Kyle Huey wrote: On Mon, Aug 4, 2014 at 4:06 PM, Mike Hommey wrote: On Mon, Aug 04, 2014 at 03:42:07PM -0700, Kyle Huey wrote: On Mon, Aug 4, 2014 at 3:09 PM, Mike Hommey wrote: On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote: On Sun, Aug 3, 2014 at 11:01 P

Re: Intent to Transition from TBPL to Treeherder

Congratulations on getting to this stage! I would like to help dogfood this, and want to know if I can trust the data parity of Treeherder and TBPL, or if that is something that you would like testing on? IOW, should I keep them both open when watching a tree / try push? Thanks! Ehsan On 2

Re: Resurrecting the Qt toolkit

Wolfgang might be interested in this! On 2014-07-24, 11:21 AM, Tom Schuster wrote: Hello! I am interested in making the Qt toolkit usable again, especially on Linux. While I don't think we can ever actually use it for more platforms, except maybe some mobile devices, it is still something I car

Re: Intent to implement: navigator.deviceStorage

virtual device storage, will discuss it in dev-webapi as well and back to dev-platform when we are going to implement it. Hi Dave and Ehsan, May I know your suggestion? Thanks, Sincerely yours. ---- *寄件者: *"Ehsan Akhgari&

Re: Intent to Implement: New Push API

On 2014-07-21, 4:25 PM, nmara...@mozilla.com wrote: On Monday, July 21, 2014 11:00:13 AM UTC-7, Ehsan Akhgari wrote: On 2014-07-21, 12:22 PM, Tyler Smith wrote: Summary: New Push API to replace the current specification for SimplePush. Purposes include 1) Switching to Promise, which

Re: Intent to implement: navigator.deviceStorage

first step here is to figure out where should new event handler be added? Since there is not only new event handler been added but also a set of APIs potentially, I support to Dave' suggestion. *寄件者: *"Ehsan Akhgari&q

Re: Intent to Implement: New Push API

On 2014-07-21, 12:22 PM, Tyler Smith wrote: Summary: New Push API to replace the current specification for SimplePush. Purposes include 1) Switching to Promise, which was sorely needed. 2) Establishing that the data field of messages is required. 3) Establishing that all background communicatio

Re: Intent to implement: navigator.deviceStorage

On 2014-07-20, 10:43 PM, mc...@mozilla.com wrote: Perhaps adding an EventListener on Window would be enough, so that we can keep the same API? As Dave said, we might still need to propose a set of WebAPI for Virutal Device Storage (Then we can have apps like dropboxstorage app, googledriversto

Re: Intent to implement: AbortablePromise and AbortableProgressPromise

On Sat, Jul 19, 2014 at 5:49 AM, Jonas Sicking wrote: > Something like this is likely to get standardized eventually. But I think > it will take longer than we are willing to wait. > > In the meantime we should only expose this API to pages that have > permission to use DeviceStorage, which is wh

Re: Intent to implement: navigator.deviceStorage

On 2014-07-18, 5:28 PM, Dave Hylands wrote: *From: *"Ehsan Akhgari" *To: *"Dave Hylands" *Cc: *"dev-platform" *Sent: *Friday, July 18, 2014 2:14:50 PM *Sub

Re: Intent to implement: navigator.deviceStorage

On Wed, Jul 16, 2014 at 9:08 PM, Dave Hylands wrote: > Currently, we have navigator.getDeviceStorage and > navigator.getDeviceStorages > > We're looking to expand device storage to add support for more virtual > storage areas, like DropBox, or GoogleDrive, etc. > See bug 1035053 > > I was going t

Re: Intent to implement: AbortablePromise and AbortableProgressPromise

Hi Yuan, Do we have feedback from other browser vendors on these APIs? Is there agreement on them? Cheers, Ehsan On 2014-07-18, 5:29 AM, "Yuan Xulei(袁徐磊)" wrote: Hi all,/ Summary/: These are subclasses of Promise. Allow promise to be canceled or send progress notification. They are planned

Re: PSA: DebugOnly<> fields aren't zero-sized in non-DEBUG builds

Should we make DebugOnly MOZ_STACK_CLASS? On 2014-07-15, 9:21 PM, Nicholas Nethercote wrote: Hi, The comment at the top of mfbt/DebugOnly.h includes this text: * Note that DebugOnly instances still take up one byte of space, plus padding, * when used as members of structs. I'm in the proc

Re: fine-grained filtering of bugmail

On 2014-07-15, 1:04 AM, Byron Jones wrote: Ehsan Akhgari wrote: On 2014-07-14, 9:50 AM, Byron Jones wrote: Ehsan Akhgari wrote: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring

Re: Intent to implement: webserial api

On 2014-07-14, 7:22 AM, tzi...@gmail.com wrote: On Monday, July 14, 2014 2:00:47 PM UTC+3, Gervase Markham wrote: On 13/07/14 18:35, Vasilis wrote: Jonas, I would be really interested in your thoughts. Try as we might (in the WebSerial API docs, at least), noone could actually think of a

Re: fine-grained filtering of bugmail

On 2014-07-14, 9:50 AM, Byron Jones wrote: Ehsan Akhgari wrote: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring (basically all cases except Watching)? In the majority of cases

Re: fine-grained filtering of bugmail

Great feature, Byron! I have three feature requests: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring (basically all cases except Watching)? In the majority of cases I want the same thing to hap

Re: Unimplement: @-moz-document regexp support?

On 2014-07-08, 6:34 PM, L. David Baron wrote: On Monday 2014-07-07 15:18 -0400, Ehsan Akhgari wrote: That seems pretty bad. I think we should at least stop supporting it for Web content. David, what do you think? I'm ok with restricting it to UA and user style sheets, although if

Re: Rethinking the crash experience

We should keep in mind that sometimes due to startup crashes, we don't get to run any of the code in Firefox, so we can't gate the crash report submission on that code at least in the case of startup crashes. Cheers, Ehsan On 2014-07-05, 8:21 AM, David Rajchenbach-Teller wrote: I haven't expe

Re: Unimplement: @-moz-document regexp support?

That seems pretty bad. I think we should at least stop supporting it for Web content. David, what do you think? Cheers, Ehsan On 2014-07-07, 4:56 AM, Frederik Braun wrote: Summary: Attackers can extract secret URL components (e.g. session IDs, oauth tokens) using @-moz-document. Using the r

Re: Try-based code coverage results

This looks awesome, Joshua! Thanks for doing this. CCing Sylvestre who has also started to look into this... Cheers, Ehsan On 2014-07-07, 1:02 AM, Joshua Cranmer 🐧 wrote: I don't know how many people follow code-coverage updates in general, but I've produced relatively up-to-date code cover

Re: Reordering opened windows

On 2014-07-04, 10:38 AM, David Rajchenbach-Teller wrote: Hi, We are considering redesigning slightly how windows are reopened by Session Restore, to ensure that most recently used windows are loaded first. I believe that, in many cases, this would enable users to start browsing faster.

Re: Intent to implement: Ability to surpress default contextmenu items

On 2014-07-02, 4:16 PM, Dao wrote: On 02.07.2014 20:51, Ehsan Akhgari wrote: We can still show the UA context menu if you hold down shift like we do today though. What would be the equivalent to that on Firefox OS? I don't think we have a similar way to do this in Firefox OS. Cheers,

Re: Intent to implement: Ability to surpress default contextmenu items

I have to expand to get to the UA items. Personally whenever I am right clicking on something, it usually to get to a UA option; rarely do I ever use the custom options (either way). With this proposal, my most used options are further away. On 2014-07-02 11:30, Ehsan Akhgari wrote: On 2

Re: Intent to implement: Ability to surpress default contextmenu items

ause most web pages do not have a useful custom context menu? Would you say the same thing about, let's say, Google Docs? The Google Docs custom context menus seem like a great use case for this to me. Cheers, Ehsan On 2014-07-02 11:30, Ehsan Akhgari wrote: On 2014-07-02, 3:12 AM, Henri

Re: Intent to implement: Ability to surpress default contextmenu items

On 2014-07-02, 3:12 AM, Henri Sivonen wrote: On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: we are looking to implement an optional attribute that allows authors to disable the default context menu items so only the applications items are shown. I think we shouldn't do this, since it wou

Re: What are the most important new APIs to document in Q3/Q4?

I can think of EME, the Mobile ID API, and WebCrypto which are missing from this list off the top of my head. Cheers, Ehsan On 2014-06-26, 6:09 AM, Eric Shepherd wrote: Hi! The docs team is trying to build our schedule for the next quarter or two, and part of that is deciding which APIs to spe

Re: Intent to unimplement: proprietary window.crypto functions/properties

Yes, please! With WebCrypto being implemented, there is very little reason for us to keep these functions around. I have heard that there are some enterprise applications that use these APIs and hopefully they will have enough time to migrate away from using them by the time that we ship Fire

Re: Difference from System.Web and System.Net

I believe you are on the wrong mailing list! On 2014-06-26, 5:49 AM, Alonze wrote: Excuse me, could anyone explain me a concept of the differnce between System.Web and System.Net? And how to use two of these? Thank you, Aom ___ dev-platform maili

Re: Proposal for adding named arguments to C++

On 2014-06-18, 2:30 PM, Milan Sreckovic wrote: Works for me. For the function override in the first place though, the names of the parameters are ignored, right? Yes. Basically, I think we should not make the names of the arguments part of the function's type, which would imply that the nam

Re: Proposal for adding named arguments to C++

On 2014-06-14, 10:58 PM, Robert O'Callahan wrote: Looks good. A classic problem we have had is with boolean parameters, which are hard to read at call sites. We currently solve that by turning them into enum or flag parameters, but named parameters would be a lighter-weight alternative. However,

Re: Javascript code coverage ?

On 2014-06-16, 1:23 PM, Sylvestre Ledru wrote: Hello, I am working on providing weekly code coverage of Firefox code. For now, I am able to do that for C/C++ code. Awesome, where can we find those reports? Thanks! Ehsan ___ dev-platform mailing lis

Re: C++ standards proposals of potential interest, and upcoming committee meeting

On 2014-06-11, 1:42 PM, Botond Ballo wrote: I'd very much like to see this as well! The C++11 attribute syntax might be a good way to accomplish this without inventing new syntax. For example, the standard could define an "exhaustive" attribute on a switch statement for an enumeration: enum

Re: Standardized assertion methods

On 2014-06-06, 10:31 PM, Jonas Sicking wrote: But rather than making the implementation of is() be more complex and/or more relaxed, could we instead convert those tests to either is_relaxed(a, b) or ok(a == b) Yes, we could. It's a largish number of tests (several hundred; a number have mult

Re: Standardized assertion methods

On 2014-06-06, 4:11 PM, Boris Zbarsky wrote: On 6/6/14, 3:19 PM, Ehsan Akhgari wrote: Can we make is() do those checks explicitly and if neither of these cases apply, fall back to a non-strict equality check? Yes. As in, we could make it special-case the number-to-string compare and use

Re: Standardized assertion methods

On 2014-06-06, 1:35 PM, Boris Zbarsky wrote: On 6/6/14, 12:21 PM, Boris Zbarsky wrote: That will be the big question, yes. https://tbpl.mozilla.org/?tree=Try&rev=e26ab6d5e1e0 says we have quite a number of things that are in fact assuming that 5 and "5" should test is(). I'm not sure how much

Re: Standardized assertion methods

On 2014-06-05, 2:08 AM, Boris Zbarsky wrote: On 6/4/14, 11:30 PM, Gavin Sharp wrote: - benefits to shared API/implementation seem uncontroversial Agreed. - specifically, consistency between mochitest/SimpleTest-based harnesses (mochitest-plain/mochitest-chrome/mochitest-browser) and xpcshell

Re: bugzilla can now show bugs that have been updated since you last visited them

On Wed, Jun 4, 2014 at 12:43 PM, Gijs Kruitbosch wrote: > On 04/06/2014 07:34, Byron Jones wrote: > >> thanks to dylan's work on bug 489028, bugzilla now tracks when you view >> a bug, allowing you to search for bugs which have been updated since you >> last visited them. >> >> see my blog post f

Re: unused non-[scriptable] XPIDL interfaces no longer shipped with Firefox

On 2014-06-04, 4:45 PM, Nathan Froyd wrote: Bug 996061 has now landed on inbound. Prior to this bug, we included non-[scriptable] XPIDL interfaces into the internal typelibs shipped with Firefox. This is no longer the case: interfaces that are not marked [scriptable] and are not referenced b

Re: bugzilla can now show bugs that have been updated since you last visited them

On 2014-06-04, 3:58 PM, Bobby Holley wrote: On Wed, Jun 4, 2014 at 9:38 AM, Bobby Holley mailto:bobbyhol...@gmail.com>> wrote: Holy moly this is incredible! So this means that I can stop reading bugmail, and rely entirely on the dashboard with no loss of information? I think that is t

Re: Standardized assertion methods

On 2014-06-04, 1:42 PM, Mike de Boer wrote: On 04 Jun 2014, at 19:20, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-06-04, 5:45 AM, Mike de Boer wrote: On 04 Jun 2014, at 00:33, James Graham mailto:ja...@hoppipolla.co.uk>> wrote: On 03/06/14 20:34, Boris Zbarsky

Re: Standardized assertion methods

On 2014-06-04, 5:45 AM, Mike de Boer wrote: On 04 Jun 2014, at 00:33, James Graham wrote: On 03/06/14 20:34, Boris Zbarsky wrote: I'm arguing against Assert.jsm using the commonjs API names. And I am arguing against using the CommonJS semantics. If we are adding new assertions it shouldn't

Re: bugzilla can now show bugs that have been updated since you last visited them

On 2014-06-04, 2:34 AM, Byron Jones wrote: thanks to dylan's work on bug 489028, bugzilla now tracks when you view a bug, allowing you to search for bugs which have been updated since you last visited them. see my blog post for more details: http://wp.me/p1JUqW-9M This is so amazing. As a lon

Re: Google announces Chrome builds for Win64

On 2014-06-03, 2:37 PM, Chris Peterson wrote: http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html What is the status of Firefox builds for Win64? When Mozilla releases Win64 builds (again), we'll be seen as reacting to Google when we've actually been working on it for a w

Re: Standardized assertion methods

On 2014-06-03, 3:34 PM, Boris Zbarsky wrote: On 6/3/14, 2:36 PM, Gregory Szorc wrote: There is a clear win in the ability to reuse, understand, and modify the common code. No one is arguing against having common harness code as far as I can see. I can't even recall which file(s) contain is/o

Re: Standardized assertion methods

On 2014-06-03, 2:17 PM, Gavin Sharp wrote: I won't argue that a great case has been made :) But I see inherent value in consistency (both in the implementations and in the user-exposed API) for assertions across our in-tree test suites (or at least, across mochitest-based harnesses and xpcshell).

Re: Standardized assertion methods

On 2014-06-03, 1:49 PM, Gavin Sharp wrote: On Mon, Jun 2, 2014 at 9:35 PM, Boris Zbarsky wrote: I think what xpcshell has now and what testharness says and what's being proposed (with the "Assert." prefix) are unreasonably long/verbose. I suspected this is where we'd end up :) "Reasonability"

Re: Standardized assertion methods

On 2014-06-03, 12:13 PM, Mike de Boer wrote: On 03 Jun 2014, at 17:39, Ehsan Akhgari wrote: On 2014-06-02, 9:35 PM, Boris Zbarsky wrote: On 6/2/14, 5:33 PM, Gavin Sharp wrote: Do either of you have reasoning for that other than "it looks better to me"? My personal experience is

Re: Policing dead/zombie code in m-c

On 2014-06-03, 5:57 AM, Henri Sivonen wrote: On Wed, May 28, 2014 at 5:45 PM, Nathan Froyd wrote: Assuming that ICU is already compiled with the moral equivalent of GCC's -ffunction-sections -fdata-sections or MSVC's /Gy, then statically linking ICU into libxul should already strip out all th

Re: Standardized assertion methods

On 2014-06-02, 9:35 PM, Boris Zbarsky wrote: On 6/2/14, 5:33 PM, Gavin Sharp wrote: Do either of you have reasoning for that other than "it looks better to me"? My personal experience is that when I try to write xpcshell tests the amount of time it takes to type the test function names is very

Re: Standardized assertion methods

On 2014-06-02, 5:33 PM, Gavin Sharp wrote: Do either of you have reasoning for that other than "it looks better to me"? I personally think consistency trumps any personal preferences based on length/concision, as long as what we end up with isn't unreasonably long/verbose. I have two reasons:

Re: Standardized assertion methods

On Mon, Jun 2, 2014 at 4:14 PM, Boris Zbarsky wrote: > On 6/2/14, 3:34 PM, Paolo Amadini wrote: > >> It seems to me that if we don't have external compatibility needs, we >> might as well move mochitests to use a set of assertion methods that is >> the same as xpcshell and maybe other test suites

Re: Standardized assertion methods

On Mon, Jun 2, 2014 at 12:27 PM, Paolo Amadini wrote: > On 6/2/2014 4:59 PM, Ehsan Akhgari wrote: > > I'm _pretty_ sure that the answer is no for > > mochitest-chrome at least. > > Are we running these tests out-of-tree in other environments? Do you mean by just openi

Re: Standardized assertion methods

mochitest-browser and mochitest-chrome have traditionally used the SimpleTest APIs. I'm not aware of the benefits that Assert.jsm provides, but do we really want to diverge these APIs with mochitest-plain? I'm _pretty_ sure that the answer is no for mochitest-chrome at least. Can you please

Re: Style guide clarity on C++-isms

On 2014-05-29, 1:20 AM, L. David Baron wrote: On Wednesday 2014-05-28 21:03 -0700, Nicholas Nethercote wrote: static T inc(T& aPtr) { return IntrinsicAddSub::add(aPtr, 1); } static T dec(T& aPtr) { return IntrinsicAddSub::sub(aPtr, 1); } static T or_( T& aPtr, T aVal) { return __sync_fetch_an

Re: OMTC on Windows

On 2014-05-22, 5:18 AM, Bas Schouten wrote: Hi Gijs, None of those things are true in my opinion. For what it's worth, the expected regression in CART was more around 20% than around 40%. The number surprises me a little, and we'll look into what makes CART so bad off (on our test servers) sp

Re: Update on sheriff-assisted checkin-needed bugs

On 2014-05-21, 5:15 PM, Chris Peterson wrote: On 5/21/14, 1:51 PM, Mike Conley wrote: Or, alternatively, attempt to automate this with Autoland (https://bugzilla.mozilla.org/show_bug.cgi?id=657828). Is anyone actively working on Autoland? Rail had been working on Autoland, but when I spoke wit

Re: Link coloring in private browsing (Was: Intent to ship: Hyperlink Auditing ())

On 2014-05-21, 4:38 AM, Frederik Braun wrote: On 20.05.2014 23:33, Ehsan Akhgari wrote: On 2014-05-20, 2:25 PM, Jonas Sicking wrote: On Fri, May 16, 2014 at 7:45 AM, Justin Dolske wrote: However we do implement some additional features in private browsing mode. For example we disable link

Re: using namespace

On 2014-05-21, 7:40 AM, Nicolas Silva wrote: Sorry, my example was not clear enough. The issue with using namespace + unifoed builds is that the using namespace declaration applies to all (or most) of the headers included in the unified translation unit. So using namespace mozilla at the top of e

Re: using namespace

On 2014-05-20, 10:00 PM, Joshua Cranmer 🐧 wrote: On 5/20/2014 8:37 PM, Ehsan Akhgari wrote: FWIW, I argued against nested namespaces a few years ago (couldn't find a link to it through Google unfortunately) and people let me "win" that battle by allowing me to edit the coding st

Re: Do we still need Trace Malloc?

On 2014-05-19, 10:25 AM, Nicholas Nethercote wrote: It's used to get stacks within the deadlock detector, but I'm not sure if that's necessary, and it doesn't seem like it would be that hard to replace if it is necessary. You would think so, but I tried in bug 939231 and failed. Cheers, Ehsan

Re: using namespace

On 2014-05-20, 9:11 PM, L. David Baron wrote: On Wednesday 2014-05-21 11:51 +1200, Robert O'Callahan wrote: On Wed, May 21, 2014 at 4:36 AM, Nicolas Silva wrote: Honestly, I don't mean to start a bikeshed about whether we should enforce strict rules about this project-wise, because I know that

Re: Intent to ship: Hyperlink Auditing ()

On 2014-05-20, 6:43 PM, Jonas Sicking wrote: On Tue, May 20, 2014 at 2:33 PM, Ehsan Akhgari wrote: But I believe that that would be a pretty crappy private browsing feature which I don't think anyone here would argue for. Private browsing is mainly about giving you a new, throw-away, ide

Re: Intent to ship: Hyperlink Auditing ()

On 2014-05-20, 2:25 PM, Jonas Sicking wrote: On Fri, May 16, 2014 at 7:45 AM, Justin Dolske wrote: On 5/16/14, 6:38 AM, Curtis Koenig wrote: Would this be disabled in Private Browsing? If not that might be perceived as negating one of the reasons users have for using that particular feature.

Re: Intent to ship: Hyperlink Auditing ()

On 2014-05-16, 9:39 AM, Tim Taubert wrote: Curtis Koenig wrote: Would this be disabled in Private Browsing? If not that might be perceived as negating one of the reasons users have for using that particular feature. Are sync XHRs and HTTP redirects disabled in private browsing? :) They are

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-15, 4:26 AM, Rik Cabanier wrote: On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-05-13, 9:01 PM, Rik Cabanier wrote: ... The problem is that the API doesn't really make it obvious that

Re: Proposed changes to autocomplete administrative levels

On 2014-05-15, 5:29 AM, Anne van Kesteren wrote: On Wed, May 14, 2014 at 1:52 AM, Brian Nicholson wrote: If we disagree with this proposal: What alternatives do we have? Given that countries require more than two administrative levels in postal address, it seems our options are limited. We can

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 9:01 PM, Rik Cabanier wrote: On Tue, May 13, 2014 at 3:16 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: ... That is not the point of this attribute. It's just a hint for the author so he can tune his application

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 2:42 PM, Rik Cabanier wrote: On Tue, May 13, 2014 at 10:43 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-05-13, 9:25 AM, Rik Cabanier wrote: Web applications can already do this today. There's nothing st

Re: nsRefPtr vs RefPtr

On 2014-05-13, 11:46 AM, Tim Abraldes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The chromium IPC code is ours now, so we can mdify it as needed. Not sure about the Chromium sandbox code. The Chromium sandbox code lives at "security/sanbox" in the tree. AIUI, we wanted to be able to

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 11:14 AM, Eli Grey wrote: On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: No, you're wrong. An available core is a core which your application can use to run computations on. If another code is already keeping it

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:54 AM, Eli Grey wrote: On Tue, May 13, 2014 at 1:43 PM, Ehsan Akhgari wrote: supporting a worker pool that actually scales to how many cores you have available 1) What is an "available core" to you? An available core to me is a core that I can use to compute. A

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:44 AM, Rik Cabanier wrote: On Tue, May 13, 2014 at 9:55 AM, Tom Schuster mailto:t...@schuster.me>> wrote: I recently saw this bug about implementing navigator.getFeature, wouldn't it make sense for this to be like hardware.memory, but hardware.cores? Is this a

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:35 AM, Eli Grey wrote: On Tue, May 13, 2014 at 11:20 AM, Ehsan Akhgari wrote: Can you please provide some examples of actual web applications that do this, and what they're exactly trying to do with the number once they estimate one? (Eli's timing attack demos d

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 9:55 AM, Tom Schuster wrote: I recently saw this bug about implementing navigator.getFeature, wouldn't it make sense for this to be like hardware.memory, but hardware.cores? No, because that would have all of the same issues as the current API. Cheers, Ehsan ___

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 9:25 AM, Rik Cabanier wrote: Web applications can already do this today. There's nothing stopping them from figuring out the CPU's and trying to use them all. Worse, I think they will likely optimize for popular platforms which either

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 2014-05-13, 7:47 AM, Benjamin Smedberg wrote: On 5/12/2014 4:07 PM, Boris Zbarsky wrote: So I'd like to propose that our C++ style require one-arg constructors to be marked explicit unless there's a clear comment explaining why the constructor is implicit. Seems there's general agreement. P

Re: nsRefPtr vs RefPtr

On 2014-05-12, 4:48 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 04:46:18PM -0700, Kyle Huey wrote: On Mon, May 12, 2014 at 2:46 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: We should get rid of RefPtr, just like we did the MFBT refcounting classes. The

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 2:37 AM, Rik Cabanier wrote: > On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 >wrote: > > > On 5/12/2014 7:03 PM, Rik Cabanier wrote: > > > >> *Concerns* > >> > >> The original proposal required that a platform must return the exact > >> number > >> of logical CPU cor

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 2014-05-12, 1:07 PM, Boris Zbarsky wrote: Background: in C++, one-argument constructors are implicit. What this means is that given this class declaration: class Foo { public: Foo(int arg); passAFoo(const Foo& arg); }; This bit of C++: Foo foo(5); foo.passAFoo(10)

Re: nsRefPtr vs RefPtr

On 2014-05-12, 2:46 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: We should get rid of RefPtr, just like we did the MFBT refcounting classes. The main thing stopping a mechanical search and replace is that the two smart pointers have different semantics aroun

Re: nsRefPtr vs RefPtr

On 2014-05-12, 9:36 AM, Kyle Huey wrote: Since bug 806279 it's fairly trivial to extend CC support to new pointer and container types. Just implement ImplCycleCollectionUnlink and ImplCycleCollectionTraverse. The possibly bigger difficulty he

Re: PSA: nsTArray lengths and indices are now size_t (were uint32_t)

On 2014-05-11, 10:15 AM, Benoit Jacob wrote: Hi, Since Bug 1004098 landed, the type of nsTArray lengths and indices is now size_t. Code using nsTArrays is encouraged to use size_t for indexing them; in most cases, this does not really matter; however there is one case where this does matter, wh

Re: Intent to implement: WebGL 2.0

On 2014-05-08, 8:55 AM, Anne van Kesteren wrote: On Thu, May 8, 2014 at 12:56 PM, Benoit Jacob wrote: WebGL is low-level and generalistic enough that it is not specifically a "3d" graphics API. I prefer to call it a low-level or generalistic graphics API. Fair, forgot about that argument. "we

Re: Intent to implement: WebGL 2.0

On 2014-05-08, 5:51 AM, Anne van Kesteren wrote: On Wed, May 7, 2014 at 6:19 PM, Benoit Jacob wrote: The "Implementations are free to return a context that implements a higher version" part violates the above requirement 1. in your email, "The WebGL working group wants web pages to opt in to th

Re: Intent to implement: WebGL 2.0

On 2014-05-07, 12:34 PM, Ehsan Akhgari wrote: On 2014-05-07, 11:40 AM, Vladimir Vukicevic wrote: On Wednesday, May 7, 2014 9:20:18 AM UTC-4, Ehsan Akhgari wrote: On 2014-05-07, 6:15 AM, Anne van Kesteren wrote: WebGL is already following the OpenGL path. Trying to make it more "webb

Re: Intent to implement: WebGL 2.0

On 2014-05-07, 11:40 AM, Vladimir Vukicevic wrote: On Wednesday, May 7, 2014 9:20:18 AM UTC-4, Ehsan Akhgari wrote: On 2014-05-07, 6:15 AM, Anne van Kesteren wrote: WebGL is already following the OpenGL path. Trying to make it more "webby" by trying to mush the APIs together isn&#

Re: Intent to implement: WebGL 2.0

On 2014-05-07, 9:37 AM, Robert Kaiser wrote: Dan Glastonbury schrieb: /Summary/: Bring more power of GPU to browsers by exposing OpenGL ES 3 features in WebGL 2.0 We currently have (almost) no documentation on MDN for WebGL 1, do we intend to put concerted work into docs along with bringing up

Re: Intent to implement: WebGL 2.0

On 2014-05-07, 6:15 AM, Anne van Kesteren wrote: WebGL is already following the OpenGL path. Trying to make it more "webby" by trying to mush the APIs together isn't doing the web a favor since the API is already more OpenGL-like, isn't doing developers a favor since they now have to have this

Re: Intent to ship: css sticky positioning in release builds (already done in B2G)

On 2014-05-06, 9:46 PM, Robert O'Callahan wrote: On Wed, May 7, 2014 at 12:31 PM, Kip Gilbert wrote: As of May 7, 2014 I intend to turn css sticky positioning on by default for desktop (already enabled on B2G). It has been developed behind the layout.css.sticky.enabled preference. This featur

Re: Intent to implement: WebGL 2.0

On 2014-05-06, 6:41 PM, Jonas Sicking wrote: That's why if we just expose different features on the object returned by getContext("webgl") depending on client hardware details, we will create a compatibility mess, unlike other Web APIs. The main probably that you have is that you haven't design

Re: Intent to implement: WebGL 2.0

On 2014-05-06, 1:21 PM, Benoit Jacob wrote: 2014-05-06 13:07 GMT-04:00 Boris Zbarsky : On 5/6/14, 12:53 PM, Benoit Jacob wrote: Ah, I see the confusion now. So the first reason why what you're suggesting wouldn't work for WebGL is that WebGL extension my add functionality without changing any

Re: Intent to implement: WebRTC identity and media isolation

Thanks, Martin! Do you know if other UAs are also implementing this API? On 2014-05-02, 4:09 PM, Martin Thomson wrote: Summary: WebRTC enables peer-to-peer communications. Identity features enable the identification of WebRTC peers using a generic identity provider interface. Stream isol

Re: intent to ship: drawFocusIfNeeded

On Thu, May 1, 2014 at 4:10 PM, Rik Cabanier wrote: > > > > On Thu, May 1, 2014 at 11:58 AM, Ehsan Akhgari wrote: > >> On 2014-05-01, 2:22 PM, Rik Cabanier wrote: >> >>> >>> >>> >>> On Thu, May 1, 2014 at 10:49 AM, Ehsan Akhgari

<    4   5   6   7   8   9   10   11   12   13   >