Re: How can I run Firefox programatically in fullscreen?

[Michael Cooper]

I'm not sure this is quite what you're looking for, but for Corsica (the
software powering the ambient displays around the office) we do this by
setting the pref full-screen-api.allow-trusted-requests-only to false. This
then allows the webpage we load (Corsica) to immediately request full
screen using the normal DOM methods.

On Mon, Jun 26, 2017 at 2:12 PM, Armen Zambrano Gasparnian <
arme...@mozilla.com> wrote:

> Asking around, looking on dxr or MDN did not yield something easily.
>
> I don't want to have to use Marionette in this specific automation context.
>
> Thanks in advance,
> Armen
> ___
> 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: nodejs for extensions ?

[Michael Cooper]

If you mean using modules from NPM in a browser add-on, the Shield client
extension recently started doing this <
https://github.com/mozilla/normandy/tree/master/recipe-client-addon>

We do this by using webpack to process the node modules, bundling the
entire dependency tree of a library into a single file. We then add a few
more bits to make the resulting file compatible with `Chrome.utils.import`.
You can see the webpack config file here <
https://github.com/mozilla/normandy/blob/master/recipe-client-addon/webpack.config.js>
and the way we use the resulting files here <
https://github.com/mozilla/normandy/blob/48a446cab33d3b261b87c3d509964987e044289d/recipe-client-addon/lib/FilterExpressions.jsm#L12
>

We suspect that this approach won't be compatible with all Node libraries,
because it is fairly naive. But it has worked well for the ones we've used
(React, ReactDOM, ajv, and mozjexl, so far).

On Fri, Jul 28, 2017 at 10:13 PM Myk Melez  wrote:

> > Enrico Weigelt, metux IT consult 
> > 2017 July 28 at 21:33
> > Hi folks,
> >
> >
> > just curious: did anyone already try nodejs modules
> > for (javascript-only) extensions ?
> There was some discussion of this in the dev-addons thread "Node and Web
> Extensions Experiment"
> .
> We also discussed a related idea in the firefox-dev thread "SpiderNode
> for Firefox chrome code"
> <
> https://groups.google.com/forum/#!topic/firefox-dev/MWE-_1xkokk/discussion
> >.
>
> -myk
>
> ___
> 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: Running different instances of Firefox side-by-side

[Michael Cooper]

On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend 
wrote:

> Woah this email got long. How Firefox considers whether to pass off to an
> existing instance of Firefox or continue launching a new one turns out to
> be more complex than you might expect. I'm mostly interested in making
> folks aware of and giving feedback on how this works after I've changed
> some things so feel free to jump down there. But I figured some folks might
> find some context in how things work currently. For that, read on!
>
> One of the goals of pushing to a profile-per-install model for Firefox is
> allowing users to run different versions of Firefox side-by-side without
> the additional hassle of editing shortcut files or running from the command
> line. This has meant changing the "remoting" code, which searches for
> existing instances of Firefox and passes command line arguments to them
> instead of starting up normally. I landed the changes to this a couple of
> days ago and I thought it was worthwhile explaining what has changed since
> it might not be exactly what you expect. And if that is the case figure out
> whether it makes sense to make any changes.
>
> *So first, a quick recap of what remoting has done in the past, because it
> varies from platform to platform...*
>
> OSX is the easy case. Firefox doesn't handle remoting at all. OSX does it
> all, assuming you are running Firefox by running an app bundle or a dock
> icon. OSX sees that an existing Firefox is running and just sends it a
> message, a new Firefox instance doesn't even start. I've made no changes
> here.
>
> Windows is the slightly more complex case. When run Firefox attempts to
> find an already running Firefox. If one exists it passes its command line
> off to it and quits. The -no-remote command line argument is a way to
> bypass this behaviour, running with it will stop the new Firefox from
> attempting to find an existing instance or becoming and instance that can
> be found by other instances. Basically there can only be one Firefox open
> that can be found by future invocations. The -new-instance command line
> argument is parsed on Windows ... and then ignored.
>
> Finally there is Linux. The more exciting case. Unless -no-remote or
> -new-instance are passed on startup linux will search for an existing
> version of Firefox based on a few criteria .. which varies a little
> depending on whether we're using dbus remoting or X remoting. We use X
> remoting if we are using X11 windows, and dbus if not (and dbus is
> supported). In both cases on startup Firefox attempts to find an existing
> instance of Firefox with the same remoting name (or you can provide a
> different remoting name with -a on the command line). dev-edition has one
> remoting name, all other versions of firefox have a different one. If there
> is more than one .. which one wins seems undefined. You can additionally
> pass "-P " in which case Firefox will only select an existing
> instance running the named profile. On X remoting there are a few extras.
> Passing "-a any" on the command line will find any running Firefox
> regardless of remoting name. Passing "-u " will consider
> Firefoxen run by the given user (otherwise it only looks at those run by
> the current user). -no-remote means FIrefox doesn't register itself to be
> found by future instances. -no-remote or -new-instance means we don't look
> for existing instances on startup.
>
> So that's all rather complicated. To make matters more fun the linux and
> windows implementations are handled by totally separate code running at
> different times during startup. The two key problems here were that windows
> completely didn't support more than one instance running, unless all but
> one were -no-remote, and linux was horribly complex and again unless you
> ran with command line arguments didn't support more than one Firefox at a
> time. We wanted something that allowed running Firefox release and Firefox
> beta and Firefox nightly with no special arguments at the same time.
>
> So I have done three things. Removed support for some of the things Linux
> supported. Made the code a lot more shared between windows and linux so
> things happen at the same time regardless of platform and both platform
> have what should be identical behaviours. Changed the order of when some
> things happen.
>
> What did I remove? Support for remoting to a different remoting name and a
> different user. Both seem unlikely to be useful for normal use cases, the
> latter frankly feels like a security risk.
>
> *How does it all work now?*
>
> OSX hasn't changed, maybe we'll want to do some changes here, but for now
> it already allows running different versions of Firefox so long as they are
> using different profiles, which is the default. So for the rest of this
> assume I'm talking about Linux (dbus or x11) and Windows. They all should
> behave the same.
>
> The new remoting does everything based on profile. When starting Firefox we
> do normal pro

Re: Running different instances of Firefox side-by-side

[Michael Cooper]

While composing this, I accidentally sent a blank message. Sorry about that.

Thanks for writing this up Dave, it is really interesting to know how this
is changing. It also explains what I thought was a bug the last few days. I
have the profile manager enabled for every startup. In the past, getting
the "choose a profile" modal on Linux always meant that remoting had failed
for some reason. So when I started getting it when clicking links in
external apps, I assumed that is what happened, closed the profile chooser,
and copy/pasted the link over. In other words, I was in fact confused by
this new behavior, since it looked similar to old buggy behavior.

Now that I know what's going on, it makes a lot of sense, and in fact I
really like being able to choose a profile to start in. On the other hand,
since it looks very similar to a buggy behavior, it was pretty easy to
assume it was bugged. Perhaps the profile manager could explain that it
will try and find an existing profile and remote in to it?

On Mon, Mar 11, 2019 at 12:19 PM Michael Cooper  wrote:

>
>
> On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend 
> wrote:
>
>> Woah this email got long. How Firefox considers whether to pass off to an
>> existing instance of Firefox or continue launching a new one turns out to
>> be more complex than you might expect. I'm mostly interested in making
>> folks aware of and giving feedback on how this works after I've changed
>> some things so feel free to jump down there. But I figured some folks
>> might
>> find some context in how things work currently. For that, read on!
>>
>> One of the goals of pushing to a profile-per-install model for Firefox is
>> allowing users to run different versions of Firefox side-by-side without
>> the additional hassle of editing shortcut files or running from the
>> command
>> line. This has meant changing the "remoting" code, which searches for
>> existing instances of Firefox and passes command line arguments to them
>> instead of starting up normally. I landed the changes to this a couple of
>> days ago and I thought it was worthwhile explaining what has changed since
>> it might not be exactly what you expect. And if that is the case figure
>> out
>> whether it makes sense to make any changes.
>>
>> *So first, a quick recap of what remoting has done in the past, because it
>> varies from platform to platform...*
>>
>> OSX is the easy case. Firefox doesn't handle remoting at all. OSX does it
>> all, assuming you are running Firefox by running an app bundle or a dock
>> icon. OSX sees that an existing Firefox is running and just sends it a
>> message, a new Firefox instance doesn't even start. I've made no changes
>> here.
>>
>> Windows is the slightly more complex case. When run Firefox attempts to
>> find an already running Firefox. If one exists it passes its command line
>> off to it and quits. The -no-remote command line argument is a way to
>> bypass this behaviour, running with it will stop the new Firefox from
>> attempting to find an existing instance or becoming and instance that can
>> be found by other instances. Basically there can only be one Firefox open
>> that can be found by future invocations. The -new-instance command line
>> argument is parsed on Windows ... and then ignored.
>>
>> Finally there is Linux. The more exciting case. Unless -no-remote or
>> -new-instance are passed on startup linux will search for an existing
>> version of Firefox based on a few criteria .. which varies a little
>> depending on whether we're using dbus remoting or X remoting. We use X
>> remoting if we are using X11 windows, and dbus if not (and dbus is
>> supported). In both cases on startup Firefox attempts to find an existing
>> instance of Firefox with the same remoting name (or you can provide a
>> different remoting name with -a on the command line). dev-edition has one
>> remoting name, all other versions of firefox have a different one. If
>> there
>> is more than one .. which one wins seems undefined. You can additionally
>> pass "-P " in which case Firefox will only select an
>> existing
>> instance running the named profile. On X remoting there are a few extras.
>> Passing "-a any" on the command line will find any running Firefox
>> regardless of remoting name. Passing "-u " will consider
>> Firefoxen run by the given user (otherwise it only looks at those run by
>> the current user). -no-remote means FIrefox doesn't register itself to be
>> found by future instances. -no-remote or -new-instance means we don't look
>>

Re: Experimenting with JavaScript type safety in mozilla-central

[Michael Cooper (mythmon)]

>
> I know from the folks talking about types earlier, we're definitely
> interested in other teams adopting some TypeScript comments in their own
> areas of the codebase, so we can gather more feedback. If anyone is
> interested in experimenting, I'd be happy to help guide some initial setup.
>

I'd like to explore adding this to the Normandy code
(toolkit/components/normandy). We already often annotate types via JSDoc
comments, though nothing so strict as what Typescript would want. I expect
the code would be pretty amicable to being strongly typed as well.

On Tue, Nov 12, 2019 at 1:33 PM Greg Tatum  wrote:

> I was getting ready to write up some updates, but was waiting for some of
> my most recent type work to land. I'll go ahead since there is interest. So
> far the experience of working in devtools/client/performance-new [0] has
> been really positive. It's a bit challenging getting the TypeScript module
> system to work with our variants of loaders, but I've made progress to get
> it working in at least one our smaller folder. It will take a broader
> effort to really teach TypeScript about Gecko, but it seems doable, and
> seems like something that could be done as an incremental improvement.
>
> The profiler front-end (which is on GitHub, and is profiler.firefox.com)
> uses a different type system (Flow), and we've really leaned in hard to it
> to trust that our code is working as expected using the type system. We've
> been using Flow there for nearly 3 years. So far, TypeScript seems to be
> able to do most all of the things that we've been relying on in
> profiler.firefox.com, but inside of Gecko. I'm feeling a lot more
> confident making changes to the code, and being able to understand the
> interfaces I'm consuming while writing and reading code. In the next month
> or two we will be heavily refactoring the profiler popup code, so hopefully
> the types will help with that work, and let us move quicker.
>
> Here are things I've gotten types working with:
>
>  * Profiler popup panel
>  * React Component (landing now)
>  * A frame script, and its environment
>  * JSM files
>  * Test files (only locally so far)
>  * DevTools module loading system
>  * Somewhat hacky with Chrome.import, and Cc["module"] style imports.
>
> So far I'm treating the rest of Gecko like it's a foreign world that I
> can't touch. However, it should be possible to make the types work with
> more "modules" in the rest of the codebase. For instance, I could see
> teaching IDL files to spit out TypeScript declaration files and automating
> some of this process.
>
> As for the test runner, right now it's a simple command to run from the
> terminal [1], but we could hook it into a mach command, and integrate it
> with our try services. I did an experiment earlier to demonstrate that this
> was feasible [2]. Right now, I'm mostly relying on in-editor hints, as VS
> Code loads the config files by default, and provides in-editor hints [3]
>
> I know from the folks talking about types earlier, we're definitely
> interested in other teams adopting some TypeScript comments in their own
> areas of the codebase, so we can gather more feedback. If anyone is
> interested in experimenting, I'd be happy to help guide some initial setup.
>
> Next, I believe we are planning on continuing to experiment with real code
> in tree, and evaluate what the next steps look like, e.g. official mach
> runners, and try server integration.
>
> [0]:
> https://searchfox.org/mozilla-central/source/devtools/client/performance-new
> [1]:
> https://github.com/mozilla/gecko-dev/blob/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/client/performance-new/typescript.md
> [2]:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=201f27967c8c6f26c6a4430fb1307478769762f7&searchStr=devtools&selectedJob=266879166
> [3]: https://giphy.com/gifs/VJkwziVsCYGvOGNsv0
>
>
>
>
>
>
>
> On Tue, Nov 12, 2019 at 2:13 PM Andreas Tolfsen  wrote:
>
>> +gtatum
>>
>> Also sprach Dave Townsend:
>>
>> > A first experiment towards understanding this has just landed (
>> > https://hg.mozilla.org/integration/autoland/rev/1dd081553a3a).
>> Specifically
>> > Greg Tatum has added TypeScript  type
>> > annotations and configuration to the JavaScript code in the
>> > devtools/client/performance-new directory.
>>
>> As mconley said, this really is great work!  Any step we can take
>> to make using JavaScript safer should be applauded.
>>
>> We’d be interested in providing stronger type hints in the new
>> remote protocol in development under remote/, as I understand
>> adding types retroactively to existing code can be challenging.
>>
>> > For the time being the perf tools team will just be checking the types
>> > locally before committing. This will give us an idea of the benefits on
>> > real in-tree code without any impact outside of the team.
>>
>> Has any progress been made since to include this in our lint checks?
>>
>> If not, what instructions do