This is just a short note about how I solved a weird problem I recently experienced when window.open wouldn't work using Ionic/Angular with Cordova under iOS (9).

It's about having trouble to get window.open actually opening a window, not within current view, nor within new in-app-browser or external browser window. And it is related to using Cordova plugins, especially inAppBrowser, and having a CSP (Content-Security-Policy) defined with the main HTML file.

Searching on e.g. stackoverflow I wasn't able to find someone describing the very same problem and it was hard to find articles that brought me on the right path. Took me some time to debug stuff. So, I'm pretty sure there must be others out there who're facing the same problem I want to describe as concise as possible:

Scenario & Objective

A controller function (available through $scope) is defined as a ng-click attributes` value as:

<a ng-click="openTerms()">Terms & Conditions</a>

The function should open a new in-app-browser window and is defined within an angular controller like this:

$scope.openTerms = function() {
   window.open('http://www.example.com/terms', '_self', 'location=yes');
}

Effect

It works as expected when tested within a Desktop browser. But nothing happens on click when deployed and tested within the iOS simulator or directly on the device, (more precisely: under iOS 9 in my case). Additional effect I experienced however is that the window unexpectedly opens when the original click is followed by another action taken like clicking on a form field or triggering an internal router navigation step.

Inspecting the Cordova/iOS device logs as well as JavaScript logs shows up entries that caught my attention to investigate on it:

cordova.js: xxxx deviceready has not fired after 5 seconds 

In my case there was also another entry telling that Ionic was 'not ready' due to incomplete loading of plugins.

When having a close look on the JavaScript console I discovered log entries complaining that the Content-Security-Policy denies access to resources under the URL scheme gap://.

Solution

Adjust your Content-Security-Policy to allow accessing resources for gap::

<meta http-equiv="Content-Security-Policy" content="
    default-src
       'self' 
       gap:
       ...
    ...
">

Background & Conclusion

The gap scheme is Cordova specific, it enables JS <-> native communications for iOS. A missing CSP entry somehow prevents the plugins from loading fully or correctly.

Strange enough, using Ionic and Cordova examples extensively, there hasn't been a single example template nor note about not to forget the famous gap url scheme entry...

So, to be honest: I'm not sure about the exact root causes and it's still confusing me. But I haven't got enough time to spend more time on investigating on every single strange behavior or effect. This article just describes my specific scenario and how I successfully solved it.

If you want to dive deeper into the details of Cordova and Content-Security-Policies under iOS, you might want to check an in-depth article about it.

Hope to help others with it!

Are you using Parallels Plesk with postfix, configured a domain for which E-Mail is handled on a foreign MX host and wonder why E-Mails created on that system (e.g. through PHP form mailer scripts) vanish and won't be transported to their destination? Yes? Then read on.

Oh dear, though Parallels Plesk greatly improved in a lot of aspects over the years, there're some bugs that seem to be "built in", like being a feature rather than a bug. But: If you start googling and searching for solutions you'll find a lot of (old) discussions, all referring to more ore less the same problem but hardly any of them giving helpful hints. I'll try to provide a straight description and solution for that specific situation and Plesk bug.

Versions affected

I faced the behavior described below years ago with older Plesk versions but today struggled with it again. My currently used and affected version is Plesk Panel 11.5.30 (at least until micro-update #35).

Situation

Let's assume you configured a domain, we name it test.com, within Plesk panel to be used for e.g. website hosting. For whatever reason on initial domain setup you've chosen to activate "E-Mail service" for that domain. But you'd configure neither E-Mail addresses nor mailboxes for that domain. You probably also don't need to configure DNS for that domain because that's done elsewhere - like the whole E-Mail (MX) stuff.

Problem

E-Mails to recipients within test.com that are generated on your Plesk host won't get transported to the correct (publicly configured MX) host. Example: E-Mails generated by a PHP form mailer script sent to info@test.com get lost. You probably register some kind of log entry in /opt/psa/var/log/maillog telling you Message aborted.

Reason...

Postfix (MTA used by Plesk) is configured with entries for test.com in the virtual_domains database. That means: Before evaluating any other way of transport, the local mail transfer agent, i.e. postfix, decides to deliver this E-Mail locally. And this is deadly wrong in our case.

... and the actual Plesk Bug

First idea is of course to uncheck "Activate E-Mail Service" in your Plesk Panels configuration page for E-Mail settings (Panel path: ... / test.com / E-Mail / E-Mail Settings). And then, your next E-Mail to info@test.com generated on that host ...fails again! Here's the specific Plesk bug: postfix virtual_domains (+ virtual) database entries are never cleaned up after "E-Mail Service" was activated once for a specific domain - even if you later deactivate this option in your Plesk domain setup configuration.

Solution

Use the shell. Find the postfix database (hash) files. Search and modify the virtual_domains as well as virtual database files using postmap. Be careful, you've been warned! But things are pretty straight forward:

$ cd /var/spool/postfix/plesk
$ postmap -s virtual_domains | grep "test.com"
test.com    test.com/
$ postmap -d test.com virtual_domains

Basically, that's it! When working with the Plesk Panel, be sure not to check "Activate E-Mail" for test.com again and you should be fine. Now, while next is not mandatory to restore desired behavior, you should also cleanup your virtual database defining user E-Mail alias addresses. Those were also automatically generated by Plesk on initial domain "Mail Service" setup. Check the entries, it will probably look something like this:

$ postmap -s virtual | grep "test.com"
postmaster@test.com    postmaster@localhost.localdomain
root@test.com    root@localhost.localdomain
mailer-daemon@test.com    mailer-daemon@localhost.localdomain
anonymous@test.com    anonymous@localhost.localdomain
drweb@test.com    drweb@localhost.localdomain

Go, take your time and delete the unwanted entries, step by step:

$ postmap -d postmaster@test.com virtual
$ postmap -d root@test.com virtual
...

Hope that was helpful for some of you guys out there. Now I'll go and submit a bug report at Parallels.