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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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
>
>
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
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::
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
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
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
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Fri, Apr 13, 2018 at 11:06 AM, Emilio Cobos Álvarez wrote:
> I'd be ok with that I guess, though it's more common each time? Also, is
> there any case where you could use braces but not parenthesis? (I'm not a
> C++ expert in this regard).
I think there are. In particular if you're initializin
On Fri, Apr 13, 2018 at 6:18 AM, Jonathan Kew wrote:
> It's presumably auto-generated by a static-analysis tool or something like
> that, but ISTM it has been overly aggressive, adding a lot more code churn
> than necessary (as well as committing some pretty extreme style violations
> such as over
Looks like it was enabled in
https://bugzilla.mozilla.org/show_bug.cgi?id=1411467
On Thu, Mar 15, 2018 at 1:23 PM, wrote:
> Is there a specific bug for enabling this, aside from the meta implement bug?
> ___
> dev-platform mailing list
> dev-platform@l
I was looking to file a bug in Core::Build Config and discovered it
doesn't exist any more. :mccr8 told me there is now a "Firefox Build
System" product that encompasses what used to be Core::Build Config.
I'm not a build peer so I don't know anything more than this; if
anybody wants more context
On Fri, Jan 12, 2018 at 2:03 PM, Nicholas Alexander
wrote:
> Does SF index non-trunk trees? I can't find a way to search
> mozilla-{release,beta} right now. Please correct me if it does?
It does not.
___
dev-platform mailing list
dev-platform@lists.mo
8-01-10 10:49 -0500, Kartikaya Gupta wrote:
>> This will probably come as a surprise to many (as it does to me each
>> time I rediscover it), but if, in a reftest.list file, you do
>> something like this (real example from [1]):
>>
>> skip-if(browserIsRemote) include ogg-vi
On Wed, Jan 10, 2018 at 3:40 PM, Daniel Holbert wrote:
> I'd lean slightly towards allowing the syntax and making it actually skip
> the include expression. This construct seems valuable to have in our
> toolbox (to be used only sparingly, e.g. for cases of platform-specific
> features).
Yeah I'
Another option would be to keep allowing this syntax of "skip-if(x)
include some/reftest.list" but actually make it skip the entire
include if the condition "x" is true.
On Wed, Jan 10, 2018 at 10:49 AM, Kartikaya Gupta wrote:
> This will probably come as a surprise to
This will probably come as a surprise to many (as it does to me each
time I rediscover it), but if, in a reftest.list file, you do
something like this (real example from [1]):
skip-if(browserIsRemote) include ogg-video/reftest.list
this may not do what you expect. My expectation, at least, is tha
Just a heads-up, thanks to a bunch of work by Emilio, searchfox.org
now indexes rust code as well, so you can do things like jump to
function definitions and call sites and whatnot. Please use it and
file bugs under Webtools :: Searchfox for defects or feature requests.
I'm not sure how quickly we'
On Fri, Dec 15, 2017 at 4:59 PM, Andreas Tolfsen wrote:
> I would be interested to hear more about what primitives for user
> input emulation are required.
Touch input emulation would also be good. There are some CSS
properties like touch-action which require emulating user touch input
for proper
It's being investigated:
https://github.com/mozilla-releng/services/issues/707
On Nov 7, 2017 19:05, "Boris Zbarsky" wrote:
On 10/4/17 10:32 AM, Jan Keromnes wrote:
> We've already disabled this "no defects" comment, and are currently
> deploying the fix to production, so the bot should stop se
+1. I also find myself less likely to read the backscroll because of the
high volume of pulsebot messages.
Thanks for bringing this up!
On Nov 4, 2017 07:45, "Philipp Kewisch" wrote:
> Hey Folks,
>
> I'm a big fan of having development discussions in the open, and in the
> past #developers has
So from the discussion here it sounds like using a full (i.e.
non-grafted) cinnabar repository "just works" for most people. It has
the problem of missing CVS history but it seems like people who need
that often can use searchfox and/or a gecko-dev branch in a cinnabar
repo to get it.
And we have
On Mon, Sep 18, 2017 at 11:04 AM, Myk Melez wrote:
> Having said that, I agree that it's worth enabling developers to clone a
> canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a
> while to experiment with ways of doing this.
That's great, thanks. If we can do something like
This message was inspired by the `mach try` thread but is off-topic
there so I think deserves its own thread.
It seems to me that a lot of people are now assuming a cinnabar repo
is the canonical way for git users to develop on mozilla-central. If
we want to make this mozilla policy I don't really
There was a bit of discussion on the PR I submitted yesterday:
https://github.com/servo/webrender/pull/1644#discussion_r136424367 -
we decided to just manually bump it once in a while instead of making
it track `stable`.
On Thu, Aug 31, 2017 at 5:54 PM, Mike Hommey wrote:
> On Thu, Aug 31, 2017 a
Do we have a policy on CI coverage for vendored rust libraries? I'm
concerned for example that we depend on a number of third-party rust
libraries that don't do CI builds against rust stable and so it's
possible they might break. I discovered that webrender CI for example
is currently only building
rr works just fine with multiple processes. Once you have a recording
you can use `rr ps` to show all the process that were recorded and `rr
replay -p ` to attach to a particular process. You can combine -p
with -g as Cameron mentioned to jump to a particular point in a
particular process' lifetime
TLDR: Once bug 1387764 merges to mozilla-central, anybody running with
WebRender enabled on Linux will need to force-enable hardware
acceleration (layers.acceleration.force-enabled=true) to keep
WebRender enabled.
Long version:
Previously the check for enabling WebRender ignored the status of
hard
gps did some magic and things seem to be working again. Pushes that
occurred previously are now showing up on try, so I've reopened the
tree.
On Fri, Aug 4, 2017 at 11:02 AM, Kartikaya Gupta wrote:
> Pushes to try appear to succeed, but the pushlog is somehow busted and
> so TreeH
Pushes to try appear to succeed, but the pushlog is somehow busted and
so TreeHerder won't pick them up and the csets on hg.m.o will show
"unknown" for push info. This is being tracked in
https://bugzil.la/1387407. I've closed the try tree for now since it's
not clear if these pushes will just get
I filed bug 1384233 for removing the header and unnecessary defines.
On Tue, Jul 25, 2017 at 2:13 PM, Honza Bambas wrote:
> Thanks! OTOH, I think we no longer need it. Since VS2015 (our minimal
> toolchain version on Win) supports %z modifier. Only VS2013 and down only
> defines %I.
> -hb-
>
>
https://github.com/mozilla/gecko-dev is generally pretty up-to-date. It
should have a branch for ESR as well.
Cheers,
kats
On Jul 22, 2017 15:43, "Enrico Weigelt, metux IT consult" <
enrico.weig...@gr13.net> wrote:
Hi folks,
are there any official git mirrors (at least for the esr branches),
t
It might be a good idea to integrate this process with the
OrangeFactor Robot, to avoid race conditions like what happened on bug
1328486 (it was bulk-closed, and then a couple of hours later the OF
robot reported that there were two failures this week - but the bug
remained closed).
Cheers,
kats
On Thu, Jun 15, 2017 at 4:16 PM, Jim Porter wrote:
> From what I can tell, if I click inside a webpage, the event starts out
> in chrome and then propagates down into content. I assume there's some
> sort of magic happening in the message manager that pushes the event
> across process boundaries.
This sounds good to me. What mailing lists should the intent email be
sent to? It might help to have a template somewhere as well.
On Wed, Jun 14, 2017 at 4:58 AM, Carsten Book wrote:
> Hi,
>
> we had the case that a new testsuite was enabled and one test of that suite
> resulted in a new perma o
This morning I pushed bug 1252361 to inbound, which modifies the
"fuzzy" and "fuzzy-if" reftest annotations to accept ranges in
addition to single values for the fuzziness parameters. If a single
value "x" is provided, it by default maps to the range "0..x", so it
preserves the existing semantics i
(cross-posted to dev-tech-gfx and dev-tree-management, please direct
replies to dev-platform)
I just landed a change on inbound (bug 1363344) that enables various
test jobs (reftests, jsreftests, crashtests, webgl mochitests, gpu
mochitests) on the Linux64 QuantumRender (aka "linux64-qr") platform
You can update a specific crate to a specific version like so:
cd toolkit/library/rust
cargo update -p encoding_rs --precise
cd ../gtest/rust
cargo update -p encoding_rs --precise
cd ../../../../
mach vendor rust
On Tue, May 2, 2017 at 4:38 AM, Henri Sivonen wrote:
> I have toolkit/library/ru
At one point the steps at
https://wiki.mozilla.org/Platform/GFX/Quantum_Render#Testing_third-party_rust_library_changes
were known to work. I don't know if they have since been broken.
On Fri, Apr 28, 2017 at 3:07 PM, Boris Zbarsky wrote:
> On 4/28/17 1:05 PM, Josh Matthews wrote:
>>
>> Has anybo
Just a heads-up that the git mirrors of m-c (e.g.
github.com/mozilla/gecko-dev and github.com/mozilla/gecko-projects)
are not updating, and are stuck on a changeset from sometime on March
24. Bug 1350696 is open for the investigation.
Cheers,
kats
___
de
, but please file a bug as well and mark it
blocking bug 1342450. Thanks!
On Mon, Mar 13, 2017 at 6:08 PM, Kartikaya Gupta wrote:
> (Cross-posted to dev-platform and dev-tech-gfx, please reply to dev-platform)
>
> In the near future I'm planning to make a change so that WebRender
&
On Thu, Mar 9, 2017 at 10:31 AM, Kartikaya Gupta wrote:
> On Wed, Mar 8, 2017 at 6:02 PM, L. David Baron wrote:
>> As of 5 days ago, "Treeherder Bug Filer" was not using BUG_COMPONENT
>> information. I say this based on:
>> https://bugzilla.mozilla.org/show_bug.c
(Cross-posted to dev-platform and dev-tech-gfx, please reply to dev-platform)
In the near future I'm planning to make a change so that WebRender
will be built (but not enabled) by default in most Nightly/local
builds [1]. This will allow anybody running a stock nightly to turn on
The QuantumRender
On Wed, Mar 8, 2017 at 6:02 PM, L. David Baron wrote:
> As of 5 days ago, "Treeherder Bug Filer" was not using BUG_COMPONENT
> information. I say this based on:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1344304
> being filed in Core :: Layout despite:
> > $ ./mach file-info bugzilla-compon
On Wed, Mar 8, 2017 at 4:01 PM, wrote:
> In the past I have not always been made aware when my tests were disabled,
> which has lead to me feeling jaded.
We have a process (in theory) that ensures the relevant people get
notified of tests. The process involves these steps:
1) There is a moz.bui
I've been reading this thread with much sadness, but refraining from
commenting because I have nothing good to say. But I feel like I
should probably comment regardless. What makes me sad is all the
developers in this thread trying to push back against disabling of
clearly problematic tests, asking
On Mon, Mar 6, 2017 at 7:08 PM, Eric Rahm wrote:
> I assume WebRenderer will have it's own process, but maybe that just gets
> lumped in with the GPU process.
WebRender will live in the GPU process, if there is one. The UI
process otherwise.
Cheers,
kats
_
It looks like it's just the Linux builds that are no longer there. I'm
guessing this has to do with them being on TaskCluster rather than
BuildBot.
On Mon, Mar 6, 2017 at 4:23 PM, Boris Zbarsky wrote:
> On 3/6/17 4:17 PM, Eric Rahm wrote:
>>
>> I'm unaware of a bug for this decision, but https://
On Mon, Feb 27, 2017 at 1:57 PM, Henri Sivonen wrote:
> Now that the build.rs in commented out in the crates.io crate and the
> generated header is shipped in the crates.io crate:
> Considering that editing the vendored crates is not allowed, so I
> can't put moz.build files on the path to the hea
(cross-posted to dev-platform and dev-tech-gfx)
This is just a heads up that earlier today we merged the graphics
branch to m-c, so Quantum Render builds can now be done on central if
you put --enable-webrender in your mozconfig.
We will be running a limited set of builds (linux64 only) and tests
(Explicitly forwarding to dev-tech-gfx and dev-platform, since
apparently bcc'ing lists gets messages stuck in moderation. Please
reply on dev-tree-management. Sorry for my mail-fail!)
-- Forwarded message --
From: Kartikaya Gupta
Date: Mon, Jan 30, 2017 at 2:22 PM
Su
Just a heads-up that I pushed bug 1312319 which adds a new
NS_INLINE_DECL_PURE_VIRTUAL_REFCOUNTING macro to nsISupportsImpl.h.
This macro just defines pure-virtual AddRef/Release functions. It's
intended for use if you're creating a non-nsISupports interface where
you want the implementing classes
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
On Wed, Dec 21, 2016 at 6:19 AM, Gervase Markham wrote:
> Why do we paint a checkerboard
We don't actually paint a checkerboard pattern.
> rather than the default single background
> colour of the page?
This is what we do. It's still *called* checkerboarding though. The
behaviour has changed, t
On Wed, Nov 9, 2016 at 11:51 AM, Ralph Giles wrote:
> On Wed, Nov 9, 2016 at 8:41 AM, Kartikaya Gupta wrote:
>
>> If I edit the third_party/rust/cmake/src/lib.rs
>> in-place, the build fails because of a hash mismatch.
>
> Interesting! This is supposed to happen as a
I'm actually trying to debug a rust issue right now and have some
questions. I've done the |mach vendor rust| step and got all the
vendored crates. Now let's say that in one of the dependencies (the
'cmake' crate in my case) there's some sort of behaviour that I'd like
to investigate/debug. If I ed
In Firefox 52 I intend to ship support for TouchEvents on Windows
e10s. TouchEvent support has already been enabled on Android for a
long time and has been enabled on Linux e10s as well (if you have
MOZ_USE_XINPUT2=1 in your environment). The pref that controls this
feature is dom.w3c_touch_events.
In the next few days, I intend to enable support for touch-action on
Nightly (#ifdef NIGHTLY_BUILD), for all platforms. The implementation
is behind the layout.css.touch_action.enabled property. touch-action
is spec'd as part of the Pointer Events spec [1] - the rest of the
spec is currently being
The wiki says everything from July 1 onwards should be triaged, but
the triage-center tool produces bugzilla links from June 1 onwards
(when you select the "no priority decision" link). Is this
intentional, or just a mix-up?
On Thu, Jun 16, 2016 at 5:17 PM, Emma Humphries wrote:
> This afternoon
What happens after June 24? Is the whiteboard field going to be removed?
On Wed, Jun 8, 2016 at 4:32 PM, Emma Humphries wrote:
> tl;dr -- nominate whiteboard tags you want converted to keywords. Do it by
> 24 June 2016.
>
> We have a love-hate relationship with the whiteboard field in bugzilla. O
1 - 100 of 190 matches
Mail list logo
