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 don
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-02-06&keys=__none__!__none__!__none__&max_channel_version=aurora%252F53&measure=CONTENT_PROCESS_LAUNCH_TIME_MS&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-01-26&table=0&tri
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 provide the answers I c
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 t
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 is not the plan, no
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, yes
On Tue, Feb 7, 2017 at 5:19 PM, Chris Peterson
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 http: or https:. The purpose of
>&
our system. 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 wrote:
> On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote
On Fri, Feb 10, 2017 at 12:36 AM, 段垚 wrote:
>
> 在 2017/2/10 1:28, Benjamin Smedberg 写道:
>
>> 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)
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 population
On Thu, Feb 16, 2017 at 4:47 PM, wrote:
> Question of the day:
> When breaking overlong expressions, should &&/|| go at the end or the
> beginning of the line?
>
> TL;DR: Coding style says 'end', I&others think we should change it to
> 'beginning' for better clarity, and consistency with other op
On Thu, Feb 16, 2017 at 2:57 PM, L. David Baron 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 any commit, but
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?
>
>
>
> 在 2017/2/15 2
This is awesome. Congratulations to the team for pushing this through.
--BDS
On Wed, Mar 1, 2017 at 3:47 PM David Lawrence wrote:
>Today, the BMO Team changed the default bug view to the new modal
> view that has been in development for a while. For those who would like
> to use the old for
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 the default bug view to
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.
>>
>
> We shouldn't
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 patterns
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:
> I have not been a
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 experim
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 k
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
>> wrong, though!
>>
>
> Exactly
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 wrote:
> Hi!
>
Is there a particular reason this is landing directly to nightly rather
than using a pref experiment? A pref experiment is going to provide much
more reliable comparative data. In general we're pushing everyone to use
controlled experiments for nightly instead of landing experimental work
directly.
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 builds (although th
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 just makes the
change risk
I'm working on a patch which adds a new assertion, and this code is failing
in automation in an intermittent way. The assertion is in C++ code but it's
being called by unknown JS code.
Is there a way to have automation call DumpJSStack() on assertion (before
crashing), or are there other debugging
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
developer
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
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 const
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
wrote:
> On 07/17/2017 05:18 PM, Benjamin Smedberg wrote:> Unlike MOZ_CRASH,
&
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
___
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 (pre
On 8/20/2015 12:56 PM, Nathan Froyd wrote:
On Wed, Aug 19, 2015 at 7:11 PM, Benjamin Smedberg
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 updated to documen
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, **includ
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
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 cor
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 t
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, D
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 correlat
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 wo
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 tha
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 differe
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
wrote:
What are the implications of this?
The web-platform tests are pass/fail, right? So is it a bug if they
pass
but have different behaviors in
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
cate
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 and
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 don’t have SSE2.
Do we have
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 indicat
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 ma
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;
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 thre
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
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 impa
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
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
t; On Wed, Apr 6, 2016 at 2:18 PM, Benjamin Smedberg
> 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 | ". Now the signature will be &qu
On Thu, Apr 7, 2016 at 2:50 AM, L. David Baron wrote:
>
>
> I don't think the idea that a bug belongs in the triage queue if it
> is untriaged and without a needinfo? is the right process. I think,
> instead, that there should be less emphasis on needinfo? to a
> specific person, and more emphas
In today's nightly I landed a patch in bug 1252152 which will crash a
plugin-container process more aggressively if a plugin instance is torn
down while its code is on the stack. Please keep an eye out for new plugin
crashes that you're seeing. In crash-stats, this should show up with an
abort mess
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 tu
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
exp
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:
https://groups.google.com/forum/#!searchin/mozilla.governance/froyd/mozilla.govern
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
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
> wrote:
>
>> There used to be a bugzilla.mozilla.org product called "Plugins". This
>>
Starting today, there is a change to crash signatures for a subset of e10s
crashes. If the parent Firefox process detects that the child process has
sent broken or unprocessable IPDL data, or is not shutting down in a timely
manner, it kills the child process with a crash report. These crashes will
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 ver
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
suppor
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 wrote:
> >> On 5/3/16 12:21 PM, Gregory Szorc
en Hearsum 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 Smedber
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
fo
SSE2 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 wrote:
> On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg
> wrote:
>
>> I agree that we should drop support for non-SSE2. It mattered 7 yea
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 intend to make sure t
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 specifically included.
IIRC
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 Firefox for Linux?
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 better
> off overall wi
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
c
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
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
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_a_minidump
rs 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 Friday, March 11,
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:
>
>> [CC mobile-firefox-dev an
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
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 nsCocoaFeatures::On[Mountain]LionOrLater() calls in
> Firefox
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 con
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,
which
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
sandbox
\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
> toolkit/components/console/ and the component in b
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 w
or 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 th
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,
ose. 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
> wrote:
>
>> I'm going to resurrect this old thread to ask: is anybody currently
>> triaging bugs the Core:
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
reduc
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 a
orward to the future with other flags as first-class citizens.
--BDS
On Wed, Jul 13, 2016 at 7:20 PM, Gerald Squelart 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
>
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 no
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, ther
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 for Firefox.
I thin
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
> facilities that Windows
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 this
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 wrote:
> Do
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 module for firefox in c/c
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 account. It has
> o
1 - 100 of 371 matches
Mail list logo