New Firefox data steward

[Benjamin Smedberg]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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:> Unlike MOZ_CRASH,
> which only annotates crashes with compile-time constants
> > which are inherently not risky, both MOZ_CRASH_UNSAFE_OOL and
> > MOZ_CRASH_UNSAFE_PRINTF can annotate crashes with arbitrary data. Crash
> > reasons are publicly visible in crash reports, and in general it is not
> > appropriate to send any kind of user data as part of the crash reason.
>
> I suppose the same happens with rust panics, should those also be reviewed?
>
>  -- Emilio
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 constants
which are inherently not risky, both MOZ_CRASH_UNSAFE_OOL and
MOZ_CRASH_UNSAFE_PRINTF can annotate crashes with arbitrary data. Crash
reasons are publicly visible in crash reports, and in general it is not
appropriate to send any kind of user data as part of the crash reason.

If you are interested in collecting diagnostic data which is not
appropriate for public data collection, it is possible to use crash
annotations to store this information more securely.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 1380381, and is a recurrence of an older issue
from bug 1371017 and bug 1301751.

Currently these sorts of symbol errors don't fail the build and so we don't
notice them very quickly, but that is being tracked in bug 1304042 and I
hope we can land that soon to avoid a recurrence of this issue.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 confusion when doing data analysis, and make data steward
decision-making easier and faster.


Currently, there are separate options in Firefox preferences for enabling
data collection (“Enable Nightly Health Report”) and enabling extended
telemetry (“Share Additional Data (i.e., Telemetry)”). The first box is on
by default for all users, while the second box is on for prerelease users
but off for release users.



We are planning to remove the second checkbox. Here is a UI mockup of the
new option:
https://mozilla.invisionapp.com/share/5RA0R4HAE#/screens/233886993_Privacy_-_Security-ReorgV2



As part of this change, Firefox data stewards have worked with the Mozilla
legal team to document different “categories” of data collection. Please
see the page at
https://wiki.mozilla.org/Firefox/Data_Collection#Data_Collection_Categories
for a description of the data categories and the practices we use for each
category.



In histograms.json and scalars.yaml it will still be possible to define
whether a particular measurement should be collected from all users or only
from prerelease users. Users will no longer have a specific option to turn
this “extended” data on or off, but development teams may decide with data
stewards to collect data only from prerelease channels because that’s all
they need, for testing purposes, to reduce cost, or to mitigate risk. But
there is no difference in kind between data we’re collecting from the
release channel and the prerelease channels. By removing the opt-in
checkbox, the new preferences and categories will allow us to streamline
our process and get more of the data we need from the release channel.



I believe we will ship this as part of Photon work either as part of
Firefox 56 or 57.


Please followup to fx-data-...@mozilla.org if you have any questions.
fx-data-dev is the public list where Firefox product engineering, data
engineering, and data science teams do announcements and discussion. If you
are collecting or using Firefox data, I encourage you to join the list at
https://mail.mozilla.org/listinfo/fx-data-dev


--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Benjamin Smedberg]

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 riskier and may require outreach or an addon validation step. So
it's a question of risk/reward tradeoff.

Given that old-style addons are going away for 57, if it's possible to
delay addon-breaking IDL changes by one release until 57 that's probably
the easiest way to deal with this. We're already causing the addon
community a lot of churn.


>
> (4) Does Thunderbird use it? This is no longer a hard constraint, but is
> something to consider.
>

In general our policy is that we should spend only minimal time worrying
about this. A courtesy note to tbird devs is nice.


> (Although, if DevTools are moved its their own repository, that repo will
> have to be
> checked as well?)
>

I've been trying to find out some technical details about the devtools
plan, but my initial understanding is that they are trying to target stable
web/webextensions/debugger API surfaces, and so they *shouldn't* be
affected by gecko internals changes. But I'd be a lot more comfortable if
that were in writing as part of the devtools plan.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 that might make the build itself take a little
> longer).


Does this change affect our shipped build?

Long ago -Os produced faster builds than -O2 because the memory effects of
larger code outweigh the better in lining. That might not be true any more,
but I'm interested in seeing data.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship throttling of tracking timeouts

[Benjamin Smedberg]

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!
>
> As of 2017-05-15 I intend to turn on throttling of background tracking
> timeouts by default. It has  been developed behind the
> dom.timeout.tracking_throttling_delay pref. Other relevant prefs are:
> dom.min_tracking_timeout_value,
> dom.min_tracking_background_timeout_value,
> privacy.trackingprotection.annotate_channels. The values and relation
> to background tracking timeout throttling of these prefs are:
>
> dom.timeout.tracking_throttling_delay pref: the pref that toggles the
> feature, but also the amount of time that we wait before starting to
> throttle background tracking timeouts after a document has finished
> loading. A negative value indicates that the feature is turned off.
>
> dom.min_tracking_background_timeout_value: the minimum delay allowed
> for a tracking timeout from a background window where more than
> dom.timeout.tracking_throttling_delay pref ms has passed.
>
> dom.min_tracking_timeout_value: the minimum delay allowed for a
> tracking timeout from a foreground window where more than
> dom.timeout.tracking_throttling_delay pref ms has passed.
>
> privacy.trackingprotection.annotate_channels: if annotation of
> channels based on the tracking protection list is turned on. Also
> toggles this feature, needs to be true for this feature to be active.
>
> The feature is turned on by setting the following default prefs:
>
> dom.min_tracking_timeout_value: 4
> dom.min_tracking_background_timeout_value: 1
> dom.timeout.tracking_throttling_delay: 3
>
> All values are in ms. This means that 30 seconds after a document has
> finished loading,  background tracking timeouts will run at most every
> 10 second.
>
> Note that dom.min_tracking_timeout_value is a pref for throttling
> tracking timeouts for foreground windows, but this is set to the same
> value as dom.min_timeout_value, which is our minimum timeout delay for
> regular foreground timeouts. That is, we do not currently treat
> throttle tracking timeouts differently from other foreground timeouts.
>
> The bug tracking turning on this feature is:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1355311
>
> This feature is similar, but not the same, as
> https://trac.webkit.org/changeset/215116/webkit, where DOM timers are
> throttled for all cross origin iframes.
>
> We would very much appreciate if we could get feedback on any issues
> found while you're using nightly!
>
> Cheers,
> Andreas
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to change editor newline behavior

[Benjamin Smedberg]

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.  We can hypothesize either way, but we certainly can't know
> easily without getting some data first.  But unfortunately it's not
> possible to collect data about what sites are doing in terms of DOM fix-ups
> like this.  We can, at least, collect data about whether they are
> overriding the newline behavior wholesale though.  Is there any reason why
> we should not at least first collect this data before changing the behavior
> here?
>

I agree that it doesn't seem likely that telemetry can answer this sort of
question. However, we could collect data! Pick N top editing tools and
actually test their behavior. We probably can't get full confidence, but we
can get a much better picture of the risk involved. If we break (or
significantly change behavior) on five sites out of 40, that's a strong
indicator that we're going to have problems.

As an example, have we already tested or is it in a plan to test:
google docs
basic and rich text editors on wikipedia
office 365
github editor
common rich text editor libraries, and common CRM software (I don't have a
list)
the top hosted email sites: gmail, yahoo, hotmail/outlook, aol, icloud,
yandex

Being able to assert, before landing this change, that it doesn't break any
of these sites, would really help in terms of making assertions about the
risk profile.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to change editor newline behavior

[Benjamin Smedberg]

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 kind of thing that would be worth rolling out carefully and
perhaps slowly. Will this behavior be behind a pref which is easy to flip,
test, and roll out?

--BDS

On Sun, Apr 2, 2017 at 8:52 AM, Aryeh Gregor  wrote:

> In our rich-text editor (used in Firefox for designMode and
> contenteditable), when the user hits Enter, we have historically always
> inserted a .  This does not match any other browsers, which use  or
>  as line separators.  In bug 1297414, I'm changing our behavior to use
>  as a line separator.  This matches Blink/WebKit.
>
> So if you have the text "foobar" and hit Enter in between the "foo" and the
> "bar", previously you would get "foobar", and soon you will get
> "foobar".  The defaultParagraphSeparator command can
> be used to change the separator to "p" instead (which matches Edge's
> default behavior last I checked).
>
> Pages or embedders that want to keep the old behavior can run the following
> command: document.execCommand("defaultParagraphSeparator", false, "br").
>
> This change is not likely to affect high-profile sites that use rich-text
> editing (webmail etc.), because due to browser incompatibility, these sites
> all override this behavior anyway.
>
> Our new behavior is as specified in the essentially unmaintained editing
> specification that I wrote several years ago, and tested by the
> web-platform-tests editing suite.  (Except that the "br" value to
> defaultParagraphSeparator is unspecified, and is a Mozilla-specific
> extension for backwards compatibility.)
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 experiment and report bugs?  Is that something we can do
asking them to explicitly turn this on via pref? Or are you worried about
this feature accidentally breaking existing web content and you want to get
bug reports from normal users?

Could we mitigate risk by disabling this feature in chrome code by default
until you're confident in its readiness to ship?

--BDS


On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa 
wrote:

> I just landed the initial implementation of Async Iteration proposal
> (async generator and for-await-of syntax), as non-release-only feature.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1331092
>
> The implementation is only for the testing purpose (for finding spec bug
> etc), and the semantic change in the spec is highly expected.  They're not
> yet ready for production usage, either in browser code or in testcases.
> Please wait for a while :)
>
> --
>
> arai
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 able to find an owner for the Firefox::New Tab Page
> bugzilla component (bug 1346908).  There are 35 tests in the tree and
> without anyone to assume responsibility for them when they are intermittent
> (bug 1338848), I plan to delete them all if I cannot get an owner by the
> end of the month including someone who will sign up to be the triage owner
> for the bugzilla component.
>
> Thanks for helping me find owners for tests!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 of people downgrading:
https://gist.github.com/bsmedberg/1af70857106bfe29128a0e8d0b656804 - this
analysis was reviewed by chutten

users that switched channels at all: 0.48%
users that reverted to an older version: 2.55%
users that reverted to an older version, staying on the release channel:
2.19%

Downgrades are more prevalent than I thought, and channel-switching is not
a primary factor in downgrades. So the ideas that we would mostly solve
this problem by giving channels separate profiles appears to be false.

I still believe that we should do our best to make some set of downgrades
seamless for the user (if perhaps with some reversion to prior data or
duplicating). And that showing people a banner warning is user-hostile in
the sense that if they downgraded it was probably for a reason and so they
aren't going "back". What I'd like is some clearer guidance about how much
we should support downgraders and how much engineering effort we should put
into making downgrade as painless as possible.

--BDS


On Wed, Mar 8, 2017 at 9:40 AM, Ehsan Akhgari 
wrote:

> On 2017-03-07 8:02 PM, Ben Kelly wrote:
> > On Tue, Mar 7, 2017 at 6:09 PM, Xidorn Quan  wrote:
> >
> >>> This major version change is downgrade-incompatible, so IndexedDB and
> >>> DOM cache won't work in an older version if their profile has been
> >>> upgraded.
> >>> IndexedDB is also used internally, so stuff that depends on it likely
> >>> won't work too.
> >>> There's bug 1246615 [2] where you can find a discussion related to this
> >>> issue.
> >>
> >> It would probably be a good idea to backup the old files when upgrading,
> >> so that old version can at least pick the backup file to use.
> >>
> >
> > Maintaining downgrade compatibility is a lot more complex than people
> think
>
> Yes.
>
> > and we have zero test support for it.
>
> This part isn't entirely true.
>
> The full picture is a bit more complex.  Some components have supported
> full downgrades with automated tests running on the infrastructure for
> years.  Examples are the cookie manager and the permission manager.
> Other components have intentionally decided that it's OK to not maintain
> backwards compatibility, for example, IndexedDB.  In other places,
> people (myself included) have just not been careful enough and have
> (either intentionally or unintentionally) landed code that isn't
> downgrade compatible.
>
> It's certainly true that in general there is no tests that would catch
> you if you land code that breaks a downgrade scenario, and over the
> years it has become quite clear that maintaining a downgrade-compatible
> browser is impractical.
>
> I agree with Ben, Jan and others that this situation is unsustainable,
> and we have to do something about it.  I also agree with Xidorn about
> how bad it is that we risk destroying data from the very subset of our
> user population who go out of their way to help us by testing changes on
> newer builds and risk losing their data when going back to an older build.
>
> To be perfectly honest, the situation in bug 1246615 is quite
> frustrating.  I no longer understand what we are waiting for in that
> bug.  It seems like that bug is being scope creeped into a larger plan
> (based on comment 29 there) and still unclear what that exactly means,
> and here we are now: while Firefox 55 rides the trains, we *will*
> destroy our community's browsing data as they help us test Firefox.
>
> Benjamin, can we please address this with the urgency it deserves?
> Thank you for your attention.
>
> Cheers,
> Ehsan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 be removing APIs that have no alternative.
>

As a blanket statement, I don't understand what this means.

I am thinking the exact opposite sentiment: after Firefox 57 when
Webextensions are the only extensions, if our product no longer needs some
functionality (and it's "API"), let's remove it. Quickly and ruthlessly. We
need to actively work to maintain less code.

Do we disagree, or do I misunderstand?

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 the new modal
> view that has been in development for a while. For those who would like
> to use the old form, instructions on how to switch back are below in the
> background information. The old form will, however, be removed one day,
> so please try to use the new one and make suggestions on how it can be
> improved.
>
> As some of you may already know, and maybe even have been using it
> for a while, the BMO [1] team has been working on a new bug view page
> (a.k.a. show_bug.cgi) for some time [2] . The older, stock bug form was
> not well laid out and was difficult to understand, with all of the
> fields visible regardless of how often they were used. The stock form
> was originally designed to  display all of a bug’s data, and users had
> to adapt their workflows accordingly. The BMO team designed a completely
> new and more efficient view for the workflows of the majority of BMO users.
>
> The new bug-editing form has been added to BMO alongside the stock
> form and can be enabled by toggling a user preference [3]. We have been
> incrementally improving it and collecting feedback by those brave enough
> to use it early on. The new form is using more modern design practices
> and therefore is easier for us to improve and expand on. Any new
> enhancements will be done only on the new form going forward. It was
> code named ‘Bug Modal’ due to the modular layout of the page. Each
> submodule can be collapsed out of view and expanded when needed.
>
> At this time we feel that the form is feature complete and has now
> become the new default bug form for BMO. We have finished all the
> blockers in our tracking bug report [4]. The older, stock bug view form
> will still be around, and you can use the user preferences form to
> switch back to the old one [3]. In the future, we will be removing the
> old form completely after fixing a few more bugs [6], and we will make
> another announcement before doing so. Removing the old code will make it
> easier on us from a maintenance standpoint. Any bugs, comments, or ideas
> for improvement of the modal form can be reported in BMO [5].
>
> Thanks!
> BMO Team
>
> [1] https://bugzilla.mozilla.org
> [2] https://globau.wordpress.com/2015/03/31/bmo-new-look
> [3]
> https://bugzilla.mozilla.org/userprefs.cgi?tab=settings#ui_experiments_row
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1150541
> [5]
> https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org;
> component=User%20Interface:%20Modal=__default__
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1273046
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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:54, Till Schneidereit 写道:
>
>> On Tue, Feb 14, 2017 at 12:00 PM, 段垚  wrote:
>>
>>
>>> 在 2017/2/14 18:10, Till Schneidereit 写道:
>>>
>>> On Tue, Feb 14, 2017 at 12:14 AM, 段垚  wrote:

 I guess all popular softwares have exploits being traded. How this fact

> invalidates my argument?
>>
>>> I was responding to your point about the threat declining because of
>>>
>> the
>> declining usage of Flash.  This is demonstrably not true.
>>
>> Why? Assume
>>
>   threat_of_flash = exploits_of_flash_per_year *
> usage_of_flash_per_year
>
> If usage_of_flash_per_year is declining but threat_of_flash is
> increasing,
> then exploits_of_flash_per_year must be increasing.
> But the report you cited does not provide such data.
>
> That assumption doesn't hold: malicious uses of Flash don't need
>
 non-malicious ones.

 I agree. So let me ask this question instead: is there any proof that
>>> local-only Flash
>>> exploits are increasing?
>>>
>>> I don't know. I do know that legitimate usage of Flash, be it via file:
>> or
>> otherwise, is steadily declining. That's all that's needed to change the
>> cost/benefit balance here.
>>
>>
>> In fact it seems quite likely that there'll be an inverse relationship:
 less (non-malicious) usage means less testing of potentially exploitable
 code paths, which would increase the threat.

 I would assume Adobe will actively test Flash plugin with local contents
>>> for a reasonablely long time. Do you mean tests in Firefox for local
>>> Flash
>>> contents
>>> will inevitably decrease even if you don't disable it?
>>>
>>> What I'm saying is that testing and hardening against attacks isn't free,
>> so requires investing resources. This entire thread is based on the
>> conclusion that Flash usage has diminished to a point where it's can no
>> longer a good investment of resources to keep doing these activities for
>> this fairly niche-usage of Flash.
>>
>>
>> One solution to this is to decouple the amount of testing done for those
 code paths from how frequently they're used. In practice that's not
 trivial
 because at least some testing comes in the form of investigating crash
 reports from users. Another solution is what's proposed here: disable
 less-well tested configurations altogether.

 Also I think forbidding non-http(s) Flash does not fix thoses exploits
>
>> magically.
>>>
>>> Sure, this is about reducing attack surface, not completely
>>> eliminating
>>>
>> it.
>>
>> Non-http(s) Flash takes only a small fraction of all Flash contents,
>>
> even
> for users who do use non-http(s) Flash.
> I don't think users want to drop their local Flash for a small fraction
> of
> reduced attack surface,
> especially if those local Flash don't have alternatives yet. The more
> practical reaction is trying another browser.
>
> The underlying assumption here is that these usages of Flash are rare
 enough that the incompatibility, while unfortunate, becomes acceptable.
 Note that other browser vendors are planning their own measures for
 restricting Flash usage, too.

 Although usage of local Flash is rare, I'd point out that local Flash
>>> contents usually have higher
>>> value than those on web sites, Because users only save important contents
>>> to disks.
>>> Additionally, local Flash contents are much harder to replace than those
>>> on web sites
>>> because users can hardly contact the author. Please consider more for
>>> users.
>>>
>>> We are doing precisely that, but we believe that our users are better
>> served by us investing resources in tasks that have more impact. Again,
>> the
>> underlying assumption in this entire thread is that our users won't be
>> affected as strongly as you assume, or few enough will.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 any commit, but
> > especially for web compat.
>
> I don't think this is a realistic argument.  Basically any change we
> make to Gecko, including implementing new features, can affect Web
> compat.  We have to use judgment about which ones require measuring.
>

I agree that not everything requires measurement. I am saying that we need
a deliberate approach to risk, and that if we primarily relies on our
prerelease users to file bugs, we are not going to have any strong
guarantees of web compatibility.

Agree that this is not just for feature removals: new features may have
little risk if nobody on the web is using them. Or they may be very risky
if Chrome has deployed them and they already have traction, to the point
where web compatibility means implementing bug-for-bug compatibility with
Chrome and altering the specification.

So I want us to approach this from multiple approaches: what kinds of web
crawling automation could help mitigate webcompat risk?  What about
targeted fuzzing?


>
>
> > In this case, I understand the advantage of shipping CSS 'appearance'.
> I'm
> > less sure about what it would cost us to keep supporting -moz-appearance:
> > none, perhaps indefinitely.
>
> The cost is long-term or permanent differences between rendering
> engines, which leads to extra work for Web developers and to
> Web-compatibility problems for us.
>

And yet, that is sometimes (often?) a cost we should be prepared to bear.
The market costs of breaking almost any existing web content is so high
that we cannot afford to do it without knowing, and we should be prepared
to keep our quirks at the cost of extra engineering time and legacy support.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 to be an effective signal of web compatibility, for
the following reasons:

   - They are not distributed geographically; some geographies and
   languages are not well represented on beta, and nightly/aurora are even
   more skewed. So we could easily break a market-critical topsite in some
   geography and have little or no testing of that on beta.
   - We cannot rely on prerelease users to file bugs about issues they do
   encounter. Bugzilla is intimidating in general, and even more intimidating
   for people who don't speak English fluently. We have very little
   non-English documentation about filing a good bug. The signal that there is
   a bug might be people ceasing using Firefox, or a forum post in a
   language-specific board.
   - Even when people do file bugs, our bug handling and triage isn't fast
   enough to get these in front of the right person.

It has happened repeatedly over the past two years that we discovered
critical issues that affect websites only after we ship to release.

The two top market concerns in terms of Firefox quality are speed and web
compatibility. I'd encourage teams to measure carefully before taking known
web compatibility risk. It is not hard nowadays to add metrics (telemetry)
to measure web feature usage. Analyzing results is still harder than we
want, but it's self-service and we have training and data engineer partners
available to help you analyze data and make informed decisions.

We *know* that -moz-appearance: none has long been a webdev technique used
to unstyle various form controls [1][2][3][4]. We can also presume that
sometimes people sniff and hand us different markup than other browsers. So
we can't simply use data about what other engines have shipped to reason
about how changes to our own engine will affect site behavior and layout.

In this case, I understand the advantage of shipping CSS 'appearance'. I'm
less sure about what it would cost us to keep supporting -moz-appearance:
none, perhaps indefinitely.

--BDS

[1]
http://stackoverflow.com/questions/6787667/what-is-the-correct-moz-appearance-value-to-hide-dropdown-arrow-of-a-select
[2]
http://stackoverflow.com/questions/4457834/how-to-use-moz-appearance-to-display-a-menulist-button
[3] https://www.w3schools.com/cssref/css3_pr_appearance.asp
[4] https://gist.github.com/joaocunha/6273016



On Thu, Feb 16, 2017 at 10:23 AM, Mats Palmgren  wrote:

> On 02/11/2017 04:59 AM, Boris Zbarsky wrote:
>
>> The biggest worry for me is that inline style is never a "chrome sheet"
>> in this sense.
>>
>
> That's a valid concern, but I think ignoring -moz-appearance has fairly
> benign effects in most cases.  And as Jet pointed out to me, just landing
> it and see what breaks is standard procedure for unprefixing properties:
> https://bugzilla.mozilla.org/show_bug.cgi?id=775235
>
> Anyway, I took a quick look at some add-on usage in XUL files:
> https://dxr.mozilla.org/addons/search?q=moz-appearance+file%3A*.xul
>
> Most uses appears to be "-moz-appearance:none" which is reasonably safe
> to ignore, and can be easily amended with a "appearance:none" if needed.
>
> For other values, I installed the first four add-ons that use
> non-none values and analyzed what effect ignoring -moz-appearance
> would have.
>
> "dnsqueries":
> https://dxr.mozilla.org/addons/source/addons/11806/chrome/
> content/dnsqueries.xul#42
> The "-moz-appearance:textfield" has the effect of creating an extra
> border+padding around the input field.  This causes the control to
> have extra height making the whole toolbar have more height than
> needed.  Ignoring this -moz-appearance makes those "problems" go
> away and the toolbar and text control actually looks better (IMO).
> Also, the text control still works with no loss in function.
>
> "RDS Bar":
> https://dxr.mozilla.org/addons/source/addons/14581/chrome/
> content/dialogs/preferences/parameters/weather/window.xul#20
> https://dxr.mozilla.org/addons/source/addons/14581/chrome/
> content/rdstb.xul#3492,3525
> It appears this "weather" button is dead code, I couldn't find a way
> to enable it.
>
> "Print Edit":
> https://dxr.mozilla.org/addons/source/addons/193270/chrome/
> content/printedit-options.xul#123
>  has the effect of adding
> a chevron to the button.  Ignoring it makes it look like a standard
> color picker button (which is an improvement, IMO).
> There is no loss in function.
>
> "Smart Text"
> https://dxr.mozilla.org/addons/source/addons/161982/content/options.xul#16
> The "-moz-appearance:textfield" has the effect of creating an extra
> border+padding around the input field.  However, in this case it appears
> that the  (XHTML) element does count as a 

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

[Benjamin Smedberg]

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 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.
>>
>> Well, this plan seems too aggressive. I'd rather recommend implementing
> "click to play" for non-http(s) Flash first and deferring complete removal.
>
> IE requires user's confirmation to load local Flash for a long time.
>

We are planning on making Flash click-to-play by default for all content.
However, our implementation of click-to-play is based on remembering that
setting per site. This implementation does not work with file: URIs and the
engineering and QA effort to make it work is well beyond what we think is a
reasonable investment. Flash is a dying technology and this is one low-cost
way we can reduce attack surface and make users safer.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to download
a SWF they can probably own your 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 <m...@upsuper.org> wrote:

> On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:
> > 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 (and that is the
> > fundamental change we need to make). If you were to serve them via
> > localhost you could still use them (e.g. with python -m
> > SimpleHTTPServer).
>
> I kind of disagree with this. SimpleHTTPServer is simple for developers
> but not at all for normal users. I think it should be allowed to load a
> top level Flash file. What harm could it do if we allow that?
>
> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 http: or https:.  The purpose of
>> this change is to increase security and limit Flash to well-tested
>> configuraitons.
>>
>
> Do you want to also block Flash content from loading file: or ftp: URLs?
>

That is not part of this bug. I will consult with Adobe and see whether
that is likely to break anything, and perhaps propose it as a separate
change.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 (and that is the
fundamental change we need to make). If you were to serve them via
localhost you could still use them (e.g. with python -m SimpleHTTPServer).

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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) contents?
>

This is completely disabling this content.


>
> Can users get back old behavior by flipping a preference?
>

That is not the plan, no.


>
> We have developed a Firefox based tool to edit/view local EPub files,
> which may contain Flash.
>
> If this feature can't be opt-out , we and our customs will be in trouble.
>

My mind is filled with questions about how epub+Flash could ever be a good
idea, but I will avoid asking them here. Instead, could you work around
this by serving the content and loading it from http://localhost ? That is
what we intend to recommend for developers building Flash websites and
wanting to test locally.

Otherwise, you will have to build your own builds with this restriction
removed.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 there have
   been problems in the past with Flash content bypassing normal controls.
   - Flash is normally not tested with ftp: or other protocols, and we've
   had security issues in the past as a result of interactions between Flash
   and these sites.

I am not yet sure whether we will be able to prevent Flash from loading in
data: contexts or not. I'd like to, but it may not be possible without
breaking existing content.
This work is being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1335475

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Content process launch time distribution

[Benjamin Smedberg]

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 can right now.


>
> 1) How often is a content process started during a user's session? This
> would define if we should track the long tail or median (probably both).
>

With single-process e10s, this is once at app startup, plus once every time
a content process crashes.

With e10s-multi, there are additional launches that may happen at other
times.

With a bug I just patched, we'll also launch new content processes whenever
we detect that one of them is near-OOM.

With a custom query it's possible to count these as per-usage-hour or per
some other denominator.


>
> 2) Probably related to Gabor's question: How does this metric fit into the
> breakdown of timings from interaction to tab loading? Is it the major part
> or are there other metrics we need to consider?
>

I don't know exactly how to answer this: it's clearly part of the critical
path from the time a user launches Firefox to having usable web content,
but I don't think it blocks the start page if the user is using the default
start page instead of restore-tabs or a custom start page.


>
> 3) Do we know the circumstances that cause the long tail?
>

I suspect not.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Content process launch time distribution

[Benjamin Smedberg]

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 launch a content process from the
time we initially ask for it to the time we get back the first
initialization message through IPDL. So this covers actual process launch
in the OS, XPCOM startup, and other bootstrap.

At first glance, this appears worrying to me: almost 25% of content process
startups take more than 1 second, and the median is >700ms. And this is on
nightly/aurora, which users typically have faster computers.

There's a lot of potential noise here: we don't know what else is going on
on the computer (maybe it's near boot and there's still a lot of system
churn). But this time definitely can have an impact on how quickly Firefox
is ready to load pages and therefore the impression that users have of its
total speed.

Soliciting everyone's opinion, but Harald's in particular: is it important
to dive into this in more detail soon (before Firefox 57)?

This metric is currently exploratory, and so I need guidance about whether
it's important to keep this metric around for e.g. a release-health
dashboard or to prevent regressions.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Aarch64 as higher than tier-3?

[Benjamin Smedberg]

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't have any context at
all: are aarch64 phones shipping or expected to ship?

--BDS

On Mon, Jan 23, 2017 at 1:00 PM, Henri Sivonen  wrote:

> Are there any plans to support Aarch64 as a tier higher than tier-3?
> For Android or the upcoming Aarch64 flavor of Windows 10 maybe?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

As of this morning the important guts of this work have landed to
mozilla-central and should ride the Firefox 53 trains. Here are the
technical details, for those interested:


   - The only XPCOM function intentionally exported from libxul is
   XRE_GetBootstrap. This function may be called once to get a class that
   allows firefox, xpcshell, plugin-container, etc to start.
   - The remaining guts of gecko are no longer exported: mozilla::Services,
   NS_InitXPCOM, NS_GetComponentManager and all the rest are internal-only.
   - There are a few helper functions for OS.File which are exported, which
   is not a problem in terms of blocking 3rd-party code.
   - The dependent XPCOM glue static library (xpcomglue_s) no longer exists.
   - The standalone XPCOM glue library (xpcomglue) still exists, with the
   sole purpose of loading libxul and calling XRE_GetBootstrap.

I want to publicly thank Mike Hommey, Eric Rahm, and Nathan Froyd for
helping with a bunch of tedious conversion/refactoring work to get this
reviewed and landed!

I intend to file a bug for us to stop shipping and building the Mozilla SDK.

Mike and I are both working on some cleanup work after this: rearranging
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
> 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, there is
> 3rd-party software that continues to use binary XPCOM: either by loading
> DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox
> process.
>
> Binary injection has been the cause of numerous crash issues in Firefox,
> which commonly show up as startup crashes when a Firefox update is first
> run. I believe that solving these crashes is a critical part of our Firefox
> quality story and our ability to release Firefox updates in a timely manner.
>
> To that end, I believe that we should make it technically impossible for
> external DLLs to use XPCOM. I propose to do this in the following way:
>
> Integrate the remaining Firefox binary component back into xul.dll using
> internal linkage.
>
> Remove the XPCOM glue. This will involve reworking a little bit of how
> firefox.exe and plugin-container.exe initially load and launch gecko from
> xul.dll.
>
> Remove most of the XPCOM-related xul.dll exports, and as many other
> exports as possible.
> This includes all of the mozilla::services exports, as well as things like
> NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the XRE_
> functions like XRE_AddManifestLocation.
>
> Undecided: whether we can or need to remove the "frozen XPCOM string API"
> exports. I'd like to, but it's not strictly necessary to solve the primary
> stability issues of external code using binary XPCOM, and I'm not sure what
> it would affect or how hard it will be.
>
> I have prepared a list of current xul.dll exports from a recent nightly
> build, and proposed mitigations with bug numbers: https://docs.google.com/
> spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp=
> sharing
>
> It is likely that this project will affect Thunderbird and/or SeaMonkey,
> but I'm not sure in what ways. My understanding is that Thunderbird
> currently builds with internal linkage. I plan to keep Thunderbird informed
> of the work here, and accepting patches that help Thunderbird stay
> building, but I do not intend to significantly delay or WONTFIX this
> Firefox work for Thunderbird.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1299187 is the tracking bug.
>
> Please direct followup comments & questions to dev-platform.
>
> --BDS
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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
read and understand the following bits:

http://searchfox.org/mozilla-central/source/browser/modules/PluginContent.jsm
- frame script (runs in content process)
http://searchfox.org/mozilla-central/source/browser/base/content/browser-plugins.js
- UI script (runs in chrome process)
Binding files that set up the click-to-play overlay UI:
http://searchfox.org/mozilla-central/source/toolkit/pluginproblem/content

Be aware that we're actively removing plugin support from the Mozilla
platform; soon only Flash is likely to work, and after a while NPAPI might
be removed completely. So don't get too wedded to plugin support in
XULRunner as a long-term strategy.

--BDS


On Wed, Jan 11, 2017 at 10:01 PM, 段垚  wrote:

> Hi,
>
> In Firefox, "click to play" can be enabled by setting pref
> "plugin.state.flash" to 1.
>
> However, when I do this in a XULRunner app, flash plugin is disabled
> completely.
>
> Is this feature unavailable to XULRunner? If so, how can I implement it?
>
>
> Thanks.
>
>
> Duan Yao.
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Grid

[Benjamin Smedberg]

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.
> https://drafts.csswg.org/css-grid/
> This also includes all parts of the CSS Box Alignment spec that are
> relevant to Grid layout:
> https://drafts.csswg.org/css-align-3/
>
> It has been developed behind the "layout.css.grid.enabled" preference,
> and has been enabled by default in Nightly and Aurora for some time now.
>
> Other UAs shipping this or intending to ship it are:
> Chrome - intends to ship:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink
> -dev/hBx1ffTS9CQ
> Safari - is implementing it (independently):
> https://bugs.webkit.org/show_bug.cgi?id=60731
> Edge - status unknown to me
>
> Note about the 'subgrid' feature:
> We will *not* support the subgrid feature of CSS Grid in this first
> release.  This feature is marked as "at-risk" in the spec and thus
> not needed for spec compliance.  (Chrome is likewise not going to
> support subgrid in their first release.)
>
> This feature was previously discussed in this "intent to implement" thread:
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/
> jSmfRivZOrU/ZMPcwySUEW4J
>
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1217086
>
> CSS Grid meta bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=css-grid
>
> The Devtools team is implementing specific tools for Grid:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1181227
> (some of which will ship in 52 I'm told)
>
>
> /Mats
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: OpenType Variation Fonts

[Benjamin Smedberg]

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.
>
> From the Microsoft announcement[1] of Font Variations technology:
>
> "...make use of a variety of font weights and styles to make your message
> stand out clearly. The problem has been that all those weights and
> styles—bold, semibold, regular, display, caption—are separate font files,
> which increases application size and slows down web page load times,
> especially on mobile phones. OpenType Font Variations provide all the
> weights and styles of a full font family in a single, compact file to
> improve applications size and web site responsiveness."
>
> Other companies and designers have also been posting about the technology,
> which is arousing a good deal of interest in the font and web design
> communities.[2,3,4]
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1302685
>
> Link to standard: https://drafts.csswg.org/css-fonts-4/, particularly
> https://drafts.csswg.org/css-fonts-4/#low-level-font-variati
> on-settings-control-the-font-variation-settings-property.
>
> Platform coverage: All platforms, although implementation may proceed at
> different speeds depending on native font back-ends involved.
>
> Estimated or target release: Not yet determined.
>
> Preference behind which this will be implemented:
> layout.css.font-variations.enabled
>
> DevTools bug: It's not yet clear to me whether specific DevTools work will
> be needed, beyond the support we'll automatically get for a new CSS
> property.
>
> Do other browser engines implement this?
> Blink: Google has discussed the intention to support variation fonts in
> Chrome (see [2]); I'm not sure if a formal "Intent to implement" mail is on
> file.
> Edge: The Microsoft announcement[1] indicates a clear intention to support
> this technology.
> WebKit: Experimental support is in WebKit nightly builds on OS X (see
> https://webkit.org/blog/7051/variable-fonts-on-the-web/).
>
> Tests: Not yet written.
>
> (Because of the already-existing support for font variations in the macOS
> font system, this will probably be the first platform backend to be
> implemented in Gecko. There's a try build linked from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1321031#c5 for anyone who
> cares to play around with it already.)
>
> JK
>
>
> [1] https://www.microsoft.com/en-us/Typography/FontVariationsAnn
> ouncement.aspx
> [2] https://opensource.googleblog.com/2016/09/introducing-openty
> pe-font-variations.html
> [3] https://medium.com/@tiro/https-medium-com-tiro-introducing-
> opentype-variable-fonts-12ba6cd2369
> [4] http://blog.typekit.com/2016/09/14/variable-fonts-a-new-kind
> -of-font-for-flexible-design/
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Volunteer maintainer wanted: mac x86

[Benjamin Smedberg]

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 build and test infrastructure will only be testing the x86-64
codepaths on mac. However, we are willing to keep the x86 build
configuration supported as a community-supported (tier 3) build
configuration, if there is somebody willing to step forward and volunteer
as the maintainer for the port. The maintainer's responsibility is to
periodically build the tree and make sure it continues to run.

Please contact me directly (not on the list) if you are interested in
volunteering. If I do not hear from a volunteer by 23-December, the Mozilla
project will consider the Mac-x86 build officially unmaintained.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Please do not add any new CppUnitTests/GeckoCppUnitTests

[Benjamin Smedberg]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Recovering a Bugzilla account

[Benjamin Smedberg]

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
> obsolete PGP crypt on it which bugzilla wisely uses for recovery emails.
> Due to the removal of Persona, I can no longer log in with that account.
>
> --
> ==
> ~Omega X
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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++. In case of an error in
> my module I want to show a simple error dialog.
>
> This is want I do, the code was tested and working:
>
> ```
> void ac_firefox_show_alert_dlg(const char* title, const char* text) {
> const NS_ConvertASCIItoUTF16 wTitle(title);
> const NS_ConvertASCIItoUTF16 wText(text);
>
> nsCOMPtr promptService = (do_GetService("@
> mozilla.org/embedcomp/prompt-service;1"));
>
> if (promptService != NULL) {
> promptService->Alert(NULL, wTitle.get(), wText.get());
> }
> }
> ```
>
> No I found out that the dialog wasn`t working in latest firefox 46.0.2
> version. The call to ```do_GetService("@mozilla.
> org/embedcomp/prompt-service;1")``` returns NULL.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some recent crash-stats improvements

[Benjamin Smedberg]

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:

> Does the "raw dump" tab support require special permissions?  I don't see
> any way to download the memory report from:
>
> https://crash-stats.mozilla.com/report/index/1a572047-
> ac64-4add-a82f-a31512161004#tab-rawdump
>
> On Sun, Oct 9, 2016 at 7:51 PM, Nicholas Nethercote <
> n.netherc...@gmail.com>
> wrote:
>
> > Greetings,
> >
> > crash-stats.mozilla.org has had some recent improvements that are
> > worth highlighting.
> >
> > - There is new documentation on how to search through crash reports:
> > https://developer.mozilla.org/en-US/docs/A_guide_to_
> > searching_crash_reports.
> > You might think you already know how to do this, but crash-stats'
> > functionality for *grouping* search results is powerful and easy to
> > overlook, so this page is worth reading to make sure you understand it
> > fully. This documentation is linked to from the Super Search page
> > within crash-stats.
> >
> > - Some crash reports contain memory reports. (The
> > "ContainsMemoryReport" field is set in that case.) It used to be
> > difficult to download this memory report, but thanks to Peter
> > Bengtsson it's now much easier -- when a memory report is present,
> > there's now a link to it from the "Raw Dump" tab of an individual
> > crash report. See
> > https://crash-stats.mozilla.com/report/index/1a572047-
> > ac64-4add-a82f-a31512161004#tab-rawdump
> > for an example.
> >
> > - Also, something that is not in crash-stats but is closely related:
> > Marco Castellucio's new crash tools at
> > https://mozilla.github.io/stab-crashes/. There are several tools, but
> > probably the most widely-applicable one is
> > https://mozilla.github.io/stab-crashes/correlations.html, which finds
> > correlations for a particular crash signature. It works much better
> > than the existing correlations tool within crash-stats. If you have a
> > crash for which the cause is not obvious, this tool can be enormously
> > helpful -- e.g. bug 1307029 is for a generic-looking crash signature
> > that turns out to be highly correlated with a particular extension.
> >
> > Nick
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

[Benjamin Smedberg]

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.

As data steward I'd like to be kept in the loop and do a data review of any
changes here.

--BDS

On Thu, Sep 22, 2016 at 9:28 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> On 09/22/2016 04:28 AM, Nicholas Nethercote wrote:
>
>> I want to highlight a nice case where converting a normal assertion
>> into a release assertion was a win. In bug 1159244 Michael Layzell did
>> this in nsTArray::ElementAt(), to implement a form of always-on array
>> bounds checking. See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
>> discussion of how this is finding real bugs in the wild. (As well as
>> identifying new bugs, it's also helping understand existing crash
>> reports, e.g. see bug 1291082 where the crash signature changed.)
>>
>
> Independently of the release/debug assertion, I want to raise something
> that I see in the patch above, and in a patch made to investigate some rare
> crashes in the JS engine.
>
> The patch from the bug above adds instrumentation to attach a dynamically
> computed reason string (snprintf).  In the JS engine Jan De Mooij did
> something similar by dumping content on the stack between 2 magic numbers,
> in order to include this information in crash reports.
>
> What I see is a recurring pattern where the classical MOZ_CRASH /
> MOZ_ASSERT might not be ergonomic enough.  I think we should add a way to
> annotate our crashes (even in debug builds) with some state, without going
> in the internals of MOZ_CRASHs or requiring privileged access to the
> mini-dump. Maybe something like:
>
>   MOZ_ASSERT(foo < 0x1000, MOZ_REASON("Unexpected value: %x", foo));
>
> which could be converted into a lambda doing the snprintf into a
> pre-reserved space.
>
> --
> Nicolas B. Pierron
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 provides for this task, and whether or not those
> DLLs get access to the symbols currently exported from xul.dll, they can
> still cause a lot of harm.  I'm trying to understand how removing the
> XPCOM functions they can link against dynamically will improve our
> situation.
>

I'm working on that larger problem also. With the shipping of native
messaging in webextensions, we may be able to make a policy that extensions
and other addon-type software should not load DLLs into the Firefox
process. I'm currently discussing the implications and implementation
strategies of that with the addons team. This would however primarily be a
policy and addon-signing question: we don't have a good way to actively
block these DLLs.

This proposal here is a technical step we can take which will immediately
make things better. I've investigated several of the addon-related startup
crashes that have caused us to delay or respin releases or block particular
DLLs or addons over the past six months. Almost all of those crashes were
related to the addon using XPCOM and being hit by some binary-incompatible
change along the way.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 think a) is the better option, and I'd like to try it: assuming I'm right
about thunderbird using internal linkage, I don't see any reason we need to
keep exporting these symbols at all.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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, there is
3rd-party software that continues to use binary XPCOM: either by loading
DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox
process.

Binary injection has been the cause of numerous crash issues in Firefox,
which commonly show up as startup crashes when a Firefox update is first
run. I believe that solving these crashes is a critical part of our Firefox
quality story and our ability to release Firefox updates in a timely manner.

To that end, I believe that we should make it technically impossible for
external DLLs to use XPCOM. I propose to do this in the following way:

Integrate the remaining Firefox binary component back into xul.dll using
internal linkage.

Remove the XPCOM glue. This will involve reworking a little bit of how
firefox.exe and plugin-container.exe initially load and launch gecko from
xul.dll.

Remove most of the XPCOM-related xul.dll exports, and as many other exports
as possible.
This includes all of the mozilla::services exports, as well as things like
NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the XRE_
functions like XRE_AddManifestLocation.

Undecided: whether we can or need to remove the "frozen XPCOM string API"
exports. I'd like to, but it's not strictly necessary to solve the primary
stability issues of external code using binary XPCOM, and I'm not sure what
it would affect or how hard it will be.

I have prepared a list of current xul.dll exports from a recent nightly
build, and proposed mitigations with bug numbers:
https://docs.google.com/spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp=sharing

It is likely that this project will affect Thunderbird and/or SeaMonkey,
but I'm not sure in what ways. My understanding is that Thunderbird
currently builds with internal linkage. I plan to keep Thunderbird informed
of the work here, and accepting patches that help Thunderbird stay
building, but I do not intend to significantly delay or WONTFIX this
Firefox work for Thunderbird.

https://bugzilla.mozilla.org/show_bug.cgi?id=1299187 is the tracking bug.

Please direct followup comments & questions to dev-platform.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New [must_use] property in XPIDL

[Benjamin Smedberg]

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 not visible in the parse tree for static checkers.

--BDS

On Tue, Aug 23, 2016 at 9:19 AM, Eric Rescorla  wrote:

> I'm indifferent to this particular case, but I think that rkent's point
> about static
> checking is a good one. Given that C++ has existing annotations that say:
>
> - This does not produce a useful return value (return void)
> - I am explicitly ignoring the return value (cast to void)
>
> And that we have (albeit imperfect) static checking tools that can detect
> non-use of
> return values, it seems like we would ultimately be better-off by using
> those tools
> to treat use of the return value by the default flagging a compiler error
> when that
> doesn't happen yet a third annotation rather than treating "use the return
> value
> somehow" as the default and flagging a compiler error when that doesn't
> happen.
> I appreciate that we have a lot of code that violates this rule now, so
> actually cleaning
> that up is a long process gradually converting the code base, but it has
> the advantage
> that once that's done then it just stays clean (just like any other -Werror
> conversion).
>
> -Ekr
>
>
> On Mon, Aug 22, 2016 at 5:03 PM, Bobby Holley 
> wrote:
>
> > On Mon, Aug 22, 2016 at 4:39 PM, R Kent James  wrote:
> >
> > > On 8/21/2016 9:14 PM, Nicholas Nethercote wrote:
> > > > I strongly encourage people to do likewise on
> > > > any IDL files with which they are familiar. Adding appropriate checks
> > > isn't
> > > > always easy
> > >
> > > Exactly, and I hope that you and others restrain your exuberance a
> > > little bit for this reason. A warning would be one thing, but a hard
> > > failure that forces developers to drop what they are doing and think
> > > hard about an appropriate check is just having you set YOUR priorities
> > > for people rather than letting people do what might be much more
> > > important work.
> > >
> > > There's lots of legacy code around that may or may not be worth the
> > > effort to think hard about such failures. This is really better suited
> > > for a static checker that can make a list of problems, which list can
> be
> > > managed appropriately for priority, rather than a hard error that
> forces
> > > us to drop everything.
> > >
> >
> > I don't quite follow the objection here.
> >
> > Anybody who adds such an annotation needs to get the tree green before
> they
> > land the annotation. Developers writing new code that ignores the
> nsresult
> > will get instant feedback (by way of try failure) that the developer of
> the
> > API thinks the nsresult needs to be checked. This doesn't seem like an
> > undue burden, and enforced-by-default assertions are critical to code
> > hygiene and quality.
> >
> > If your concern is the way this API change may break Thunderbird-only
> > consumers of shared XPCOM APIs, that's related to Thunderbird being a
> > non-Tier-1 platform, and pretty orthogonal to the specific change that
> Nick
> > made.
> >
> > bholley
> >
> >
> >
> > > :rkent
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Welcome new Data Stewardship Peers

[Benjamin Smedberg]

Yes, people have been using the review? flag and I've bee marking that in
mozreview. The only caution I'll make is that data stewards don't typically
review the *code* that is being submitted: they review the
data/documentation. So you'll need a code review as well.

I look forward to the future 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
> > 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
> > reduces the time needed for people to get review.
> >
> > As a reminder, all data collection from the Firefox products, including
> > changes to telemetry histograms, should be reviewed by a data steward
> peer
> > before landing. More information about Firefox data collection can be
> found
> > at https://wiki.mozilla.org/Firefox/Data_Collection
> >
> > Please bear with the new peers as they learn the routine: it may be a few
> > days or weeks until they are fully up to speed.
> >
> > --BDS
>
> Welcome to the new blood!
>
>
> While I've got you here, can we please discuss one small details of the
> review process?
>
> The wiki page reads "please request approval by setting the *feedback*
> flag for the data collection module owner or a peer".
> With mozreview becoming more prevalent (and easy to use) for reviews,
> could we please just use the *review* flag instead? (At least for now*)
> Of course the data collection reviewer should only look at the data
> collection side, another reviewer should be nominated to look at the code.
>
> * A little bird told me that eventually the feedback flag will become a
> first-class citizen in mozreview. ;-)
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Core: Tracking is no more!

[Benjamin Smedberg]

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 more appropriate component.

You are welcome to keep using tracking bugs, but you should put them in a
component related to the work being tracked.

I would also encourage everyone to assign tracking bugs to the person who
is actually tracking the work (program manager, engineering manager, or
engineering lead). Having a tracking bug that is unassigned can be
confusing, because it's not clear who is actually responsible for *doing*
the tracking and followup. And that's a good way to remember to close out
tracking bugs when we're done with them!

As a reminder, the blocking relationship to use is that all the relevant
component bugs block the tracking bug, so the tracking bug depends on its
component work. Then when the

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Welcome new Data Stewardship Peers

[Benjamin Smedberg]

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
reduces the time needed for people to get review.

As a reminder, all data collection from the Firefox products, including
changes to telemetry histograms, should be reviewed by a data steward peer
before landing. More information about Firefox data collection can be found
at https://wiki.mozilla.org/Firefox/Data_Collection

Please bear with the new peers as they learn the routine: it may be a few
days or weeks until they are fully up to speed.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

This is now done, as of https://bugzilla.mozilla.org/show_bug.cgi?id=1282866
the Qt code has been removed from mozilla-central.

--BDS

On Fri, Jun 24, 2016 at 11:57 AM, Douglas Turner <do...@mozilla.com> wrote:

> I am a peer.  Feel free to file a bug against me to remove this port. It
> 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 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 we
>> have
>> clear ownership not only of reviewing patches, but the supporting
>> activities such as bug triage and some kind of continuous automation.
>>
>> --BDS
>>
>> On Sun, Apr 17, 2016 at 11:12 AM, Raine Mäkeläinen <
>> raine.makelai...@gmail.com> wrote:
>>
>> > I think that in this context we are talking about mozilla/widget/qt/*
>> > components and yes we're using those in our Gecko build. We don't use
>> > QWidgets for Sailfish Browser. User interface of the Sailfish Browser is
>> > written with Qt QML.
>> >
>> > There is more info in the embedding wiki [1] and Dmitry's blog [2].
>> > Rendering pipeline has changed after Dmitry's blog post but otherwise
>> quite
>> > close to the current state.
>> >
>> > [1]
>> > https://wiki.mozilla.org/Embedding/IPCLiteAPI
>> >
>> > [2]
>> > http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html
>> >
>> > -Raine
>> >
>> > 2016-04-14 20:38 GMT+03:00 Henri Sivonen <hsivo...@hsivonen.fi>:
>> >
>> > > Added Raine Mäkeläinen, who has been committing to qtmozembed lately,
>> to
>> > > CC.
>> > >
>> > > On Thu, Apr 14, 2016 at 1:51 AM, Jim Blandy <jbla...@mozilla.com>
>> wrote:
>> > > > On Tue, Apr 12, 2016 at 4:27 AM, Henri Sivonen <
>> hsivo...@hsivonen.fi>
>> > > wrote:
>> > > >>
>> > > >> On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano <
>> > masay...@d-toybox.com
>> > > >
>> > > >> wrote:
>> > > >> > So, my question is, why do we still have Qt widget in
>> > mozilla-central?
>> > > >> > What
>> > > >> > the reason of keeping it in mozilla-central?
>> > > >>
>> > > >> My understanding is that
>> > > >> https://git.merproject.org/mer-core/qtmozembed/ still uses it. As
>> we
>> > > >> are figuring out how to be more embeddable (see
>> > > >> https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ),
>> > it's
>> > > >> probably a bad time to make life hard for an existing embedding
>> > > >> solution.
>> > > >
>> > > >
>> > > > This doesn't really answer the question. We can't have code in tree
>> > that
>> > > > isn't tested, and isn't used, and has nobody responsible for it.
>> > > >
>> > > > If someone is willing to fix it up and get it tested and included in
>> > the
>> > > > continuous integration process, then that's fine. But "someone might
>> > > want to
>> > > > use it in the future" can't possibly be a legit reason to keep
>> > > substantial
>> > > > bits of code in the tree.
>> > >
>> > > It looked to me like the code is being used *now*.
>> > >
>> > > Raine, does qtmozembed use the Qt widget code from mozilla-central?
>> > >
>> > > --
>> > > Henri Sivonen
>> > > hsivo...@hsivonen.fi
>> > > https://hsivonen.fi/
>> > >
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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, 2016 at 5:11 PM, Paul Theriault 
wrote:

>
> > On 6 Jul 2016, at 3:39 AM, Steve Fink  wrote:
> >
> > On 07/05/2016 01:33 AM, Julian Hector wrote:
> >> If you encounter a crash that may be due to seccomp, please file a bug
> in
> >> bugzilla and block Bug 1280415, we use it to track issues experienced on
> >> nightly.
> >
> > What would such a crash look like? Do they boil down to some system call
> returning EPERM?
> >
>
>
> FYI for others since the reply was off-list:
> ---
> It is a crash of the content process, and somewhere in the logs you should
> find an entry similar to this:
>
> "Sandbox: seccomp sandbox violation: pid 5154, syscall 355, args
> 2620711623 0 0 0 3012860244 3077481872.  Killing process."
>
> You could also check by setting: security.sandbox.content.level = 0 and
> see if the problem still exists.
> ---
> There is also a wiki page with more information from b2g that has some
> information.
> https://wiki.mozilla.org/Security/Sandbox/Seccomp#Use_in_Gecko
>
> We will update to make this Linux specific instead of b2g.
>
> Thanks,
> Paul
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 the following documents to match:

http://foo.com/...
https://foo.com/...
https://subd.foo.com
http://subd.baz.com

But http://www.bar.com would not match.

The existing domain and security checks in nsDocument::StartDocumentLoad
all operate on the nsIChannel, so I suppose that's the right starting point.

I couldn't find an existing API on nsContentUtils to do the check that I
care about. I'm sure that there is a way to do what I want using
nsIScriptSecurityManager, but I'm not sure whether that's the "right" thing
to do or whether this code already exists somewhere.

Reading the APIs, I imagine that I want to do something like this:

contentPrincipal = ssm.getChannelResultPrincipal(channel);
testPrincipal = ssm.createCodebasePrincipalFromOrigin(origin); // Is it ok
that this is scheme-less?
if (testPrincipal.subsumes(contentPrincipal)) -> FOUND A MATCH

Is this the right logic, or is there a simpler way to do this that doesn't
involve creating a bunch of principal objects on every document load? Is
running this logic on every document load a potential perf problem?

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

On Mon, Jun 27, 2016 at 2:26 PM, Cory Price <cpr...@mozilla.com> wrote:

>
> On Mon, Jun 27, 2016 at 11:05 AM, Justin Dolske <dol...@mozilla.com>
> wrote:
>
>> What's the policy for reviews and testing with this addon?
>>
>
> You can see the current process for deploying things in the Go Faster
> documentation (Wiki <https://wiki.mozilla.org/Firefox/Go_Faster>, Release
> Process
> <https://docs.google.com/document/d/1x27I7hAmWDWiqk3o3YC3fklhE3N59bdgHCQHF5p_lkU/edit#>
> ).
>
> I've also added this to our system add-on pipeline
> <https://trello.com/b/moJCpVCD/go-faster-system-add-on-pipeline> which we
> discuss in our weekly meetings (invited Mike/Justin).
>

This seems like an inadequate answer to the particular question: who in
particular is the module owner of this code, who is responsible for 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 we have
clear ownership not only of reviewing patches, but the supporting
activities such as bug triage and some kind of continuous automation.

--BDS

On Sun, Apr 17, 2016 at 11:12 AM, Raine Mäkeläinen <
raine.makelai...@gmail.com> wrote:

> I think that in this context we are talking about mozilla/widget/qt/*
> components and yes we're using those in our Gecko build. We don't use
> QWidgets for Sailfish Browser. User interface of the Sailfish Browser is
> written with Qt QML.
>
> There is more info in the embedding wiki [1] and Dmitry's blog [2].
> Rendering pipeline has changed after Dmitry's blog post but otherwise quite
> close to the current state.
>
> [1]
> https://wiki.mozilla.org/Embedding/IPCLiteAPI
>
> [2]
> http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html
>
> -Raine
>
> 2016-04-14 20:38 GMT+03:00 Henri Sivonen :
>
> > Added Raine Mäkeläinen, who has been committing to qtmozembed lately, to
> > CC.
> >
> > On Thu, Apr 14, 2016 at 1:51 AM, Jim Blandy  wrote:
> > > On Tue, Apr 12, 2016 at 4:27 AM, Henri Sivonen 
> > wrote:
> > >>
> > >> On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano <
> masay...@d-toybox.com
> > >
> > >> wrote:
> > >> > So, my question is, why do we still have Qt widget in
> mozilla-central?
> > >> > What
> > >> > the reason of keeping it in mozilla-central?
> > >>
> > >> My understanding is that
> > >> https://git.merproject.org/mer-core/qtmozembed/ still uses it. As we
> > >> are figuring out how to be more embeddable (see
> > >> https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ),
> it's
> > >> probably a bad time to make life hard for an existing embedding
> > >> solution.
> > >
> > >
> > > This doesn't really answer the question. We can't have code in tree
> that
> > > isn't tested, and isn't used, and has nobody responsible for it.
> > >
> > > If someone is willing to fix it up and get it tested and included in
> the
> > > continuous integration process, then that's fine. But "someone might
> > want to
> > > use it in the future" can't possibly be a legit reason to keep
> > substantial
> > > bits of code in the tree.
> >
> > It looked to me like the code is being used *now*.
> >
> > Raine, does qtmozembed use the Qt widget code from mozilla-central?
> >
> > --
> > Henri Sivonen
> > hsivo...@hsivonen.fi
> > https://hsivonen.fi/
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: Error Console

[Benjamin Smedberg]

\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 bugzilla (Toolkit: Error
> Console).  This will also remove the —jsconsole command line flag for
> consumers that don’t use devtools.
>
> The code isn't used at all in Firefox, as discussed in
> https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/XYPqQ58ndX4/discussion.
> It’s also now possible to migrate usages to the Browser Console i.e.
> Seamonkey is no longer using it as of bug 1223341.
>
> Brian
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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
sandboxed so that they could not run plugins.

I am going to ask social networking/sharing sites that are commonly
embedded to join this blocklist. I'll also contact commonly-embedded web
tools such as disqus. And finally I'll be working with large ad networks,
because that is where a lot of the infection risk comes from.

The implementation of this system will likely use the sandboxed-iframe
mechanism.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1277876

Target release: unsure; hopefully 50

Behavior of other browsers: we have no indication that other browsers are
ready to adopt this strategy yet.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Benjamin Smedberg]

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 is the allocation resolution of Windows VM.

If you look at the raw dump tab, you'll see:

"largest_free_vm_block": "0xf" - which is 983040 bytes, less than 1MB.

--BDS



On Tue, May 31, 2016 at 12:37 PM, Jonathan Kew  wrote:

> On May 31, 2016, at 2:22 , Nicholas Nethercote
  wrote:

>>>
> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string
 argument given. These are mostly OOMs, though there are a few
 others in there. These ones should be annotated so they show up
 separately.

>>>
> I took a quick look at a random one of these OOMs[1], and what strikes me
> about it is that according to the crash report:
>
> Total Virtual Memory2147352576
>
> Available Virtual Memory122331136
>
> System Memory Use Percentage52
>
> Available Page File 4932567040
>
> Available Physical Memory   1790652416
>
> OOM Allocation Size 24
>
> it seems like the system is still some way from running out of memory.
> Available Virtual Memory is "only" 122MB, which admittedly isn't very much
> in present-day terms, but stillwhy can't we successfully allocate a
> 24-byte block? Can those 122MB really be _so_ fragmented?!
>
> JK
>
> [1]
> https://crash-stats.mozilla.com/report/index/e59d2f18-2131-4f24-9f43-7038b2160524
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Benjamin Smedberg]

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 content and plugin process crashes - those aren't "startup"
crashes the same way, and they don't prevent users from updating or
disabling addons
* added facets on the crash reason and the abort message
* added the time-since-last-crash to the column list

The top things on this list are:

by signature:

__RtlUserThreadStart | _RtlUserThreadStart (maybe bug 1164826
 , need to dig to
separate by this DLL)
mozalloc_abort | NS_DebugBreak | ErrorLoadingBuiltinSheet (longstanding
problem, perhaps evidence of a bad update or install - bug 1194856
)
OOM | small - this is surprising and disturbing to me - I wonder how much
of this is actually OOM and how much is memory corruption. I filed bug
1276993 as a work item for this.
EMPTY: no crashing thread identified; ERROR_NO_MINIDUMP_HEADER - again
normally OOM but I wouldn't expect that at startup


--BDS


On Tue, May 31, 2016 at 11:52 AM, Milan Sreckovic 
wrote:

> By the way, this is the kiss of death query.  MOZ_CRASH, start up, in safe
> mode.  We’re basically forcing these people away.  There is nothing they
> can do even if they really want to run Firefox (assuming this is a
> persistent start up crash, of course.)  The numbers aren’t high, and
> majority of them are OOMs, but I still feel like this query should never
> have things in it.  (Randomly picked 8 seconds, I know that some consider
> it a start up crash if it crashes much later than that.)
>
>
> https://crash-stats.mozilla.com/search/?product=Firefox_crash_reason=%21__null__=%3C8_mode=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
>
> It’s also interesting to extend the query to specify the amount of memory
> the machine has - how do we get an OOM on startup when the users have 2GB
> of RAM?
> —
> - Milan
>
>
>
> >
> >> On May 31, 2016, at 2:22 , Nicholas Nethercote 
> wrote:
> >>
> >> Hi,
> >>
> >> Here is a crash-stats search that shows all the crash reports in the
> >> past 7 days that have a "MozCrashReason" field -- which means they
> >> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e.
> >> aggregated) by that field:
> >>
> >>
> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason
> >>
> >> I've included the output below. (Apologies if it gets munged when the
> >> email is processed; just click on the link above to see the live
> >> list.)
> >>
> >> #1 by a long way is shutdown hangs. No great surprise.
> >>
> >> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
> >> given. These are mostly OOMs, though there are a few others in there.
> >> These ones should be annotated so they show up separately.
> >>
> >> From #3 down we have smaller numbers, but many of them are still
> >> non-trivial, and a lot of them are probably indicative of problems
> >> that are very easy to fix if the right person sees them. Please take a
> >> look through the list to see if any of them are familiar to you.
> >>
> >> (If you're wondering why I made this search... I've found that many
> >> crash reports lack enough data to be actionable -- especially those
> >> involving crashes caused by bad memory accesses. So it's worth
> >> focusing to some degree on the crash reports that are more likely to
> >> be actionable, and places where we deliberately abort are an obvious
> >> case.)
> >>
> >> Nick
> >>
> >>
> >> 1  MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)
> >>129715  9.92 %
> >> 2  MOZ_CRASH() 25987   1.99 %
> >> 3  MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor)
> >> 21040.16 %
> >> 4  MOZ_CRASH(Unexpected error during FakeBlack creation.)  16790.13
> %
> >> 5  MOZ_CRASH(IPC FatalError in the parent process!)783 0.06
> %
> >> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> >> collector found more references to an object than its refcount)509
> >>0.04 %
> >> 7  MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 %
> >> 8  MOZ_CRASH(Bogus tree op)459 0.04 %
> >> 9  MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas &&
> >> sAliveDisplayItemDatas->Contains(aData))   263 0.02 %
> >> 10 MOZ_CRASH(Using observer service off the main thread!)  223 0.02
> %
> >> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping)
> >>222 0.02 %
> >> 12 

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

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 49 and just assume everywhere that MacOSX specific Gecko code is
> running on 10.9 or later?
>
>
>
> On Fri, May 27, 2016 at 4:59 PM, Ralph Giles  wrote:
>
> > On Thu, May 26, 2016 at 3:37 PM, L. David Baron 
> wrote:
> >
> > > There's a screenshot in:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
> > > (which is the bug that made the necessary changes for the Mac OS X
> > > support change in Firefox 49).
> >
> > Ah, that's great. Thanks!
> >
> >  -r
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Benjamin Smedberg]

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 that works, we should probably do the same
thing or something similar for the new MozCrashReason field. (I'm not sure
why we used different field names for these.)

--BDS

On Tue, May 31, 2016 at 9:18 AM, Gabriele Svelto 
wrote:

> On 31/05/2016 13:26, Gijs Kruitbosch wrote:
> > We could do a find/replace of no-arg calls to a new macro that uses
> > MOZ_CRASH with a boilerplate message, and make the argument non-optional
> > for new uses of MOZ_CRASH? That would avoid the problem for new
> > MOZ_CRASH() additions, which seems like it would be wise so the problem
> > doesn't get worse? Or is it not worth even that?
>
> What about adding file/line number information? This way one could
> always tell where it's coming from even if it doesn't have a descriptive
> string.
>
>  Gabriele
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 and dev-fxos for notes below.]
>>
>> Bug 1246743 (Mac libc++ support) and bug 1273934 (Android libc++
>> support for local development builds) have landed on mozilla-central.
>> This change means that all of our Tier-1 platforms now have a
>> more-or-less conformant C++11 standard library.  We can therefore
>> begin removing a decent amount of code that we required to support
>> pre-C++11 standard libraries and use standard facilities instead.  You
>> are still strongly encouraged to use Gecko-specific data structures
>> (nsTArray ns{C,}String, etc.) in preference to the standard library
>> ones, unless you need to interface with a third-party library.
>>
>> Given the standard library's pervasive use of exceptions, and our
>> aversion to the same, if you are using a standard library header
>> that's not listed here:
>>
>> http://dxr.mozilla.org/mozilla-central/source/config/stl-headers
>>
>> you need to ask for review to get that header added to the list, per
>> policy in that file.
>>
>> This change also means that any non-Tier-1 platforms (FxOS, for
>> instance) that don't provide a C++11 standard library will probably
>> break in very short order as various code is removed from the tree.
>>
>> Developers who work on the C++ side of Firefox for Android are
>> strongly encouraged to upgrade to an r11 NDK; the r10 NDK should work,
>> but test results in the presence of crashes might be slightly wonky.
>>
>> Enjoy!
>> -Nathan
>>
>>
> Do we have any automation that prevents using headers that aren't in the
> list?
>
> Cheers,
> Josh
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
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

[Benjamin Smedberg]

Existing users should not be upgraded.

The Mozilla website will use UA versions to redirect users on these
versions to a SUMO page.

If a user does end up downloading and attempting to the DMG, the minimum
version is set in the app bundle and MacOS will show a warning saying that
this application requires a minimum MacOS version of 10.9.

--BDS

On Thu, May 26, 2016 at 5:33 PM, Chris Pearce <cpea...@mozilla.com> wrote:

> What will the behaviour be for users on unsupported MacOSX versions?
>
> It sounds like existing users won't get updated to a non-supported version.
>
> 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 Friday, March 11, 2016 at 7:04:03 AM UTC+13, Benjamin Smedberg wrote:
> > 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 prioritize these bugs. Especially with the
> > deployment of e10s we're seeing intermittent and permanently failures on
> > MacOS 10.6 that we are not seeing elsewhere. We get very little testing
> > of old MacOS versions from our prerelease testers and cannot dedicate
> > much paid staff testing support to these platforms. We also have an
> > increasingly fragile set of old hardware that supports automated tests
> > on 10.6 and do not intend to replace this.
> >
> > This will affect approximately 1.2% of our current release population.
> > Here are the specific breakdowns by OS version:
> >
> > 10.6
> >   0.66%
> > 10.7
> >   0.38%
> > 10.8
> >   0.18%
> >
> > The final timeframe for this deprecation has not been finalized, but the
> > current proposal is to remove support in Firefox 46. We will try and
> > update existing users on old MacOS versions to the Firefox 45 ESR
> > release stream, so that they stay with security update support through
> > the end of 2016.
> >
> > Because of the ESR update window, I would like to finalize this decision
> > by Monday. If you have questions or concerns about this plan, please
> > reply to the firefox-dev mailing list immediately. Jeff Griffiths will
> > be working with our communications team to coordinate more public
> > communications such as post to the Future of Firefox blog.
> >
> > --BDS
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documentation on how to read crash reports

[Benjamin Smedberg]

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

--BDS


On Wed, May 25, 2016 at 2:06 AM, Nicholas Nethercote  wrote:

> Hi,
>
> Do we have documentation on how to read crash reports? The only thing
> I have found is this page:
>
> https://support.mozilla.org/en-US/kb/helping-crashes
>
> which is not bad, but is lacking some details. I suspect there is
> quite a bit of crash report interpretation wisdom that is in various
> people's head, but not written down anywhere...
>
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
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

[Benjamin Smedberg]

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 24, 2016 at 7:35 PM, Xidorn Quan  wrote:

> On Wed, May 25, 2016 at 2:19 AM, Lawrence Mandel 
> wrote:
>
> > On Tue, May 24, 2016 at 12:11 PM, Henrik Skupin 
> wrote:
> >
> > > Mike Hommey wrote on 05/11/2016 05:06 AM:
> > > >> The post states "Mozilla will end support for Firefox on OS X 10.6,
> > > 10.7,
> > > >> and 10.8 in August, 2016." This means that we will end support with
> > the
> > > >> Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.
> > > >
> > > > That's why the post should have given a version number instead of an
> > > > ambiguous date.
> > >
> > > Bug 1269790 only landed on mozilla-central. Shouldn't it then also be
> > > backported to mozilla-aurora so it will hit the 48.0 release?
> > >
> >
> > Given the confusion, we will drop support in 49.0.
>
>
> Can we now make 48.0 a half-ESR? Firefox 49.0 starts to drop 10.6~10.8 as
> well as machines which do not support SSE. Given we are still support them
> with 45ESR, I think it makes sense to extend the support cycle of 48 to the
> end of cycle of 45ESR.
>
> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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
case.

The standard dataset for looking at this is the "longitudinal" 1% sample at
sql.telemetry.mozilla.org (employee-only access, for privacy reasons).

--BDS

On Wed, May 25, 2016 at 2:04 AM, Eric Rahm  wrote:

> I've seen statements such as "0.04% Firefox users don't have SSE"*. What
> I'd like to know is if when we make these measurements we also ascertain
> whether or not those users are on the most recent release.
>
> There's often pushback, which I think is certainly reasonable, related to
> abandoning users or maintaining an ESR to support said users that we're
> abandoning. So my question is: How many of these users are actively
> updating? I think this would be useful in making decisions on what support
> to deprecate.
>
> -e
>
> *not a direct quote, probably not accurate
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 with MSVC-2015 on the 48 channel.. We’re going to orphan that
> population eventually anyhow but perhaps we want to live with the crashes
> while we prep the infrastructure to deal with it as nathan mentions in a
> different thread. I'm really torn.
>

At this point, I don't think we should change "back" to requiring SSE2 for
FF48. The update work would have to be uplifted to 47 which is already at
last-beta, and the install work has not landed.

I don't know whether there is a way to switch to MSVC2015 without requiring
SSE2. I know people were looking into compiler workarounds for a while: I
don't know what the status of that is.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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? Yes, I am
comfortable making that decision today.

Should we also take actions that prevent anyone from supporting non-SSE2
codepaths? I don't know. There seem to be at least a few cases that this
affects:

   - Rust and its support for non-SSE2 arches
  - This seems to be both about build-time targeting and runtime
  dynamic selection. I don't personally understand the
cost/benefit tradeoff
  here.
  - Our own JITs and their support for non-SSE2 paths
  - Our primary JIT doesn't support non-SSE2, right? So these users
  already fall back to the slow interpretation path?
   - Other platform code that does dynamic SSE2 detection. For example,
   image decoders which we compiler in both SSE2 and non-SSE2 configs
   currently, and select the codepath at runtime.
  - I imagine we'd like to remove this complexity from the tree,
  especially given that we won't have any testing for it.
  - Our relationships with 3rd-party code, in particular Flash,
   OpenH264, Widevine, and Primetime
  - Some of these already don't support non-SSE2 and may not ever.


> Now, with my Debian hat on, I can tell you with 100% certainty that
> angry Debian users *will* come with patches and will return even
> angrier if patches are not even welcome.
>

In the abstract, I'm willing to accept the cost of a minority of angry
users for an offsetting benefit; that benefit can either be perf
improvements or maintenance/development improvements in the Firefox
codebase. I just don't understand the costs yet.


> That said, Talos could tell something different, but I'm not convinced
> building with SSE2 would make a huge difference. Things where it does
> make huge differences are already using run-time selected SSE2 code.
> And even if it does make huge differences, I'm tempted to say "so what"?
> So, if people want to build the same way as currently, even if Mozilla
> and most distros end up defaulting to SSE2, why prevent them from doing
> so? Why specifically not welcome patches, instead of, say, making it
> tier-3, like e.g. sparc or mips?
>


One obvious cost is either continued testing of the runtime selection
codepaths, *or* releasing code which we haven't tested. And the mental
overhead of changing that code. Although I bet we aren't testing the
non-SSE2 codepaths even right now, given how hard it has been to find any
machine at Mozilla that didn't have SSE2.

If we're going to accidentally keep introducing bugs where non-SSE2 CPUs
crash, it would be far better to add a runtime check at the beginning of
main() and error out, than to have a steady trickle of bug reports about
crashes on illegal instructions which end up being marked INVALID.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Benjamin Smedberg]

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 the Mozilla builds of Firefox for Linux already require SSE2 by virtue
of their -i686 build targeting, so the real question here is whether we
want to support distros that don't require SSE2? I'm ok with that, but I
don't whether there are distros who want to disagree or how I'd communicate
this more effectively.

--BDS
___
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

[Benjamin Smedberg]

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 that Beta/Release/ESR is configured in such a way
>> that users get the most up to date release possible. Eg: serve 10.6-10.8
>> users the latest 48.0 point release, then give them a deprecation notice.
>>
>
> Presumably, the deprecation notice will mention ESR as a way to continue
> to get security updates for several more months?
>
>
> --
> Adam Roach
> Principal Platform Engineer
> Office of the CTO
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Benjamin Smedberg]

I am talking about requiring SSE2. That is a larger (but still quite small)
population, but the upside of being able to turn on SSE2 optimizations by
default is an important benefit. I've discussed and confirmed this with
Firefox product management.

So yes, the plan of record is to require 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 <g...@mozilla.com> wrote:

> On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg <benja...@smedbergs.us>
> wrote:
>
>> 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.
>>
>
> Wait - are we talking about requiring SSE or SSE2? The thread up to this
> point was talking about requiring just SSE, not SSE2. I just want to make
> sure we're on the same page since according to mhoye's post the non-SSE2
> population is ~25x larger than the non-SSE population...
>
>
>>
>> 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 versions of MacOS.
>> Gregory, will you own that? You will probably need to add CPU feature
>> detection to the update URL/params for 47, or use some kind of system addon
>> to shunt these users off the main update path.
>>
>
> Given that 47 is in Beta, is it too late/risky to make this change on that
> channel? Should we revert to VS2013 on Aurora/48 and make the updater
> modifications on that channel? I think this will have minimal negative
> impact, as most of the impact to changing toolchains would be on central,
> as that is where most developers and automation live.
>
>
>>
>> On Fri, May 6, 2016 at 10:10 AM, Mike Hoye <mh...@mozilla.com> wrote:
>>
>>> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>>>
>>>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>>>> instructions. This instruction is part of the original SSE instruction
>>>> set,
>>>> which was initially unveiled by Intel on the Pentium 3 in 1999 and
>>>> later by
>>>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>>>> need
>>>> Firefox to run on processors manufactured in the 90s.
>>>>
>>> Per an IRC conversation with chutten, Firefox users on CPUs that do not
>>> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
>>> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
>>> etc), this work provides continuity of support to 0.01% of our users.
>>>
>>> - mhoye
>>>
>>>
>>> 09:59  So, to put it clearly and precisely, of the Firefox
>>> Population in release and beta who are reporting at least base telemetry
>>> collection on machines running supported configurations, only 0.01% cannot
>>> definitively say they have SSE.
>>> 10:00  (according to a 1% random sample as stored in the
>>> longitudinal dataset)
>>>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>
___
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?

[Benjamin Smedberg]

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
for existing users.

This will be much easier now that we have widevine and are dropping
npapi/silverlight, but addon compat is also a concern and we wanted to
partly wait for webextensions before pushing more on this.

--BDS

On Thu, May 12, 2016 at 11:45 AM, Ted Mielczarek  wrote:

> Hello,
>
> Given all the discussion around SSE[2] lately, I was curious as to
> whether we had made any plans to update Windows users that are running
> 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows
> builds. The 64-bit Windows builds do use SSE2, since that's a baseline
> requirement for x86-64 processors, and the overall performance should
> generally be better (modulo memory usage, I'm not sure if we have an
> exact comparison). Additionally 64-bit builds are much less likely to
> encounter OOM crashes due to address space fragmentation since they have
> a very large address space compared to the maximum 4GB available to the
> 32-bit builds.
>
> It does seem like we'd need some minimal checking here, obviously first
> for whether the user is running 64-bit Windows, but also possibly
> whether they use 32-bit plugins (until such time as we unsupport NPAPI).
> 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have
> the equivalent of Universal binaries like we do on OS X).
>
> -Ted
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
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

[Benjamin Smedberg]

I didn't know we intended to drop support in 48. I just assumed 49 from
reading the blog post and knowing that things were just landing in nightly.
At this point, though, I don't want to do uplifts and would prefer that
this ride the 49 train.

--BDS

On Fri, May 13, 2016 at 3:24 PM, Ben Hearsum <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 Smedberg wrote:
>
>> 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
>> support will be Fx49.
>>
>> If anyone wants to follow along, the tracking bug for the various pieces
>> of
>> client, updater, website, and SUMO changes are being tracked in bug
>> 1255589.
>>
>> --BDS
>>
>> On Fri, May 13, 2016 at 2:15 PM, Nils Ohlmeier <nohlme...@mozilla.com>
>> wrote:
>>
>>
>>> On May 10, 2016, at 19:58, Lawrence Mandel <lman...@mozilla.com> wrote:
>>>>
>>>> The post states "Mozilla will end support for Firefox on OS X 10.6,
>>>> 10.7,
>>>> and 10.8 in August, 2016." This means that we will end support with the
>>>> Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.
>>>>
>>>
>>> Why do Firefox DevEdition users on Mac OS X 10.6 then still get updates
>>> to
>>> DevEd 48?
>>>
>>> I just tested it on a 10.6 machine and updates have stopped for Nightly.
>>> Which is good, because the Nightly 49 build which I manually downloaded
>>> crashes and brings up the Mac OS X crash reporter.
>>> But the DevEdition installed on the same system updated itself to 48. And
>>> 48 started and appeared to be still working.
>>>
>>> Best
>>>Nils Ohlmeier
>>>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>>
>>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
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

[Benjamin Smedberg]

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 wrote:
> >>
> >>> * The update server has been reconfigured to not serve Nightly updates
> to
> >>> 10.6-10.8 (bug 1269811)
> >>
> >> Are we going to be showing some kind of notice to affected users upon
> Release? That is, if I'm a 10.6 user and I update to Firefox 48, at some
> point should I see a message saying I'll no longer receive future updates?
> >
> > Even better, is there any way to get the update system to automatically
> move such users over to 45ESR?
>
> I agree. At least users should get updated to the latest version in their
> channel. If not automatically or getting pointed to manually switch to the
> latest secure release for their version/channel.
>
> Right now I started a Nightly 40 on 10.6.8 and it simply refused to do any
> update at all. That is less then ideal I would say.
>
> Best regards
>   Nils Ohlmeier
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
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

[Benjamin Smedberg]

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
support will be Fx49.

If anyone wants to follow along, the tracking bug for the various pieces of
client, updater, website, and SUMO changes are being tracked in bug 1255589.

--BDS

On Fri, May 13, 2016 at 2:15 PM, Nils Ohlmeier 
wrote:

>
> > On May 10, 2016, at 19:58, Lawrence Mandel  wrote:
> >
> > The post states "Mozilla will end support for Firefox on OS X 10.6, 10.7,
> > and 10.8 in August, 2016." This means that we will end support with the
> > Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.
>
> Why do Firefox DevEdition users on Mac OS X 10.6 then still get updates to
> DevEd 48?
>
> I just tested it on a 10.6 machine and updates have stopped for Nightly.
> Which is good, because the Nightly 49 build which I manually downloaded
> crashes and brings up the Mac OS X crash reporter.
> But the DevEdition installed on the same system updated itself to 48. And
> 48 started and appeared to be still working.
>
> Best
>   Nils Ohlmeier
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Benjamin Smedberg]

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 versions of MacOS.
Gregory, will you own that? You will probably need to add CPU feature
detection to the update URL/params for 47, or use some kind of system addon
to shunt these users off the main update path.

--BDS


On Fri, May 6, 2016 at 10:10 AM, Mike Hoye  wrote:

> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>
>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>> instructions. This instruction is part of the original SSE instruction
>> set,
>> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
>> by
>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>> need
>> Firefox to run on processors manufactured in the 90s.
>>
> Per an IRC conversation with chutten, Firefox users on CPUs that do not
> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> etc), this work provides continuity of support to 0.01% of our users.
>
> - mhoye
>
>
> 09:59  So, to put it clearly and precisely, of the Firefox
> Population in release and beta who are reporting at least base telemetry
> collection on machines running supported configurations, only 0.01% cannot
> definitively say they have SSE.
> 10:00  (according to a 1% random sample as stored in the
> longitudinal dataset)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Benjamin Smedberg]

As I understand it, Firefox: Extension Compatibility was a component where
we made Firefox product changes to support extension compat. But it's true
that most of the things that get filed there are "extension X broke in
Firefox version N".  I expect WebExtensions to make this better, but in the
meantime I'm not sure who should own this component or what is welcome or
unwelcome there.

Kev or Andy, do you have suggestions?

--BDS


On Mon, May 2, 2016 at 4:01 PM, Justin Dolske <dol...@mozilla.com> wrote:

> Will Firefox :: Extension Compatibility also be rolled into 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 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 we want to track those defects is when
>> we want to make explicit outreach efforts because those defects affect
>> Firefox users.
>>
>> There were previously almost a hundred different "components" for fine
>> classification of these bugs. This was not producing good results and
>> caused confusion for many people filing bugs. So I've asked for most of
>> these components to be retired, and now there will be just three components:
>>
>> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
>> working with Adobe when necessary.
>> "OpenH264" - I believe Maire Reavy's team triages this component for bugs
>> that affect our deployment of OpenH264 with Cisco.
>> "Other" - For defects in basically all other 3rd-party software,
>> including other NPAPI and GMP plugins, Firefox extensions, and other
>> software such as antivirus tools, that may affect Firefox. I am triaging
>> these bugs as necessary.
>>
>> --BDS
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Changes to bugzilla "plugins" product

[Benjamin Smedberg]

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 we want to track those defects is when
we want to make explicit outreach efforts because those defects affect
Firefox users.

There were previously almost a hundred different "components" for fine
classification of these bugs. This was not producing good results and
caused confusion for many people filing bugs. So I've asked for most of
these components to be retired, and now there will be just three components:

"Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
working with Adobe when necessary.
"OpenH264" - I believe Maire Reavy's team triages this component for bugs
that affect our deployment of OpenH264 with Cisco.
"Other" - For defects in basically all other 3rd-party software, including
other NPAPI and GMP plugins, Firefox extensions, and other software such as
antivirus tools, that may affect Firefox. I am triaging these bugs as
necessary.

--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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.governance/NwsV30-qaWc/I7WgNPqVDAAJ

--BDS

On Thu, Apr 21, 2016 at 12:01 PM, Jason Orendorff 
wrote:

> More evidence that our coding conventions need an owner...
>
> -j
>
>
> On Wed, Apr 20, 2016 at 10:07 PM, Kan-Ru Chen (陳侃如) 
> wrote:
>
> > Nicholas Nethercote  writes:
> >
> > > Hi,
> > >
> > > C++ constructors can't be made fallible without using exceptions. As a
> > result,
> > > for many classes we have a constructor and a fallible Init() method
> > which must
> > > be called immediately after construction.
> > >
> > > Except... there is one way to make constructors fallible: use an
> > |nsresult&
> > > aRv| outparam to communicate possible failure. I propose that we start
> > doing
> > > this.
> >
> > Current coding style guidelines suggest that out parameters should use
> > pointers instead of references. The suggested |nsresult&| will be
> > consistent with |ErrorResult&| usage from DOM but against many other out
> > parameters, especially XPCOM code.
> >
> > Should we special case that nsresult and ErrorResult as output
> > parameters should always use references, or make it also the default
> > style for out parameters?
> >
> > I think this topic has been discussed before didn't reach a
> > consensus. Based the recent effort to make the code using somewhat
> > consistent style, should we expend on this on the wiki?
> >
> >Kanru
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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
experiment system so that you don't have to write an addon at all:
that you can just specify pref values in the experiment manifest. That
would require engineering work and a little bit of new signing work
that is currently not planned; but if somebody wants to do that work,
I would be willing to mentor.

Data review is required only if an experiment collects new data. My
goal is for this to be fast and straightforward, but IIRC it wasn't
necessary at all for your recent experiment. There is no legal review
required for experiments unless I raise a question during data review.

There is no explicit QA "approval" process required: clearly we don't
want to ship broken code, so we should use normal good judgement about
how to test each particular experiment, but that should not be a
high-process thing by default.

In what ways does your experience differ from the ideal? What can we
change to make this less painful?

--BDS


On Tue, Apr 19, 2016 at 4:43 PM, Kartikaya Gupta  wrote:
> (Cross-posted to dev-platform and release-management)
>
> Hi all,
>
> Not too long ago I ran a telemetry experiment [1] to figure out how to
> tune some of our code to get the best in-the-wild behaviour. While I
> got the data I wanted, I found the process of getting the experiment
> going to be very heavyweight as it involved getting all sorts of
> approvals and reviews. Going through that process was more
> time-consuming than I would like, and it has put me off from doing
> further experiments of a similar nature. However, this means that the
> decisions I make are going to be less data driven and more guesswork,
> which is not good for obvious reasons.
>
> What I would like to see is a simplified process for telemetry
> experiments on Nightly, making it easier to flip a pref on 50% of the
> population for a week or two and get some useful data out of it. It
> seems to me that many of the approvals (QA, RelMan, Legal, Product)
> should not really be needed for this kind of simple temporary
> pref-flip, assuming the necessary data collection mechanisms are
> already in the code. Does anybody have any objections to this, or have
> other suggestions on how to streamline this process a bit more?
>
> To be clear, I'm not suggesting we do away with these approvals
> entirely, I just want to see more nuance in the process to determine
> when they are *really* required, so that they don't slow us down
> otherwise.
>
> Cheers,
> kats
>
> [1] https://wiki.mozilla.org/Telemetry/Experiments
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 turning this on by default, could we try exposing this to advanced
users (perhaps via test pilot or a similar extension), and try out some UI
options so that users have some ability to override this?

Or could we explore doing this first only for 3rd-party requests.

I oppose this proposal as written.

--BDS


On Thu, Apr 14, 2016 at 4:54 AM, Chris Peterson 
wrote:

> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set over non-secure HTTP can be sniffed and
> replayed. Clearing those cookies at the end of the browser session would
> force the user to log in again next time, reducing the window of
> opportunity for an attacker to replay the login cookie. To avoid this,
> login-requiring sites should use HTTPS for at least their login page that
> set the login cookie.
>
> * Privacy: most ad networks still use non-secure HTTP. Content sites that
> use these ad networks are prevented from deploying HTTPS themselves because
> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
> over non-secure HTTP at the end of every browser session would be a strong
> motivator for ad networks to upgrade to HTTPS, which would unblock content
> sites' HTTPS rollouts.
>
> However, my testing of Henri's original proposal shows that too few sites
> set the `secure` cookie flag for this to be practical. Even sites that
> primarily use HTTPS, like google.com, omit the `secure` flag for many
> cookies set over HTTPS.
>
> Instead, I propose treating all cookies set over non-secure HTTP as
> session cookies, regardless of whether they have the `secure` flag. Cookies
> set over HTTPS would be treated as "secure so far" and allowed to persist
> beyond the current browser session. This approach could be tightened so any
> "secure so far" cookies later sent over non-secure HTTP could be downgraded
> to session cookies. Note that Firefox's session restore will persist
> "session" cookies between browser restarts for the tabs that had been open.
> (This is "eternal session" feature/bug 530594.)
>
> To test my proposal, I loaded the home pages of the Alexa Top 25 News
> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
> cookies. Treating non-secure cookies as session cookies means that over
> 1100 cookies would be cleared at the end of the browser session!
>
> CONS:
>
> * Sites that allow users to configure preferences without logging into an
> account would forget the users' preferences if they are not using HTTPS.
> For example, companies that have regional sites would forget the user's
> selected region at the end of the browser session.
>
> * Ad networks' opt-out cookies (for what they're worth) set over
> non-secure HTTP would be forgotten at the end of the browser session.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>
> Link to standard: N/A
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 49
>
> Preference behind which this will be implemented:
> network.cookie.lifetime.httpSessionOnly
>
> Do other browser engines implement this? No
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
> [2] http://www.alexa.com/topsites/category/Top/News
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Crash signature change: signatures now include abort messages

[Benjamin Smedberg]

No, it does not catch MOZ_RELEASE_ASSERT, because that doesn't call
NS_DebugBreak and that is what does the AbortMessage annotation[1].
NS_RUNTIMEABORT is the recommended way to reliably crash if you're in
XPCOM-y code.

Bug 1104682 is filed for this, though. I'd love for somebody to take this.

--BDS

[1]
http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsDebugImpl.cpp#392

On Wed, Apr 6, 2016 at 5:29 PM, Kyle Huey <m...@kylehuey.com> wrote:

> Does this catch MOZ_RELEASE_ASSERT and similar?  It would be nice to
> distinguish those somehow in crash-stats.
>
> - Kyle
>
> 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 | ". Now the signature will be "Abort | > message up to 80 chars> | ".
>>
>> This should make it much easier to distinguish various classes of abort.
>>
>> 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
>>
>
>


-- 
Benjamin Smedberg
Engineering Manager, Firefox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Crash signature change: signatures now include abort messages

[Benjamin Smedberg]

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 "Abort |  | ".

This should make it much easier to distinguish various classes of abort.

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

[Benjamin Smedberg]

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 take for us to gain 1.2% new users and how
much does it cost to keep the support. My personal estimation for the first
is pretty high :(


The math is pretty striking: the problem is not so much about user 
acquisition but about retention and user engagement. We have no problem 
getting new Firefox users: we still have amazingly high brand 
recognition and get many downloads. In terms of retention, what kind of 
engineering effort do we need to do to keep users one, two, four, eight 
weeks after they've tried Firefox? In terms of ongoing engagement, the 
Firefox product strategy has us measuring and optimizing how many days 
(per week) Firefox users use Firefox.


Our basic product strategy is that by focusing our engineering efforts 
on engagement/retention of new users, we'll end up in a much better 
spot, both in terms of overall product quality and our position in the 
market, than if we focus on keeping small cohorts of existing users. 
That tradeoff of existing users for new-user engagement is driving our 
strategy with e10s, extensions, and other engineering priorities, and is 
the basis for this decision.


--BDS
___
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

[Benjamin Smedberg]

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 impact, not just the impact relative to the mac population.


Dolske answered with more details about the numbers.

On 3/10/2016 6:38 PM, Nils Ohlmeier wrote:

Excuse my ignorance, but what means “deprecate support” exactly?

I’m only asking because of the opposing reply’s so far. I’m assuming it means 
we stop testing and building/releasing for these. Would it be a possible 
alternative to turn of the tests, but continue to build and release unsupported 
builds?

We intend to do the following things:

* add version checking to the builds so that they refuse to run on these 
versions of MacOS

* stop doing any software testing on these versions of MacOS
* stop automated testing on Mac 10.6

As soon as we stop testing, we are going to break things. We shouldn't 
be willing to call things "Firefox" that we aren't proud of, which 
includes real testing.




On 3/10/2016 6:49 PM, Kyle Huey wrote:


Why can't we just not ship e10s to these users?  We have a number of other
populations we're not shipping to, at least for now.


We did explicitly consider this option and ultimately rejected it. It 
would potentially buy us at least one more ESR cycle until next January. 
After that point we want e10s to be the only configuration. It comes at 
the cost of ignoring known issues already as well as a nontrivial amount 
of testing. Ultimately we don't believe this is the right tradeoff. It 
also prevents us making progress on other areas such non-universal builds.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to deprecate: MacOS 10.6-10.8 support

[Benjamin Smedberg]

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 prioritize these bugs. Especially with the 
deployment of e10s we're seeing intermittent and permanently failures on 
MacOS 10.6 that we are not seeing elsewhere. We get very little testing 
of old MacOS versions from our prerelease testers and cannot dedicate 
much paid staff testing support to these platforms. We also have an 
increasingly fragile set of old hardware that supports automated tests 
on 10.6 and do not intend to replace this.


This will affect approximately 1.2% of our current release population. 
Here are the specific breakdowns by OS version:


10.6
0.66%
10.7
0.38%
10.8
0.18%

The final timeframe for this deprecation has not been finalized, but the 
current proposal is to remove support in Firefox 46. We will try and 
update existing users on old MacOS versions to the Firefox 45 ESR 
release stream, so that they stay with security update support through 
the end of 2016.


Because of the ESR update window, I would like to finalize this decision 
by Monday. If you have questions or concerns about this plan, please 
reply to the firefox-dev mailing list immediately. Jeff Griffiths will 
be working with our communications team to coordinate more public 
communications such as post to the Future of Firefox blog.


--BDS


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: call prompt service dynamically

[Benjamin Smedberg]

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 thread is 
pretty much doomed. Even if this isn't the case, binary XPCOM is not 
considered a stable API and so your code would have to be recompiled for 
every release.



  The code below works great until I stay on MS Visual Studio. But our project 
is running on eclipse/gcc.

  nsCOMPtr promptService = 
do_GetService("@mozilla.org/embedcomp/prompt-service;1"));
  promptService->Alert(NULL, NULL, NULL);

I`m getting the following error during linking, that comes because of the 
different coding convention between VS and mingw/gcc on windows.


That's correct. The c++ ABI is incompatible. There is essentially no way 
to fix this. Even if you use an SDK compiled with GCC instead of MSVC, 
the vtable format for interfaces is not the same and so you won't be 
able to use them.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: call prompt service dynamically

[Benjamin Smedberg]

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;
nsXPTCVariant params[3];


Why are you trying to do this? Are you writing a shim layer that 
connects some other dynamic/scripting language to XPCOM?




rc = NS_GetXPTCallStub(NS_IPROMPTSERVICE_IID, proxy, );

params[0].val.p = NULL;
params[0].type = nsXPTType::T_VOID;
params[0].flags = 0;

params[1].val.p = (void*)title;
params[1].type = nsXPTType::T_CHAR_STR;
params[1].flags = 0;

params[2].val.p = (void*)text;
params[2].type = nsXPTType::T_CHAR_STR;
params[2].flags = 0;

rc = NS_InvokeByIndex(mXPTCStub, 1, 3, params);
NS_DestroyXPTCallStub(mXPTCStub);

But I don`t know how to use NS_GetXPTCallStub!
What means the second and third parameter from NS_GetXPTCallStub?


Have you read the doccomments at 
http://mxr.mozilla.org/mozilla-central/source/xpcom/reflect/xptcall/xptcall.h#174 
?


If you are trying to *invoke* a method, you don't need an xptcall stub 
at all. You just need NS_InvokeByIndex.


An XPTCall stub is used to *implement* an XPCOM object whose 
type/interface definition isn't known at compile time, typically by 
mirroring it to an underlying scriptable object. You would need to 
implement a c++ class which implements nsIXPTCProxy and implements 
CallMethod.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Exit code -11 must die

[Benjamin Smedberg]

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 may know (+ted):

 * Are we sure that the crash is happening in firefox.exe? Or is it
   possible that some other process is crashing and taking down our
   test harness with it?
 * Can somebody point to exactly what line of code in the test harness
   collects the -11 code?
 * Is there no crash dump because the crash reporter is turned off?
 o If it's turned on, is the crash reporter itself crashing? Or is
   the test harness not picking up the crash dump?



We *need* to find some solution to it -- even if it's to decide it's a
(safe) artifact of some underlying problem outside of our control.


Is "we" you? Are you asking somebody else to help you with this, or own 
the problem completely?



   I'd
far rather find a true cause and either fix or wallpaper it.  But right
now it's stopping me from landing some important code changes.

On the plus side, I have a nice Try run which will cause it 100% of the
time - though when I tried to provoke it on a loaner Test VM after
painfully emulating what's needed to run tests, it wouldn't fail -- but
I don't trust that was a well-setup recreation of a real Try run.

https://treeherder.mozilla.org/#/jobs?repo=try=b2eb01359621

IIRC, there was recently a post about how you can submit a try job and 
have the VM stay alive afterwards for postmortem debugging. I don't 
remember/can't find the details right now


Can we also submit a try job with rr enabled, and get a recording of the 
failure? That combination could lead to a pretty quick cause diagnosis 
of this, since it's Linux.


Also, does this failure happen if you disable all the tests except for 
the one which is permafailing 
(dom/media/tests/mochitest/identity/test_setIdentityProviderWithErrors.html)? 
If so, that would make it easier to record and debug.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[Benjamin Smedberg]

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 indicator of the evolving quality of Firefox.
Actionable bugs are those with the status NEW for which the next action
required - if any - is unambiguous: does the bug need immediate attention,
will it be worked on for a future release, will it be worked on at all?


As the sponsor for this project, I want to clarify some things related 
to this project. The bug-handling initiative is a key part of our 
Firefox quality programs in 2016. I have asked Emma to focus on our 
process for making explicit decisions about incoming bugs. There are two 
primary reasons for this:


* When we don't see incoming regression bugs, that is high risk to our 
quality and shipping schedule. We have done dot-releases or similar 
respins numerous times over the past year: in many cases the bugs that 
caused those respins were filed well before release but either not seen 
or we didn't react to them.
* Our testing community, especially prerelease users, are a core part of 
our success. We know that one of the greatest turn-offs for people 
filing their first bug is to have it sit with no response. On the other 
hand, a quick response is a good predictor of continued and deeper 
involvement in the project.


I don't think that we are going to learn much about quality or risk just 
by counting the number of open bugs. So I don't think the statement 
"best metric of code quality available" is true, and it has generated a 
lot of the feedback in this thread. But I do assert that a core risk 
metric is the number of new bugs without a *decision*, and we should be 
tracking that number and driving it to zero.


Part of the program that is already underway is triaging everything out 
of Core:Untriaged and Firefox:Untriaged into the proper component. This 
is a task that we've been accomplishing both with our volunteer 
community and with the support of Softvision contractors, and we're on 
track to burn the Untriaged components to 0 bugs by the end of this quarter.


My intention, once we have this system in place, is to focus activities 
on increasing the both the quality and quantity of incoming bug reports, 
especially from our prerelease users: building product features which 
enable users to file more detailed and useful bug reports, combined with 
data collected within the browser. Filing a bug in bugzilla is still a 
scary experience for many people, and we can do better.


To keep focus and avoid creeping scope, an explicit non-goal of this 
program is to deal with the prioritization of non-critical bugs within a 
team or component. The primary goal here is to solve the flow for 
incoming bugs to a clear decision-state. Beyond the bucket of "backlog 
of work", teams can continue to use aha or tracking bugs or external 
spreadsheets.


One other important thing to note is that we plan on implementing 
bugzilla UI improvements to make triage much simpler. This may include 
things like one-click decision making on bugs and autoloading bug 
reports from triage lists. We expect that work to commence once the 
initial trials are done in Q1 and we have better experience with the 
details.


To reply to a few specific comments and questions...

Richard Newman wrote:

In my experience, component watching adequately serves this purpose, 
and component watchers collaboratively respond to, immediately triage, 
or flag with a tracking-? flag. That might not be true for some 
components, but it is for the three products I watch.


I disagree that component watching is working well now. There are 
components that are well-watched, and it mostly works to surface 
high-priority (tracking+) bugs. But for non-critical bugs, they are 
often left filed as NEW without even so much as a comment explaining a 
decision: the bug reporter is left without a clear understanding of what 
to expect or even knowledge that somebody has looked at their bug 
report. We owe it to our community of bug filers to be more clear and 
explicit with these decisions.


I think it's worth pointing out that it's not always worth assigning 
bugs to a developer — in my experience that does more harm than good 
if they're not working on it. Be realistic. Neither does P1 mean 
anything useful in many of the components I follow.
Emma is talking explicitly about bugs which rise to the level of a 
tracking+ bug (critical regression or a bug in a new feature). Right now 
we're living in a world where release drivers mark a bug tracking+ bug 
many of these bugs remained assigned to nobody forever. This is a bad 
state and the goal is to start sending out daily alerts for tracking+ 
bugs without an owner.


Many of our regressions are reported informally on Twitter, as GitHub 
issues, or on IRC. 

Re: Does SSE2 usage still need to be conditional?

[Benjamin Smedberg]

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 any, say telemetry, that would move this from speculation
into numbers?  Sure, numbers aren't necessarily perfect, but I'm sure
that they would help.


Milan is quoting numbers from telemetry data. The last time I calculated 
this was 8 months ago, but at the time our users were using an almost 
50/50 split of 32-bit Windows and 64-bit Windows. We expect that number 
to grow slowly over time with the device replacement cycle.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Benjamin Smedberg]

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 Steam users are sufficiently similar. I don't think that's 
necessarily true since most Steam titles have substantially higher 
system requirements.


The last time we broke this (by accident) was several years ago. At the 
time, we got vigorous complaining from various people who had relatively 
recent bare-bones machines without SSE2.


It might be worth reconsidering now: I'm not willing to throw away 0.5% 
of our users without good cause, but perhaps there is a good cause to be 
made here? What would the performance gain be for the remaining 99.5% of 
users, realizing that we already have dynamic SSE2/non-SSE switching in 
place for some of our hottest paths.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Benjamin Smedberg]

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
category of documentation that's not written yet.


Not just.  For example, there is no way to "r-" in mozreview.  You can 
only "r+" or remove the review request, in Bugzilla terms.


There is a pattern that some teams have been using where they never mark 
"r-" on a change. I think the rationale for this is that it feels 
negative and discouraging to receive the "review not granted" email, 
especially for new contributors. Instead, they will either clear the 
review or mark an f+ and ask for a new patch.


I don't like this practice: I encourage people to use the r- flag. It's 
important to make clear in bugzilla that something has already been 
reviewed and that the result is that something is not ready. Without r- 
or something very similar, it's difficult to distinguish between various 
important cases:


 * I'm too busy/not the right person to review this (clear the review
   or redirect it)
 * I started the review and have a question (leave the r? flag, add a
   NEEDINFO)
 * This isn't good enough (r-)
 * I've looked this over and it's ok in general, but it still needs a
   detailed code review: mark f+, redirect the r? flag as appropriate

In addition, I've seen several contributors become confused receiving an 
f+ and not realizing that what it really meant is "not good enough, 
please make changes".


Our reviewboard tooling should support explicit r- and not just clearing 
review flags.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: wptview [Re: e10s]

[Benjamin Smedberg]

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

but have different behaviors in e10s and non-e10s mode?



Yeah, I'm confused.

If a wpt test passes but with different output, then either there is no
problem or the test is incomplete and should be changed.


Maybe I should clarify.

web-platform-tests are slightly different to most tests in that we run 
both tests we currently pass and tests that we currently don't pass. 
On treeherder all we check is that we got the same result in this run 
as we expected on the basis of previous runs.


Is this "same as previous run" behavior automatic, or manually 
annotated? Running tests which don't pass is supported and common on 
many other test suites: fail-if and random-if are used to mark tests as 
a known fail but still run them.


Is this a temporary state, where the end goal is to have the 
web-platform tests use similar manifests to all of our other tests? Can 
you provide some context about why web-platform tests are using 
different infrastructure from everywhere else?


The effect of all of this is that in order to understand what's 
actually needed to bring e10s builds up to par with non-e10s builds 
you need to look at the actual test results rather than just the list 
of disabled tests. I believe that there are both instances of tests 
that pass in non-e10s but not in e10s builds, and the reverse. wptview 
gives you the ability to do that using data directly from treeherder. 
The actual action to take on the basis of this data is obviously 
something for the people working on e10s to determine.


This is not the responsibility of the e10s team; this is an all-hands 
effort as we switch to making e10s the default configuration and soon 
the only configuration for Firefox. If having different results for e10s 
and non-e10s is not expected, who is the module owner/responsible for 
the web platform tests and can create a list of the problem results and 
find owners to get each one fixed?


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: wptview [Re: e10s]

[Benjamin Smedberg]

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 differences in this case.

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 e10s and non-e10s mode?


If it is a problem (or a potential problem), who is responsible for 
understanding the problem and fixing it? Should it turn something on 
treeherder red?


--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: about:profiles and the new profile manager

[Benjamin Smedberg]

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 that, it's not intended for use by end-users.


One of the things I'm most concerned about with about:profiles is that 
it will be easier for users to discover it, but the technical benefits 
of removing a lot of the no-profile gecko startup paths and complex 
restart logic will make this a nice win overall.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: about:profiles and the new profile manager

[Benjamin Smedberg]

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 would go 
into the product?

Have you consulted anyone from the Firefox front-end or Firefox UX team about 
this already?


As it stands, this is not intended to be product code and so I 
specifically advised Andrea not to spend UX/product time on this. It is 
still a strict replacement for the old profile manager code which was 
very difficult to maintain.


It's unlikely that we'd use this code as a base for any production 
version of multiple-user Firefox.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using the Taskcluster index to find builds

[Benjamin Smedberg]

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 correlate telemetry data, I need a time series of all 
mozilla-central nightly builds (with version and buildid). It's 
important that when there are multiple nightlies on a given date, that I 
get all of them.


Similarly for betas, I want to know all the beta+candidates so that I 
can mark the beta numbers properly in dashboards instead of listing only 
buildids. That will feed into dashboards such as 
http://bsmedberg.github.io/telemetry-dashboard/new-pipeline/crash-summary.html 
(choose "beta").


I'd also like to enhance that dashboard to construct regression range 
links between particular builds. How would I go from a channel+buildid 
(recorded in telemetry) to a revision number? Would that be for example 
deconstructing the buildid and putting it back into the form 
gecko.v2.mozilla-central.pushdate..MM.DD/BUILDID/firefox/ and then 
reconstructing the "linux32-opt" path from the other telemetry data?


I'd like to recreate 
http://bsmedberg.github.io/firefox-regression-range-finder/ using 
something other than FTP scraping. How would I go from a known 
build/revision to the previous/next nightly/aurora/beta build?


I'm feeling a bit stupid about the actual API: how does one go from a 
"browse" URL such as 
https://tools.taskcluster.net/index/artifacts/#gecko.v2.mozilla-central.nightly.2015.11.27.latest.firefox.win64-opt/gecko.v2.mozilla-central.nightly.2015.11.27.latest.firefox.win64-opt 
to a machine-readable API URL? I imagine that tools like mozregression 
have similar needs.


Can taskcluster directly provide version number/buildid/revision of a 
particular nightly, would I have to fetch one of the artifacts like 
buildprops.json or buildbut_properties.json to get that data? Looking 
through buildprops, it has the buildid and revision but not the version 
number. If I wanted to get this data for a whole range of builds, would 
I have to fetch each file individually or is there a list/batch API? Are 
either buildprops.json or buildbut_properties.json documented/stable 
formats?


Right now the actual data (paths and formats) seem pretty 
under-documented: exploring what's there via browseing is nice but 
time-consuming and I'm not sure which things are supported. What are the 
plans to document the various paths so that they are reliable? Do you 
consider this a production system right now, or is this still a 
development system?


What are the performance characteristics of this system? Would it be 
acceptable to this this API from dashboards, or would that affect the 
system? Should we be prepared to transform the data into some other form?


--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding out if the main thread is currently animating

[Benjamin Smedberg]

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, David Rajchenbach-Teller wrote:

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 lasts more than 32ms".

Do we have a reliable way to do that?



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Merging comm-central into mozilla-central

[Benjamin Smedberg]

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 this proposal come with a plan to check out subsets of the code? In 
particular, I want to express the following as something inbetween 
"serious concerns" and "requirements":


 * The default view of dxr.mozilla.org should not include non-Firefox code
 * The default checkout should not include non-Firefox code. (Note:
   this is about the working tree: I don't think the space in the .hg
   directory matters enough to worry about).


- TTBOMK, Thunderbird is Mozilla's second largest project in terms of
   number of users, behind Firefox, and before Firefox for Android and
   Firefox OS.  Many of those users may legitimately want to contribute
   to Thunderbird, and the bar to entry is made much higher by the
   multi-repository setup and the extra complexity it entails. Mozilla is
   actively making the bar to entry for Firefox/Firefox for
   Android/Firefox OS contributions lower, at the expense of Thunderbird
   contributors. This is a sad state of affairs.


I'm sorry that it makes you sad, but Mozilla has explicitly decided to 
prioritize the bar to entry for Firefox development, and the speed of 
development of Firefox, at the expense of Thunderbird (and seamonkey). 
And as Firefox development moves faster toward things such as stopping 
supporting XUL addons, removing support for heavyweight themes, and even 
cutting XUL altogether, we should all expect the impedance mismatch to 
become worse. We are not only saying that you don't have to fix 
comm-central apps: we're also saying that we don't *want* core 
contributors to spend time on comm-central.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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 corresponding error protocol we found out, that the root cause of the issue is the 
"mozalloc.dll".

You see the full error protocol (German) below (customer details were 
obliterated).

Can anybode help me? What whould be a solution for this issue?


XULRunner is no longer built or maintained by Mozilla, and XULRunner 10 
has been out of support since April 2012.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mach mozregression command

[Benjamin Smedberg]

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 added a "mach mozregression" command
that allow to run mozregression (a regression range finder for Mozilla
nightly
and inbound builds) directly from your checkout of mozilla-central. To
learn more about
how to use it, just run:

./mach mozregression --help

See http://mozilla.github.io/mozregression/ if you don't know about the
tool.

I hope you'll find this useful!

Julien
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benjamin Smedberg]

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, **including** the software included with the device are FDA 
certified.  We (as an user of the device) are not allowed to provide our own software to 
access the device (which we could do without much effort).  We have to use the 
certified C library.

The manufacture of the device (and its library) do not wish to share their Intellectual 
Property (IP) with us so that we could create a modern browser extension.  As 
most of their customers use their product with native OS clients, not browser based 
clients.


I recommend that you write this as a Firefox addon in the following way:

* construct a shim program which links the C library and communicates 
with the addon on stdin/stdout
* use the addon SDK and system/child_process to launch your shim program 
and communicate with it


See 
https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process 
for a description of system/child_process.


I'm going to contradict Ehsan here: ctypes is a powerful-but-dangerous 
API and I wouldn't recommend it unless you have no other choice. We may 
decide to stop supporting it in the future.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: recording use counters for web features

[Benjamin Smedberg]

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 updated to document this? I don't
recall being asked to review the final data collection proposal
for this mechanism.


They have not.  I didn't realize there were documents to update or 
that adding new histograms required separate review.


Yes. The Firefox data stewards (myself and peers Vladan and Ally) review 
all changes to Firefox data collection. See the policy doc at 
https://wiki.mozilla.org/Firefox/Data_Collection


This really does need some docs. I don't particularly care whether this 
ends up in the telemetry document tree at 
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/docs/ 
or add a new area for DOM documentation. But we absolutely need to 
describe the system and the histograms it produces.


I do think we should end up documenting the use counters in the 
auto-generated docs, but that can be a followup bug. Bug 1194287 is 
currently filed to get Histograms.json itself included in the 
auto-generated docs.




In particular:

* Will this only collect to the opt-in (prerelease) population, or
does this also affect the release population?


 Since these are just histograms within Telemetry, I assume this 
affects prerelease and release populations. (That was the intent, 
anyway; it's possible I didn't flip the right switches for this to 
happen.)


Will that solve all of the use-cases? I'm perfectly fine with being able 
to specify that use counters are opt-out (FHR), but opt-in/telemetry is 
the default in Histograms.json. In any case, this should be tested as 
part of QA verification for the bug.




* This involves collecting a numerator and denominator as separate
histograms, correct?


 I don't know what numerator and denominator refer to here, maybe # of 
pages using feature and # of total pages, respectively?


Isn't that the use-case that this was trying to solve?



For each defined use counter, there are two separate boolean 
histograms.  One describes the use of that thing for individual 
documents, and the other describes the use of that thing for 
top-level pages: basically what we think of as a web page.


Interesting, this is not how I imagined this would work. I figured we'd 
have a couple of global counters:


* counter: number of documents
* counter: number of toplevel documents

And then for each feature we'd have a couple of counters:

* counter: per-document feature usage
* counter: per-toplevel-document feature usage

In terms of the total data collected, it appears to be equivalent. But 
one reason for doing it this is that it can significantly reduce the 
telemetry payload size for measuring infrequently-used features: we 
don't include unused histograms at all in the telemetry payload.


* Is there reporting in place for this mechanism already? If not,
who is going to write that?


Since these are just histograms, reporting should not be a problem.  
There have been problems on the server-side when the first part of 
this landed back in May (bug 1168409), so it's possible that there are 
some changes needed on the server side for histogram validation, etc.


Has somebody verified that the current histogram displays on 
telemetry.mozilla.org can answer the questions you care about?




* How are we going to do data-collection reviews for additions,
especially if the collection is added through WebIDL/UseCounters?


I do not know.  hg push hooks?


Let's start out by just stating the obvious, that you cannot add a new 
use counter without data collection review. If that stops working, we 
can think about the more complicated hook process.




* Is there a mechanism for auto-expiring data collection like
there is for histograms?


The histograms are currently set to never expire.  It is probably 
worth rethinking that.


Yes, I think this is a requirement. Very few of the use-cases for use 
counters are candidates for permanent data collection, and so we should 
explicitly be able to specify the expiration.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: recording use counters for web features

[Benjamin Smedberg]

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 (prerelease) population, or does 
this also affect the release population?
* This involves collecting a numerator and denominator as separate 
histograms, correct?
* Is there reporting in place for this mechanism already? If not, who is 
going to write that?
* How are we going to do data-collection reviews for additions, 
especially if the collection is added through WebIDL/UseCounters?
* Is there a mechanism for auto-expiring data collection like there is 
for histograms?


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

XULRunner future and ownership

[Benjamin Smedberg]

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. 
In order to keep XULRunner in the tree, we need an owner who wants to 
keep it building and running properly. Currently, I am the nominal owner 
of the XULRunner code, but I have no desire to do this work or even 
really to review the necessary patches. I am looking to see whether 
there is an alternate owner who is interested in the task of keeping 
XULRunner building and running properly and reviewing patches to 
XULRuner-specific code. Please contact me if you want to nominate 
yourself or somebody else for this role.


If I do not find a suitable owner in the next two weeks, I intend to 
remove the XULRunner code from the mozilla-central repository on 14-August.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform