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

Karl Tomlinson writes: > "Show Older Inlines" "Disabled" sounds like something to avoid > like the plague. I wonder whether global configuration to remove > that setting is available ... My comment was rash. The setting can actually be very useful (at least tempor

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

Thank you for highlighting those, Jonathan. "Show Older Inlines" "Disabled" sounds like something to avoid like the plague. I wonder whether global configuration to remove that setting is available ... I find the "Collapse" operation on inline comments useful to track remaining relevant

Intent to ship: AudioWorklet

As of this week I intend to turn on AudioWorklet by default for all platforms. It has been developed behind the "dom.audioworklet.enabled" and "dom.worklet.enabled" preferences. Status in other browsers is: Chrome, Opera: shipping. Edge, Webkit: not shipping, intentions unknown. Product: Adam

NotNull and pointer parameters that may or may not be null

Google style requires pointers for parameters that may be mutated by the callee, which provides that the potential mutation is visible at the call site. Pointers to `const` types are permitted, but recommended when "input is somehow treated differently" [1], such as when a null value may be

non-const reference parameters in new and older code

https://google.github.io/styleguide/cppguide.html#Reference_Arguments has a simple rule to determine when reference parameters are permitted: "Within function parameter lists all references must be const." This is consistent with Mozilla's previous coding style: "Use pointers, instead of

precedence of Mozilla, Google, and clang-format styles for C++ code

Near the top of https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style there is > New code should try to conform to these standards, so it is as > easy to maintain as existing code. [...] > > This article is particularly for those new to the Mozilla > codebase [...]" Before

Re: C++ method definition comments

Ehsan Akhgari writes: > What tool do you use which has difficulty showing function names in diffs > right now? It seems to work fine for me both in git and hgweb... It's cases like these that are truncated earlier due to putting the return type before the function name: % hg export

Re: C++ method definition comments

Ehsan Akhgari writes: > On Mon, Jan 28, 2019 at 2:58 PM Jeff Gilbert wrote: > >> I would much rather revert to: >> /*static*/ void >> Foo::Bar() >> >> The Foo::Bar is the most relevant part of that whole expression, which >> makes it nice to keep up against the start of the line. >> > > The

Re: C++ method definition comments

Ehsan Akhgari writes: > On Mon, Jan 28, 2019 at 6:27 PM Ryan Hunt wrote: > >> [...] >> >> So for converting from C-style to C++-style, that would be: >> >> /* static */ void Foo::Bar() { >> ... >> } >> >> // static >> void Foo::Bar() { >> ... >> } >> >> [...] >> >> My one concern would be the

Re: Plan for Sunsetting MozReview

Martin Thomson writes: > On Wed, Sep 5, 2018 at 4:42 PM Mark Banner wrote: >> A couple of things that may help with the scrolling & finding, that >> people may or may not have found yet... > > The keyboard shortcuts are more accessible (type ? to see the list > [1]), though in my experience they

Re: Plan for Sunsetting MozReview

Mark Côté writes: > On August 20, we will remove public access to MozReview and archive > patches. Every landed, in-progress, and abandoned patch will be downloaded > from MozReview and stored in an S3 bucket. The “stub attachments” in > Bugzilla that currently redirect to MozReview will be

Re: Intent to implement: Scrollbar color properties

Xidorn Quan writes: >> Would the color for the auto property be derived in such as way as >> to hide the thumb or to make it constrast? > > No, currently we don't derive them from each other. We simply use some > fallback color in that case. How is the fallback color chosen? > It is not

Re: Intent to implement: Scrollbar color properties

Thanks very much for answering some of my questions for me. Xidorn Quan writes: > On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote: >> Is there a plan to avoid the contrast problems we have mixing >> document colors with system colors in other widgets? >> >>

Re: Intent to implement: Scrollbar color properties

Is there a plan to avoid the contrast problems we have mixing document colors with system colors in other widgets? e.g. If one scrollbar color is specified by the document, then what ensures that other parts of the scrollbar are visually distinct? Does the computed value of the other scrollbar

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

Is there a guideline that should be used to evaluate what can acceptably run in the same process for different sites? I assume the primary goal is to prevent one site from reading information that should only be available to another site? There would also be defense-in-depth value from having

Re: Coding style: brace initialization syntax

On Fri, 13 Apr 2018 10:22:06 -0400, Boris Zbarsky wrote: > On 4/13/18 9:37 AM, Emilio Cobos Álvarez wrote: >> Would people agree to use: >> >>  , mIsRootDefined { false } >> >> Instead of: >> >>  , mIsRootDefined{ false } > > So my take is that we should not use braced initializer syntax in >

Re: Removing tinderbox-builds from archive.mozilla.org

On Fri, 18 May 2018 13:13:04 -0400, Chris AtLee wrote: > IMO, it's not reasonable to keep CI builds around forever, so the question > is then how long to keep them? 1 year doesn't quite cover a full ESR cycle, > would 18 months be sufficient for most cases? > > Alternatively, we could investigate

Re: Intent to ship: media-capabilities

Steven Englehardt writes: > While it may have been > theoretically possible for all trackers to gather statistics on video > playback for each configuration, the only scripts that could practically > carry out those attacks without degrading user experience would have been > video providers. This

Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

On Fri, 4 May 2018 14:32:20 -0400, Boris Zbarsky wrote: > On 5/4/18 3:34 AM, Karl Tomlinson wrote: >> Not sure I understand your question, but the observable behavior >> described by this section, or specifically "Before an AudioNode is >> deleted, it will discon

Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

ng to fix it. > If there is no difference in observable behavior, what would a > normative requirement mean? Good question. I will find that useful at some point. > Karl Tomlinson wrote: >> If the whole normative AudioNode lifetime section were dropped >> then this would clearly be an implementati

Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

Boris Zbarsky writes: > On 5/2/18 5:21 AM, Karl Tomlinson wrote: >> [[AudioNode Lifetime]] https://github.com/WebAudio/web-audio-api/issues/1471 > > I've read through that thread, but I'm still a little unclear on > where thing stand. With the latest proposal, can the

Intent to implement: AudioWorklet

=Summary/benefits: "The AudioWorklet object allows developers to supply scripts (such as JavaScript or WebAssembly code) to process audio on the rendering thread, supporting custom AudioNodes." [[Concepts]] Allowing scripts to process audio on the rendering thread is important for low latency

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

> On Thu, Nov 30, 2017 at 11:09:07AM +1300, Karl Tomlinson wrote: >> The native bytes may not be valid UTF-8, and so if the >> character encoding is UTF-8, then there may not be a valid >> `path` that can be encoded to produce the same `nativePath`. Kris Maglione

Re: Building mozilla-central with clang + icecream

Zibi Braniecki writes: > On Tuesday, November 7, 2017 at 2:54:45 AM UTC-8, pa...@paul.cx wrote: >> I'm using this setup daily (with clang trunk from some weeks ago, not >> 5.0, but it's the same really), here is my mozconfig: >> >> ``` >> export CC="icecc clang" >> export CXX="icecc clang++" >>

Re: How can I get SOCKS settings params of Firefox?

I don't know how well GConf is supported by more recent GNOME versions. I assume GSettings support was added to nsUnixSystemProxySettings because GConf was to be no longer supported, but the crash reporter uses separate code. https://bugzilla.mozilla.org/show_bug.cgi?id=1388897

Re: Bulk Closing Intermittents

I assume this was integrated with OrangeFactor? That is the only way I know to determine whether an intermittent failure has occurred, because failures are not necessarily reported to bugzilla. Is there a mechanism for tracking a failure that we intend to addresss, even when it does not fail

Re: Is it OK to make allocations that intentionally aren't freed?

Andrew McCreight writes: > On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote > wrote: > >> There's also a pre-processor constant that we define in Valgrind/ASAN/etc. >> builds that you can check in order to free more stuff than you otherwise >> would. But I can't for

Re: Improving visibility of compiler warnings

On Sat, 20 May 2017 14:59:11 -0400, Eric Rescorla wrote: > On Sat, May 20, 2017 at 1:16 PM, Kris Maglione > wrote: > >> On Sat, May 20, 2017 at 08:36:13PM +1000, Martin Thomson wrote: >> >>> Hmm, these are all -Wsign-compare issues bar one, which is fixed >>> upstream. We

Re: Using references vs. pointers in C++ code

Nathan Froyd writes: > I think a broader definition of "POD struct" would be required here: > RefPtr and similar are technically not POD, but I *think* you'd > want to require RefPtr* arguments when you expect the smart pointer > to be assigned into? Not sure. Yes, please, for similar reasons as

firefox-dev posting [was Re: unowned module: Firefox::New Tab Page, help me find an owner]

ox-dev, would very clearly be > on-topic and not rejected. > > Justin > > On Wed, Mar 22, 2017 at 7:35 PM, Karl Tomlinson <mozn...@karlt.net> wrote: > >> Benjamin Smedberg writes: >> >> > This is not the list for this question. Please respect this question to the &

Re: unowned module: Firefox::New Tab Page, help me find an owner

Benjamin Smedberg writes: > This is not the list for this question. Please respect this question to the > firefox-dev list. https://wiki.mozilla.org/Firefox/firefox-dev says "Anyone can post. By default, posts will be reviewed by a moderator before being sent to the list." bit in fact some

Re: Project Stockwell (reducing intermittents) - March 2017 update

> It'd make me feel slightly less sad that we're disabling tests > that do their job 90% of the time... The way I interpret a test failing 10% of the time is that either it has already done its job to indicate a problem in the product, or the test is not doing its job. Either way, if it is not

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

zbranie...@mozilla.com writes: > * I still have only 8GB of ram which is probably the ultimate > limiting factor You are right here. RAM is required not only for link time, but also when compiling several large unified files at a time (though perhaps this is not so significant with only 4

Re: Project Stockwell (reducing intermittents) - March 2017 update

I would like to see failure rates expressed as a ratio of failures to test runs, but I recognise that this data may not be readily available and getting it may not be that important if we have a rough idea. These are a means for setting priorities, and so a rank works well. If we have 100 tests,

Re: Please don't abuse "No bug" in commit messages

Gijs Kruitbosch writes: >> What if it causes a regression and a blocking bug needs to be filed? > Then you file a bug and needinfo the person who landed the commit > (which one would generally do anyway, besides just marking it > blocking the regressor). I find the association of multiple

Re: autoland cleanup

Gregory Szorc writes: > On Wed, Nov 30, 2016 at 12:40 PM, Karl Tomlinson <mozn...@karlt.net> wrote: >> When history is rewritten, is there a way to view the original >> history through the web interface, so that autoland tinderbox >> builds can be used to find regressio

Re: autoland cleanup

Gregory Szorc writes: > When the autoland repository was introduced, it was advised to not pull > from this repository because we plan to do rewrites like this frequently in > the future. So if this rewriting impacted your local repo and you aren't a > sheriff, you should consider changing your

Re: Intent to restrict to secure contexts: navigator.geolocation

Aryeh Gregor writes: > On Tue, Oct 25, 2016 at 8:12 PM, Anne van Kesteren wrote: >> The basic problem is prompting the user at all for non-HTTPS since >> that leads them to think they can make an informed decision whereas >> that's very much unclear. So prompting more would

Re: Keyboard scan codes on Linux

On Fri, 19 Aug 2016 17:05:30 -0400, Eric Shepherd wrote: > I'm trying to update the table of scan codes and the keys they go with here: > > https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code#Code_values_on_Linux_(X11)_(When_scancode_is_available) > > But the values in that table

Re: Making try faster for debugging intermittents

William Lachance writes: > As part of a larger effort to improve the experience around > debugging intermittents, I've been looking at reducing the time it > takes for common "try" workloads for developers (so that > e.g. retriggering a job to reproduce a failure can happen faster). > Also,

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

> Could the lack of failure emails be specific to taskcluster jobs? https://bugzilla.mozilla.org/show_bug.cgi?id=1275774 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

Could the lack of failure emails be specific to taskcluster jobs? https://treeherder.mozilla.org/#/jobs?repo=try=a8c6ab15dd8f ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Updating 32-bit Windows users to 64-bit Windows builds?

Lawrence Mandel writes: > Do we need this criteria? > > RAM - Does it hurt to move an instance that has <4GB? Yes. OOM will be more common with 64-bit builds on systems with less RAM because 64-bit builds use more memory. ___ dev-platform mailing list

Re: Can we remove nsIEntityConverter?

Cross-posting to mozilla.dev.tech.mathml so that this is seen by people who are interested. Please follow-up to mozilla.dev.platform. Henri Sivonen writes: > We ship data tables for converting from Unicode to HTML entities. > These tables obviously take space. (They are not optimized for space

Re: Intent to implement and ship: IIRFilterNode

Thanks for the replies, Dan and Roy. A first order filter node with AudioParam inputs seems a likely future addition AFAIK. Even with that though, having a way to apply a custom biquad without needing to decompose into multiple textbook filters is useful I think. And I agree that implementing

Re: Static analysis for "use-after-move"?

Xidorn Quan writes: > I think this specific case should actually use UniquePtr& rather > than && in parameter for conditional move, so that callsite can only pass > in an lvalue, and we don't need a Move there. Jim Blandy writes: > TakeMediaIfKnown is accepting a > UniquePtr as an inout

Re: Intent to implement and ship: IIRFilterNode

Daniel Minor writes: > Summary: This provides an alternative to using BiquadFilterNode when > odd-order filters are required or automation is not needed. It is part of > the Web Audio spec and is already implemented in Blink. Thanks for looking at this, Daniel. I fear that high order filters

Re: How is libc shared object chosen in libxul?

libxul.so is dlopen()ed from the firefox process. That firefox process would already have a libc.so.6, I assume, and so I would not expect libxul.so to load another libc.so.6. That seems to be confirmed here by running strace -e trace=file firefox/firefox See whether something different is

Re: MozReview's interdiffs

Thanks for the info, Mark. In the mean time, at least, it would make interdiffs easiest to read if patch authors can submit updates to patches against the same revision as the original patches. If that causes too much inconvenience (and it will sometimes), then separate pushes for the rebase and

Re: Why is Mozreview hassling me about squashed commits?

Eric Rescorla writes: > I don't believe I am asking for this, just auto-squash on submit. I > certainly understand if it's your position that you have higher priorities, > that's fine, but it's not fine to remove the ability to do squashed reviews > before something like that lands. Perhaps the

Re: Intent to enable e10s by default when running tests locally

Felipe G. writes: > Yeah, --e10s enables e10s in the browser for mochitest-chrome. However, > the test harness is a .xul file opened in a tab, and that runs that tab as > non-remote, so for most tests it ends up testing the same thing as not > using --e10s. Other tabs and/or windows opened

Re: Just Autoland It

Honza Bambas writes: > On 1/25/2016 20:23, Steve Fink wrote: >> For navigation, there's a list of changed files at the top >> (below the fixed summary pane) that jumps to per-file anchors. > > Not good enough for review process. > >> Are you saying you want tabs or something for this (like >>

Re: Just Autoland It

Boris Zbarsky writes: > On 1/23/16 9:48 PM, Mike Hommey wrote: >> Note that if /other/ changes from other bugs have happened to the same >> files between the last reviewed iteration and the rebase before landing, >> the interdiff will show them without any kind of visual cues. > > Ah, that's

Re: Just Autoland It

>> On 25/01/16 05:44 PM, Eric Rescorla wrote: >> >On Mon, Jan 25, 2016 at 1:58 PM, Mike Hommey wrote: >> > >> >>It's also painful to use MozReview's comment system. The comments in the >> >>reviews pane don't show much diff context, and while I just realized >> >>it's possible

Re: Just Autoland It

On Fri, 22 Jan 2016 14:24:38 -0500, Ehsan Akhgari wrote: > What about the case where the information doesn't exist in the > repository because the author, for example, cherry-picked a > specific commit on a throw-away branch because the rest of the > dependencies are still being worked on? Or,

Re: Just Autoland It

Mike Hommey writes: > On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote: >> Heh. Your list of UI complaints is very similar to mine. Some comments: >> >> >> On 01/25/2016 04:26 AM, Honza Bambas wrote: > Also, iirc, when you reply diff comments in MozReview, the resulting > comments

Re: nsThread now leaks runnables if dispatch fails

Xidorn Quan writes: > On Thu, Jan 7, 2016 at 6:47 AM, Karl Tomlinson <mozn...@karlt.net> wrote: >> Xidorn Quan writes: >> >>> You can keep a raw pointer yourself, and release it manually after you >>> find the dispatch fails, like what is done in >>

Re: nsThread now leaks runnables if dispatch fails

Xidorn Quan writes: > On Wed, Jan 6, 2016 at 3:53 AM, Kyle Huey wrote: >> On Mon, Jan 4, 2016 at 4:10 PM, Randell Jesup wrote: >>> >>> Yup. In cases where we anticipate a possible Dispatch failure (which is >>> supposed to become impossible, but isn't

Re: nsThread now leaks runnables if dispatch fails

Kyle Huey writes: > (This is a continuation of the discussion in bug 1218297) > > In bug 1155059 we made nsIEventTarget::Dispatch take an > already_AddRefed instead of a raw pointer. This was done to allow the > dispatcher to transfer its reference to the runnable to the thread the > runnable

Re: Too many oranges!

Kartikaya Gupta writes: > Personally I much prefer the new approach to reporting intermittents. > It's much easier for me to see at a glance (i.e when the bugs are > updated with the weekly count) which ones are actually occurring more > frequently and which bug would be best to spend time on.

Re: Finding out if the main thread is currently animating

David Rajchenbach-Teller writes: > To improve the Performance Stats API, I'm looking for a way to find out > if we are currently animating something on the main thread. > > My definition of animating is pretty large, i.e. "will the user probably > notice if some computation on the main thread

Re: Decommissioning "dumbmake"

On Fri, 16 Oct 2015 10:31:43 -0700, Gregory Szorc wrote: > But as awesome as > these targets are, they can still build more than is desired (especially in > the edit .h file case). This slows down iteration cycles and slows down > developers. > > For this reason, I think dumbmake needs to remain

Re: large memory allocations / resource consumption in crashtests?

On Mon, 27 Jul 2015 21:35:20 +1200, Karl Tomlinson wrote: Sometimes it would be nice to check in crashtests that use, or attempt to use large memory allocations, but I'm concerned that checking in these crashtests could disrupt subsequent tests because there is then not enough memory to test

Re: Use of 'auto'

Jonas Sicking writes: On Sun, Aug 2, 2015 at 3:47 AM, Xidorn Quan quanxunz...@gmail.com wrote: Probably we should generally avoid using constructor directly for those cases. Instead, use helper functions like MakeUnique() or MakeAndAddRef(), which is much safer. We used to have NS_NewFoo()

Re: Allowing web apps to delay layout/rendering on startup

James Burke writes: On Thu, Jul 30, 2015 at 1:28 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: Can't you just make everything display:none until you're ready to show it? Just using display: none seems like it will run into the same problem that prompted bug 863499, where the browser did

Re: large memory allocations / resource consumption in crashtests?

Thanks everyone. That gives me some ideas on how to clean up after the page. I figure that then any OOM issues will at least be in the vicinity of the test doing the large allocation. ___ dev-platform mailing list dev-platform@lists.mozilla.org

large memory allocations / resource consumption in crashtests?

Sometimes it would be nice to check in crashtests that use, or attempt to use large memory allocations, but I'm concerned that checking in these crashtests could disrupt subsequent tests because there is then not enough memory to test what they want to test. Is anything done between crashtests to

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

Tom Tromey writes: It was mentioned elsewhere in this thread that some code assigns to arguments. The style guide should clarify that parameters named aFoo should not be assigned to. Otherwise that defeats the purpose. Non-const references are the exception. If these are really needed, then

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

Bobby Holley writes: On Wed, Jul 8, 2015 at 4:45 PM, Karl Tomlinson mozn...@karlt.net wrote: I think we could relax the 'a' prefix requirement to be a convention used when identifying the variable as a parameter is useful. My opinion is that this is useful for most parameters in all non

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

Bobby Holley writes: On Wed, Jul 8, 2015 at 3:52 AM, Gabor Krizsanits gkrizsan...@mozilla.com wrote: The priority is to automatically rewrite our source with a unified style. foo - aFoo is reasonably safe, whereas aFoo-foo is not, at least with the current tools. So we either need to

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

Jeff Gilbert writes: On Tue, Jul 7, 2015 at 5:41 PM, Karl Tomlinson mozn...@karlt.net wrote: Some people find the prefix helps readability, because it makes extra information immediately available in the code being examined, while you are indicating that this is a significant burden

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

Jeff Gilbert writes: It can be a burden on the hundreds of devs who have to read and understand the code in order to write more code. Some people find the prefix helps readability, because it makes extra information immediately available in the code being examined, while you are indicating

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

Jeff Gilbert writes: I work with a number of these, but after a page or two, why is it at all relevant which vars were args? For information flow? Should we mark locals that purely derive from args as `aFoo` as well? Long functions (which have poor readability anyway) generally have so much

Re: Shutdown hangs are very common

Vladan D. writes: Should fixing shutdown hangs be higher priority? _exit() after profile-before-change notification would be the many-holes-with-one-plug bug to prioritize. https://wiki.mozilla.org/XPCOM_Shutdown https://bugzilla.mozilla.org/show_bug.cgi?id=662444

Re: Voting in BMO

I would like to vote for voting. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: what is new in talos, what is coming up

William Lachance writes: Hi Karl, On 2015-06-04 12:30 AM, Karl Tomlinson wrote: jma...@mozilla.com writes: We will deprecate those instances of compare-talos next quarter completely. The treeherder version seems to randomly choose which and how many of the results to load and so

Re: Extra commit metadata on hg.mozilla.org

Gregory Szorc writes: hg.mozilla.org now displays extra metadata on changeset pages. e.g. https://hg.mozilla.org/mozilla-central/rev/dc4023d54436. Read more at http://gregoryszorc.com/blog/2015/06/04/changeset-metadata-on-hg.mozilla.org/ Thank you, Gregory. I'm sure that will be *very*

Re: The War on Warnings

Nicholas Nethercote writes: Do warnings (as opposed to NS_ASSERTION) do anything in tests? I don't think they do. If that's right, a warning is only useful if a human looks at it and acts on it, and that's clearly not happening for a lot of these. Warnings in tests don't do anything but log

Re: what is new in talos, what is coming up

Thanks, Joel. I've benefited from being able to use perf.html#/comparechooser and will look forward to the performance discussion. jma...@mozilla.com writes: 2) compare-talos is in perfherder (https://treeherder.mozilla.org/perf.html#/comparechooser), other instances of compare-talos have a

Re: The War on Warnings

Martin Thomson writes: I guess that most of these are as a result of actual problems, even if they are minor. The ones that are actual problems would be the ones that are harder to resolve. In my experience, however, when I've seen many of one kind of warning, investigation has revealed that

Re: Intent to implement and ship: document.execCommand(cut/copy)

On 2015-05-23 5:02 AM, Jesper Kristensen wrote: It would be nice of you could also support paste. Ehsan Akhgari writes: Handling paste is a difficult topic, and I definitely don't have a good answer yet. Prompting for paste has two issues: 2. The synchronous nature of the execCommand API

Re: PSA: New C++11 features made available by dropping support for gcc-4.6 in Gecko 38

Ehsan Akhgari writes: On Monday, May 11, 2015, Xidorn Quan quanxunz...@gmail.com wrote: On Tue, May 12, 2015 at 7:29 AM, Ehsan Akhgari ehsan.akhg...@gmail.com javascript:_e(%7B%7D,'cvml','ehsan.akhg...@gmail.com'); wrote: On 2015-04-30 7:57 AM, Xidorn Quan wrote: I guess we probably

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

Ehsan Akhgari writes: On 2015-05-07 5:53 PM, Karl Tomlinson wrote: Ehsan Akhgari writes: This seems similar to the compiler warning situation. Usually at least, I don't think we should automatically modify the code in line with how the compiler reads the code just to silence the warning

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

Ehsan Akhgari writes: This seems similar to the compiler warning situation. Usually at least, I don't think we should automatically modify the code in line with how the compiler reads the code just to silence the warning. Instead the warning is there to indicate that a programmer needs to

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

Ehsan Akhgari writes: On 2015-04-27 9:54 PM, Trevor Saunders wrote: On Mon, Apr 27, 2015 at 09:07:51PM -0400, Ehsan Akhgari wrote: On Mon, Apr 27, 2015 at 5:45 PM, Trevor Saunders tbsau...@tbsaunde.org wrote: I believe we have some cases in the tree where a virtual function doesn't

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

Ehsan Akhgari writes: I think there's a typo of some sort in the question, but if you meant every overriding function must be marked with override, then yes, that is the change I'm proposing, but the good news is that you can now run clang-tidy on the entire tree and get it to rewrite the

Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?

On Wed, 8 Apr 2015 20:40:12 -0700, Nicholas Alexander wrote: On Wed, Apr 8, 2015 at 4:06 PM, Mike Hommey m...@glandium.org wrote: If running nightly screws up profiles for older versions, that's a serious problem imho. Really? Presumably not every forward DB migration can be reverted

Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

Bobby Holley writes: On Fri, Mar 27, 2015 at 2:04 PM, Mats Palmgren m...@mozilla.com wrote: So let's change the project-wide coding rules instead to allow 99 columns as the hard limit, but keep 80 columns as the recommended (soft) limit. I think we should avoid opening up a can of worms

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

On Fri, 19 Dec 2014 18:58:53 -0500, Ehsan Akhgari wrote: On 2014-12-19 4:40 PM, Nils Ohlmeier wrote: On Dec 19, 2014, at 6:56 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Logging sufficiently is almost always enough to not have to use these timers, as those tests have demonstrated in

Re: Getting rid of already_AddRefed?

On Tue, Dec 23, 2014 at 1:21 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Are there good use cases for having functions accept an nsRefPtrT? If not, we can outlaw them. Aryeh Gregor writes: Do we have a better convention for an in/out parameter that's a pointer to a refcounted class?

Re: Unified compilation is going to ride the train

On Fri, 28 Nov 2014 00:46:07 -0800, L. David Baron wrote: On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote: The downside from doing so, though, is that non-unified build *will* be broken, and code purity (right includes in the right sources, mostly) won't be ensured. Do you think this is

Re: [RFC] We deserve better than runtime warnings

L. David Baron writes: On 20/11/14 17:56, Boris Zbarsky wrote: Ah, we can't. We can whitelist the number of assertions in a mochitest (or a number range if the number is not quite stable), but not the text of the assertion. On Thursday 2014-11-20 18:05 +0100, David Rajchenbach-Teller

Re: Removing unused Perl scripts from the tree

Nicholas Nethercote writes: UNSURE -- ./layout/mathml/updateOperatorDictionary.pl - appears to be in fairly recent use This was used to generate an in-tree file from an external spec. It is reasonably likely that there will be future changes to the spec, in which case the script will

Re: treating B2G device tests as tier 1

Jonas Sicking writes: But any type of regression is cause for backout. While I agree regressions are bad, this isn't the usual process. If it were, then I wouldn't bother filing bugs, but merely back out the offending change. There is some kind test for whether the regression costs more than

Re: Getting rid of already_AddRefed?

Aryeh Gregor writes: The compiler is required to use the move constructor (if one exists) instead of the copy constructor when constructing the return value of a function, and also when initializing an object from the return value of a function, or assigning the return value of a function.

Re: Depending on libnotify

Philip Chee writes: On 02/07/2014 18:13, David Rajchenbach-Teller wrote: We had libnotify support but this was removed from the tree on the grounds that it didn't suit our needs. I don't think those were the grounds. AIUI it was just that people didn't want to put effort into a lower

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

Thanks for the overview of a real problem, Andrew. (I recall having to add an exception for a Mozilla Root CA to access email at one time.) Andrew Sutherland writes: I propose that we use a certificate-observatory-style mechanism to corroborate any invalid certificates by attempting the

Re: Gecko style: Formatting function return type and specifiers

Birunthan Mohanathas writes: For top-level function definitions, the recommended style is: templatetypename T static inline T Foo() { // ... } The main reasons for having the function name at the start of a new line, I assume, was to help some tools (including

Re: Policy for disabling tests which run on TBPL

Thank you for putting this together. It is important. jmaher writes: This policy will define an escalation path for when a single test case is identified to be leaking or failing and is causing enough disruption on the trees. Exceptions: 1) If this test has landed (or been modified) in

Re: Recommendations on source control and code review

On Fri, 11 Apr 2014 13:29:01 -0700, Gregory Szorc wrote: https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code I would be thrilled if we started adopting some of the recommendations such as more descriptive commit messages and many, smaller commits over fewer,

  1   2   >