We noticed an issue with an application we are writing and I'm relatively sure that I've pinpointed the issue.

If JavaScript is being run in a window which is then hidden, at the point at which it is hidden requestAnimationFrame stops working. The API docs do not describe what the expected behaviour of this is or whether it is being backgrounded, however I suspect it is and understand that the default behaviour of most browsers is:

requestAnimationFrame() calls are paused in most browsers when running in background tabs or hidden <iframe>s in order to improve performance and battery life.

Presumably window#hide backgrounds a Window. Is that why requestAnimationFrames callback is never executed? Our application has been written so that it runs JavaScript in one window but renders into another, and currently the behaviour seems to mean that it will be impossible to use any libraries which use requestAnimationFrame (e.g. React 16). Ideally, we would like to be able to continue to do this, but ensure that the background is not throttled at all and that requestAnimationFrame still runs normally.

I notice that internally you are setting backgroundThrottling: false and we are not overriding this flag. I thought this was meant to ensure that setTimeout and setInterval are not slowed down and that requestAnimationFrame is still called.

I know you are loosely based on electron and hence share some of the same configuration. In fact, I think you have the same bug that Electron seems to have! I also found this related issue - maybe this implies that enabling requestAnimationFrame was never supported on hidden/backgrounded Windows?

What should the expected behaviour be? Is this broken? Will you fix it? Or will you consider this a feature request?

As you probably realise requestAnimationFrame is used frequently in modern libraries - for example, the new React reconciler Fiber makes frequent use of it (and I believe Angular uses it, too). If this can't be fixed, we will need to completely rethink the architecture that we were thinking of doing (for performance we were considering running the core JavaScript of our application in a hidden window while then rendering to multiple child windows).

Hi there,

I'm following the build instructions on the README, but I get the error mentioned on the title; below the steps to reproduce, output and environment specs; full logs are available on https://gist.github.com/maoo/20fc62e6af91d58d94d0ea4dff887feb

Thanks!

Steps to reproduce

git clone https://github.com/HadoukenIO/core.git
cd core
npm install

Error

Error: TypeError: _.foldl is not a function
Warning: Task "ts:default" failed. Use --force to continue.

Aborted due to warnings.
npm ERR! code ELIFECYCLE
npm ERR! errno 3
npm ERR! [email protected] postinstall: `grunt`
npm ERR! Exit status 3
npm ERR!
npm ERR! Failed at the [email protected] postinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/m/.npm/_logs/2017-11-22T14_12_32_564Z-debug.log
------------------------------------------------------------

Environment

• macOS High Sierra, 10.13.1
• npm -v, no5.4.2
• node -v, v8.3.0

Hi,

Does openfin support background file download like in electron? Without invoking SaveAs dialog

const { BrowserWindow } = require('electron')
let win = new BrowserWindow({ width: 800, height: 600 })

win.webContents.downloadURL('hello.pdf')

I see no mention within the openfin documentation of tools like React DevTools and Redux DevTools. These types of tools are extremely useful for debugging modern applications. Has there been any thought into first-class support for them to improve the developer experience?

You could look into an approach like the one found in electron-devtools-installer as this might help you in coming up with a good approach for the feature.

As it stands I have to build/use standalone versions of the tools which isn't ideal.

Sorry, if I'm not meant to ask this here, but you've open-sourced so it felt like fair game! :)

Api to retrieve desktop owner settings for services

RUN-5112

The goal is for services to be able to retrieve desktop owner level settings. Much of the details surrounding what these look like can be found here.

The proposed API would be added to the v2 System namespace as:

fin.System.getServiceConfiguration({name: 'whatever'})
    .then(conf => {
        conf.name               //=> whatever
        conf.appDirectoryHost   //=> https://app-directory.openfin.co
        conf.manifestUrl        //=> https://example.org/services/whatever/app.json
        conf.config             //=> {service specific json blob}
    })
    .catch(err => {/* xyz service is not configured in desktop owner settings file... */})

Do we care about which app directory it was fetched from here (appDirectoryHost)?

This assumes that service configurations are not "private" per se, meaning that any app can get any service configuration. To restrict this info to just the service itself we would need some work provide apps with the concept of being a service and an identity as such.

I think that there is a larger conversation around service discovery and the apps themselves actually knowing that they are being launched as services that needs more discussion.

Removing the commercial source as recommended results in a broken
build system.

It isn't clear from Hadouken.io or OpenFin resources which components
are open, and which are commercial. It is also unclear which subset of
the project is Hadouken, and which are OpenFin. The open and commercial
source are entangled and interdependent.

Removing commercial source from the core project would resolve any doubt and
encourage contributions.

Hey,

I've noticed that right-clicking in DevTools in Openfin v6 doesn't seem to work. Was that a conscious decision, or a regression from v5?

Issue:
When an application is hidden using the tray icon, core notifications take 5 seconds longer to show than they normally do.

How to reproduce:

• Create an application (#1) with a tray icon.
• Put an element on the DOM, and attach an click listener to it that hides the window.
• Attach the same listener to the tray icon on click.
• Create a separate application that sends an InterAppBus message to Application 1.
• When Application 1 receives that message, have it create an OpenFin Notification.
• Compare the time it takes to show the notification.

When you hide the window using the DOM Element click handler, notifications show up normally. However, if you hide the window using the tray icon, it takes significantly longer to show.

In verbose logs, take a look at the time elapsed between the create-notification and show-window actions. There is a 5 second delay between the events if you hide using the tray icon. If you hide using the DOM element, the difference is less than a second.

Given a UUID/window name pair, there currently isn't any simple way to check if the window exists. Only options are System.getAllWIndows, Application.getChildWindows, or Window.wrap - then test an API for success.

Would be very nice if we had something like Application.hasWindow(name); and/or System.hasWindow(uuid, name);