New Firefox data steward

I am happy to announce that Rebecca Weiss will be taking over my responsibilities as Firefox data steward. Rebecca has been a data steward peer for a while and has been instrumental in helping Mozilla use data effectively. --BDS https://wiki.mozilla.org/Firefox/Data_Collection

Re: Care in the use of MOZ_CRASH_UNSAFE_* macros: data review needed

I don't know really anything about how rust panics get reflected into crash-data. Who would be the right person to talk to about that? --BDS On Mon, Jul 17, 2017 at 12:40 PM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: > On 07/17/2017 05:18 PM, Benjamin Smedberg wrote:> Unli

Care in the use of MOZ_CRASH_UNSAFE_* macros: data review needed

Please take care when using the MOZ_CRASH_UNSAFE_* macros. Because of the risk involved and because this constitutes data collection, I would like Firefox data stewards to review any new usages of the MOZ_CRASH_UNSAFE_* macros. Unlike MOZ_CRASH, which only annotates crashes with compile-time

mozilla-central is closed for lack of mac symbols/crash data

Starting with Monday's nightly we've discovered that we're missing mac symbols for the XUL library. Because this makes crash statistics useless, this means that we can't bisect or detect most crash issues on mac. For that reason, I've asked sheriffs to close the tree. This is being tracked in bug

Intent to ship: telemetry opt-in and extended data changes

As part of streamlining Firefox preferences and making our data pipeline work more smoothly, we’re are planning some changes to the way Firefox data opt-in and preferences work. We’re making this change to reduce user confusion and align preferences with the Firefox privacy notice, remove

Re: Changing .idl files

On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote wrote: > > (3) Do extensions use it? If so, changing it probably isn't possible. This > can > be imperfectly determined by searching through addons/ in DXR. > There is no rule that we can't break old-style addons: it

Re: Linux builds now default to -O2 instead of -Os

On Thu, Jun 1, 2017 at 8:52 PM Mike Hommey wrote: > Hi, > > For some reason, the default when building on Linux had stayed -Os. I > just landed a change[1] to this default to now use -O2 instead (on > autoland at the moment). This is going to give better performance to > local

Re: Intent to Ship throttling of tracking timeouts

Do you have a risk assessment and/or test plan for this feature? This feels like something that is both quite important and quite risky and I'd love to understand more about how you plan to test/validate this kind of feature. --BDS On Thu, May 11, 2017 at 10:59 AM, Andreas Farre

Re: Intent to change editor newline behavior

On Tue, Apr 4, 2017 at 8:12 PM, Ehsan Akhgari wrote: > I doubt it's used much. My assumption is only that not many sites are >> UA-sniffing Firefox, finding the s, and modifying them in some way >> that breaks if they're no longer s. That could still be totally >>

Re: Intent to change editor newline behavior

I'd like to encourage you to set up a test plan for this. My impression of the risk profile of this work is that we could easily break some really important use-cases, and it's likely that sites customize for gecko behavior and rely on it, either accidentally or on purpose. This is definitely the

Re: Async Iteration is available on non-release-only, for testing purpose

I am concerned about the accidental consequences of turning this on for nightly/aurora. What if we start writing browser code that relies on these features which unexpectedly starts failing in beta? I presume the value of enabling this in nightly/aurora is that we can get web developers to

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

This is not the list for this question. Please respect this question to the firefox-dev list. Also I recommend that another way to get traction in this sort of question is to contact the moisture owner, in the case Dave Townsend. --BDS On Wed, Mar 22, 2017 at 9:25 AM wrote:

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

I apologize for the delays in bug 1246615. It fell off my radar with a series of trips. I've set up a meeting tomorrow to at least identify who is responsible for this decision, because it's not exactly me. I analyzed some data in the bug which I'll repeat here. Here is an analysis of the

Re: Tracking bug for removals after XPCOM extensions are no more?

On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky wrote: > On 3/15/17 3:26 PM, Botond Ballo wrote: > >> What will happen to WebExtension Experiments once these APIs start >> being removed? My understanding is that WebExtension Experiments use >> the same XPCOM APIs as XUL addons.

Re: ANN: Default bug view for BMO changed today!

One other tip which really helped me: you can hit Control-E to go to bug editing mode. I bet there are other cool keyboard shortcuts, but I don't know if there's a guide or not. --BDS On Wed, Mar 1, 2017 at 3:47 PM, David Lawrence wrote: >Today, the BMO Team changed

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

At this point it seems unlikely that I will have time to fix this for Firefox 54, so most-likely it will be Firefox 55. --BDS On Tue, Feb 14, 2017 at 8:54 PM, 段垚 wrote: > Seems I failed to convince you to change the plan. > > So the last question is: when will this happen? >

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On Thu, Feb 16, 2017 at 2:57 PM, L. David Baron <dba...@dbaron.org> wrote: > On Thursday 2017-02-16 13:20 -0500, Benjamin Smedberg wrote: > > I'm surprised and disheartened that "land it and see what breaks" is > > considered an acceptable strategy for pretty much

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

I'm surprised and disheartened that "land it and see what breaks" is considered an acceptable strategy for pretty much any commit, but especially for web compat. We *don't* see what breaks fast enough or before things hit the release population. We cannot currently rely on our prerelease

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Fri, Feb 10, 2017 at 12:36 AM, 段垚 <duan...@ustc.edu> wrote: > > 在 2017/2/10 1:28, Benjamin Smedberg 写道: > >> On Wed, Feb 8, 2017 at 2:26 AM, 段垚 <duan...@ustc.edu> wrote: >> >> Is this just preventing auto-loading (like "click to play") or comp

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

. We don't have anyone testing or defending this effectively. So we believe that there is significant harm in the current situation, and very little upside. --BDS On Thu, Feb 9, 2017 at 7:09 PM, Xidorn Quan <m...@upsuper.org> wrote: > On Fri, Feb 10, 2017, at 04:29 AM, Benj

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Tue, Feb 7, 2017 at 5:19 PM, Chris Peterson <cpeter...@mozilla.com> wrote: > On 2/7/2017 1:15 PM, Benjamin Smedberg wrote: > >> I intend to ship a change which will prevent Flash from loading from >> file:, >> ftp:, or any other URL scheme other than

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

Will this also prevent loading downloaded .swf files into Firefox? This is > useful for running Flash games, which tend to work best in the browser > (some media players also support loading Flash files, but their hotkeys > tend to conflict). It will prevent them from loading via File > Open,

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Wed, Feb 8, 2017 at 2:26 AM, 段垚 wrote: > Is this just preventing auto-loading (like "click to play") or completely > disable Flash for non-http(s) contents? > This is completely disabling this content. > > Can users get back old behavior by flipping a preference? > That

Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

I intend to ship a change which will prevent Flash from loading from file:, ftp:, or any other URL scheme other than http: or https:. The purpose of this change is to increase security and limit Flash to well-tested configuraitons. - file: same-origin security mechanism is different, and so

Re: Content process launch time distribution

On Tue, Feb 7, 2017 at 2:38 PM, Harald Kirschner wrote: > > To better understand the long tail of slow process startup, 95th > percentile is over 5s, the context of this metric could : > I doubt that I'm the right person to own a deep dive into this, but I will attempt to

Content process launch time distribution

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2017-02-06=__none__!__none__!__none___channel_version=aurora%252F53=CONTENT_PROCESS_LAUNCH_TIME_MS_channel_version=null=Firefox=1_keys=submissions_date=2017-01-26=0=1_submission_date=0 This shows the distribution of times to

Re: Aarch64 as higher than tier-3?

I've started an discussion about the arm64 windows version, but we don't have any news/decision yet. We may need to for market reasons, but the cost in terms of release engineering, release testing and to some extent feature testing is not trivial. I expect that Android arm64 is similar, but I

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

the files in xpcom/glue as well as making our startup code and sequence less crazy and spread across many files and directories. --BDS On Tue, Aug 30, 2016 at 11:44 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > This is notice of an intent to change how we export symbols from the

Re: Is it possible to implement "click to play" for Adobe Flash in XULRunner app?

You have to manage the UI yourself. Firefox does this with a combination of applying an overlay to the disabled Flash which shows the grey UI, plus script that sets permissions and activates plugins appropriately. Because of e10s, that code is split between multiple files, but you should try to

Re: Intent to ship: CSS Grid

Have the various grid properties be added to our fuzzers and we've been fuzzing the implementation fairly comprehensively? --BDS On Tue, Nov 15, 2016 at 7:40 PM, Mats Palmgren wrote: > As of Gecko 52, I intend to let CSS Grid ride the trains on all platforms. >

Re: Intent to implement: OpenType Variation Fonts

I want to make sure that our test plan includes fairly comprehensive fuzzing coverage, since this appears to be a new attack surface. --BDS On Mon, Dec 5, 2016 at 9:28 AM, Jonathan Kew wrote: > We're proposing to implement support for OpenType Variation Fonts in Gecko. > >

Volunteer maintainer wanted: mac x86

As of Firefox 53, we are intending to switch Firefox on mac from a universal x86/x86-64 build to a single-architecture x86-64 build. To simplify the build system and enable other optimizations, we are planning on removing support for universal mac build from the Mozilla build system. The Mozilla

Please do not add any new CppUnitTests/GeckoCppUnitTests

Please do not add any new CppUnitTests. With the pending removal of the XPCOM glue, CppUnitTests will fail to build and are no longer an option. We are currently porting current CppUnitTests to gtests, and if you are tempted to write a CppUnitTest, please write it as a gtest instead. --BDS

Re: Recovering a Bugzilla account

Leman, off-list please contact Emma Humphries , the Mozilla bugmaster, who can help coordinate account recovery. --BDS On Mon, Nov 7, 2016 at 5:19 PM, Leman Bennett (Omega X) < Redacted.For.Spam@request.contact> wrote: > I need to talk to an admin about recovering my bugzilla

Re: do_GetService("@mozilla.org/embedcomp/prompt-service; 1") doesn`t work any longer in FW v

Please don't use binary XPCOM. Support for binary XPCOM is being removed. And also it's very unlikely that a modal prompt is a good UI solution from within the network stack. --BDS On Thu, Oct 27, 2016 at 4:19 AM, Tobias Wolf wrote: > Hi folks, > > I`ve developed a nss

Re: Some recent crash-stats improvements

Yes, downloading raw minidumps and memory reports requires the PII permission in crash-stats. This can be obtained by Mozilla employees with the assent of your manager, although I'm not sure now what the correct bugzilla component is. --BDS On Mon, Oct 10, 2016 at 6:23 PM, Ben Kelly

Re: Converting assertions into release assertions

Definitely explore this! I want us to be very careful/deliberate about the privacy consequences of this, though. Any values which could be user data need to be tightly controlled, in the same manner we control access to the minidumps themselves. So I don't think we should be too generic about

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

On Tue, Aug 30, 2016 at 6:08 PM, Ehsan Akhgari wrote: > > Can you please clarify why this proposal is around preventing external > DLLs from using XPCOM? In my experience, a good number of the DLLs > different programs inject into Firefox are injected using the several

Re: Intent to harden binary injection by removing XPCOM and related xul.dll exports

On Tue, Aug 30, 2016 at 12:16 PM, Gregory Szorc wrote: > > To clarify, are you proposing a) removing all support for exporting XPCOM > symbols from libxul full stop or b) changing the shipping configuration of > Firefox to not export these symbols? > b) is the minimum option

Intent to harden binary injection by removing XPCOM and related xul.dll exports

This is notice of an intent to change how we export symbols from the Firefox DLLs and binaries. Currently our policy is that extensions may not include binary XPCOM components, and we've implemented some very basic rules that make it difficult for extensions to load these components. However,

Re: New [must_use] property in XPIDL

cast-to-void is commonly suggested as an alternative to an explicit unused marking, and it is something that I wanted to use originally. Unfortunately, we have not been able to make that work: this is primarily because compilers often remove the cast-to-void as part of the parsing phase, so it's

Re: Welcome new Data Stewardship Peers

with other flags as first-class citizens. --BDS On Wed, Jul 13, 2016 at 7:20 PM, Gerald Squelart <squel...@gmail.com> wrote: > On Thursday, July 14, 2016 at 6:51:21 AM UTC+10, Benjamin Smedberg wrote: > > I'd like to welcome Chenxia Liu, François Marier, and Rebecca Weiss as >

Core: Tracking is no more!

The "Tracking" component has been a place for a random hodgepodge of bugs that were designed to track things, but often had very poor ownership and decision-making. So we've removed it! I went through the open tracking bugs and either closed them if they were no longer relevant, or moved them to

Welcome new Data Stewardship Peers

I'd like to welcome Chenxia Liu, François Marier, and Rebecca Weiss as peers of Firefox Data Stewardship, joining Ally and myself. I'm excited to bring a selection of people from across the organization who are familiar with different products and projects within Mozilla, and I hope that this

Re: Why do we still need to include Qt widget in mozilla-central?

> served it's purpose. Anyone that wants to keep it alive can do it outside > of m-c (long live dvcs). > > > > On Thu, Jun 23, 2016 at 12:35 PM Benjamin Smedberg <benja...@smedbergs.us> > wrote: > >> I'm going to resurrect this old thread to ask: is anybody cu

Re: Enabling seccomp-bpf for content process on nightly Linux desktop

Assuming these crashes show up in crash-stats.mozilla.com, are there particular signatures, metadata, or other patterns that would let us say "this crash is caused by a sandbox failure"? That seems like it would be fairly important, so that we can monitor this in the field. --BDS On Tue, Jul 5,

Guidance wanted: checking whether a channel (?) comes from a particular domain

As part of plugin work, I'm implementing code in nsDocument::StartDocumentLoad which is supposed to check whether this document is being loaded from a list of domains or any subdomains. So e.g. my list is: ["foo.com", "baz.com"] // expect 15-20 domains in this list, maybe more later And I want

Re: [Go Faster] WebCompat Go Faster Add-on

or doing code review? And who is the QA/QE lead for this addon and what kind of systems will be used to determine whether a particular webcompat tweak is working both before before and after deployment? --BDS -- Benjamin Smedberg Engineering Manager, Firefox ___

Re: Why do we still need to include Qt widget in mozilla-central?

I'm going to resurrect this old thread to ask: is anybody currently triaging bugs the Core: Widget: Qt bugzilla component? I'm trying to find owners for all of our active bugzilla components, and I'm not sure the status of this. I would support us removing the widget/qt code from the tree unless

Re: Intent to remove: Error Console

\o/ Is there a bug to track this code removal? --BDS On Mon, Jun 6, 2016 at 4:04 PM, Brian Grinstead wrote: > There is an Error Console feature in toolkit that's been replaced by the > Browser Console. We'd like to remove associated code in >

Intent to implement: a list of domains to auto-disable plugins

Summary: plugins, especially Flash, are still a major attack vector for malware authors. We intend to create a list of domains which are commonly loaded in a 3rd-party context and which therefore present a higher than normal risk of malware attacks. Sites on this list would be automatically

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

It's likely that this particular report is running out of VM, yes. jemalloc allocates new memory chunks in large blocks (1MB?), and with only 122MB of VM it's likely that a lot of that is inaccessible, either because of fragmentation or because sites are allocating VM blocks of less than 64k,

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

You're assuming that this happens every time, instead of randomly. If you add the time since last crash to your column list, you can see that this is true in some cases and not others. I changed your link a little: * remove "moz crash reason exists" - any startup crash is a problem * excluded

Re: Intent to deprecate: MacOS 10.6-10.8 support

Yes. --BDS On Sun, May 29, 2016 at 6:59 PM, Chris Pearce wrote: > So, given that users won't be able to install Firefox on unsupported > versions of MacOSX, and unsupported users won't be upgraded, can we proceed > to remove all the

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

You shouldn't need to annotate the file/line separately, because that is (or at least should be!) the top of the stack. FWIW, we are currently working on changing the signature for crashes with an AbortMessage (those using NS_RUNTIMEABORT) so that the abort message is part of the signature. After

Re: C++11 standard library support enabled on all Tier-1 platforms

It used to be that using STL headers not in the approved list would fail to compile. I don't know whether that mechanism is still turned on or works correctly. --BDS On Fri, May 27, 2016 at 8:24 AM, Josh Matthews wrote: > On 2016-05-26 9:50 PM, Nathan Froyd wrote: > >>

Re: Intent to deprecate: MacOS 10.6-10.8 support

> What about users to try to install Firefox on an unsupported MacOS > version? Will the installer show some sort of notification/dialog box > saying that their OS is unsupported? Or will Firefox just fail to start or > crash mysteriously? > > > cpearce. > > > > On Fr

Re: Documentation on how to read crash reports

Here is a selection of docs that we've written over the years. Many are incomplete. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Crash_reporting https://developer.mozilla.org/en-US/docs/Crash_Data_Analysis

Re: Intent to deprecate: MacOS 10.6-10.8 support

I thought this was already asked and answered, but just to be clear. We are not going to make any changes to the ESR schedule or make Firefox 48 any kind of long-term release. The development costs of maintaining another branch are high, and not something we're willing to pay. --BDS On Tue, May

Re: How do we measure active users on a given architecture?

In general, the update pattern of these users matches the rest of our population. They have updates turned on and generally are running a new version. That is true of populations we've looked at including WinXP (and WinXPSP2) and MacOS. I'm not sure if we looked at that specifically for the SSE2

Re: On the merits of bringing back MSVC2015 to 48 to fix a top crasher

On Thu, May 19, 2016 at 5:34 PM, Patrick McManus wrote: > > I’m not sure how to compare the size of the populations impacted by the > crash vs the size of the population impacted by the SSE dependency. My > intuition says the no-SSE population is very small and we might be

Re: Requiring SSE2 on all 32-bit x86 OSs (was: Re: Reverting to VS2013 on central and aurora)

On Wed, May 18, 2016 at 6:54 AM, Mike Hommey wrote: > Henri Sivonen wrote: > > > It seems that we are almost ready to require SSE2 for Mozilla-built > > Firefox for 32-bit x86 Linux. > There are a couple of interrelated issues here. Can we require SSE2 for Mozilla builds of

Re: Reverting to VS2013 on central and aurora

On Mon, May 16, 2016 at 8:47 AM, Henri Sivonen wrote: > > > For clarification: Does this decision apply to 32-bit x86 Linux as > well? (It would be sad to have to supply and maintain non-SSE2 x86 > code paths just for Linux.) > Nobody asked about that, so it's wasn't

Re: Intent to deprecate: MacOS 10.6-10.8 support

The actual content of the page is not final, but I did include that recommendation in my request for a SUMO page. See https://bugzilla.mozilla.org/show_bug.cgi?id=1270221 --BDS On Fri, May 13, 2016 at 4:59 PM, Adam Roach wrote: > On 5/13/16 14:26, Ben Hearsum wrote: > >> I

Re: Reverting to VS2013 on central and aurora

starting in Firefox 49, and I will update the tracking bugs to reflect that. --BDS On Fri, May 6, 2016 at 1:17 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg <benja...@smedbergs.us> > wrote: > >> I agree that we shoul

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

We have considered this, but in the grand rollout plans for 64-bit Firefox it's low on the list. We're still dealing with Flash sandboxing/functional regressions as a blocker for wider rollout, and the next step is probably to progressively roll out win64 to new users before we consider anything

Re: Intent to deprecate: MacOS 10.6-10.8 support

<bhear...@mozilla.com> wrote: > Thanks for clarifying. It seems like the confusion came from the fact that > we had *intended* to drop support in 48.0, but it hadn't happened yet. And > now we don't *intend* to drop support until 49.0? > > On 2016-05-13 02:55 PM, Benjamin Smedb

Re: Intent to deprecate: MacOS 10.6-10.8 support

Nils, feel free to file a bug on this and cc bhearsum. I don't know how much work this would be. --BDS On Fri, May 13, 2016 at 2:18 PM, Nils Ohlmeier wrote: > > > On May 3, 2016, at 15:18, Adam Roach wrote: > > > > On 5/3/16 4:59 PM, Justin Dolske

Re: Intent to deprecate: MacOS 10.6-10.8 support

Right now the code to disable 10.6 has landed only on nightly/49, and other bits are still blocked (see bug 1270217) because our MacOS builders (not the testers) are still running MacOS 10.7. As of this point, I expect that Firefox 48 will still run on 10.6-10.8 and the first release to drop

Re: Reverting to VS2013 on central and aurora

I agree that we should drop support for non-SSE2. It mattered 7 years ago (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really doesn't matter now. We do need to avoid updating these users to a build that will crash, and do the same "unsupported" messaging we're doing for old

Re: Changes to bugzilla "plugins" product

this new :: > Other component? > > (There are ~700 open bugs there still, most of which look pretty stale.) > > Justin > > On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg <benja...@smedbergs.us> > wrote: > >> There used to be a bugzilla.mozilla.org product ca

Changes to bugzilla "plugins" product

There used to be a bugzilla.mozilla.org product called "Plugins". This product has been renamed "External Software Affecting Firefox" and its component structure has been greatly simplified. It is usually not helpful to track defects in 3rd-party software in the Mozilla bug tracker. The only time

Re: Out parameters, References vs. Pointers (was: Proposal: use nsresult& outparams in constructors to represent failure)

I used to be the module owner of our coding conventions, but I believe that duty has now fallen on Nathan Froyd with the establishment of the new module covering c++ idioms and usage, noted in this governance thread:

Re: Telemetry experiments need to be easier (on Nightly)

The goal of this is for experiments to be fairly lightweight. Can you talk about where the problems were? The only signoffs that are currently required are code review (no surprise there) and acknowledgement from a release driver. For pref flips in particular, we've talked about extending the

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

I don't see how we can do this by default without harming our users. We can be confident that this will break persistent login for lots of sites. I appreciate the goal of moving HTTPS forward, but we are not in a position where we our marketshare would force changes to the web ecosystem. Before

Re: Crash signature change: signatures now include abort messages

le > > On Wed, Apr 6, 2016 at 2:18 PM, Benjamin Smedberg <bsmedb...@mozilla.com> > wrote: > >> A change just landed which will change the way crash signatures are >> computed for intentional aborts. Previously the crash signature would be >> "NS_DebugAbort

Crash signature change: signatures now include abort messages

t. Thanks to Adrian Gaudebert for taking this in bug 803779! --BDS -- Benjamin Smedberg Engineering Manager, Firefox ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 3/12/2016 7:19 PM, Gabor Krizsanits wrote: Seems like a tough decision for such a short time... There were some great points on both sides so far, but I'm missing the math. To evaluate the cost/benefit for a decision like this we should be able to estimate how much engineering time does it

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 3/10/2016 5:25 PM, Mike Hommey wrote: It's unfair to mention those populations by percentage of the global Firefox population. Why do you think this is unfair? This is about making the best use of our limited engineering/testing/QA resources, and so what really matters is the total

Intent to deprecate: MacOS 10.6-10.8 support

This is notice of an intent to deprecate support within Firefox for the following old versions of MacOS: 10.6, 10.7, and 10.8 The motivation for this change is that we have continued failures that are specific to these old operating systems and don't have the resources on engineering teams to

Re: call prompt service dynamically

On 3/8/2016 7:33 AM, Tobias Wolf wrote: We`re develping a PKCS11 modul in c/c++ for a custom card reader to support. I just want to display a simple dialog. This is not a good idea. I don't believe that PKCS11 modules run on the UI thread and so trying to do anything with XPCOM from this

Re: call prompt service dynamically

On 3/7/2016 11:17 AM, Tobias Wolf wrote: I try to call this code dynamically: nsCOMPtr promptService = do_GetService("@mozilla.org/embedcomp/prompt-service;1")); promptService->Alert(NULL, NULL, NULL); I do the following: nsISomeInterface* mXPTCStub; nsresult rc;

Re: Exit code -11 must die

On 2/27/2016 9:06 PM, Randell Jesup wrote: months until recently it popped up a bit). Note that this failure *never* results in a crashdump, and I've never seen it locally, just in Automation. What we do know: * Exit code -11 is evidence a SIGSEGV (crash). This I don't know, but somebody

Re: Bug Program Next Steps

On 1/29/2016 6:45 PM, Emma Humphries wrote: Why This Matters Bugs are a unit of quality we can use to see how we’re doing. We believe that the number of outstanding, actionable bugs is the best metric of code quality available, and that how this number changes over time will be a strong

Re: Does SSE2 usage still need to be conditional?

On 2/1/2016 7:35 PM, Martin Thomson wrote: On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic wrote: Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit Windows. If I’m reading the data correctly, more than half. A small percentage of those

Re: Does SSE2 usage still need to be conditional?

On 1/29/2016 2:05 PM, Cameron Kaiser wrote: On 1/29/16 9:43 AM, Ashley Gullen wrote: FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under "other settings"): http://store.steampowered.com/hwsurvey For that to be valid, one must assume that the population of Firefox users

Re: Just Autoland It

On 1/26/2016 10:26 AM, Boris Zbarsky wrote: On 1/26/16 7:38 AM, Axel Hecht wrote: Which is basically what I do whenever I want to do something. I have a clear idea and intention on what I want to show up on bugzilla, but not on what to do on reviewboard to get there. Which might just be a

Re: wptview [Re: e10s]

On 1/8/2016 6:02 PM, James Graham wrote: On 08/01/16 22:41, Robert O'Callahan wrote: On Sat, Jan 9, 2016 at 10:27 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: What are the implications of this? The web-platform tests are pass/fail, right? So is it a bug if they pass bu

Re: wptview [Re: e10s]

On 1/8/2016 3:16 PM, Kalpesh Krishna wrote: For web-platform-tests there is an additional issue; tests may be enabled but give a different result in e10s builds compared to non-e10s builds. Therefore compiling a list of disabled web-platform-tests in e10s is insufficient to spot all the

Re: about:profiles and the new profile manager

On 12/18/2015 5:09 PM, Stephen Horlander wrote: I am not sure I understand. Does "not intended to be product code" mean that this won't be riding the trains and shipping in a general release of Firefox? No. It means that, like the old profile manager, about:config, and other things like

Re: about:profiles and the new profile manager

On 12/18/2015 4:07 PM, shorlan...@mozilla.com wrote: Hi Andrea, This looks like a promising effort to improve profile management. I work on the on the Firefox UX team and I do have some concerns about the current design. Can you tell us some more about next phases of this work before it

Re: Using the Taskcluster index to find builds

Where is the right place to ask questions about this and file bugs? mozilla.dev.builds? I have a series of use-cases that I need to solve, and it's still very unclear to me whether taskcluster is the right solution for these, or how I'd solve them. Here are a few examples: In order to

Re: Finding out if the main thread is currently animating

On the main thread of which process? Please consider non-"animation" use-cases. In particular, users do notice the latency of typing into edit boxes as much as anything else. So let's make sure that editing latency triggers this as much as a current animation. --BDS On 10/29/2015 9:14 AM,

Re: Merging comm-central into mozilla-central

I support going back to a giant monolithic repository if we can cleanly delineate the code for various projects. We know that the searchability and readability of our code is a major barrier to some kinds of participation. We should continue to optimize ourselves around that workflow. Does

Re: [XULRunner 10] eclipse.exe crash caused by mozalloc.dll

On 10/14/2015 4:33 AM, Willy Michel wrote: Hi all, we are using XULRunner 10.0.4 for our "Eclipse RCP" application based on "Eclipse 3.8". Some of our customers report, that the application occasionally crashes with the error dialog that "eclipse.exe caused an error". After analyzing the

Re: mach mozregression command

Does this command work by downloading nightly/hourly builds (the way mozregression typically works) or by doing local builds at various changesets and getting a local source regression range? --BDS On 9/14/2015 12:43 PM, Julien Pagès wrote: Hey everyone, I'm pleased to announce that we just

Re: NPAPI plug-in use case: certified medical devices

On 8/28/2015 10:25 AM, Tony wrote: Our product makes use of a 3rd party medical device that requires a C library for usage. We created a NPAPI plugin that wraps this C library so we can access the device from JavaScript. Here's where the lawyers get involved... The medical device,

Re: recording use counters for web features

On 8/20/2015 12:56 PM, Nathan Froyd wrote: On Wed, Aug 19, 2015 at 7:11 PM, Benjamin Smedberg benja...@smedbergs.us mailto:benja...@smedbergs.us wrote: On 8/19/15 11:35 AM, Nathan Froyd wrote: These statistics are reported through Telemetry. Have the in-tree docs been

Re: recording use counters for web features

On 8/19/15 11:35 AM, Nathan Froyd wrote: These statistics are reported through Telemetry. Have the in-tree docs been updated to document this? I don't recall being asked to review the final data collection proposal for this mechanism. In particular: * Will this only collect to the opt-in

XULRunner future and ownership

The Mozilla project no longer sees XULRunner as a priority project. It's not core to advancing the open web or any of our current or planned products. As Ben Hearsum noted a couple weeks ago, we are turning off automated XULRunner builds and so XULRunner will probably quickly cease to work.

  1   2   3   >