Re: [ANN] Changing the default bug view for BMO

Right now if I turn on the experimental UI, the bugzilla setting for skin changes from my preference of "Dusk" to "Mozilla", and doesn't let me change it back. Will the Dusk skin still be supported going forward? On Fri, Jan 6, 2017 at 12:09 PM, Dave Lawrence wrote: > Announcement: Changing the d

Re: Decoupling the build config via moz.build files (nuking all.js)

On 13-03-15 20:06 , Benjamin Smedberg wrote: *Also* note that we actually have two different files: "all.js" is the defaults for the Mozilla platform, including Tbird/Seamonkey and all XULRunner apps. "firefox.js" is where Firefox-specific prefs and overrides typically should live. There is al

Proposal for using a multi-headed tree instead of inbound

(Cross-posted to mozilla.dev.tree-management; please reply to mozilla.dev.platform) TL;DR: I propose that instead of using inbound as a "linear commit; rebase as needed" tree, we use a tree that allows multiple heads (e.g try) to land patches on. Each patch queue would be based off a known-gr

Re: Proposal for using a multi-headed tree instead of inbound

Thanks for the many comments! I replied to a bunch of stuff below. On 13-04-03 18:34 , Justin Lebar wrote: This is a really interesting idea. git is smart enough to let you pull only the csets that end up getting merged into master. I don't know how multiple heads works with hg, but I wonder i

Re: Proposal for using a multi-headed tree instead of inbound

On 13-04-03 23:05 , Jesse Ruderman wrote: I suggest adding an Auto branch between Try and Central. Advantages: [snip] * In Scenario D (when subtle patch interactions cause build or test failures), automation can move on to another set of Try landings, giving sheriffs time react without the pre

Re: Proposal for using a multi-headed tree instead of inbound

(Moving thread from from m.d.tree-managment to m.d.platform) On 13-04-03 19:03 , Jeff Hammel wrote: Without wanting to start a contraversy, is there a particular reason to use multiple trees here vs e.g. a checkin-needed flag on bugzilla or similar? I'm not quite sure what you're suggesting. A

Re: Proposal for using a multi-headed tree instead of inbound

On 13-04-03 19:49 , Jesse Ruderman wrote: +1. But can we do this with rebased changesets instead of "trivial" merge changesets? While the core of hg can handle merges, pretty much none of the tools we rely on for understanding history (hg {log, grep, diff, bisect}) handle them well. Thinking

Proposal for using a multi-headed tree instead of inbound (updated)

Sorry for starting a new thread, but I screwed up the previous thread by mashing together my replies to unrelated messages in a single message. If you didn't read all the messages in all sub-threads you may have missed my response. Most of my responses were in this message: https://groups.goog

Some data on mozilla-inbound

TL;DR: * Inbound is closed 25% of the time * Turning off coalescing could increase resource usage by up to 60% (but probably less than this). * We spend 24% of our machine resources on changes that are later backed out, or changes that are doing the backout * The vast majority of changesets that

Re: Some data on mozilla-inbound

On 13-04-23 11:41 , Chris AtLee wrote: We've considered enforcing this using some cryptographic token. After you push to try and get good results, the system gives you a token you need to include in your commit to m-i. ... or you could just merge the cset directly from try to m-i or m-c. (i.e.

Re: Some data on mozilla-inbound

On 13-04-23 00:39 , Ehsan Akhgari wrote: How hard would it be to gather a list of the total number of patches being backed out plus the amount of time that we spent building/testing those, hopefully in a style similar to ? Not trivia

Re: Some data on mozilla-inbound

On 13-04-23 03:57 , Axel Hecht wrote: Do we know how many of these have been pushed to try, and passed/compiled what they'd fail later? I haven't looked at this. It would be useful to know but short of pulling patches and using some similarity heuristic or manually examining patches I can't t

Re: Some data on mozilla-inbound

On 13-04-23 19:21 , Nicholas Nethercote wrote: - The 'inbound was closed for 15.3068% of the total time due to "bustage"' number is an underestimate, in one sense. When inbound is closed at 10am California time, it's a lot more inconvenient to developers than when it's busted at midnight Califor

Re: Some data on mozilla-inbound

On 13-04-26 11:37 , Phil Ringnalda wrote: Unfortunately, engineering is totally indifferent to things like having doubled the cycle time for Win debug browser-chrome since last November. Is there a bug filed for this? I just cranked some of the build.json files through some scripts and got t

Re: Proposal for an inbound2 branch

My only concern with this is that it increases the difficulty of bisecting regressions. Lately I've run into this a few times, where I see regressions on areweslimyet.com and dig into it, only to find the regression happened on a "merge from m-c" changeset. Since the mobile AWSY only runs on m

Reviewer checklist

Some of us over in #mobile brainstormed a list of things that reviewers (and patch-writers) should check for in patches. The idea is to have a handy list of these things that often get forgotten, overlooked, or otherwise slip through. I have put up our list on the MDN wiki at [1] - please feel

Tegra build backlog is too big!

Earlier today the backlog on Android build jobs was on the order of 1300. It seems to be coming down a little now but for a while there I was worried it was going to grow unboundedly. Try jobs from over 10 hours ago still have pending jobs - as I'm sure you all know, having a 10-hour turnaround

Re: Tegra build backlog is too big!

AFAIK an unusually high load of try pushes. On 13-09-11 17:47 , Jim Chen wrote: Do we know why it's that much backed up? I started noticing it yesterday. Is it because of lots of inbound pushes? lots of try pushes? Lots of clobbering? Lots of tests? Jim On 9/11/13 5:31 PM, Kartikaya

Re: Tegra build backlog is too big!

reverted. Let me know if you want any further info, ok? John. == On 9/11/13 2:31 PM, Kartikaya Gupta wrote: Earlier today the backlog on Android build jobs was on the order of 1300. It seems to be coming down a little now but for a while there I was worried it was going to grow unboundedly. Try jobs f

Re: Central location for tracking known broken build configurations (with bugs)

I would favour a whiteboard tag or keyword on the bug tracking the build failure. It should be easy enough to create a query for all open bugs with this tag. Usually you want to get to the bug anyway for the latest workaround and/or info on what to back out locally. Cheers, kats On 13-11-19 1

Target Milestone field in bugzilla

I think the "Target Milestone" field is poorly named, at least with respect to what we use it for. In practice this field is set to the version of m-c on which the patches originally landed, and doesn't change when patches are uplifted to other branches. However, I've seen many people mistake

Re: Target Milestone field in bugzilla

That sounds pretty reasonable to me. Cheers, kats On 14-01-14 10:59 , dklaw...@gmail.com wrote: After some discussion with other BMO devs, how about this proposal? We add a (info) link next to the Milestone label on the show_bug.cgi page that has some custom documentation explaining the purpo

Non-technical comments in Bugzilla

Hi all, Recently I've noted a significant increase in the number of bug comments that are meta-information and not particularly relevant to the bug itself. Often these comments are product/planning people moving the bug around asking for attention on it (this particularly happens in B2G-land

Re: Non-technical comments in Bugzilla

On 19/2/2014, 8:57, Byron Jones wrote: two other useful tags are "obsolete" and "typo", both will also cause the comment to be collapsed by default. That's excellent, thank you! kats ___ dev-platform mailing list dev-platform@lists.mozilla.org http

Re: Recommendations on source control and code review

Just a reminder that this page exists: https://developer.mozilla.org/en-US/docs/Developer_Guide/Reviewer_Checklist and you should feel free to add things to it, and use it when reviewing any code (your own or other people's). kats On 11/4/2014, 17:47, Mike Conley wrote: Whoa, didn't expect

Re: Follow up on clang-format

I tried using clang-format on entire files and I noticed two things (there might be others, I didn't look too closely): 1) When it reformats comments to fit in the line length, it just inserts linebreaks rather than rewrapping the text. So you end up with text like this, where the last couple

Re: Intent to implement: CSSOM-View scroll-behavior property

On 23/5/2014, 6:12, Jonas Sicking wrote: Basically we need an API like div.addToScrollPosition(hightOfNewContent); This would allow the browser to send this delta to the compositing thread along with the newly updated painting of the DOM. This is certainly a valid use case, and it has come up

Re: PSA: ./mach build doesn't work reliably any longer

On 25/8/2014, 14:16, Aryeh Gregor wrote: FWIW, I've often made changes like this when touching files like nsCOMPtr.h or nsINode.h -- or switching nsresult from a typedef to an enum class! -- and I find just doing ./mach build binaries works fine. It reports errors randomly from all over the tree,

Re: Git -> Hg workflows?

Thanks for sending this email! Some responses below.. On 31/10/2014, 1:48, Gregory Szorc wrote: a) Landing code to inbound, fx-team, aurora, etc b) Pushing to Try My workflow involves exporting patches from git as flat text files and then using qimport/push from a single hg pseudo-unified rep

Re: Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View DOM Extensions for Smooth Scrolling

On 30/10/2014, 19:02, Jonas Sicking wrote: Couldn't we simply change the defined behavior of element.scrollBy({ top: 50, behavior: "smooth" }) such that it sends the delta coordinates to the composition thread, and adds the current scroll position there instead of on the main thread? FYI we fil

Re: Revisions to the Job Visibility Policy

Looks good to me! On Mon, Jul 6, 2015 at 10:52 AM, Ryan VanderMeulen wrote: > For a little over 2 years, our Job Visibility Policy has been in place to > identify all the requirements necessary for a build or test suite to be > visible in our infrastructure. > https://wiki.mozilla.org/Sheriffing/

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

I'd be interested to know: of those people who are in favour of removing the prefix, how many regularly have to deal with functions that are longer than two pages (a "page" is however much code you can see at a time in your coding environment)? I'd be happy to support removing the prefix if people

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tue, Jul 7, 2015 at 9:18 AM, Honza Bambas wrote: >> I'd be happy to support >> removing the prefix if people also commit to splitting any giant >> functions they touch as part of the prefix removal. > > > That's (sorry) non-sense. In almost all cases longer methods/functions > cannot be just s

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tue, Jul 7, 2015 at 3:33 PM, Jeff Gilbert wrote: > On Tue, Jul 7, 2015 at 6:03 AM, Kartikaya Gupta wrote: >> >> I'd be interested to know: of those people who are in favour of >> removing the prefix, how many regularly have to deal with functions >> that are lo

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tue, Jul 14, 2015 at 10:10 AM, Tom Tromey wrote: >>> That assumes that the 'Foo' of aFoo is stable across function >>> boundaries, which is not always the case. > > Ehsan> No, it doesn't. In the scenario above, all you're looking for is when > Ehsan> a value was computed, so you can quickly se

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

/webapprt 0 ./widget 876 ./xpcom 177 ./xpfe 8 ./xulrunner 0 On Tue, Jul 14, 2015 at 10:30 AM, L. David Baron wrote: > On Tuesday 2015-07-14 10:27 -0400, Kartikaya Gupta wrote: >> Admittedly not perfect, but as a first-order approximation: >> >> kats@kgupta-air mozilla-git$ find

PSA: Enabling APZ on nightly desktop (OS X, Windows)

Just a heads-up that I just pushed bug 1157746 to inbound, which enables async scrolling for trackpad/wheel scrolling by default for nightly OS X desktop builds. It requires e10s, and so if you have e10s disabled it has no effect for you. If you have e10s enabled, you should see smoother/more respo

PSA: New reftest analyzer keyboard shortcuts

Since keyboard shortcuts aren't very discoverable this is just a note to let you all know that in bug 1187025 I added some more keyboard shortcuts to the reftest analyzer. Previously '1' and '2' would switch between the test/reference images, and now 'd' will toggle the differences view and 'p' and

Re: layers.async-pan-zoom.enabled amazing performance increase

The OP filed bug 1189237 for this issue, but it seems like it was reported on Firefox 39 where we don't support async-pan-zoom. If you can reproduce this issue in a Nightly build please file a new bug. Thanks, kats On Thu, Jul 30, 2015 at 5:32 PM, Andreas Tolfsen wrote: > On Thu, Jul 30, 2015 at

PSA: searchfox now indexing macOS Rust/C++ code

Just a heads up that as of today Searchfox is also indexing Rust and C++ code that is conditionally compiled only on macOS. It was previously only doing code compiled on Linux. Windows and Android are not yet indexed; those will be added as time permits. One caveat is that there are some generated

Re: mozilla-esr60 fails to build on windows

This is because of https://bugzilla.mozilla.org/show_bug.cgi?id=1479540 - it should be fixed on the ESR branch soon (already approved, somebody just needs to push the patch). On Sat, Sep 22, 2018, 20:05 john.bieling--- via dev-platform, < dev-platform@lists.mozilla.org> wrote: > I was able to bui

Re: Extension to integrate Searchfox features in Phabricator

Neat! I took a quick peek at your addon source and the stuff it's relying on seems ok for now. At least, it's not anything we plan to change anytime soon. If there are changes to searchfox that would make your life easier in terms of expanding your addon, let me know and we can discuss possibilitie

Re: Announcing new test platform "Android 7.0 x86"

I'm also excited to see this up and running, as it will probably be quite useful with testing webrender on android. Thank you! On Thu, Nov 1, 2018 at 6:40 PM Chris Peterson wrote: > > On 2018-11-01 3:06 PM, Nicholas Alexander wrote: > >> Like the existing "Android 4.2" and "Android 4.3" test platf

PSA: searchfox now indexing Windows Rust/C++ code

Hello searchfox fans, Those of you working in Windows-only Rust and C++ code will probably be happy to hear that as of today searchfox is indexing the Windows-only bits of our codebase as well. The same caveat as with macOS applies - in cases where there is generated source that conflicts with Li

PSA: Searchfox now supports .mailmap entries

Thanks to a patch by Nika, searchfox now respects the git .mailmap file in mozilla-central. When viewing old commits/blame info, the author information is updated using the .mailmap file to the new values. (Also, while I'm here, if anybody is interested in working on adding Python support to searc

Re: Dogfooding WebRender

On Wed, Nov 28, 2018 at 4:19 AM Jean-Yves Avenard wrote: > You can already enable webrender on mac and linux:set gfx.webrender.enabled > to true. Note that on Linux you need to set gfx.webrender.all to true, because .enabled by itself won't do much unless you also force on acceleration. That be

Re: Dropping support for compiling with MSVC in the near future

This is sort of tangential, but what's the linking story currently? Are we still linking with MSVC, or with lld? I discovered recently that the rust toolchain we use in automation on windows tries to use link.exe for linking. I'm in the process of trying to get standalone webrender tests running on

Re: Dropping support for compiling with MSVC in the near future

This makes sense, thanks! On Tue, Dec 11, 2018 at 6:45 AM Ted Mielczarek wrote: > > On Mon, Dec 10, 2018, at 8:29 PM, Kartikaya Gupta wrote: > > This is sort of tangential, but what's the linking story currently? > > Are we still linking with MSVC, or with lld? > &g

Re: Automatic changes during the dev workflow [was: Re: Upcoming changes to our C++ Coding Style]

On Fri, Dec 14, 2018 at 1:58 PM Sylvestre Ledru wrote: > We have more and more tools at review phase (clang-format, flake8, eslint, > clang-tidy, codespell, etc) which propose some auto-fixes. Honestly I find it quite annoying when I'm trying to review a patch and the phabricator diff is filled

Re: Upcoming changes to our C++ Coding Style

Personally I would prefer if we rewrote the commits locally to be formatted prior to submitting it into Phabricator. That way everything stays in sync. Also usually clang-formatting a patch is the last thing I want to do before submission anyway. And doing it now is kind of annoying if you have a m

Re: Upcoming changes to our C++ Coding Style

Local commit hooks are even better, thanks! Are there instructions somewhere on how to set up the hooks and make sure they run properly? On Mon, Dec 17, 2018 at 9:22 AM Ehsan Akhgari wrote: > > On Fri, Dec 14, 2018 at 7:20 AM Kartikaya Gupta wrote: >> >> Personally I would pr

Re: nasm will soon become a build dependency

Looks like the default nasm in the Ubuntu 16.04 repositories is 2.11. Are there plans to make `./mach bootstrap` find a 2.13 version from somewhere, instead of just installing via `apt-get` and assuming it's the right version? On Fri, Dec 21, 2018 at 12:00 AM Thomas Daede wrote: > > On 12/20/18

Re: nasm will soon become a build dependency

On Fri, Dec 21, 2018 at 4:10 PM Thomas Daede wrote: > There is a toolchain build for nasm for windows: > https://bugzilla.mozilla.org/show_bug.cgi?id=1511224 > > If getting a newer nasm version is inconvenient for a majority of linux > users, the toolchain build could be used to produce nasm binar

Re: nasm will soon become a build dependency

o be able to > move further with the static analysis builds for coverity. > > > On 28 Dec 2018, at 22:19, Botond Ballo wrote: > > > >> On Fri, Dec 21, 2018 at 4:21 PM Kartikaya Gupta wrote: > >> > >>> On Fri, Dec 21, 2018 at 4:10 PM Thomas Da

Re: Moving reviews to Phabricator

Ditto for git. Also note that when you click the "preview landing" button in Lando, the popup that shows the commits shows the author information on the patch, so you can use that to verify that the attribution is correct. On Wed, Feb 6, 2019 at 8:10 PM Barret Rennie wrote: > > If you commit with

Re: Important: Update to latest central before running |mach try|

On Tue, Feb 26, 2019 at 3:06 PM Andrew Halberstadt wrote: > 4. Trigger the migration again: mach try --no-push Note that the migration should be triggered again using a version of m-c that includes https://hg.mozilla.org/mozilla-central/rev/f2145aac6de2 ___

Re: PSA: Min clang / libclang requirement was updated not long ago...

On Wed, Feb 27, 2019 at 3:40 AM Axel Hecht wrote: > > Can we please not force bootstrap? +1. In general bootstrap isn't "rock solid" enough to force people into running it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozil

Searchfox support for mobile/android just got a little better

As of today Searchfox is providing C++/Rust analysis for Android-specific code. So stuff in widget/android and behind android ifdefs should be turning up when you search for symbols. Note that we're using data from an armv7 build, so code that is specific to aarch64 or x86 is not covered. That can

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

Due to popular demand, searchfox now also has mozilla-{beta,release,esr60} repos. Text search only for now; blame should appear within a couple of days or so. Follow along on bug 1282123 or just mash F5 periodically to find out when exactly. Rust/C++ indexing for beta and release will happen someti

Re: Each piece of PresShell::HandleEvent() and PresShell::HandleEventInternal() was spun out to each method of PresShell::EventHandler class

Thank you! As somebody who occasionally has had to go digging in that code, this cleanup is much appreciated. On Thu., Mar. 14, 2019, 04:05 Masayuki Nakano, wrote: > Hi, > > We had too big, complicated and important method, > `PresShell::HandleEvent()` (*1), and its helper method, > `PresShell::

Re: Duplicate dependency policy for Rust in mozilla-central?

FWIW there often ad-hoc attempts to deduplicate Rust dependencies, and they often run into nontrivial blockers. Currently there's a few things blocked on bug 1530448. On Fri, Mar 15, 2019 at 9:32 AM Xidorn Quan wrote: > > Hi all, > > Recently I tried to build Firefox on cloud, and noticed that bu

Re: PSA: Define and share |mach try| presets in-tree

This is really nice! Thanks! On Mon, Mar 18, 2019 at 11:57 AM Andrew Halberstadt wrote: > > Hello all, > > Just a quick heads up that you can now define and share try presets > in-tree by adding them to this file: > https://searchfox.org/mozilla-central/source/tools/tryselect/try_presets.yml > >

Re: Shippable Builds Incoming...

Will the change to taskcluster indexes affect mozregression? On Tue, Mar 26, 2019 at 2:56 PM Justin Wood wrote: > > Hey Everyone, > > tl;dr I landed "shippable builds" [1] to autoland, and I'll assume it > sticks. This replaces Nightly and PGO for most job types for desktop jobs. > Expect to see

Re: Intent to deprecate - linux32 tests starting with Firefox 69

I would be happy to see Linux32 (and in particular, desktop non-e10s) tests decommissioned, as that is pretty much the only configuration with APZ disabled now. If we can drop that then we can remove a bunch of complexity and code paths. On Fri., Apr. 5, 2019, 10:05 Boris Zbarsky, wrote: > On 4/

Re: Intent to deprecate - linux32 tests starting with Firefox 69

On Fri, Apr 5, 2019 at 10:45 AM Boris Zbarsky wrote: > > On 4/5/19 10:20 AM, Kartikaya Gupta wrote: > > If we can drop that then we can remove a bunch of complexity > > and code paths. > > Are we talking about just dropping linux32 _tests_, or dropping linux32 > _supp

Re: crash reporting, inline functions, and you

Thank you for doing this work! Any additional information for inlined frames in crash stacks will be hugely helpful. On Fri, Apr 5, 2019 at 12:34 PM Nathan Froyd wrote: > > TL;DR: We're making some changes to how inlined functions are handled > in our crash reports on non-Windows platforms in bug

Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

On Mon, Apr 8, 2019 at 11:39 PM Brian Grinstead wrote: > I've prepared a script that rewrites this across the tree. The script and the > generated patch can be seen at > https://bugzilla.mozilla.org/show_bug.cgi?id=1542877. The following > directories are excluded: > > - third_party Just as a

Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

On Tue, Apr 9, 2019 at 12:01 AM Felipe G wrote: > > > I'm writing to the list in order to: > > 2) See if there are any general best-practices for getting this type of > > change reviewed / landed. For example, should we prefer separate commits / > > reviews per directory, or does a single tree-wid

Some searchfox updates

Over the past week or so I've landed a bunch of small searchfox papercut fixes and improvements. Highlights include: - the blame popup now includes a link to the full changeset on hg.m.o - an "other tools" section on nav panel with links to hg.m.o and dxr (and github's rendering of .md and .rst fi

Re: PSA: Avoid |mach try| task generation by running it in the background

This is great, thank you! On Fri, May 3, 2019 at 10:08 AM Andrew Halberstadt wrote: > > If you use |mach try fuzzy| or |mach try chooser|, you've probably noticed > the line: > Task configuration changed, generating target task set > > Followed by a 20-30 second delay as we rebuild the taskgraph

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Tue., Jun. 11, 2019, 04:01 Jean-Yves Avenard, wrote: > > 1- If you define a StaticPref in StaticPrefList.h there is absolutely > no-need to also defines the value in all.js. In fact this is strongly > discouraged and there should almost never be a need for it. There will > be no end-user visib

Re: Searchfox has prettier position: sticky display now, but you may need to shift-control-refresh

A big thank you to Andrew for implementing this feature! As always, if you do run into problems with it or have suggestions for improvement, please file bugs in Webtools::Searchfox! On Tue, Jun 11, 2019 at 5:45 PM Andrew Sutherland wrote: > > Devoted Searchfox Users, > > Last week you may have n

Re: Firefox 68 beta Build Fail with Tests

Do you have any local changes applied? IIRC some people were running into this after making a local change because it clang-formatted that file and caused the checksum mismatch. On Tue, Jun 18, 2019 at 6:02 PM Charles Robertson wrote: > > Hi, > > I'm trying to build Firefox 68 beta with tests (no

Re: Firefox 68 beta Build Fail with Tests

applied. Is there anything I can do to work around > this? > > Charles Robertson > SUSE > > From: dev-platform on behalf of > Kartikaya Gupta > Sent: Wednesday, June 19, 2019 8:16 AM > To: Charles Robertson > Cc: dev-platform@lists.mozill

PSA: Change to running Gecko tests with WebRender enabled

This is a heads up that once bug 1558598 (on autoland now) sticks it will change how to run test suites with WebRender enabled to make things simpler and more consistent. Previously, if you ran tests with `./mach ` WebRender may or may not have been enabled depending on the hardware being used. To

Re: New and improved stack-fixing

Thank you for the work you put in making this happen! I for one certainly appreciate the results - stack symbolication used to be pretty dodgy for me but now it seems fast and reliable! On Tue, Apr 14, 2020 at 10:22 PM Nicholas Nethercote wrote: > > On Fri, 6 Mar 2020 at 09:52, Nicholas Nethercot

Re: PSA: Changes to Gecko/Firefox mirrors on github

Yay! Thanks for doing this. For posterity, do you happen to know the first commit that was migrated with cinnabar? On Thu, Apr 16, 2020 at 9:55 PM Mike Hommey wrote: > > Hi, > > There are two officially supported mirrors of Gecko/Firefox on github: > - https://github.com/mozilla/gecko-dev/ for ma

Re: Tooling and reporting changes

With this new triage query, a bug like https://bugzilla.mozilla.org/show_bug.cgi?id=1633584 is considered untriaged, because it doesn't have any of the status-firefoxXX flags set. However it's an "enhancement" type bug and so those flags don't really make much sense to be setting. Is this intention

PSA: mozilla/gecko github repository being removed

Hi all, The mozilla/gecko github repository was originally created as a cinnabar mirror of mozilla-central, but it hasn't been updated in over a year now, as the automation machinery that updates it is broken and not maintained. Given that its older sibling mozilla/gecko-dev is now updated with ci

PSA: Python min version bumped to 3.6 for building gecko

For those of you who like me are still running Ubuntu 16.04 LTS: the minimum version of python required to build gecko got bumped from 3.5 to 3.6. As Ubuntu 16.04 doesn't offer python3.6 out of the box, you may need to build it from source to get going again. See https://bugzilla.mozilla.org/show_b

Re: Shutting down legacy Taskcluster deployment

Do these legacy artifacts include firefox builds that are used by mozregression? It looks like there's still a reference to the old taskcluster.net URL at https://github.com/mozilla/mozregression/blob/3df977cf7b9c50bdbe8495cde17baeb6c5724be2/mozregression/config.py#L23 which gets used. It would be

Re: Shutting down legacy Taskcluster deployment

ear we (all > parties) have only accessed 19.04 GB of the 971.77 TB that are older > than 180 days. > > cheers, > -- > coop > > On Fri, Jun 26, 2020 at 6:41 AM Kartikaya Gupta wrote: > > > > Do these legacy artifacts include firefox builds that are us

Desktop pinch zooming on in nightly

Hi all, In bug 1620055 I've flipped the switch to turn on "desktop zooming" (aka pinch zooming on desktop) by default on Nightly (starting tomorrow, probably). We know there are still some issues with this feature, notably around interacting with scrollbars after zooming, but we would like to enab

Re: A new testing policy for code landing in mozilla-central

First - thank you for making these changes! I do find the testing prompt useful as a reviewer, and it has already resulted in a few extra tests being added where they probably wouldn't have been otherwise. After living with this for a week or so, I have two (relatively minor) papercuts: - I really

Re: Searchfox now provides code coverage information directly in the code listing!

Thank you for implementing this Andrew! It's not always easy carving out the time from your "day job" to work on searchfox stuff so kudos for helping keep it the premier source code indexing tool for Mozilla Firefox :) Also thank you to Marco and team for exposing the code coverage info - and whil

Re: Please run mach bootstrap; NodeJS/NPM security fixes landed

Piling on with tangentially-related info: bug 1668921 bumps the minimum cbindgen version requirement and is on autoland now. So if you want until that merges you'll only need to rebootstrap once instead of twice (assuming you use bootstrap to get your cbindgen installed). On Thu, Oct 8, 2020 at 12

Re: View port meta tag

Do you have test cases that demonstrate this behaviour? If so, it would be better to file a bug and attach the test cases, so we can reproduce the behaviour and investigate it. Cheers, kats On 12-08-02 18:09 , Arthur Stolyar wrote: Hi, all. I just tested view port meta tag on various devices

Re: Changes to JS components/JSMs

On 12-10-30 16:31 , Dave Townsend wrote: In case people missed this part specifically, I just want to point out that the change in bug 798491 are targeted for FF18 (Aurora). See comment 75 for philikon's early risk evaluation. From our read of the bug, although this represents major code change,

Re: Scrolling, Scrolling and more Scrolling

I agree, we should try to unify all of this code. A related (but possibly deferrable) problem is to unify all of the gesture detection. I can help you with the Java code in Fennec, in terms of understanding what it does and helping replace it with the B2G fork. This has been on my to-do list f

Intent to implement and ship: CSS property touch-action:pinch-zoom

We intend to enable the following feature in m-c soon, and ship it in Gecko 85. Summary: Support for the "pinch-zoom" keyword value for the touch-action CSS property Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1329241 Standard: https://compat.spec.whatwg.org/#touch-action Pl

<    1   2