Intent to prototype and ship: signal property on AddEventListenerOptions

Summary: https://github.com/whatwg/dom/issues/911 proposes to add signal property to AddEventListenerOptions const ac = new AbortController(); target.addEventListener('fooEvent', (e) => { ... }, { signal: ac.signal } ); so that one can easily remove the event listener when AbortController is

Re: Firefox Profiler now supports recording IPC messages

FWIW, apparently the UI is in the devtools profiler UI, not in the profiler addon. https://profiler.firefox.com/ still tells users to install the addon from there. I was told that one can get the button similar to the addon by enabling devtools.performance.popup.enabled boolean pref and then

Re: To what extent is sccache's distributed compilation usable?

On 10/24/19 9:17 AM, Marcos Caceres wrote: On Thursday, October 24, 2019 at 6:46:08 AM UTC+11, Christopher Manchester wrote: As announced in this week's project call, sccache-dist schedulers have been deployed to mozilla offices, and those with hardware available can enroll servers based on

Of writing asynchronous tests

Hi all, during the past year, while optimizing page load by changing how various tasks within Gecko are scheduled, intermittently failing tests have often caused trouble and required fixes to them or occasionally disabling them. Now with Fission we are seeing even more issues and we will do

Re: Finding windows and docshells leaked until shutdown

On 10/3/19 1:18 AM, Andrew McCreight wrote: On Wed, Oct 2, 2019 at 2:35 PM Geoff Lankow wrote: Hi all, I need some advice. I'm trying to enable Mochitest on debug builds of Thunderbird. It works fine, except for the leak check, which finds a number of leaked windows and docshells. Obviously

Re: Range-based for and STL-style iterators for nsClassHashtable, nsDataHashtable, nsInterfaceHashtable

And as with other data structures, be careful with modifications when using range-based for. We had plenty of crash issue with nsTArray + range-based for when we started to use it. -Olli On 10/2/19 1:15 PM, Simon Giesecke wrote: Hi, I recently [1] added STL-style iterators and

Of writing asynchronous tests

Hi all, during the past year, while optimizing page load by changing how various tasks within Gecko are scheduled, intermittently failing tests have often caused trouble and required fixes to them or occasionally disabling them. Now with Fission we are seeing even more issues and we will do

Intent to implement & ship: queueMicrotask

Summary: queueMicrotask exposes the platform primitive to queue microtasks. Without the API, web pages have used hacks around MutationObserver or Promise. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480236 Link to standard:

MOZ_ALLOW_DOWNGRADE environment variable

Hi all, looks like I didn't send email about, IMO, rather useful environment variable [1]: MOZ_ALLOW_DOWNGRADE does the same thing as --allow-downgrade passed to firefox, bypasses the profile downgrade protection. (At least I need to bypass that all the time when testing various local and/or

Disabling document.createEvent("TouchEvent"), document.createTouch* and ontouch* event handlers on desktop

Hi all, I'm trying to disable document.createEvent("TouchEvent"), document.createTouch* and ontouch* event handlers on desktop in order to follow what has been done in other browsers. See https://bugzilla.mozilla.org/show_bug.cgi?id=1412485 The issue is that some web pages use those features

Re: Browser Architecture Newsletter #7 (S02E02)

On 09/20/2018 04:21 PM, Mike Hommey wrote: On Thu, Sep 20, 2018 at 12:18:49PM +0300, smaug wrote: On 09/19/2018 08:34 PM, Nicholas Alexander wrote: 2. Making the main browser window be an HTML document with (mostly) HTML DOM elements instead of a XUL document with (mostly) XUL DOM

Re: Browser Architecture Newsletter #7 (S02E02)

On 09/19/2018 08:34 PM, Nicholas Alexander wrote: 2. Making the main browser window be an HTML document with (mostly) HTML DOM elements instead of a XUL document with (mostly) XUL DOM elements. It is still mystery to me how the performance can be anywhere close to XUL when starting

Re: Plan for Sunsetting MozReview

On 09/05/2018 06:40 AM, Kris Maglione wrote: On Tue, Sep 04, 2018 at 07:37:28PM +0200, Dão Gottwald wrote: This may have been discussed before since it's kind of an obvious question: Was there a conscious decision not to post phabricator review comments to bugzilla? It's a somewhat significant

Re: Extending the length of an XPCOM string when writing to it via a raw pointer

On 08/30/2018 11:21 AM, Henri Sivonen wrote: We have the following that a pattern in our code base: 1) SetCapacity(newCapacity) is called on an XPCOM string. 2) A pointer obtained from BeginWriting() is used for writing more than Length() but no more than newCapacity code units to the XPCOM

Re: Intent to Ship: Shadow DOM and Custom Elements

On 08/15/2018 06:06 PM, darin.hens...@gmail.com wrote: On Wednesday, August 15, 2018 at 5:56:06 AM UTC-5, smaug wrote: On 08/15/2018 01:54 PM, smaug wrote: On 08/14/2018 09:43 PM, darin wrote: When it ships in version 63 will shadowdom and webcomponent be shipped disabled or enabled

Some of the Phabricator review requests don't show up in Bugzilla dashboard

Hi all, I think it is good to let people know that some of the review requests in Phabricator don't show up in Bugzilla. https://bugzilla.mozilla.org/show_bug.cgi?id=1482110 So, if some review seems to take too much time, better to ping the requestee. -Olli

Re: Intent to Ship: Shadow DOM and Custom Elements

sites, but there isn't too much we can do other than trying to ship. David On 10 August 2018 at 15:49, smaug wrote: I'm planning to keep Shadow DOM and Custom Elements turned on on beta/release builds. Target release is Firefox 63. prefs are dom.webcomponents.customelements.enabled

Intent to Ship: Shadow DOM and Custom Elements

I'm planning to keep Shadow DOM and Custom Elements turned on on beta/release builds. Target release is Firefox 63. prefs are dom.webcomponents.customelements.enabled and dom.webcomponents.shadowdom.enabled. Custom elements has been enabled in Nightly since January and Shadow DOM since late

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On 07/12/2018 11:08 PM, Randell Jesup wrote: I do hope that the 100 process figures scenario that was given is a worse case scenario though... It's not. Worst case is a LOT worse. Shutting down threads/threadpools when not needed or off an idle timer is a Good thing. There may be some perf

Re: Intent to implement: Clear-Site-Data header

On 06/20/2018 04:14 PM, Andrea Marchesini wrote: Summary: The Clear-Site-Data header allows a secure origin to send a header requesting the deletion of its own browsing data. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1268889 Link to standard:

Re: PSA: new CopyableErrorResult class

On 04/27/2018 12:14 AM, Ben Kelly wrote: Hi all, I just pushed another helper class that I thought others might find useful. CopyableErrorResult is a specialized form of ErrorResult. Its intended to allow slightly more rich error values to be passed through things like ipdl structure and

Re: Default Rust optimization level decreased from 2 to 1

On 04/25/2018 08:38 PM, Bobby Holley wrote: On Wed, Apr 25, 2018 at 10:21 AM, Ted Mielczarek wrote: On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote: At minimum we should make --enable-profiling build with rust-opt. This sounds reasonable, although the quirk is

Re: PSA: Deprecating JS-Implemented WebIDL

On 04/24/2018 09:25 AM, Andreas Tolfsen wrote: Also sprach Bobby Holley: For reasons outlined in bug 1450827, the DOM peers have decided to deprecate support for JS-implemented WebIDL APIs. This means that new additions of |JSImplementation="foo"| are no longer permitted. Out of curiosity,

Phabricator and Bugzilla

Hi all, just some random notes about Phabricator. I've been reviewing now a bunch of patches in Phabricator and the initial feeling from reviewer's point of view is that it is ok. Not great, but ok. MozReview's interdiff, when it works, is easier to use or at least to discover than

Re: Use cases for invalid-Unicode atoms

On 03/19/2018 09:30 PM, Kris Maglione wrote: On Mon, Mar 19, 2018 at 08:49:10PM +0200, Henri Sivonen wrote: It appears that currently we allow atomicizing invalid UTF-16 string, which are impossible to look up by UTF-8 key and we don't allow atomicizing invalid UTF-8. I need to change some

Re: Improved wpt-sync now running experimentally

On 02/09/2018 10:39 PM, James Graham wrote: On 09/02/2018 19:59, Josh Bowman-Matthews wrote: On 2/9/18 1:26 PM, James Graham wrote: * One bug per PR we downstream, filed in a component determined by the files changed in the PR. What does this mean exactly? What is the desired outcome of

Re: Faster gecko builds with IceCC on Mac and Linux

On 01/16/2018 11:41 PM, Mike Hommey wrote: On Tue, Jan 16, 2018 at 10:02:12AM -0800, Ralph Giles wrote: On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard wrote: But I would be interested in knowing how long that same Lenovo P710 takes to compile *today*…. On my

Re: Refactoring proposal for the observer service

On 01/04/2018 12:30 AM, Ben Kelly wrote: On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: So after validating my approach in that bug (which is almost ready) I've thought that it might be time to give the observer service the same treatment. First of all we'd have a

Re: Next year in web-platform-tests

Great work on wpt! On 12/15/2017 05:38 PM, James Graham wrote: Following the summary of what we achieved in wpt in the last year, I'd like to solicit input from the gecko community to inform the priorities of various pieces of wpt work for the next year. In order to maximise the compatibility

Re: Problems of Microtasks & Promises in Firefox

since the end of last year to push this forward by providing a correct microtask scheduling (Thanks Olli(:smaug) for the major work of the new scheduling patch) and fixing the test failures in our implementation discovered by the scheduling change. Good news is that we have all WPT green no

Re: Hiding 'new' statements - Good or Evil?

On 11/28/2017 06:33 AM, Boris Zbarsky wrote: On 11/27/17 7:45 PM, Eric Rescorla wrote: As for the lifetime question, can you elaborate on the scenario you are concerned about. Olli may have a different concern, but I'm thinking something like this: for (auto foo : myFoos) { foo->bar();

Re: Hiding 'new' statements - Good or Evil?

rom it. Sure, prove it out. But we really don't need more moz-specific constructs. We should choose our deviations carefully. On Mon, Nov 27, 2017 at 3:24 AM, smaug <sm...@welho.com> wrote: On 11/27/2017 01:05 PM, Nicolas B. Pierron wrote: On 11/26/2017 12:45 AM, smaug wrote: On 11/24/2

Intent to implement (again): Shadow DOM

This is basically an after the fact notification that we're in progress of implementing Shadow DOM again, this time v1[1]. While doing this, the v0 implementation, which was never exposed to the web, will be removed. v1 is luckily way simpler, so this all should simplify various bits in DOM.

Re: Intent to implement (again): Shadow DOM

On 11/27/2017 02:20 PM, smaug wrote: This is basically an after the fact notification that we're in progress of implementing Shadow DOM again, this time v1[1]. While doing this, the v0 implementation, which was never exposed to the web, will be removed. v1 is luckily way simpler, so this all

Re: Hiding 'new' statements - Good or Evil?

On 11/27/2017 01:05 PM, Nicolas B. Pierron wrote: On 11/26/2017 12:45 AM, smaug wrote: On 11/24/2017 06:35 PM, Eric Rescorla wrote: On Thu, Nov 23, 2017 at 4:00 PM, smaug <sm...@welho.com> wrote: On 11/23/2017 11:54 PM, Botond Ballo wrote: I think it makes sense to hide a 'new

Re: Hiding 'new' statements - Good or Evil?

On 11/24/2017 06:35 PM, Eric Rescorla wrote: On Thu, Nov 23, 2017 at 4:00 PM, smaug <sm...@welho.com> wrote: On 11/23/2017 11:54 PM, Botond Ballo wrote: I think it makes sense to hide a 'new' call in a Make* function when you're writing an abstraction that handles allo

Re: Hiding 'new' statements - Good or Evil?

On 11/23/2017 11:54 PM, Botond Ballo wrote: I think it makes sense to hide a 'new' call in a Make* function when you're writing an abstraction that handles allocation *and* deallocation. So MakeUnique makes sense, because UniquePtr takes ownership of the allocated object, and will deallocate it

Re: Intent to ship: CSP Violation DOM Events

On 11/17/2017 12:55 AM, Chung-Sheng Fu wrote: Content Security Policy suggests Security Policy Violation DOM Events [1]. In case any of the directives within a policy are violated, such a SecurityPolicyViolationEvent is generated and sent out to a reporting endpoint associated with the policy.

Re: Website memory leaks

On 11/02/2017 09:58 PM, Kris Maglione wrote: Related: I've been thinking for a long time that we need better tools for tracking what sites/usage patterns are responsible for the time we spend in CC (and possibly GC, but I think that tends to be less of a problem). I've noticed, in particular,

Re: Website memory leaks

On 11/02/2017 10:01 PM, Kris Maglione wrote: On Thu, Nov 02, 2017 at 05:37:30PM +0200, smaug wrote: This has been an issue forever, and there aren't really good tools on any browser, as far as I know, for web devs to debug their leaks. Internally we do have useful data (CC and GC graphs

Re: Website memory leaks

This has been an issue forever, and there aren't really good tools on any browser, as far as I know, for web devs to debug their leaks. Internally we do have useful data (CC and GC graphs and such), but would need quite some ux skills to design some good UI to deal with leaks. Also, the data to

Re: Visual Studio 2017 coming soon

+1 On Mon, Oct 30, 2017 at 8:03 AM, smaug <sm...@welho.com> wrote: On 10/30/2017 04:52 PM, Simon Sapin wrote: On 30/10/17 15:05, smaug wrote: And let's be careful with the new C++ features, pretty please. We managed to not be careful when we started to use auto, or ranged-for or lambdas.

Re: Visual Studio 2017 coming soon

On 10/30/2017 04:52 PM, Simon Sapin wrote: On 30/10/17 15:05, smaug wrote: And let's be careful with the new C++ features, pretty please. We managed to not be careful when we started to use auto, or ranged-for or lambdas. I'd prefer to not fix more security critical bugs or memory leaks just

Re: Visual Studio 2017 coming soon

And let's be careful with the new C++ features, pretty please. We managed to not be careful when we started to use auto, or ranged-for or lambdas. I'd prefer to not fix more security critical bugs or memory leaks just because of fancy hip and cool language features ;) -Olli On 10/30/2017

Re: De-XBL Plans

On 10/21/2017 01:14 PM, Philipp Kewisch wrote: On 10/20/17 7:47 PM, Dave Townsend wrote: For some time now we've been talking about moving away from XUL and XBL. The browser architecture team has been hard at work figuring out how to go about doing that and we're ready to share the first of our

Re: De-XBL Plans

On 10/21/2017 11:45 PM, Yura Zenevich wrote: I would also like to bring to the team's attention another force worth being on the radar (in terms of "forces on the system") - accessibility. One theme that seems to consistently happen with re-writes such as the ones from xul to React is

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

Sounds very reasonable. (Hoping the r=documentation flag won't be misused ;)) On 10/19/2017 04:37 PM, Andreas Tolfsen wrote: Some time ago there was a discussion on dev-builds@ regarding the state of our in-tree source code documentation. The main focus was that MDN, moving forward, will

Re: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)

On 10/18/2017 08:08 AM, Jet Villegas wrote: SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for oldest fixed bug? whoohoo, didn't realize it was that old. One day I'll start reading the bugs I review ;) That is, do I owe you another steak? :-) On Wed, Oct 18, 2017

Re: Experimenting with a shared review queue for Core::Build Config

On 10/11/2017 09:55 PM, Andreas Tolfsen wrote: +tools-marionette Also sprach Chris Cooper: Many of the build peers have long review queues. Is having a long review queue the actual issue? Isn't (too) high throughput at least equally bad issue. Does the new setup somehow try to ensure reviews

Re: Follow up on clang-format

On 05/23/2014 04:29 AM, Anthony Jones wrote: Some of you may remember the discussion on clang-format and the `mach clang-format` command. What we have in place right now is very temporary but it is functional enough to give it a try. I have not put the effort into upstreaming my changes.

Re: More Rust code

ust we throw that away. I agree. but we are quickly going to hit a point where "I don't feel like learning Rust" is not going to cut it anymore. Indeed. On Tue, Jul 11, 2017 at 4:37 PM, smaug <sm...@welho.com> wrote: How is the performance when crossing Rust <-> C++

Extensions and Gecko specific APIs

Hi all, recently in couple of bugs there has been requests to add Gecko specific APIs for extensions. It isn't clear to me why, and even less clear to me is what the plan is there. I thought WebExtensions should work in several browsers, but the more we add Gecko specific APIs, the less

Re: Phabricator Update, July 2017

On 07/12/2017 04:20 PM, Ben Kelly wrote: On Tue, Jul 11, 2017 at 11:49 PM, Martin Thomson wrote: On Wed, Jul 12, 2017 at 1:34 PM, Byron Jones wrote: instead of disabling splinter for phabricator backed products, we could make it a read-only patch

Re: More Rust code

On 07/11/2017 04:27 PM, Ben Kelly wrote: On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote wrote: If I were the owner of that module I would consider implementing a policy something

Re: More Rust code

On 07/10/2017 01:29 PM, Nicholas Nethercote wrote: Hi, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.org/Oxidation for details. I think this is an excellent trend, and I've been thinking about how to accelerate it. Here's a

Re: More Rust code

On 07/10/2017 09:04 PM, zbranie...@mozilla.com wrote: One more thought. There's a project that fitzgen told me about that aims to allow for components to communicate between JS and Rust using Streams. If we could get to the point where instead of WebIDL/XPIDL we could just plug streams

Re: Converting const char ()[N] to nsACString

On 07/04/2017 04:47 PM, Dexter wrote: Hi everyone! Could you tell me please, how I can clearly convert char ()[N] to nsACString? I tried this: char* cname = new char[N]; memcpy(cname, , N); nsAutoString strName; strName.AssignWithConversion(cname, N); I can't find out how to get nsACString.

Re: How can I run Firefox programatically in fullscreen?

On 06/27/2017 12:12 AM, Armen Zambrano Gasparnian wrote: Asking around, looking on dxr or MDN did not yield something easily. I don't want to have to use Marionette in this specific automation context. Thanks in advance, Armen Do you mean fullscreen in chrome level, or running web pages in

Re: How are events passed between chrome and content?

On 06/16/2017 02:32 AM, Jim Porter wrote: On 6/15/17 4:12 PM, Kartikaya Gupta wrote: Not quite. For e10s, mouse events are sent across the process boundary using the PBrowser ipdl protocol. On the parent side they go into EventStateManager::DispatchCrossProcessEvent [1] which picks up the

Re: Avoiding jank in async functions/promises?

On 05/18/2017 09:25 PM, Domenic Denicola wrote: On Thursday, May 18, 2017 at 4:34:37 AM UTC-4, smaug wrote: FWIW, I just yesterday suggested in #whatwg that the platform should have something like IdlePromise or AsyncPromise. And there is the related spec bug https://github.com/whatwg/html

Re: Avoiding jank in async functions/promises?

FWIW, I just yesterday suggested in #whatwg that the platform should have something like IdlePromise or AsyncPromise. And there is the related spec bug https://github.com/whatwg/html/issues/512#issuecomment-171498578 On 05/18/2017 04:22 AM, Mark Hammond wrote: Given our recent performance

Re: Using references vs. pointers in C++ code

On 05/09/2017 04:52 PM, smaug wrote: On 05/09/2017 01:55 PM, Mike Hommey wrote: On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote: On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: I think references help to encode that a bit more in the type

Re: Using references vs. pointers in C++ code

On 05/09/2017 01:55 PM, Mike Hommey wrote: On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote: On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote: I think references help to encode that a bit more in the type system, and help reasoning about the code

Re: Ambient Light Sensor API

On 04/25/2017 04:38 PM, Ehsan Akhgari wrote: On 04/24/2017 06:04 PM, Martin Thomson wrote: I think that 60Hz is too high a rate for this. I suggest that we restrict this to top-level, foreground, and secure contexts. Note that foreground is a necessary precondition for the attack, so that

Re: A reminder about commit messages: they should be useful

On 04/25/2017 08:20 PM, Boris Zbarsky wrote: On 4/25/17 1:07 PM, Alexander Surkov wrote: I bet there's always room for improvements, and I hope this was a counterpoint for the example only, not for the bug organization approach. Sort of. It was a counterpoint to "just check the bug; all the

Re: IPDL now supports async returns with MozPromise

On 04/20/2017 05:15 AM, Bevis Tseng wrote: A soft reminder of using AbstractThread::GetCurrent()/MainThread() ​ after some design change for Quantum-DOM. If this message/callback is to be handled on *the main thread of the content process*, please use the replacement called

Re: A reminder about commit messages: they should be useful

On 04/18/2017 04:24 PM, Ehsan Akhgari wrote: On 2017-04-18 12:30 AM, Mike Hommey wrote: I've yet to see that to happen. What is crucial is fast way to browse through the blame in time. So commit messages should be short and descriptive. Telling what and why. (I very often need to go back to CVS

Re: A reminder about commit messages: they should be useful

On 04/18/2017 03:12 AM, gsquel...@mozilla.com wrote: On Tuesday, April 18, 2017 at 11:58:11 AM UTC+12, smaug wrote: On 04/18/2017 02:36 AM, Gregory Szorc wrote: On Mon, Apr 17, 2017 at 4:10 PM, smaug <sm...@welho.com> wrote: On 04/17/2017 06:16 PM, Boris Zbarsky wrote: A quick re

Re: A reminder about commit messages: they should be useful

On 04/18/2017 02:36 AM, Gregory Szorc wrote: On Mon, Apr 17, 2017 at 4:10 PM, smaug <sm...@welho.com> wrote: On 04/17/2017 06:16 PM, Boris Zbarsky wrote: A quick reminder to patch authors and reviewers. Changesets should have commit messages. The commit message should describe no

Re: A reminder about commit messages: they should be useful

On 04/17/2017 06:16 PM, Boris Zbarsky wrote: A quick reminder to patch authors and reviewers. Changesets should have commit messages. The commit message should describe not just the "what" of the change but also the "why". This is especially true in cases when the "what" is obvious from the

Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

On 04/05/2017 07:34 PM, Tom Ritter wrote: On Tue, Apr 4, 2017 at 10:29 PM, wrote: Security & Privacy Concerns: none It looks like this exposes pointerType, which reveals whether the user is using a mouse, pen, or touch input. Note, that is already available through

Re: Please write good commit messages before asking for code review

On 03/10/2017 12:43 AM, Ben Kelly wrote: On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote: On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: I review a large number of patches on a typical day, and usually I have to spend a fair amount of time to just

Re: The future of commit access policy for core Firefox

On 03/10/2017 12:59 AM, Bobby Holley wrote: At a high level, I think the goals here are good. However, the tooling here needs to be top-notch for this to work, and the standard approach of flipping on an MVP and dealing with the rest in followup bugs isn't going to be acceptable for something

Re: The future of commit access policy for core Firefox

On 03/12/2017 10:40 PM, Ehsan Akhgari wrote: On 2017-03-11 9:23 AM, smaug via governance wrote: On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: I'd be ok to do a quick r+ if interdiff was w

Re: The future of commit access policy for core Firefox

On 03/11/2017 08:23 AM, Nicholas Nethercote wrote: On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: I'd be ok to do a quick r+ if interdiff was working well. Depending on the relative timezones of the reviewer and reviewee, that could delay l

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

change Definitely use cache * every page load This happens rarely, so probably doesn't matter etc. I wonder, if everybody uses Add*VarCache, doesn't it cause another performance problem when a pref is changed? On 2017/02/22 20:18, smaug wrote: Hi, Preferences::GetBool is a slow hashtable

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

matches the one you requested a cache for. So if you have prefs "blah.foo" and "blah.foo.bar", changing blah.foo.bar will write garbage into your cache for blah.foo. https://bugzilla.mozilla.org/show_bug.cgi?id=1208744 ~ Gijs On 22/02/2017 11:18, smaug wrote: Hi, Preference

Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

Hi, Preferences::GetBool is a slow hashtable lookup and has been showing up in performance profiles in many places. Please use Preferences::AddBoolVarCache. Same with other pref types. Or if the pref needs to be read just once, store the value in some static variable or so. -Olli

Re: Intent to ship: Event.timeStamp as DOMHighResTimeStamp

On 02/21/2017 07:03 AM, Brian Birtles wrote: As of Firefox 54, I intend to turn on, by default, the code that makes Event.timeStamp a DOMHighResTimeStamp. This makes this member a double whose value is the number of milliseconds since the time origin. This has been developed behind the

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

On 02/18/2017 07:08 PM, Eric Rescorla wrote: I'd also note that if we're not going to use "this is what we have done historically" as a guide, then it seems like much bigger changes are on the table and we would probably be better off adopting some other well-defined coding standard wholesale

Re: Mozilla naming style vs. C++ standard library containers

On 02/16/2017 07:24 PM, Henri Sivonen wrote: It seems that we already have MFBT code that has lower case methods begin/end/cbegin/cend, etc., for compatibility with C++ standard library iteration: https://dxr.mozilla.org/mozilla-central/source/mfbt/ReverseIterator.h#136 I guess these methods

Re: Mozilla naming style vs. C++ standard library containers

On 02/16/2017 08:05 PM, smaug wrote: On 02/16/2017 07:24 PM, Henri Sivonen wrote: It seems that we already have MFBT code that has lower case methods begin/end/cbegin/cend, etc., for compatibility with C++ standard library iteration: https://dxr.mozilla.org/mozilla-central/source/mfbt

Re: Please don't add JS implemented telemetry probes to hot code paths. (eom)

On 02/15/2017 12:41 AM, Botond Ballo wrote: But yes, don't implement probes as JS event listener when the event is some rather commonly dispatched. Same applies to observer service observers etc. In bug 1238137, I added a SCROLL_INPUT_METHODS telemetry ping in autoscrollLoop. Is that also

Re: Please don't add JS implemented telemetry probes to hot code paths. (eom)

On 02/12/2017 08:52 PM, Jared Wein wrote: The original email looks to be related to: https://bugzilla.mozilla.org/show_bug.cgi?id=1338891 and https://bugzilla.mozilla.org/show_bug.cgi?id=1338902 though I agree that the message could have been explained a little better. Sorry about that. I

Please don't add JS implemented telemetry probes to hot code paths. (eom)

___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

On Wed, Jan 18, 2017 at 12:50 AM, smaug <sm...@welho.com> wrote: On 01/18/2017 08:28 AM, smaug wrote: On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote: On Mon, Jan 16, 2017 at 3:08 PM, smaug <sm...@welho.com> wrote: On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the thin

Re: Intent to implement and ship: URLSearchParams from array or object

So we'll get support for object too in FF53, not only array? On 01/17/2017 07:11 PM, Andrea Marchesini wrote: Summary: URLSearchParams constructor is changed in the latest URL spec. Now it's possible to create URLSearchParams objects starting from a string, an array and from an object. Bugs:

Re: Deprecating XUL in new UI

On 01/18/2017 08:28 AM, smaug wrote: On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote: On Mon, Jan 16, 2017 at 3:08 PM, smaug <sm...@welho.com> wrote: On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how

Re: Deprecating XUL in new UI

On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote: On Mon, Jan 16, 2017 at 3:08 PM, smaug <sm...@welho.com> wrote: On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application a

Re: Deprecating XUL in new UI

On 01/17/2017 12:05 AM, Dave Townsend wrote: Trees! I knew I was forgetting something, thank you. Yeah those are things we're going to need some sane replacements for. AS far as XBL goes, while I suspect it works from HTML documents I think we want to be phasing out use of XBL too for pretty

Re: Deprecating XUL in new UI

On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible. The benefits for doing this are varied, some obvious examples: * XUL is a proprietary standard and we

Re: Report about the NetworkInformation meeting

On 01/07/2017 02:55 AM, Andrea Marchesini wrote: Today we had a meeting about the next steps for NetworkInformation API. The results of this meeting are: 1. we want to keep what we have in m-c. It means NetworkInformation enabled on fennec, main-thread and workers. It stays disabled on

Re: Intent to Experiment: CSS Houdini Paint API Level 1

On 01/05/2017 06:00 PM, Jet Villegas wrote: Spec: https://drafts.css-houdini.org/css-paint-api/ Summary: The CSS Paint API is the first of several Web Rendering proposals from the CSS Houdini Task Force. The CSS Paint API allows Web authors to define and register a custom Paint method to be

Re: Introducing mozilla::Result for better error handling

On 12/20/2016 03:46 PM, Jan de Mooij wrote: Hi all, A few weeks ago we added mozilla::Result to MFBT [0][1]. 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 success value of type V or

Re: Introducing mozilla::Result for better error handling

On 12/22/2016 08:14 PM, Bobby Holley wrote: We've had this debate several times already, culminating in the attempt to ban NS_ENSURE_* macros. It didn't work. This is a bit different. One of the most common NS_ENSURE_ macros is SUCCESS variant which explicitly has the return value. MOZ_TRY

Re: Intent to unship: BeforeAftereKeyboardEvent

On 12/16/2016 10:36 AM, Masayuki Nakano wrote: Due to the end of B2G platform, I'd like to remove mozbrowserbeforekeydown, mozbrowserbeforekeyup, mozbrowserafterkeydown and mozbrowserafterkeyup events and its event classes. They were implemented by bug 989198 [1] for allowing embedded browser

Re: Intent to ship: NetworkInformation

On 12/15/2016 09: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 developers have been asking for this for

Re: [e10s] Higher priority handling for vsync in child processes

: On 10/11/2016 00:22, smaug wrote: Parent process doesn't yet have higher priority handling [2]. Need to fix racy tests first. Locally using higher priority also in parent process seems to make tab throbber smoother. We have an ad-hoc mechanism for scheduling memory pressure event ahead of all other

[e10s] Higher priority handling for vsync in child processes

Hi, the latest nightly has higher priority for vsync/refreshDriver/requestAnimationFrame handling in child processes [1], which should make rendering updates smoother, at least in some cases. If you see any unexpected behavior, please file bugs and CC me, :smaug. And if there are cases when

Re: HTML spec changes about data: URIs and origins

On 11/07/2016 10:41 PM, smaug wrote: Just to get some idea how many tests would be broken: https://treeherder.mozilla.org/#/jobs?repo=try=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b The results show that quite a few tests need to be fixed, if we want to change data: handling. Should we start

  1   2   3   >