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: 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 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: 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: 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: 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: 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: 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: 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: 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

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/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?

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?

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

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: 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: 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

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: 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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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:

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: 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

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

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

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: 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: 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: 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: 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: 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: 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

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

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:

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

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

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

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

<    1   2   3