PSA: Staying in control of Phabricator comments, and avoiding a footgun

In talking to some other devs recently, it seems there's poor awareness of the options to make your life easier when dealing with Phab Revisions that accumulate a lot of comments. First, the footgun: setting `Settings → Diff Preferences → Show Older inlines → Disabled` will hide comments made

Re: PSA: The `mach bootstrap` installed Mercurial `evolve` extension needs an update

(Conversation taken to the bug.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

PSA: The `mach bootstrap` installed Mercurial `evolve` extension needs an update

Mercurial was broken for me this morning after updating Homebrew packages on macOS. It seem that `mach bootstrap` does not yet update it's copy of the Evolution extension to be sufficiently new. An `hg pull -u` in `$HOME/.mozbuild/evolve` fixes things. I filed

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

Just in case you're not aware of it, there are a couple of perf issues that may make people prefer ccache for now: https://github.com/mozilla/sccache/issues/219 https://github.com/mozilla/sccache/issues/160 Jonathan On 07/06/2019 18:13, Chris M. wrote: > I've been working through issues with

Re: PSA: web-platform-tests (dashboard | fuzzy-reftests | reftest comparisons)

These are all really great. Thanks, James! On 12/04/2019 12:11, James Graham wrote: > There have been a few recent changes related to wpt that may be of > interest to a wider audience; for brevity I'm coalescing them into a > single email: > > * New wpt dashboard focused on interop problems >

Re: sccache as ccache

On 26/07/2017 16:19, Botond Ballo wrote: > On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek wrote: >> If you build Firefox on Linux or OS X you can (and >> should) use sccache in place of ccache for local development. > > Can sccache be used in conjunction with icecc [1]? > > I currently use the

Re: C++ method definition comments

Personally I find them useful. Putting them on a separate line seems reasonable to me. Jonathan On 26/01/2019 04:49, Ryan Hunt wrote: > Hi all, > > Quick C++ style question. > > A common pattern in Gecko is for method definitions to have a comment with the > 'static' or 'virtual'

Re: Intent to unship: most -moz-appearance values not supported by other UAs / spec

Sounds great, and that all looks good to me. Thanks for following up on this, Mats! On 10/10/2018 13:28, Mats Palmgren wrote: > Hi, > > In bug 1496720 I intend to unship most -moz-appearance values that > aren't supported by other UAs / spec. These are mostly XUL-related > values that we use

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

nt WebKit. :) > > > On 2018-08-07 3:16 PM, Jonathan Watt wrote: >> Summary >> --- >> >> I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to >> turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref >

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

On 08/08/2018 21:08, Boris Zbarsky wrote: > On 8/7/18 6:16 PM, Jonathan Watt wrote: >> Spec: None. We're reverse engineering Chrome and ignoring >>https://drafts.csswg.org/css-ui-4/#appearance-switching >>since the 'appearance' property defined there is not >

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

Hi Mike, On 08/08/2018 16:31, Mike Taylor wrote: > Hi Jonathan, > > On 8/7/18 5:16 PM, Jonathan Watt wrote: >> Summary >> --- >> >> I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to >> turn on the '-webkit-appearance'

Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

Summary --- I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref simultaneously changes the behavior of the 'menulist-button' value, and shortly the 'button-bevel' value. Spec: None. We're reverse

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

On 23/03/2018 18:23, Emilio Cobos Álvarez wrote: > Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. > > This is a non-standard API only implemented by Mozilla It was removed from Blink[1] after they forked, but it's actually still implemented in Webkit it seems. Hopefully we

Re: Unifying the common platform parity-* whiteboard flags as keywords

rity-opera opera-parity parity-opera-mini parity-presto opera parity-opera12 As before, preferably direct any feedback to the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1443764 -Jonathan On 08/03/2018 21:56, Jonathan Watt wrote: > I've filed a bug[1] proposing that we create

Unifying the common platform parity-* whiteboard flags as keywords

I've filed a bug[1] proposing that we create the following four keywords in bugzilla, and use the new keywords to replace the various whiteboard flags (and their uppercase variants) indented under each keyword: compat-blink parity-blink parity-chrome parity-opera compat-edge parity-edge

Re: Intent to Ship: Web Authentication

This is really awesome and a significant advance on other 2FA solutions. I've been looking forward to us shipping this. Thank you for all your hard work! On 05/12/2017 20:44, J.C. Jones wrote: > Summary: Support public key cryptographic authentication devices > through Web Authentication. > >

Re: Intent to ship: Retained Display Lists

On 14/11/2017 03:26, matt.wood...@gmail.com wrote: > On Thursday, October 26, 2017 at 5:13:15 PM UTC+13, mwoo...@mozilla.com wrote: >> >> This has now landed in Nightly, and looks to be working really well. >> >> We'd really appreciate some early feedback, so feel free to set >>

MOZ_DEBUG_CHILD_PAUSE is now more flexible

The environment variable MOZ_DEBUG_CHILD_PAUSE can now be set to the time in seconds that you want new content processes to sleep for just after they start (to give time to attach a debugger). For backwards compatibility, setting the value to 1 is special and maintains the old behavior of 30s

Re: Intent to ship: CSS 'transform-box' property

On 01/03/2017 21:54, Jeff Muizelaar wrote: > What is the status of this property in other browsers? We would be the first to implement. Safari: it's primarily Apple people who edit the spec so I'd hope they'd implement, but who knows. Blink: previously when we've tried to get commitment there's

Intent to ship: CSS 'transform-box' property

In bug 1208550[1] we plan to allow the 'transform-box' property[2] to ride the trains to release. Summary: This property solves a common SVG authoring request - allowing transforms in SVG to be relative to an element's bounds (to rotate around its center, for example) - but in a more consistent

Intent to ship: support "basic shapes" for the CSS 'clip-path' property

Summary: Currently clip-path clipping requires a reference to an SVG element which can be cumbersome for authors. We intend to allow clip-path to specify basic shapes (circle, ellipse, polygon) inline, for example: style="clip-path: polygon(20% 50px, 200px 25%, 200px 150px, 20% 75%)"

Re: C++ Core Guidelines

For those who are interested in this, there's a bug to consider integrating the Guidelines Support Library (GSL) into the tree: https://bugzilla.mozilla.org/show_bug.cgi?id=1208262 On 30/09/2015 22:00, Botond Ballo wrote: Hi folks, I wanted to draw your attention to a new project underway in

Re: Intent to ship: Directory picking and directory drag-and-drop

On 22/09/2015 15:46, Anne van Kesteren wrote: On Mon, Sep 21, 2015 at 5:37 PM, Jonathan Watt <jw...@jwatt.org> wrote: 2. https://wicg.github.io/directory-upload/proposal.html It still seems bad that this is not being integrated into whatwg/html directly. It's not that this isn't

Re: Intent to ship: Directory picking and directory drag-and-drop

On 22/09/2015 00:27, Richard Barnes wrote: On Mon, Sep 21, 2015 at 6:58 PM, Jonathan Watt <jw...@jwatt.org> wrote: I don't think directory picking is bad - there are many sites with legitimate uses. I think it's right that we need to think about the security implications though, and m

Re: Intent to ship: Directory picking and directory drag-and-drop

to users what's going on? Is there going to be a way to disable it? -Ekr On Mon, Sep 21, 2015 at 8:37 AM, Jonathan Watt <jw...@jwatt.org> wrote: Targeting Firefox 44 we intend to ship[1] Directory Upload[2], which provides directory picking (via ) and directory drag-and-drop. Our implementati

Re: Intent to ship: Directory picking and directory drag-and-drop

On 21/09/2015 19:57, Eric Rescorla wrote: On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking wrote: Note that this, similarly to clipboard integration, is already exposed to the web through flash. So the main goal of this feature is to enable developers to migrate off of flash

Re: Intent to ship: Directory picking and directory drag-and-drop

On 21/09/2015 19:31, Eric Shepherd wrote: Jonas Sicking wrote: Note that this, similarly to clipboard integration, is already exposed to the web through flash. So the main goal of this feature is to enable developers to migrate off of flash and instead use Gecko. That said, if there are ways

Intent to ship: Directory picking and directory drag-and-drop

Targeting Firefox 44 we intend to ship[1] Directory Upload[2], which provides directory picking (via ) and directory drag-and-drop. Our implementation has been developed behind the `dom.input.dirpicker` preference, enabled only in Nightly builds so far. In addition to previously announcing

Intent to implement: directory picking and directory drag and drop

MS has a proposal for a minimal set of functionality to support directory picking via input and to support directory drag and drop. https://microsoftedge.github.io/directory-upload/proposal.html This spec is a work in progress but we now have an implementation for platforms that have a

Scott Meyers new book Effective Modern C++

On his blog he has a discount code you can use on the publishers site for those of you who care to have a copy of the new C++11/C++14 book. http://scottmeyers.blogspot.com/2014/12/effective-modern-c-exists.html ___ dev-platform mailing list

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On 21/11/2013 01:12, Daniel Glastonbury wrote: I followed your advice. Quit Xcode, created .lldbinit, ./mach clobber ./mach build and my missing breakpoints are back. Thank you. You're welcome. ___ dev-platform mailing list

UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

Just a heads-up for other LLDB users... The last few days I've been driven nuts by Xcode failing to stop at some breakpoints (it just lists them as pending). I've now tracked this down to the use of UNIFIED_SOURCES. The issue is explained here: http://lldb.llvm.org/troubleshooting.html

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On 20/11/2013 18:30, Ehsan Akhgari wrote: On Wed, Nov 20, 2013 at 1:27 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt jw...@jwatt.org wrote: I may end up being the guinea pig that is perpetually having his builds broken because he has to have

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On 20/11/2013 18:48, Ehsan Akhgari wrote: On 2013-11-20 1:33 PM, Jonathan Watt wrote: I'm still investigating this, and will contact them once I understand a bit better what's going on. For now I still wanted to give other LLDB using mozilla devs a heads-up though. Thanks! Please keep us

Re: nsGUIEvent.h related stuff has been sorted out

On 23/10/2013 09:18, Masayuki Nakano wrote: I hope this change makes you happy! It does - this is great stuff! Thank you for all your work on this! -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___

Re: Cost of ICU data

On 15/10/2013 17:06, Benjamin Smedberg wrote: I'm going to post some details here about how much this costs in terms of disk footprint, to discuss whether there are things we can remove from this footprint, and whether the footprint is actually worth the cost. As a heads up, I'm currently

Re: Extending the text-overflow/overflow property to support fading out

On 21/05/2013 11:04, fantasai wrote: First thought: I don't think this belongs on 'overflow'. That says how to handle overflow, not how to style the visible content. In the case of extending 'overflow', I'd imagine the fade would go on the outside of the clip rect rather than on the inside.

Extending the text-overflow/overflow property to support fading out

The design for the Australis theme refresh calls for tab text that needs to be truncated to be faded out instead of using an ellipsis. This fade should be a fixed width (say 2em) regardless of the width of the tab, and apparently needs to work over non-solid color backgrounds (so a

Please upgrade to at least Mercurial 2.5.1

Earlier today I noticed that hg annotate was messed up on m-c for nsSVGFilters.cpp. Turns out this was due to a bug that has been fixed in Mercurial 2.5. Please update to version 2.5.1 to help us avoid this problem in future. Details for those that are interested: