Intent to implement and ship: fetch() cache control API

*Summary*: This API allows a web page to specify how the resources it fetches interact with the browser HTTP cache. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1120715 *Link to standard*: https://fetch.spec.whatwg.org/ *Platform coverage*: All platforms *Estimated or target release*:

Re: HTML-based chrome and

On 2016-02-26 5:52 PM, Fabrice Desré wrote: > On 02/26/2016 02:42 PM, Ehsan Akhgari wrote: > >>> Look at what you need to implement to get the simplest gecko based >>> product that builds with --enable-application=my_great_app and compare >>> it to the same pr

Intent to implement and ship: fetch() referrer and referrer policy APIs

*Summary*: These APIs allow a web page to specify a referrer and a referrer policy when fetching a resource. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1184549 *Link to standard*: https://fetch.spec.whatwg.org/ *Platform coverage*: All platforms *Estimated or target release*: Firefox 47

Re: Just Autoland It

On 2016-01-22 2:10 PM, Gregory Szorc wrote: On Fri, Jan 22, 2016 at 7:30 AM, Boris Zbarsky wrote: On 1/22/16 10:08 AM, Andrew Halberstadt wrote: In the end, it's on the reviewer. If the patch is complicated, has open dependencies or looks like it might cause problems, as a

Re: Moving FirefoxOS into Tier 3 support

Hi Fabrice, On 2016-01-25 11:00 AM, Fabrice Desré wrote: Hi all, With the smartphone activity shifting to a more exploratory status, we have been discussing with the platform & releng people which setup would allow us to keep improving the product and supporting our community of users while

Re: Moving FirefoxOS into Tier 3 support

On 2016-01-25 12:11 PM, Fabrice Desré wrote: Hi Ehsan, On 01/25/2016 08:38 AM, Ehsan Akhgari wrote: I have two questions about this: 1. What does this mean for Firefox OS specific code in Gecko which is designed to keep some level of testing possible on the Firefox OS side by adding hacks

Re: Just Autoland It

On 2016-01-23 1:20 PM, Gregory Szorc wrote: On Fri, Jan 22, 2016 at 1:45 PM, Boris Zbarsky wrote: On 1/22/16 3:52 PM, Gregory Szorc wrote: I would say that pushing cherry-picked commits for review that depend on other commits not in the commit's ancestry is just wrong. If

Re: Just Autoland It

On 2016-01-23 9:37 PM, Boris Zbarsky wrote: On 1/23/16 2:41 PM, Ehsan Akhgari wrote: FWIW, option 3 is basically my usual workflow Option 3, or option 2? Just to recap, option 3 is that I write patches for bug A and bug B in that order in my tree (A, then B) and ask for review on both

Re: Moving FirefoxOS into Tier 3 support

On 2016-01-25 5:59 PM, Juan Gómez wrote: Yeah, upgarding to gcc 4.8 was a bit tough but it established the basis for less compllcated upgardes in the future. I could compile all FFOS flavors (ICS, JB, KK and LL) using gcc-4.9 base toolchain without any remarcable complication. My plan was to

Re: Intent to switch to Visual Studio 2015

On 2016-03-17 8:35 PM, Yuhong Bao wrote: >> On Thu, Mar 17, 2016 at 3:30 PM, >> > wrote: >> What about the depreciation of XP SP2? >> >> Results from bug 1124017 say XP SP2 still works on binaries built with >> VS2015u1. This may not

Re: Proposal: revisit and implement navigator.hardwareConcurrency

On 2016-03-14 3:23 PM, Boris Zbarsky wrote: > On 9/8/15 3:21 PM, Luke Wagner wrote: >> On a more technical detail: WebKit and Chromium have both shipped, >> returning the number of logical processors where WebKit additionally >> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed

Re: Proposal: revisit and implement navigator.hardwareConcurrency

On 2016-03-14 6:43 PM, Kyle Huey wrote: > On Mon, Mar 14, 2016 at 2:30 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto:ehsan.akhg...@gmail.com>> wrote: > > On 2016-03-14 3:23 PM, Boris Zbarsky wrote: > > On 9/8/15 3:21 PM, Luke Wagner wrote: >

Re: Intent to enable e10s by default when running tests locally

On 2016-03-24 1:25 PM, Andrew McCreight wrote: > One potential sticking point is mochitest-chrome. It currently does not >> get run in e10s in CI, so local configuration should mirror this. >> However, since --e10s is being removed, this means it would be >> impossible to run mochitest-chrome in

Re: Intent to enable e10s by default when running tests locally

y confusing. :( Should we refuse to accept --e10s when running mochitest-chrome to help avoid this confusion? > > On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > >> On 2016-03-24 1:25 PM, Andrew McCreight wrote: >> > One potent

Re: Status: e10s on 45, 46, and 47

Hi Jim, On 2016-03-07 10:25 AM, Jim Mathies wrote: > Users involved in this experiment will: > > - not have addons installed > - will not have used accessibility recently (including touch screen users) > - will not be using rtl builds Out of curiosity, what's the reason for excluding the RTL

Re: Intent to enable e10s by default when running tests locally

On Sun, Apr 3, 2016 at 11:51 PM, Blair McBride wrote: > Default options imply the default is somehow favoured over the > non-default. Which, for this, makes me wonder: Is getting tests passing on > non-e10s less important now? > Fennec doesn't use e10s, so at least for

Re: Intent to unship: Mobile ID API

Thanks for cleaning this stuff up! On 2016-03-29 2:26 PM, Fernando Jiménez Moreno wrote: > Hello, > > the non-standard Mobile Identity API [1] allows a privileged web application > to obtain a verified phone number [1]. It is only available on Firefox OS and > it was added with FxOS Hello

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

On 2016-04-29 1:39 AM, Jonathan Kew wrote: > On 28/4/16 18:11, Jeff Muizelaar wrote: >> Do we use any of the OS specific parts of ICU? > > I don't know. What are those OS specific parts? ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Static analysis for "use-after-move"?

On 2016-04-28 8:00 AM, Gerald Squelart wrote: > On Thursday, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote: >> Can we catch this pattern with a compiler somehow? >> >> Foo foo; >> foo.x = thing; >> DoBar(mozilla::Move(foo)); >> if (foo.x) { /* do stuff */ } I think so. We already have an

Re: Static analysis for "use-after-move"?

On 2016-04-28 8:53 AM, smaug wrote: > On 04/28/2016 08:00 AM, Gerald Squelart wrote: > >> Because sometimes the function will choose not to actually move from >> an rvalue-ref > > FWIW, this is the reason why I think Move is broken by definition. Move > doesn't move anything. > It should have

Re: Static analysis for "use-after-move"?

On 2016-04-28 8:54 AM, Jack Moffitt wrote: > I apologize if this seemed flippant. I sent it sincerely to show that > such an analysis is possible, and it makes up one of the key features > of Rust. I have no idea how feasible this is to implement in C++, but > I suspect it must be hard as it is

Re: Static analysis for "use-after-move"?

On 2016-04-28 9:00 AM, Gerald Squelart wrote: > On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote: >> On 2016-04-28 8:00 AM, Gerald Squelart wrote: >>> On Thursday, April 28, 2016 at 9:35:56 AM UTC+10, Kyle Huey wrote: >>>> Can we catch this p

Re: Static analysis for "use-after-move"?

On 2016-04-28 9:09 AM, Gerald Squelart wrote: > On Thursday, April 28, 2016 at 11:00:12 AM UTC+10, Gerald Squelart wrote: >> On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote: >>> On 2016-04-28 8:00 AM, Gerald Squelart wrote: >>>> On Thursday, Ap

Re: Static analysis for "use-after-move"?

On 2016-04-28 9:52 AM, Gerald Squelart wrote: > On Thursday, April 28, 2016 at 11:25:38 AM UTC+10, Ehsan Akhgari wrote: >> On 2016-04-28 9:00 AM, Gerald Squelart wrote: >>> On Thursday, April 28, 2016 at 10:41:21 AM UTC+10, Ehsan Akhgari wrote: >>>> On 2016-04-28

Re: Static analysis for "use-after-move"?

On 2016-04-28 10:48 AM, Jed Davis wrote: > Kyle Huey writes: > >> Can we catch this pattern with a compiler somehow? >> >> Foo foo; >> foo.x = thing; >> DoBar(mozilla::Move(foo)); >> if (foo.x) { /* do stuff */ } > > https://bugzilla.mozilla.org/show_bug.cgi?id=1186706 >

Re: Intent to remove:

On 2016-04-26 10:42 PM, Boris Zbarsky wrote: > I think removing this is reasonable at this point So... The last time that I personally used the "we're the only engine shipping this feature, therefore it must be safe to remove" argument for unshipping something, we ended up breaking a huge

Re: Clarifications needed to 'Intent to ship' process

On Wed, Apr 27, 2016 at 12:33 PM, smaug <sm...@welho.com> wrote: > On 04/26/2016 01:47 PM, Ehsan Akhgari wrote: > >> On 2016-04-26 1:02 PM, Mike Hommey wrote: >> >>> On Mon, Apr 25, 2016 at 10:52:02PM -0400, Boris Zbarsky wrote: >>> >>>> On 4/

Re: Clarifications needed to 'Intent to ship' process

On 2016-04-25 10:58 PM, Boris Zbarsky wrote: > That said, note that a bunch of the items above lie somewhat out of a > specific module, so it's not clear to me that we want intent-to-ship OKs > to be module-specific. Yeah, a bunch of stuff definitely crosses multiple module boundaries, so I think

Re: Clarifications needed to 'Intent to ship' process

On 2016-04-26 1:02 PM, Mike Hommey wrote: > On Mon, Apr 25, 2016 at 10:52:02PM -0400, Boris Zbarsky wrote: >> On 4/25/16 10:34 PM, Mike Hommey wrote: >>> Don't we already have that with superreviewers? >> >> Kinda, sorta. >> >>> (How outdated is that list, btw?) >> >> Quite. If we're talking

Re: Reverting to VS2013 on central and aurora

On 2016-05-10 9:43 PM, Lawrence Mandel wrote: > On Tue, May 10, 2016 at 7:05 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto:ehsan.akhg...@gmail.com>> wrote: > > On 2016-05-10 4:45 PM, Gregory Szorc wrote: > > On Thu, May 5, 2016 at 9:26 PM, G

Re: Reverting to VS2013 on central and aurora

On 2016-05-10 10:01 PM, Robert Strong wrote: > On Tue, May 10, 2016 at 6:55 PM, Lawrence Mandel > wrote: > >> On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg >> wrote: >> >>> I agree that we should drop support for non-SSE2. It mattered 7 years ago

Re: Intent to remove:

On Wed, Apr 27, 2016 at 8:54 AM, Henri Sivonen wrote: > > As much as I'd like us to get rid of as soon as we can, I > > oppose doing so without first measuring its actual usage for Firefox > > through telemetry. > > Suppose we measured hitting the isindex special case in

Re: Spidernode/JXCore

On 2016-04-14 12:08 PM, Steve Fink wrote: > On 04/14/2016 06:21 AM, Philip Chee wrote: >> On 12/04/2016 19:27, Henri Sivonen wrote: >> >>> My understanding is that >>> https://git.merproject.org/mer-core/qtmozembed/ still uses it. As we >>> are figuring out how to be more embeddable (see >>>

Re: Intent to implement: CSS Houdini - Properties & Values API Level 1

On 2016-07-22 5:26 PM, Jonathan Chan wrote: > Summary: > > Allow web developers to register typed and animatable custom CSS properties > through JavaScript with configurable inheritance and initial values. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1273706 > Link to standard:

Re: Reproducible builds

On 2016-07-18 2:56 PM, Gregory Szorc wrote: > A significant obstacle to even comparable builds is "private" data embedded > within Firefox. e.g. Google API Keys. I /think/ we're also shipping some > DRM blobs. Then of course there is build signing, which takes a private key > and cryptographically

Re: Redirecting http://hg.mozilla.org/ to https://

I have two extra suggestions for added security benefits: 1. In order to ensure that clients that support CSP will never attempt to contact the HTTP version of the site for fetching any subresources that may still point to http:, please make sure to serve the |Content-Security-Policy:

Re: Intent to unship: xml:base attribute

On 2017-02-16 6:06 PM, Xidorn Quan wrote: > On Fri, Feb 17, 2017, at 01:38 AM, Ehsan Akhgari wrote: >> On 2017-02-16 1:51 AM, Xidorn Quan wrote: >>> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 >>> >>> Summary: >>> * It has been re

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On 2017-02-10 7:51 PM, 段垚 wrote: > > > 在 2017/2/11 2:26, t...@ritter.vg 写道: >> On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote: >>> I thought I enumerated the harm at first, but I'll elaborate a little. >>> >>> 1) Flash doesn't know about and breaks our "current and

Re: Changing the representation of rectangles in platform code

On 2017-02-11 3:27 AM, ISHIKAWA,chiaki wrote: > On 2017/02/11 7:07, Botond Ballo wrote: >> On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic >> wrote: >>> First step needs to happen completely before the second step does, so I >>> guess the danger is that we start and give

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On 2017-02-13 11:50 AM, 段垚 wrote: > > > 在 2017/2/14 0:24, Ehsan Akhgari 写道: >> On 2017-02-10 7:51 PM, 段垚 wrote: >>> >>> 在 2017/2/11 2:26, t...@ritter.vg 写道: >>>> On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote: >>>

Re: Tool for converting C++ standard library naming style to Gecko naming style?

On 2017-02-16 7:41 AM, Henri Sivonen wrote: > Is there some kind of tool, similar to ./mach clang-format for > whitespace, that changes identifies from C++ standard library style to > Gecko style? > > I.e. foo becomes Foo, foo_bar becomes FooBar and arguments and members > get prefixed with a and

Re: Intent to unship: xml:base attribute

On 2017-02-16 1:51 AM, Xidorn Quan wrote: > Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 > > Summary: > * It has been removed from the spec years ago. > * No other browser supports it. > * We pay performance penalty for it. > * It makes things trickier for stylo to handle URL

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

On 2016-08-30 11:44 AM, Benjamin Smedberg wrote: > This is notice of an intent to change how we export symbols from the > Firefox DLLs and binaries. > > Currently our policy is that extensions may not include binary XPCOM > components, and we've implemented some very basic rules that make it >

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

On 2016-08-31 9:27 AM, Benjamin Smedberg wrote: > > > On Tue, Aug 30, 2016 at 6:08 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto:ehsan.akhg...@gmail.com>> wrote: > > > Can you please clarify why this proposal is around preventing external &g

Re: Intent to unship: SimplePush API

On 2016-08-31 4:09 AM, Gabriele Svelto wrote: > Hello, > the non-standard SimplePush API provided a mechanism for Firefox OS to > receive push messages before the standard Push API was finalized. With > the standard Push API now implemented in Gecko and already enabled on > Android builds it

Re: upcoming meeting announcement - intermittent orange hacking

Given the platform-wide D meeting scheduled for the same date and time, is this going to be rescheduled for this week? Thanks! On Mon, Oct 3, 2016 at 3:01 PM, jmaher wrote: > Every 2 weeks on Friday at 9 PDT [1] we will be hosting a meeting to > discuss intermittent

Re: Intent to unship: Canvas ImageBitmapRenderingContext

Thanks Morris! As far as I know, no other engine has shipped this feature, is that correct? On 2016-10-07 3:34 AM, Morris Tseng wrote: > In bug 1172796, we shipped ImageBitmapRenderingContext accidentally. Due to > spec change very rapidly. We would like to unship this feature until the > spec

Re: Intent to unship: Use strict in function with non-simple parameters

On 2016-10-07 8:01 AM, Tom Schuster wrote: > To simplify parsing ES 2016 disallows "use strict" in functions with > non-simple parameters, like defaults or rest. > > For example `function f(a = 1) { "use strict"; }` is going to start > throwing. > > Chrome, JSC and Edge already made this change.

Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case

Also, in many cases the HTTP cache may not have enough space to store a downloaded movie, for example. But more importantly, it seems to me that relying on the browser's internal magic for this is error prone. For example, the video player reusing the same URL as the one being passed to

Re: Converting assertions into release assertions

On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote: > On 23/09/2016 11:20, Ted Mielczarek wrote: >> On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote: >>> I used to do that in the past, but nowadays artifact builds have changed >>> the cost-benefit trade-off so very few people bother AFAIK, when

Re: Converting assertions into release assertions

On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote: > On 23/09/2016 11:20, Ted Mielczarek wrote: >> On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote: >>> I used to do that in the past, but nowadays artifact builds have changed >>> the cost-benefit trade-off so very few people bother AFAIK, when

Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case

On 2016-09-21 4:35 PM, Robert O'Callahan wrote: > On Thu, Sep 8, 2016 at 5:45 AM, Andrew Sutherland < > asutherl...@asutherland.org> wrote: > >> A motivating use-case is for a site that wants to download movies/podcasts >> in the background and keep them around for offline purposes. Once the

Re: Converting assertions into release assertions

On 2016-09-22 9:07 AM, Gijs Kruitbosch wrote: > On 22/09/2016 05:28, Nicholas Nethercote wrote: >> Greetings, >> >> Assertions, such as MOZ_ASSERT, are great. But they only run in debug >> builds. >> >> Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds. >> >> I want to highlight a

Re: New [must_use] property in XPIDL

On 2016-08-23 6:30 PM, Gerald Squelart wrote: > On the build-time vs static analysis point: > > I'd much prefer to have errors pointed out right from './mach build', which I > can fix on the spot; rather than wait hours until I notice static analysis > errors on a treeherder build. > (e.g., I

Re: Intent to restrict to secure contexts: navigator.geolocation

On 2016-10-22 9:32 AM, Richard Barnes wrote: > On Fri, Oct 21, 2016 at 8:59 PM, Chris Peterson > wrote: > >> On 10/21/2016 3:11 PM, Tantek Çelik wrote: >> Does this mean that we'd be breaking one in 5 geolocation requests as a > result of this? That seems super

Re: Intent to restrict to secure contexts: navigator.geolocation

On 2016-10-22 10:16 AM, Boris Zbarsky wrote: > On 10/22/16 9:38 AM, Richard Barnes wrote: >> I'm not picky about how exactly we turn this off, as long as the >> functionality goes away. Chrome and Safari both immediately call the >> error >> handler with the same error as if the user had denied

Re: Intent to restrict to secure contexts: navigator.geolocation

an extremely low bar. While it's easy for us to match that bar, we can (and I argue we should) do better. PS. Please note that I'm disappearing later today going on vacation, which may mean I may not get to continue arguing this side. I'm secretly hoping someone else will. :-) > On 10/22/16

Re: Intent to restrict to secure contexts: navigator.geolocation

On 2016-10-24 4:14 AM, Gervase Markham wrote: > On 22/10/16 18:12, Ehsan Akhgari wrote: >> Have we considered doing something here to help the user when we block >> this API? For example, we could check to see whether the site has a TLS >> version > > If ther

Intent to ship: Selection events

As of Firefox 52, I'm planning to let the selection events API < http://w3c.github.io/selection-api/#user-interactions> ride the trains on all platforms. This feature has been implemented and enabled on Nightly behind the dom.select_events.enabled pref since September last year. Blink, WebKit and

Re: Intent to ship: NetworkInformation

On 2016-12-15 11:14 AM, Boris Zbarsky wrote: > On 12/15/16 11:00 AM, Ben Kelly wrote: >> We are shipping the connection type information on android already. >> Since >> FF32 as far as I can tell. > > That's... not great. Especially since there was no intent to ship at > the time. FWIW Chromium

Re: Intent to ship: NetworkInformation

On 2016-12-15 11:14 AM, Boris Zbarsky wrote: > On 12/15/16 11:00 AM, Ben Kelly wrote: >> We are shipping the connection type information on android already. >> Since >> FF32 as far as I can tell. > > That's... not great. Especially since there was no intent to ship at > the time. FWIW Chromium

Re: Intent to ship: NetworkInformation

On 2016-12-15 2:53 PM, Boris Zbarsky wrote: > On 12/15/16 2:39 PM, Ehsan Akhgari wrote: >> FWIW I was one of the people who were involved in the discussions around >> this for Firefox OS. From what I remember, the argument for shipping >> this API was that web develo

Re: Intent to Implement: Private Browsing Storage (IndexedDB, Blobs, etc)

This is great Kyle. Historically this has been one of the biggest requests that we've had from developers with regards to private browsing. I'm happy that we're finally addressing this use case. On Tue, Dec 13, 2016 at 7:35 PM, Kyle Machulis wrote: > In bug 781982,

Re: Intent to Implement: Private Browsing Storage (IndexedDB, Blobs, etc)

On Wed, Dec 14, 2016 at 9:35 AM, Ben Kelly wrote: > On Tue, Dec 13, 2016 at 7:35 PM, Kyle Machulis > wrote: > > > AFAIK, Chrome's strategy for this is to just store everything in memory > and > > keep a fairly small size cap on it (something like

Re: Runnable labeling for Quantum DOM

On 2016-12-01 11:21 PM, Boris Zbarsky wrote: > On 12/1/16 10:40 PM, Bill McCloskey wrote: >> As part of the Quantum DOM project, we're going to be "labeling" all >> runnables in the browser to say which document they're operating on. > > Is the intent basically to get rid of

Re: Runnable labeling for Quantum DOM

On 2016-12-02 12:42 PM, Tom Tromey wrote: >> "Bill" == Bill McCloskey writes: > > Bill> As part of the Quantum DOM project, we're going to be "labeling" all > Bill> runnables in the browser to say which document they're operating on. > > I wonder whether this can be

Re: tier-2 Windows clang-cl static analysis builds running on inbound

On 2016-12-29 9:34 AM, Ryan VanderMeulen wrote: > On 12/23/2016 3:21 PM, Nicholas Nethercote wrote: >> Hooray! >> >> What is the name of the job on Treeherder? I see a "Windows 2012 x64 opt >> Executed by TaskCluster build-win64-clang/opt tc(Bcl)" job (and some >> minor >> variations) but I

Re: Intent to ship: NetworkInformation

On 2016-12-18 4:16 PM, Karl Dubost wrote: > When reading a thread about a new API or feature such as… > > Le 16 déc. 2016 à 04:39, Ehsan Akhgari <ehsan.akhg...@gmail.com> a écrit : >> From what I remember, the argument for shipping >> this API was that web

Re: Who loves multiple selection feature in editor?

On 2016-12-18 5:09 PM, Karl Dubost wrote: > As Ehsan said: > > Le 17 déc. 2016 à 02:32, Ehsan Akhgari <ehsan.akhg...@gmail.com> a écrit : >> (I also wonder how many people even know about these ways to create >> multi-range selections, given how undiscoverable they are!

Re: Introducing mozilla::Result for better error handling

On 2016-12-20 8:46 AM, Jan de Mooij wrote: > Hi all, > > A few weeks ago we added mozilla::Result to MFBT [0][1]. Amazing! > I was asked > to inform dev-platform about this, so here's a quick overview. > mozilla::Result is based on Rust's Result type [2]. It contains > either a

Re: Intent to implement and ship: CSS caret-color property

Gecko supports a navigation mode caret which can be activated by pressing F7 or Preferences -> Advanced -> General -> Always use the cursor keys to navigate within pages. The spec does mention this, but I can’t figure out what it’s saying that the browser should do with the navigation caret.

Re: Introducing mozilla::Result for better error handling

On 2016-12-23 6:40 AM, Nicholas Nethercote wrote: > It was once a mess, but is not any more. MFBT has for some time used > standard Mozilla style, with the following minor exception described in > mfbt/STYLE: > > - Some of the files use a lower-case letter at the start of function names. > This

Re: GCC 4.9 now required to build on Linux/Android

On 2016-12-23 11:08 AM, Nathan Froyd wrote: > This change paves the way for being able to compile in C++14 mode for > all of our Tier-1 platforms, which in turn unlocks using some C++14 > features in our codebase: > > * binary literals > * digit separators > * generic lambdas > * initialized

Re: Intent to implement and ship: CSS caret-color property

On 2016-12-23 8:13 PM, Xidorn Quan wrote: > On Sat, Dec 24, 2016, at 04:32 AM, Ehsan Akhgari wrote: >> Gecko supports a navigation mode caret which can be activated by >> pressing F7 or Preferences -> Advanced -> General -> Always use the >> cursor keys to navigat

Re: Who loves multiple selection feature in editor?

On 2016-12-19 6:59 PM, Mats Palmgren wrote: > I've made an example Grid to illustrate that last point, try selecting > the first column then the second (first some A's then some B's) > (you need Nightly or DevEdition for the example to work): >

Re: GCC 4.9 now required to build on Linux/Android

On 2016-12-23 6:39 PM, gsquel...@mozilla.com wrote: >> paves the way for being able to compile in C++14 > So, can we start using the good stuff right now, or should we wait for a > proper "go" signal? Bug 1325632 needs to be fixed first. Currently we still build in C++11 mode.

Re: Who loves multiple selection feature in editor?

On 2016-12-15 4:46 AM, Masayuki Nakano wrote: > At investigating selection API behavior, I realized that non-Gecko > engines don't support multiple selection. > > For example, document.getSelection().addRange(somethingNewRange) does > nothing when the selection has a range. > > You can see the

Re: Intent to ship: NetworkInformation

On 2016-12-15 6:28 PM, Boris Zbarsky wrote: > On 12/15/16 6:15 PM, Ehsan Akhgari wrote: >> (I personally agree with most of what you said, except that I'm >> convinced that we should expose that one bit.) > > Exposing this one bit makes a lot of sense to me. >

Re: Faster gecko builds with IceCC on Mac and Linux

On Thu, Mar 23, 2017 at 7:51 PM, Jeff Gilbert wrote: > I'm interested to find out how the new Ryzen chips do. It should fit > their niche well. I have one at home now, so I'll test when I get a > chance. > Ryzen currently on Linux implies no rr, so beware of that. > On

Re: Future of out-of-tree spell checkers?

On Wed, Mar 22, 2017 at 11:50 AM, Jeff Muizelaar wrote: > On Wed, Mar 22, 2017 at 11:08 AM, Henri Sivonen > wrote: > > > > dlopening libvoikko, if installed, and having thin C++ glue code > > in-tree seems much simpler, except maybe for sandboxing.

Quantum Flow Engineering Newsletter #3

Hi everyone, Another week, another Quantum Flow engineering newsletter! We have a lot to cover, so let me get started. Michael Layzell is getting really close on his work on bug 1346415 in order to collect native stacks from Background Hang

Re: Cost of "duplicating" (or "worse") large parts of web-platform-tests

On 2017-03-20 2:19 PM, Anne van Kesteren wrote: > web-platform-tests has a nice feature which generates a bunch of > boilerplate for you for dedicated worker tests and tests that can be > run both in a window and a dedicated worker: > >

Re: Third Party Library Alert Service

On 2017-03-18 3:22 PM, Daniel Veditz wrote: > On Fri, Mar 17, 2017 at 3:26 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto:ehsan.akhg...@gmail.com>> wrote: > > We have library imports that are forks, for example > ​ ​ > dom/media/webaudio/blin

Re: Switching to async/await from Task.jsm/yield

On 2017-03-17 7:41 PM, Kris Maglione wrote: > On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote: >> Have we measured the performance of our async/await implementation? I >> think we should definitely do some extensive testing of the performance >> of any new

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

On 2017-03-17 10:08 AM, Michael Layzell wrote: > I don't think we have any particularity good tools for this right now. A > while ago I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1320179 to > add a separate crate like the nsstring crate which provides the nsresult > bindings. If we are

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

On 2017-03-21 10:40 PM, Boris Zbarsky wrote: > On 3/21/17 4:34 PM, Eric Rahm wrote: >> This doesn't affect the behavior of |Preferences::AddStrongObserver| >> which >> does prefix matching, correct? > > That's correct. Same for AddWeakObserver. > > It's a little harder to misuse because it

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

017 at 11:26 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto:ehsan.akhg...@gmail.com>> wrote: > > On 2017-03-17 10:08 AM, Michael Layzell wrote: > > I don't think we have any particularity good tools for this right now. A > > while ago I filed http

Re: Future of out-of-tree spell checkers?

bt that MoCo will prioritize supporting a whole new spell checking backend for 2 new languages, but I think we can do a lot to help. > On Fri, Mar 24, 2017 at 6:20 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto:ehsan.akhg...@gmail.com>> wrote: > > On 201

Re: Future of out-of-tree spell checkers?

On 2017-03-24 4:20 AM, Henri Sivonen wrote: > On Fri, Mar 24, 2017 at 2:38 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: >> On Wed, Mar 22, 2017 at 11:50 AM, Jeff Muizelaar <jmuizel...@mozilla.com> >> wrote: >>> >>> On Wed, Mar 22, 2017

Quantum Flow Engineering Newsletter #2

Hi everyone, This past week was another busy week chasing down performance issues in Firefox. We managed to knock out a few issues, get closer to close out a couple of really high impact ones, and are making good progress on starting to get performance data from telemetry which will hopefully

Re: Tracking bug for removals after XPCOM extensions are no more?

On 2017-03-16 2:29 PM, Bobby Holley wrote: > On Thu, Mar 16, 2017 at 11:23 AM, R Kent James wrote: > >> On 3/15/2017 3:51 PM, Benjamin Smedberg wrote: >> >>> after Firefox 57 when >>> Webextensions are the only extensions, if our product no longer needs some >>> functionality

Posthumous intent to unship: experimental createImageBitmap() overload accepting ArrayBuffer and ArrayBufferView arguments

Last night, we were informed of security vulnerabilities in the implementation of an experimental extension to createImageBitmap() accepting ArrayBuffer and ArrayBufferView arguments which, as it turns out, was accidentally shipped in bug 1141979. After careful examination it became clear that

Re: Switching to async/await from Task.jsm/yield

On 2017-03-16 6:29 PM, Dave Townsend wrote: > For a long time now we've been writing JS code that waits for promises > using Task.jsm and generator functions. Recently though the JS team > added support for the JS standard way of doing this, async/await: >

Re: Third Party Library Alert Service

We have library imports that are forks, for example dom/media/webaudio/blink, as the README file explains. That should probably be removed from that list. On 2017-03-17 2:30 PM, Tom Ritter wrote: > As part of a broader initiative to perform a security review of the > third party libraries we

Re: Intent to ship: IntersectionObserver API

On 2017-03-15 8:14 AM, Michael de Boer wrote: > Hi Tobias, > > Very exciting! This is a _very_ welcome addition to the family of Web APIs, > IMHO. > > I’m curious about the performance characteristics for consumers of this API: > how does it scale in respect to > 1. The amount of observers

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 11:07 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > > Now, on to the credits section. I’d like to take a moment to recognize > the work of the following individuals who have helped with various aspects > of the Quantum Flow project. Thank you

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 4:27 PM, Kris Maglione <kmagli...@mozilla.com> wrote: > On Thu, Mar 16, 2017 at 11:07:19AM -0400, Ehsan Akhgari wrote: > >> This is why a while ago we decided to disallow the addition of new >> synchronous IPC messages by default (bug 13369

Re: Intent to change editor newline behavior

On Tue, Apr 4, 2017 at 11:31 AM, Aryeh Gregor <a...@aryeh.name> wrote: > On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > > I don't own this module any more, so this isn't my call to make, but if > > I had to choose what to do here,

Re: Tier 3 win64 ASan builds on try

On 2017-04-10 12:47 AM, Chris Pearce wrote: > On Friday, April 7, 2017 at 2:11:32 PM UTC+12, Ting-Yu Chou wrote: >> Just a heads up that now we have win64 ASan builds on try. The try format: >> >> try: -b o -p win64-asan -u none -t none >> >> Bug 1347793 is tracking the failed tests on

Re: Tier 3 win64 ASan builds on try

Indeed, thanks Ting-Yu and everyone else who finally made this happen. This is extremely valuable, especially for Gecko developers who work on security sensitive bugs, as they can now use address sanitizer on Windows similarly to other major OSes that we support! On 2017-04-07 4:25 PM, Kan-Ru

<    5   6   7   8   9   10   11   12   13   >