Re: [dev-platform] ESMification: in-tree migration completed!

This is an amazing accomplishment. Thank you to everyone that worked on this project. On Fri, 29 Mar 2024 at 13:01, Tooru Fujisawa wrote: > Hi, everyone! > > > Thanks to everyone’s efforts and cooperations, the Firefox codebase is now > fully ESMified! > > >

[dev-platform] Re: Turning on linting for unused JavaScript function arguments

signature then that is the preferred way to do it rather than disabling the rule entirely. On Wed, 29 Nov 2023 at 11:15, Dave Townsend wrote: > We’re going to start throwing lint errors for unused function arguments. > This matches our existing behaviour of throwing errors for unused var

[dev-platform] Re: Turning on linting for unused JavaScript function arguments

as we have no reliable way of telling which is which and believe that in general removing the arguments is a better cleanup than applying a prefix to everything. On Wed, 29 Nov 2023 at 14:37, Marco Bonardo wrote: > On Wed, Nov 29, 2023 at 2:11 PM Dave Townsend > wrote: > >> >>

[dev-platform] Re: Turning on linting for unused JavaScript function arguments

Those are all cases of unused arguments after any used arguments. Unused arguments before used arguments won't be touched. > On Wed, Nov 29, 2023 at 12:15 PM Dave Townsend > wrote: > >> We’re going to start throwing lint errors for unused function arguments. >> This match

[dev-platform] Turning on linting for unused JavaScript function arguments

We’re going to start throwing lint errors for unused function arguments. This matches our existing behaviour of throwing errors for unused variables within functions. Specifically we will be setting the arguments option for eslint’s no-unused-vars rule to after-used

[dev-platform] New high-level overview docs added to firefox-source-docs

Thanks to the help of more folks than I can remember we've now added some high-level overviews on our applications to firefox-source-docs. This is targeted at new contributors/employees to help them understand the main pieces of the applications and how they fit together. It's deliberately basic,

[dev-platform] Re: Deprecating the chrome and resource protocols

Publicly viewable link for non-employees: https://docs.google.com/document/d/e/2PACX-1vS0E2ANhH7eKkA-LscLudWLguseklE_003b_6nzLGViSYn7z-KS2aHwNpfGUGpRWZZBFBJXS5xY48by/pub On Wed, 7 Jun 2023 at 14:05, Dave Townsend wrote: > Hi all. I've written up a proposal for moving us away from the confus

[dev-platform] Deprecating the chrome and resource protocols

Hi all. I've written up a proposal for moving us away from the confusing chrome and resource URLs that we use internally to reference files in the build in favour of a new simpler URL scheme based on the file's path in the source tree. This will make it clearer to developers where code is coming

Re: [dev-platform] [build] macOS SDK is now bootstrapped

023 at 10:31:54AM +0000, Dave Townsend wrote: > > Does this mean we no longer need XCode installed at all? > > XCode was, in fact, already not required. Some documentations might > still be referencing it, but it hasn't been a strict requirement for a > little while now. You do still

Re: [dev-platform] [build] macOS SDK is now bootstrapped

Does this mean we no longer need XCode installed at all? On Wed, 1 Feb 2023 at 16:47, Mike Hommey wrote: > Hi, > > As of bug 1522986 (on autoland right now, will be on central on the next > merge), the macOS SDK will be bootstrapped automatically rather than the > one installed on the system

Re: [dev-platform] Reducing bugmail by aggregating bot changes

Does this mean I will no longer receive two bugmails when the bot needinfo's me on a bug, one for the change to the bug and one for the flag request? On Wed, 17 Aug 2022 at 19:59, Suhaib Mujahid wrote: > Hello, > > Part of a continuous effort to reduce noize generated by the autonag >

Re: [dev-platform] Re: Removing Services.jsm

It appears to be https://bugzilla.mozilla.org/show_bug.cgi?id=1667455 On Mon, 11 Jul 2022 at 14:05, Rob Wu wrote: > Where is the bug that tracks the removal of the Services.jsm file? > There are still some out-of-tree uses of Services.jsm, and I'd like to > make sure that there is an update

[dev-platform] Re: CSS Preprocessing in moz-central

Yes, excellent work. I'm interested, were there any cases that were left more awkward from removing pre-processing, cases where maybe CSS would benefit from some new feature? On Tue, 29 Mar 2022 at 18:35, Brian Grinstead wrote: > Nice work! Glad to see we were able to move to built-in CSS

Re: [dev-platform] Intent to deprecate InstallTrigger

On Thu, 17 Mar 2022 at 01:50, Daniel Veditz wrote: > On Wed, Mar 16, 2022 at 10:41 AM Luca Greco wrote: > > TL;DR: We are preparing to deprecate the non-standard InstallTrigger > global. > > Thanks for taking this on! As the creator of this API all I can say is > "I'm sorry; it made sense at

Not blocking on UX decisions

Hi folks, We’re all pretty overloaded these days and so, sometimes, it can be hard to get even a small moment of help from a different team when you’re trying to solve a problem. One example of this is when fixing a bug requires changing a small piece of UI and, ideally, you might want to get UX

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

ut not > > long-term usage. Unfortunately I can't settle for a proposal like "allow > it > > only in debug or only in nightlies" because I often need to debug actual > > user-facing builds. Is there any way we could build some auto-expiration > > into this setting,

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

Non-e10s is such a different environment that I don't think we have any hope of keeping it working without running the full test suite in that mode and I don't think anyone wants to do that. Now that this has started breaking I think it is actively harmful to our users for us to allow them to

Re: Testing Rust code in tree

Aha, someone has pointed out that I skipped over rusttests, which don't appear to be listed at https://developer.mozilla.org/en-US/docs/Mozilla/QA/Automated_testing, or indeed anywhere in our various docs that I can see. I guess that makes it my job? On Mon, May 11, 2020 at 3:37 PM Dave Townsend

Testing Rust code in tree

Do we have any standard way to test in-tree Rust code? Context: We're building a standalone binary in Rust that in the future will be distributed with Firefox and of course we want to test it. It lives in-tree and while we could use something like xpcshell to drive the produced executable and

Re: Changes to the Firefox and Toolkit modules

that was what happened. I’ll be reaching out directly to the peers shortly. > On Dec 13, 2019, at 1:03 PM, Dave Townsend wrote: > > The Firefox and Toolkit modules together cover a large amount of code > encompassing the entire front-end of Firefox as well as numerous services > that are u

Changes to the Firefox and Toolkit modules

The Firefox and Toolkit modules together cover a large amount of code encompassing the entire front-end of Firefox as well as numerous services that are used by external projects, notably Thunderbird. For a while now both modules have been owned by me with identical peer lists. We have also had

Re: Intent to Implement and Ship: Make MOZ_QUIET the default, require opt-in for DOMWINDOW/DOCSHELL logs

Thank you for doing this. On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter wrote: > In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to > remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default. > It will automatically be enabled in browser-chrome tests where it is >

Experimenting with JavaScript type safety in mozilla-central

JavaScript powers a lot of Firefox but unlike the other languages that ship code in our product JavaScript uses a dynamic type system. Types for variables are decided at execution time and can change as new values are assigned to them. This leaves you open to accidentally passing the wrong kind of

Re: The sec-approval process makes users safer

On Mon, Sep 9, 2019 at 6:01 PM Jeff Walden wrote: > Those of you longer in the tooth may remember Firefox was successfully > exploited in Pwn2own 2012...and we didn't have to lift a finger to fix it. > We already had -- in the Firefox release shipping days later. 臘 > >

Re: Must we rebuild all our rust code constantly?

Thanks to a tip I've tracked this down. This seems to only be the case when I have sccache enabled. Disabling it gives me nice quick incremental builds again. Of course that isn't an ideal solution but it will do for now. On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend wrote: > For a cou

Must we rebuild all our rust code constantly?

For a couple of weeks now I've seen that any attempt to build Firefox, even incremental builds seem to rebuild an awful lot of rust code. I found this in the source which seems to suggest why: https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238. But, this means that now an

Re: New module proposal: WebCompat Addons

Which section of modules (Core, etc..) do you intend to put this in? On Thu, Jul 18, 2019 at 12:47 PM Dennis Schubert via governance < governance@lists.mozilla.org> wrote: > Hi there, > > I'm sending this mail on behalf of Mike Taylor (CC'ed), who for some > reason is constantly stuck in a

Please watch your character encodings

(If you don't know much about character encodings and how they can cause issues I just posted the blog post for you: https://www.oxymoronical.com/blog/2019/07/Please-watch-your-character-encodings ) I've run into a few bugs recently where non-english characters were causing things to break

Re: Crash Reporting module added

The previous discussion proposed making it a Core::Crash Reporting module, is there a reason that that changed? On Tue, Jul 2, 2019 at 2:19 AM Gabriele Svelto via governance < governance@lists.mozilla.org> wrote: > As per the discussion in thread [1] I've created the "Crash reporting" >

Re: telemetry.mozilla.org module changes

t=Data%20Platform%20and%20Tools=Telemetry%20Dashboards%20%28TMO%29=---_id=14775089> > and other related things. > I don't know how that best renders to the current Wiki representation of > the modules though. > > Georg > > On Thu, Jun 6, 2019 at 9:40 PM Dave Townsend via

Re: Upcoming changes to our JS coding style

Prettier will share eslint's list of things to ignore and those tests are already ignored: https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/.eslintignore#239 . Of course if you want parts of that directory to be linted and formatted then you can modify that file

telemetry.mozilla.org module changes

Hi folks. The telemetry.mozilla.org module ( https://wiki.mozilla.org/Modules/Firefox#telemetry.mozilla.org) is a little outdated and its current owner has moved on from the project. After some discussion with the folks involved I'd like to propose that this module should now be owned by Chris

Re: [Mozilla Enterprise] upcoming ESR 68 / Impact of "Dedicated profiles per Firefox installation"

Currently as long as SNAP_NAME is defined to something it will disable profiles-per-install, but there is an intention to replace that method of detecting snap packaged so I can't guarantee that that will exist long-term. On Thu, May 30, 2019 at 3:50 AM James Pearson wrote: > Dave Towns

Re: [Mozilla Enterprise] upcoming ESR 68 / Impact of "Dedicated profiles per Firefox installation"

t a better solution would appreciated. > > kind regards, > > Bardo Wolf > > > -- > opsi - Open PC-Server-Integration > > Wondering who's using opsi? Have a look at the opsi > map:http://opsi.org/opsi-map/. <http://opsi.org/opsi-map/> > -- > --

Re: [Mozilla Enterprise] upcoming ESR 68 / Impact of "Dedicated profiles per Firefox installation"

(sorry if this doesn't thread right, I only just joined this list) Regarding how the dedicated profiles per install feature works, there is currently no difference between how it works on normal Firefox builds and ESR. New versions of Firefox are not new installations. The installation is

Re: Outline of a plan to remove all XUL documents from mozilla-central

Which test files are we talking about here? If they are testing UI widgets, and our long-term goal is to use html and not xhtml for the UI then those tests should, at some point, be in html. On Tue, May 14, 2019 at 1:48 PM Brian Grinstead wrote: > There isn't any particular reason functionally

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

Is there still a configuration (ignoring hidden prefs) that can cause a user to end up using non-e10s? If so we should turn these tests back on. On Tue, Apr 23, 2019 at 8:25 AM Joel Maher wrote: > Here is where we initially turned on non-e10s tests for win7: >

Re: Updating the list of "Other" modules

I have updated the wiki to reflect these changes. On Tue, Apr 2, 2019 at 6:12 AM Dave Townsend wrote: > As with Core we have many old or unowned modules sitting in the "Other" > list (https://wiki.mozilla.org/Modules/Other). This is a list of proposed > changes to get thin

Re: Announcing ./mach busted

This is awesome. It is so frustrating to hit issues that stop you from being able to build and test your work. Glad that we're making it easier to solve issues as you find them. On Thu, Apr 11, 2019 at 9:12 AM Bobby Holley wrote: > TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a

Re: MOZ_DBG

I just landed support for MOZ_DBG for nsIFile (shows the path of the file) and nsIURI (shows the uri spec) onto inbound. On Sat, Mar 30, 2019 at 8:04 AM Dave Townsend wrote: > This sounds excellent. I think on Monday I'll go right to work making this > work for URIs which are pr

Re: Updating the list of "Other" modules

Sure thing. On Tue, Apr 2, 2019 at 9:45 AM Jörg Knobloch wrote: > On 02 Apr 2019 15:12, Dave Townsend via governance wrote: > > *Penelope*Move the module to Thunderbird. > > Hi, > > can we remove this? Penelope was the attempt to support a "Eudora" look > and f

Re: Proposal to update unowned and stale Core modules

make sure that the peers for your modules are up to date and make changes as necessary. On Tue, Mar 19, 2019 at 10:05 AM Dave Townsend wrote: > The list of Core modules is long and many are listed as owned by folks no > longer involved in the project. Others have only temporary

Updating the list of "Other" modules

As with Core we have many old or unowned modules sitting in the "Other" list (https://wiki.mozilla.org/Modules/Other). This is a list of proposed changes to get things up to date. Once again if there are no objections, and I'd expect there to be none, we'll consider this approved. *Addon SDK*

Re: MOZ_DBG

This sounds excellent. I think on Monday I'll go right to work making this work for URIs which are probably the things I end up logging the most from C++. On Fri, Mar 29, 2019 at 11:16 PM Cameron McCormack wrote: > Lately I've been finding Rust's dbg!() macro[1] useful for quick > debugging.

Re: Proposal to update unowned and stale Core modules

two open bugs here into a more appropriate component, so yes lets close this. > - Core::Geolocation: Should be renamed Core::DOM: Geolocation? > Yes that makes sense I think. > > Thanks, > > Emma > > > On Tue, Mar 19, 2019 at 10:06 AM Dave Townsend via governance < >

Re: Core Crash Reporting Module

Being in the toolkit directory I guess this feature is currently nominally part of the general Toolkit module. As owner of that I'm perfectly fine with this getting its own module, most of the folks who work day to day on Toolkit likely do not have the expertise required for working on the crash

Re: Let's remove the "Android Background Services" module

I've noted that requests for changes like this often receive little to no response, I'm sure because generally they are totally uncontroversial. So I suggest that unless you hear opposition within a week you should just consider this to be approved (and maybe we should make that a standard rule

Re: Let's remove the "BrowserID" module

Given that there have been no signs of opposition here I think we can consider this approved for removal. Please can you update the wiki accordingly? On Wed, Mar 7, 2018 at 11:29 AM Ryan Kelly via governance < governance@lists.mozilla.org> wrote: > The "Other/BrowserID" module is obsolete and

Proposal to update unowned and stale Core modules

The list of Core modules is long and many are listed as owned by folks no longer involved in the project. Others have only temporary owners. In discussion with the TLMC and other folks I've put together a list of changes to address this. In some cases we've found willing owners for the code, in

Re: Running different instances of Firefox side-by-side

ntioning this post on dev-platform rather than > the bug where the regression was introduced). > > - Marco. > > > Il 13/03/19 22:14, Dave Townsend ha scritto: > > A quick update here. After hearing some feedback from folks I've filed > the > > following bug

Re: Running different instances of Firefox side-by-side

is running. https://bugzilla.mozilla.org/show_bug.cgi?id=1535144 Return -new-instance to its previous behaviour. On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend wrote: > Woah this email got long. How Firefox considers whether to pass off to an > existing instance of Firefox or continue launching a n

Re: Searchfox now indexing m-beta, m-release, m-esr60

Thank you thank you thank you thank you thank you thank you thank you thank you thank you thank you. (I appreciate this) On Tue, Mar 12, 2019 at 11:15 AM Kartikaya Gupta wrote: > Due to popular demand, searchfox now also has > mozilla-{beta,release,esr60} repos. Text search only for now; blame

Running different instances of Firefox side-by-side

Woah this email got long. How Firefox considers whether to pass off to an existing instance of Firefox or continue launching a new one turns out to be more complex than you might expect. I'm mostly interested in making folks aware of and giving feedback on how this works after I've changed some

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

Townsend wrote: > Just a heads up, we've decided to defer this change to a later release to > make sure we get the experience right for our users. I'll post another > update once we have a better idea of when this will land. > > On Thu, Oct 18, 2018 at 12:32 PM Dave Townsend > wrot

Re: Skipping changesets when viewing blame

This is wonderful! Thanks especially for back-filling the eslint work. On Wed, Jan 2, 2019 at 8:58 AM Felipe G wrote: > If you ran `mach bootstrap` or `mach vcs-setup` in the last month, you > should already have a new hg command alias called `smart-annotate`, which > runs `hg annotate` while

Re: Checking if an nsIURI came from a resource: URL

This suggests that channel.originalURI should help: https://searchfox.org/mozilla-central/source/netwerk/base/nsIChannel.idl#37 On Fri, Dec 7, 2018 at 9:19 AM Henri Sivonen wrote: > On Fri, Dec 7, 2018 at 3:23 PM Daniel Veditz wrote: > > > > I'm afraid to ask why you want to treat these

Re: HG problem: abort: decoding near '9: error: ‘sse2::l': 'ascii' codec can't decode byte 0xe2 in position 213: ordinal not in range(128)

I would report this to mercurial. On Sat, Dec 1, 2018 at 11:53 PM ISHIKAWA,chiaki wrote: > Hi, > > I am developing mozilla patches locally under my local PC running linux. > > I often include the GCC's error/warning message in the mercurial > commit message (in the second and subsequent lines,

Re: The upcoming C/C++ coding style change

On Thu, Nov 29, 2018 at 4:38 AM Sylvestre Ledru wrote: > The experimentation with dom/media highlighted that we need an efficient > way to automatically rebase patches before the merge. > To achieve this, we updated the bootstrap process to include an extension > called hg formatsource. > This

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

Just a heads up, we've decided to defer this change to a later release to make sure we get the experience right for our users. I'll post another update once we have a better idea of when this will land. On Thu, Oct 18, 2018 at 12:32 PM Dave Townsend wrote: > In Firefox 65 we intend to ship

Re: Re[2]: Updating (or deprecating?) the modules wiki page

The TLMC actually started discussing this yesterday, expect to see some proposals/changes soon. On Fri, Oct 26, 2018 at 7:39 AM mhoye via governance < governance@lists.mozilla.org> wrote: > > Dave Camp recently put forward a proposal to "restructure the > Firefox-related modules under control of

Re: Updating (or deprecating?) the modules wiki page

Please do not update module pages without either talking to the module owner or discussing with governance first. On Fri, Oct 26, 2018 at 2:55 AM spike--- via governance < governance@lists.mozilla.org> wrote: > Hello Gabriele, > > I cannot comment on how much of

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

had setup > just because firefox updated. > > On Mon, Oct 22, 2018 at 11:21 PM Dave Townsend > wrote: > >> On Mon, Oct 22, 2018 at 3:20 PM Mike Hommey wrote: >> >>> On Thu, Oct 18, 2018 at 12:32:36PM -0700, Dave Townsend wrote: >>> > In Firefox 6

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

On Mon, Oct 22, 2018 at 3:20 PM Mike Hommey wrote: > On Thu, Oct 18, 2018 at 12:32:36PM -0700, Dave Townsend wrote: > > In Firefox 65 we intend to ship two new features to help prevent user > > frustration caused by using profiles created by newer versions of > Fi

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

gt; On Fri, Oct 19, 2018 at 2:43 PM mhoye wrote: > >> >> >> -- Original Message -- >> From: "Dave Townsend" >> To: "dev-platform" ; "Firefox Dev" < >> firefox-...@mozilla.org> >> Sent: 2018-10-18 3:32:36 PM >

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

On Fri, Oct 19, 2018 at 6:31 AM Tom Ritter wrote: > Awesome! > > > On Thu, Oct 18, 2018 at 3:32 PM Dave Townsend > wrote: > > > For cases where users manually downgrade an install of Firefox or > attempt > > > to forcefully use an older version of Firefox wi

Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

In Firefox 65 we intend to ship two new features to help prevent user frustration caused by using profiles created by newer versions of Firefox. Why Firefox stores all of its settings in the user’s profile and unless certain command line arguments are used Firefox always launches with the same

Re: Moving Windows MSVC Builds Back To Tier 1

If we've made the decision to stick with clang-cl, why would we continue to support MSVC builds going forwards? On Fri, Oct 12, 2018 at 1:06 PM Ryan VanderMeulen wrote: > When we made the decision to switch to clang-cl for our Windows builds, > MSVC builds and tests were kept running as Tier 2

Re: mozilla-central Fails to Build on Mac With Latest Xcode (10.0)

This seems to be tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1487552 On Tue, Sep 25, 2018 at 5:12 AM J. Ryan Stinnett wrote: > The Xcode 10 Release Notes[1] in the "Command Line Tools" heading suggests > that future versions will not provide a *.pkg to install headers to >

Re: Stopgap for Commit Series in Phabricator

This is an excellent tool and I'm using it for basically all my submissions. Just one word of warning though, it doesn't currently support submitting patches that contain binary files at this time. The binary file will become truncated at phabricator, so watch out for that. On Thu, Jul 26, 2018

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

On Tue, Jun 26, 2018 at 3:54 PM Gregory Szorc wrote: > On Tue, Jun 26, 2018 at 3:45 PM, Dave Townsend > wrote: > >> On Tue, Jun 26, 2018 at 3:06 PM Sebastian Hengst wrote: >> >> > Original-Nachricht >> > Betreff: Re: mozilla-inbound b

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

On Tue, Jun 26, 2018 at 3:06 PM Sebastian Hengst wrote: > Original-Nachricht > Betreff: Re: mozilla-inbound backout policy subject to change (become > similar to autoland) > Von: Boris Zbarsky > Datum: 2018-06-24 21:28 > > On 6/19/18 9:04 AM, Sebastian Hengst wrote: > >>

Re: Update on rustc/clang goodness

On Tue, May 29, 2018 at 10:03 PM Jeff Gilbert wrote: > I get that, but it reminds me of the reasons people give for "our > website works best in $browser". > I was concerned by this too but found myself swayed by the arguments in

Re: Is super-review still a thing?

Presumably it supports multiple reviews for a patch, in which case I think we're fine. On Fri, Apr 20, 2018 at 3:03 PM Gregory Szorc wrote: > On Fri, Apr 20, 2018 at 2:51 PM, L. David Baron wrote: > > > On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:

Re: Is super-review still a thing?

No, super-review has not really been a thing for some time, we should remove documentation suggesting it is. That said we definitely have room for this kind of architectural review. Webidl for example already uses something like this. On Fri, Apr 20, 2018 at 2:24 PM Kris Maglione

Re: Intent to implement: Early, experimental support for application/javascript+binast

This is awesome. I understand that we already do some kind of pre-compile for our chrome code, is there any plan/benefit to switch to this eventually there? On Wed, Apr 18, 2018 at 9:50 AM David Teller wrote: > # Summary > > JavaScript parsing and compilation are

Re: CPU core count game!

What is the point you're trying to drive home? On Tue, Mar 27, 2018, 15:58 Steve Fink wrote: > Just to drive home a point, let's play a game. > > First, guesstimate what percentage of our users have systems with 2 or > fewer cores. > > Then visit

Re: The future of "remote XUL"

My understanding is that it has been effectively unsupported for some time anyway so I think we should just go ahead and disable it altogether at this point. If we need bits for automated tests then we should work to switch tests away from those if we can. On Tue, Mar 27, 2018 at 8:36 AM Boris

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

As one of the folks who brought up the initial concern let me be clear that at this point my only real concern here is one of optics. The DoH service we're using is likely more private than anything the user is currently using. I just don't want to see random folks on the web "discover" these DoH

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Sun, Mar 18, 2018 at 5:27 PM Patrick McManus wrote: > Obviously, using a central resolver is the downside to this approach - but > its being explored because we believe that using the right resolver can be > a net win compared to the disastrous state of unsecured local

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Sat, Mar 17, 2018 at 3:51 AM Patrick McManus wrote: > DoH is an open standard and for this test we'll be using the DoH server > implementation at Cloudflare. As is typical for Mozilla, when we > default-interact with a third party service we have a legal agreement in >

Re: Data issues with cloned profiles

ly > require the user to re-enter their FxA password, but I'm not sure. > > Dropping fx-data-dev, CCing FxA and Sync to discuss. > > On Mon, Feb 5, 2018 at 2:45 PM, Dave Townsend <dtowns...@mozilla.com> > wrote: > >> A new feature we are targetting for Firefox 6

Re: Data issues with cloned profiles

ly > require the user to re-enter their FxA password, but I'm not sure. > > Dropping fx-data-dev, CCing FxA and Sync to discuss. > > On Mon, Feb 5, 2018 at 2:45 PM, Dave Townsend <dtowns...@mozilla.com> > wrote: > >> A new feature we are targetting for Firefox 6

Browser Architecture Newsletter 5

Welcome to the exciting fifth instalment in our series of Browser Architecture Newsletters! Storage and Sync We are pleased to report that the Sync and Storage roadmap proposal successfully passed review by dcamp. Thanks to the 20+ people from around the organization who helped us build

Re: Overriding JS to allow for opening in a new tab?

We have some precedent for overriding a site. Popup blocking and redirecting new windows to tabs for example. But I'm not sure how we could technically do this here. If the site is doing some JS work (possibly including async stuff) ultimately ending with an assignment to window.location how would

De-XBL Plans

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 proposals more widely. We have developed a plan to remove XBL from Firefox. It's been

Re: We need better canaries for JS code

allowing > modules to opt-in to using them, perhaps just as an experiment. Presumably > most existing modules wouldn't, but new ones being written might. > > Dan > 2017-10-18 9:06 GMT-07:00 Dave Townsend <dtowns...@mozilla.com>: > >> On Wed, Oct 18, 2017 at 4:51 AM

Re: We need better canaries for JS code

On Wed, Oct 18, 2017 at 4:51 AM Mark Banner wrote: > I remember that we had bugs of this kind lurking for years in our > codebase, in code that was triggered daily and that everybody believed > to be tested. > > I'd like to think that there is a better way to handle these

Browser Architecture Newsletter 3

es. We’re getting ready to run through a design review for our XBL replacement plans. The review will be chaired by Dave Townsend and include a panel of experts on both Gecko and Firefox. The review process itself is a work in progress, and our XBL Removal review is a trial run to help us refine it. L

Re: Switching to per-channel profiles

On Fri, Jun 23, 2017 at 4:45 PM, Richard Newman wrote: > How we populate the new profile we create for Nightly and Beta channels is >> an open question. We could simply clone the existing Release profile or use >> Firefox Refresh to copy across the basic data. In either case

Re: Switching to per-channel profiles

On Fri, Jun 23, 2017 at 4:37 PM, Aki Sasaki wrote: > I'm a Nightly only user who periodically uses Release, and I'm not > thrilled with the idea of my profile going away. Nightly users are probably > better suited to dealing with this (using sync, etc) than the Beta >

Re: Switching to per-channel profiles

On Fri, Jun 23, 2017 at 4:11 PM, Mike Hommey <m...@glandium.org> wrote: > On Fri, Jun 23, 2017 at 03:43:54PM -0700, Dave Townsend wrote: > > TL;DR: We should make each Firefox channel use its own profile data > > allowing you to run multiple channels at the same time. >

Switching to per-channel profiles

TL;DR: We should make each Firefox channel use its own profile data allowing you to run multiple channels at the same time. Running multiple channels of Firefox is currently harder than it needs to be. You can't start more than one channel at a time and either you use the same profile data for

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

On Mon, Apr 3, 2017 at 9:38 AM, Joshua Cranmer  <pidgeo...@gmail.com> wrote: > On 3/16/2017 5: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 add

Re: Bancontact apps blocked by Firefox

Can you describe more about what aspect of Bancontact is blocked, do you receive some kind of error message? I don't know the system so it is difficult to understand what the problem is. On Wed, Mar 29, 2017 at 12:56 PM, Véronique Hayen < hayen_veroni...@hotmail.com> wrote: > > > > > Hello, > >

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

It looks like the main concern raised about switching over to async/await where possible is bug 1242505. We're going to try to get some resources for fixing that bug and it probably blocks doing a mass rewrite of existing code but I don't think it blocks people starting to use async/await right

Re: Better download security through browsers

I remember that Gerv was interested in a similar idea many years ago, you might want to see if he went anywhere with it. https://blog.gerv.net/2005/03/link_fingerprin_1/ On Fri, Mar 24, 2017 at 10:12 AM, Gregory Szorc wrote: > I recently reinstalled Windows 10 on one of my

Re: intent to remove: standalone about:addons UI and tests

I agree that this has outlived its usefulness and we should remove it and cleanup the code where we can. On Wed, Mar 22, 2017 at 2:36 PM, Robert Helmer wrote: > Currently we support running the about:addons UI in both a standalone > window, and also in a browser tab. > >

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

cause problems as we attempt to automatically rewrite older code and tests make bad assumptions. On Thu, Mar 16, 2017 at 3:29 PM, Dave Townsend <dtowns...@mozilla.com> wrote: > For a long time now we've been writing JS code that waits for promises > using Task.jsm and generator functio

Switching to async/await from Task.jsm/yield

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: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

Re: Is there a way to improve partial compilation times?

70 minutes is about what a clobber build takes on my Surface Book. And yes I agree, it is way too much! On Tue, Mar 7, 2017 at 3:24 PM, Mike Hommey wrote: > On Tue, Mar 07, 2017 at 11:29:00AM -0800, zbranie...@mozilla.com wrote: > > So, > > > > I'm on Dell XPS 13 (9350), and

  1   2   3   >