Re: PSA: New method for registering XPCOM components

[Robert Helmer]

On Wed, Feb 6, 2019 at 2:25 PM Kris Maglione  wrote:
> >* Perhaps a link (or multiple links) to MDN docs we already
> >have on XPCOM components - which may provide an introduction as
> >to what they are, when and why they’re used, etc.
>
> I'm not sure this is a good idea. Docs about Gecko internals on
> MDN are generally deprecated, and the ones about XPCOM are
> obsolete to the point of being useless.

+1, just say no to internal docs on MDN.

Documentation that we can auto-generate from the source code directly
is preferred over standalone docs, although even in the latter case
it's much better to have this live alongside the source code so we
know which revision of m-c it applies to. In both cases
https://firefox-source-docs.mozilla.org/ should always be used for
Firefox internals, and MDN only for web standards and standard-ish
things like WebExtension APIs.

Speaking of auto-generation, could some/all of the code blocks in
https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/build/docs/defining-xpcom-components.rst
be generated via autodoc from
https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/xpcom/components/gen_static_components.py
? I suspect it'd increase the readability of that file and make it
easier to modify if those bits were separated into a Python class
anyway.

Note that I don't have particularly strong feelings about this, if you
think it's easier to keep the docs separate and/or don't expect to
change it much in the future then that's fine too.

> I'm also a bit leery about mentioning old coding styles in docs
> like this, since those kinds of mentions tend to stick around
> long after everyone has forgotten that style ever really
> existed...

Agreed, we're still dealing with fall-out from people getting confused
about old add-ons documentation and snippets etc. that look official
since they are on MDN. An even better example where this causes
confusion over internals is
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Observer_Notifications
- that would be a great candidate for auto-generating from source
code.

> >* An example of ‘old style’ vs. ’new style’ xpcom definition,
> >  perhaps even a ‘good’ vs. ‘bad’ - but there’s a negative
> >  connotation there, which may not be preferred.
> >* A full example (prolly on a second page would be best), which
> >  showcases the discrete steps to get from zero to hero. Err, I
> >  mean new component.
> >
> >I’m suggesting all this extra work, because I think it will
> >actually save you a lot in the future; rtfm is a very simple,
> >yet powerful response to all the queries you’re gonna get.
>
> Again, I'm not sure the linked doc is really the best place for
> such things, since the doc is meant to be permanent, and it
> would get dated fast.
>
> I can give examples in this thread, if you think it would be
> useful. But given that I've already converted (or have pending
> patches to convert) pretty much all of our old-style
> registrations, it wasn't clear to me that it would.

I would like to see examples in this thread. It'll be as easy to link
folks to the mailing list archive, and it'll be clearer that it's
ephemeral since it's a mailing list from a specific time period.

Thanks again for making this change :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Robert Helmer]

On Thu, May 3, 2018 at 11:57 AM, Adam Roach  wrote:
> On 5/3/18 12:18 PM, Nicholas Alexander wrote:
>>
>> Not all features are feasible to ship behind feature flags.
>
>
> I'm pretty sure the proposed policy isn't intended to change anything
> regarding features that ship without associated feature flags, nor is it
> trying to get more features to ship behind flags than currently do. It's
> just trying to rationalize a single, more managable process for those that
> *do* ship behind flags.
>
> /a

I agree that not every single feature is appropriate to ship behind a
feature flag, since the cost to maintain parallel implementations can
be huge, and has implications on things like the size of the
application and updates. In addition, if you look at
e10s/stylo/webrender we've set up parallel testing infrastructure,
which needs to be maintained for quite a while even after we've
enabled the feature.

We did however consider the benefits to be worth the complexity for
even the very large and complex projects mentioned above, and there
are many downsides and risks to not using a phased roll-out approach
(which can be done without feature flags), so I'd be interested in
continuing this discussion in a separate thread.

For this specific proposal, the only change I'd suggest is that we
should move away from the term "Pref Flip" in favor of "Feature Flag",
since (as evidenced in this thread so far) the latter is the more
standard industry term.

I also think there's an argument to be made that the pref system on
Firefox Desktop is not the right system for implementing feature flags
in general, but I'll leave that for a separate thread as well.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Robert Helmer]

On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez  wrote:
> Nicholas Nethercote
> 2018 March 9 at 20:02
>
> What's your definition of XPCOM?
>
> This is basically what I'm asking Kris. I define it as the system that
> Firefox uses to make intra- and inter-language calls between C++ and JS via
> XPIDL and XPConnect. I'm interested in what else it provides that makes it
> so indispensable.
>
> Look in xpcom/, there is a ton of stuff in
> there that is unrelated to XPIDL...
>
> Indeed, but that doesn't tell me how much of XPCOM would remain essential to
> Firefox if we no longer used XPIDL.
>
> For example, XPCOM supports component registration and overriding at
> runtime. But it isn't clear that Firefox needs those features, now that it
> no longer supports XUL extensions (unless perhaps for system extensions).

Just a quick note on this point - we shouldn't make any special
concessions for system add-ons (or any other Mozilla-published add-ons
like Test Pilot, Shield Studies, etc). Legacy add-ons kept us in a
confusing compatibility bind for many years, so I want to make sure
nobody feels that they need to be careful to preserve any form of
compat here.

While the overall compat story should be much simpler as everything
continues to migrate over to WebExtensions, there will still be the
possibility of bundling experimental WE APIs inside add-ons published
by Mozilla (which contain chrome-privileged JS code). The authors of
these add-ons will continue to be responsible for ensuring that the
release(s) of Firefox they are targeting can support their needs.

That said, there are tests for in-tree system add-ons (in
browser/extensions/) so any potential bustage for add-ons that
implement Firefox features (activity stream, screenshots, pocket, etc)
can be quickly found and fixed.

> And xpcom/ contains a ton of stuff, as you say. But it isn't clear how much
> of it is core to XPCOM and how much just happens to live in that directory.
>
> I'm not playing the devil's advocate. I'm genuinely curious about the extent
> of XPCOM's feature set (and how well it aligns with Firefox's current
> requirements).
>
> -myk
>
>
> ___
> 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

Re: Still-supported cases of out-of-tree XPCOM code?

[Robert Helmer]

On Wed, Nov 15, 2017 at 8:31 AM, Kris Maglione  wrote:
> On Wed, Nov 15, 2017 at 04:12:06PM +0200, Henri Sivonen wrote:
>>
>> On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini
>>>
>>> This is why we had this issue. It should not be impossible for a
>>> 'standard'
>>> webextension to generate such mess.


I followed up w/ jkt about the bug in question here, and the reason
for the backout is that the feature was broken on NIghtly for users
without the add-on. The add-on was *also* broken, but I agree with
everyone else in the thread so far that we should not be backing out
changes from mozilla-central because it breaks an add-on produced by
Mozilla.


>> How many Mozilla-signed special extensions are there? Does an analog
>> of https://dxr.mozilla.org/addons/ exist for searching their code? Is
>> there a CI system testing that the continue to work?
>
>
> The situation is pretty bad at this point. Ideally, all XPCOM add-ons that
> we support should run tests in treeherder on checkin, both for add-on
> changes and m-c changes. But as of now, most system add-ons, Test Pilot
> add-ons, and SHIELD studies are hosted on Github and do their own ad-hoc
> testing, mostly using Node-ish testing frameworks.


We shouldn't try too hard to solve for our *current problem* though -
as we wind down bootstrapped add-ons and use webextensions for
everything Mozilla ships, folks that want to contribute Mozilla-only
webextension APIs will need to do so using whatever the standard
Firefox development workflow is. We're in a transition period now
though where webextensions can't do the sorts of things we use Test
Pilot and Shield Studies for, yet.

All this doesn't matter to Firefox developers though. If you break
someone's bootstrapped add-on at this point and their CI doesn't catch
it, that's on the add-on author(s) to fix.


> There's also no standard place to host or index all of this add-on code, or
> even to get a list of what such add-ons exist. At one point, I asked for all
> SHIELD add-ons to at least be hosted in the same Github organization. The
> same should probably go for all other Mozilla-signed add-ons. That would at
> least give us a single place to find any XPCOM add-on code that we still
> support.


Strongly agree here... I think an indexed archive of everything we've
shipped would be helpful. Personally I don't really care how people
developed the add-on (they can be emailing patches around a mailing
list for all it matters), but we should have a single place to see
what shipped and when.


> In the mean time, though, as far as I'm concerned, the maintainers of those
> add-ons are responsible for dealing with breakage that results from not
> having in-tree tests and a standard place to search that code. If you're
> removing legacy XPCOM functionality, all you should need to care about is
> whether treeherder is green.


Yes.

My understanding is that the change in question here was not backed
out due to the extension being broken, and that should continue to be
the case. I'd love to be corrected here if I have this wrong!


>
> ___
> 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: verifying unpacked signed add-ons

[Robert Helmer]

On Fri, Nov 3, 2017 at 3:43 PM, David Keeler <dkee...@mozilla.com> wrote:
> On 11/03/2017 03:34 PM, Robert Helmer wrote:
>> On Fri, Nov 3, 2017 at 3:25 PM, David Keeler <dkee...@mozilla.com> wrote:
>>> [firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
>>> direct follow-up discussion to dev-platform]
>>>
>>> Hello All,
>>>
>>> As you're no doubt aware, from 57 onwards, only signed WebExtensions
>>> will be available as add-ons for the general release population. My
>>> understanding is these are all packaged as "xpi" files (zip files,
>>> really, but what's important is that they're bundled up as a single file
>>> rather than a directory). Add-on developers can develop their add-ons by
>>> temporarily loading them as unsigned packages or unsigned unbundled
>>> directories (again, if my understanding is correct).
>>>
>>> This leaves the question of what use we have for verifying unbundled
>>> add-ons. Is there ever a case where we want to verify an unbundled yet
>>> signed add-on? For example, do we ever do this with system add-ons? (And
>>> if we do, I've been told this would be bad for performance, so perhaps
>>> we should disallow this?)
>>
>>
>> System add-on updates must be packed into a XPI[1]. Built-in add-ons are 
>> always
>> shipped packed (along with Firefox in the application directory), but
>> unpacked will
>> work for builds so you can modify a file in ./browser/extensions/ and
>> see the change
>> without a rebuild.
>
> I imagine those directories are unsigned when you're doing that work,
> though, right?


Yes.


>> We plan to move built-in add-ons into the omni jar eventually (bug 1357205)
>>
>>
>>>
>>> Thanks,
>>> David
>>>
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>
>> 1 - 
>> http://searchfox.org/mozilla-central/rev/af86a58b157fbed26b0e86fcd81f1b421e80e60a/toolkit/mozapps/extensions/internal/XPIProvider.jsm#6561
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: verifying unpacked signed add-ons

[Robert Helmer]

On Fri, Nov 3, 2017 at 3:25 PM, David Keeler  wrote:
> [firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
> direct follow-up discussion to dev-platform]
>
> Hello All,
>
> As you're no doubt aware, from 57 onwards, only signed WebExtensions
> will be available as add-ons for the general release population. My
> understanding is these are all packaged as "xpi" files (zip files,
> really, but what's important is that they're bundled up as a single file
> rather than a directory). Add-on developers can develop their add-ons by
> temporarily loading them as unsigned packages or unsigned unbundled
> directories (again, if my understanding is correct).
>
> This leaves the question of what use we have for verifying unbundled
> add-ons. Is there ever a case where we want to verify an unbundled yet
> signed add-on? For example, do we ever do this with system add-ons? (And
> if we do, I've been told this would be bad for performance, so perhaps
> we should disallow this?)


System add-on updates must be packed into a XPI[1]. Built-in add-ons are always
shipped packed (along with Firefox in the application directory), but
unpacked will
work for builds so you can modify a file in ./browser/extensions/ and
see the change
without a rebuild.

We plan to move built-in add-ons into the omni jar eventually (bug 1357205)


>
> Thanks,
> David
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>

1 - 
http://searchfox.org/mozilla-central/rev/af86a58b157fbed26b0e86fcd81f1b421e80e60a/toolkit/mozapps/extensions/internal/XPIProvider.jsm#6561
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

intent to remove: standalone about:addons UI and tests

[Robert Helmer]

Currently we support running the about:addons UI in both a standalone
window, and also in a browser tab.

Firefox has only used the latter for many years, but we've continued
to maintain tests for both, which increases both our maintenance
burden and also the time it takes tests to run.

This removal is being tracked in bug 1349723.


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

Re: What are your use cases for the Touch Bar on the new MacBook Pro?

[Robert Helmer]

+1 on doing WebExt APIs in parallel - this can be done outside of
mozilla-central on non-release channels using WebExtension Experiments
(https://webextensions-experiments.readthedocs.io)

Once the implementation in mozilla-central is settled down, the
experimental API can be merged.

On Tue, Jan 3, 2017 at 6:38 PM, Stephen A Pohl  wrote:
> I can see the advantage of addons exploring and iterating on this, but
> making the first version of this API addon-accessible might
> unnecessarily delay it. If there is enough interest in this, we might
> want to start this effort in parallel and release it in a subsequent
> version.
>
> On 1/3/17 4:31 PM, Ryan VanderMeulen wrote:
>> Will this API be accessible to addons? Seems like this would be a good
>> place for people to explore and iterate.
>>
>> On 1/3/2017 12:17 PM, Stephen A Pohl wrote:
>>> We will develop[1] a solid 1.0 API around the top features to get the
>>> ball rolling and will iterate on these going forward.
>> ___
>> 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

symbolapi downtime tomorrow noon PST (2015-03-04)

[Robert Helmer]

Hello,

Per bug 1077633 we are taking symbolapi.m.o (used by the Gecko
Profiler to do symbolication) down for preventative maintenance
tomorrow at noon PST. Expected downtime is 1 hour.


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

symbol server (symbols.m.o) moved

[Robert Helmer]

Hello,


We're now hosting symbols in S3, and have just completed the
transition of the Mozilla symbol server (http://symbols.mozilla.org)
in bug 1097209.

If you use this service and notice any problems, please file a bug in
Socorro::Infra (or just let me know)


Thanks!
Rob Helmer
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tool for generation of regression-range links

[Robert Helmer]

On Tue, Oct 14, 2014 at 8:48 AM, Gregory Szorc g...@mozilla.com wrote:
 On 10/13/14 12:17 PM, Benjamin Smedberg wrote:

 tl;dr: I have a tool for generating regression-range links from
 buildids. http://bsmedberg.github.io/firefox-regression-range-finder/

 Often times when we're investigating regressions (crashes, etc), we have
 the build ID of the nightly where the regression started. But it's not
 the easiest thing in the world to turn that into an actual pushlog link
 which lists the commits in the regression range.

 To help fix this, I've created a tool that lets you paste in a buildid
 or two and automatically figures out the proper regression range link,
 and also links you to the nightly build directories.

 This tool is pretty hacky: it loads http://ftp.mozilla.org directory
 listings to find builds, and then loads the .txt files describing the
 revisions involved. If we ever changed webserver for ftp.mozilla.org the
 tool would likely break. But since it's something I do at least once a
 week and I know other QA people do this even more regularly, I figured
 it was worth automating.

 Right now the tool uses ES6 features `let` and `for...of` and so it only
 works in Firefox and not in Chrome. I figured for this audience that
 wouldn't be a problem.


 FWIW, Robert Helmer wrote a tool for scraping the FTP server, storing the
 relevant bits in a database, and exposing the result via HTTP+JSON. It used
 to run on Mozilla's Stackato deployment, but he turned off his instance for
 reasons I can't recall. The service was really useful: someone should look
 into deploying this again.

 https://github.com/rhelmer/releases-api/


The code for this was pulled out of Socorro and modified to run as a
standalone service, the reasons I decided not to go forward at that
time were:

1) the code in Socorro was undergoing big changes and it was hard to
keep in sync
2) I'd rather work with releng to expose this in a more direct way

My plan at the time was to move Socorro over to using this service too
(so point 1 would be moot) but I didn't have time to pull it off right
then.

I am ambivalent about the second point, we could probably put up a
REST API that scrapes FTP now and change the way it works internally
later without breaking the API.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform