My first dance with Cordova + Ionic + Crosswalk + LiveReload… WHITE SCREEN! THINGS BROKE!

tl;dr – Since I am apparently a long winded such-in-such (ex: even my tldr is too long)… If you’re having white screen issues with Ionic + Crosswalk + LiveReload after introducing Crosswalk to your working project, here’s the updated process for introducing Crosswalk to your ionic project:

npm install ionic -g
cd MySupaAwesomeApp
ionic browser add crosswalk
ionic plugin add
ionic run -lcs android

Special note: This is just a work around – this is projected to be ‘fixed’ in the very near future.. 

First, who (of my imaginary readers (I see the traffic numbers)) knows what framework I’ve been using a lot lately?

Give up?

The supa-awesome one, The Ionic Framework.

Being the frequent deliverer of new and cool things related to the Cordova / Ionic Framework scene that they are, we were recently officially introduced to Crosswalk via their January blogpost ‘Crosswalk Comes to Ionic‘.

Being neck deep in other project related todos and still really just learning my way, I can’t say that I read much into the announcement… I knew the bullet points –  I knew that Crosswalk would likely equate to a ‘problem solved for me’ down the road and I knew that I’d have to learn about it when I got down the road…

Admittedly, I didn’t exactly grok how big of a ‘deal’ this ‘problem’ was – for those who also don’t, we’re talking more or less about “an identical application across all <4.4 devices”.. While not ‘as big of a deal’ with native apps (since you kind of just get that), it actually is kind of a big deal when dealing with hybrid applications…  On pre Android 4.4 devices, you’re talking about your app’s rendering engine varying from handset to handset, generally based on the manufacturer’s widely differing preference or implementations for the default Android web browser – Crosswalk removes this widely ranged variable out of your equation and gives you a browser engine based off of various, specific releases of Chromium/Blink.

Well…  As you likely have guessed… ‘Down the road’ arrived…  Time came… I had to learn Crosswalk…  Fortunately, in typical fashion, the Ionic blog post provided an at-the-time working code samples for adding Crosswalk to a new project or an existing project…

I’ll take just a second to toot their horn for them right now – this is something that they really shine at and deserve kudos for… The Ionic Framework team strives to not only inform you of what they’ve added, but to provide you with working code to try out the feature being discussed for yourself – then and there…  Not ‘embedded in a library somewhere on github for you to find‘ code, but ‘copy/paste this‘ code…  A lot of projects don’t do this… And it’s super awesome and greatly appreciated when a project of this size makes the effort.

So… We realized that we *need* <4.4 support and that we don’t have it out of the box – cross device compatibility testing made this crystal clear for us…  I begin tackling adding Crosswalk to our projects… After reading along and pecking in the provided code snippets, I fired off my beloved “ionic run -lcs android” command… As expected, I was greeted with a worki….


No. Not a working app…  A white screen – no application loading screen, no remote debugging via Chrome/Chromium, just a shell of an ionic project (viewing in remote debugging mode) without any actual project resources being loaded…

Mind you: this was just working… I’d been working in the app all day without any issue resembling something like this up until moments ago…

I’ve probably messed something up.. I bet if I redo the tutorial, real careful like, that it will work...”

I remove Crosswalk and revert back to the default Android browser… (for brevity (HAHAHAAA… ‘brevity’ from me?! Pffff.) sake, I will link to another issue related to this that we will pretend, in the context of this post, didn’t happen)…

I test the app again – gravy and working mostly as designed (exactly as coded 😉 )… Things are looking good again – I’m happy to see my UI again, no matter how ugly it may be…

“Alright, now we’re back on track”, I think to myself.. Re-add Crosswalk – check… Run ‘ionic run -lcs android -t mylegacydeviceid’… App building… good… App installing… good… App running… goooooo…. Noooooo!!!!! WHITE SCREEN!!!!

“This is a huge feature and someone has documented the solution already for me”, I thought… Queue lots of Googling and tail chasing…

Unfortunately, all of my Googling of “stupid things and stuff don’t work crosswalk ionic live reload” yielded little of value…

Accepting my fate -that I must (*gasp*) communicate on the Internets with strangers- I started posting in the Ionic Forums…

*TOOT* Imma do it again… One of the cool things about working with the Ionic Framework as of late hasn’t just been the official team providing a great support infrastructure, but the community doing so as well… Seriously.. I’ve worked with a handful of open source projects over the years, and while a lot are very friendly and helpful, some are very much not friendly nor very helpful – often responding to opened issues or forum posts with something akin to “you fix it.”  (seriously – I was previously told that it was “my responsibility” to fix a project which I was not involved with previously and then I was told to “drop the attitude” when I indicated such…)…  We all have bad days, so I won’t harp on it – especially since it was a project that I **love** and use daily now.


So I started doing the whole “talking to people” thing to see if it would get me anywhere… In typical-of-the-Ionic-community fashion, it wasn’t long before I had some responses – many sharing their similar pains and others providing pointers on where to look…  Then a kind soul by the name of thebosz came along with the missing awesomesauce – that the Cordova project had decided recently to split out the whitelist functionality into a plugin of its own and so you needed to manually add it to your Ionic project via “ionic plugin add” for the time being.


There you have it:

ionic plugin add

You’re still here?  Ok.. I will keep going…

As you may or may not know, the whitelist stuff lies very much central to a lot of the features which I and many of you love and are dependent on within the Ionic Framework – and so it being plucked from ‘core Cordova’ “broke” a lot of things previously working in Ionic.

I won’t go too deeply into things that I only understand superficially, but as I’ve gathered, Crosswalk requires a later release of Cordova than Ionic normally uses when you generate a project (3.7.1 at the time of this writing).  When adding Crosswalk to a project, Ionic actually grabs a special 4.0.0+ fork of Cordova that they’re currently maintaining…

Someone closer to the source would have to speak in specifics about how/when the disconnect happened, but apparently the whitelist-removed-version of Cordova made it into the Ionic fork some time after the ‘Crosswalk Comes to Ionic‘ post was published (disclaimer: this is just a guess of mine, so someone please correct me if wrong)…  People, such as myself, were left scratching their heads after following the blog instructions and then attempting to resume their normal, LiveReload-centric, development process… Now running the beloved “ionic run -lcs android” command resulted in the previously working application simply displaying a white screen instead of the app’s UI (with no debugging info making it to any consoles).

No Bueno.

Thankfully, as is normally the case with the Ionic Ecosystem, the Ionic Team took notice of the activity pretty quickly and have been sharing the work around while waiting on the Whitelist Plugin to make its way into the official Cordova repos – at which time it will be automatically handled by Ionic CLI and so no longer an issue…  You can now find the amended directions in the linked ‘Crosswalk Comes to Ionic’ blog post…  It’s also scattered throughout the forum and github repos now and so turning up more in Google searches on issue a lot more as of late…

Muy Bueno!

Again, as mentioned in the too long tl;dr, this is a temporary work around and likely won’t be required for very much longer.. In all likelihood, this issue will be resolved very soon – once the Whitelist plugin makes its way into the official Cordova plugin repository, Ionic CLI will most likely be updated to pull this new plugin dependency automatically during generation/upgrade processes….

Just wanted to debrief and share in the case that it helped anyone else!


Ionic – CORS with Live Reload Part 2

Hello again, reader.

I wanted to follow up (better late than never, right?!) on my previous post regarding CORS issues encountered while working with the Ionic Framework’s –livereload feature.

If you’re reading this, then you likely already know that some interesting things can happen when using the Live Reload (–livereload / -l) features of Ionic… Namely:

XMLHttpRequest cannot load
No 'Access-Control-Allow-Origin' header is present
on the requested resource. Origin ''
is therefore not allowed access.

As you may very well be aware, generally speaking, resources external to a Ionic/Corodova project are whitelisted in the project’s config.xml via an ‘access’ element possessing an origin property having a value of ‘*’. This is so that you can consume external resources, such as an API.

As a result of how Live Reload currently works, this origin policy has to be updated while using –livereload – where it’s changed to the URL of your live reload server (generally an http://local_ip:port variety) when you kick off the “ionic run -lcs android’ (or whatever) command.

Due to the changes of the project and perhaps due to the way the livereload does the magic that it does (I admittedly have a high level understanding of this system, as I’ve not had time to dig in too deeply), many users have ran up against CORS issues when developing/debugging using –livereload.

While I’d previously read on proxy configuration in Ionic, it hadn’t quite clicked in relation to this issue until a helpful github user spelled it out using crayon fonts for me. Here is the response that I am referring to:

Essentially, as Yonn-Trimoreau has spelled out, you can configure a proxy in your ionic.project file that will proxy your external resource requests ‘locally’, effectively eliminating CORS issues while working with –livereload…

Here is an example of this configuration (ionic.project file) for 2 proxies:

 "name": "MyProject",
  "app_id": "",
  "gulpStartupTasks": [
  "watchPatterns": [
  "proxies": [
      "path"    : "/remoteAPI",
      "proxyUrl": ""
      "path"    : "/localAPI",
      "proxyUrl": ""

As you’ve likely inferred, after adding the proxy configuration to your project, you will be enabled to call external resources as if they are local – “/remoteAPI” and “/localAPI” in the case of this example.

Quite useful when developing against multiple APIs or when using Live Reload in general.


Ionic – CORS with Live Reload

File this one under ‘lessons learned from hours spent chasing my tail’.

Recently, I’ve been working quite a bit with the Ionic Framework… While I can’t say that I was initially on board for the whole ‘hybrid app’ approach for mobile development, I’ve really grown to love the stack and find it fun to work in. Fun development aside, this isn’t to say that the stack (like any stack) is without its issues – for me currently, it’s the undocumented (or the only-documented-in-a-github-issue) gotchas that can create the largest headaches, as they can often result in an hour or two of tail-chasing.

As you’ve likely gathered from this post’s title, the most recent fun on this front was trying to chase down a CORS issue when testing a tablet application that I am currently writing. In this application, we’ve opted for custom auth headers – adding which caused the CORS issues to rear their ugly head…  In my case, it was specifically issues with Access-Control-Allow-Headers.

“No big deal – Cordova/Phonegap whitelists all domains, so you’re good to go”, right?  As is often the case, “no big deal” can be filed under the category of “famous last words” here…

Not previously known to me, apparently using -l(/livereload) causes a modification to the config.xml at runtime for that build – a modification that removes the ‘*’ whitelisting, which can result in banging your head against CORS issues when interfacing with a REST service during development using livereload…

For the skinny, check out the github issue discussing this –

Unfortunately, Googling for “Ionic CORS” will provide you with a lot of noise that can result in some tail chasing as you start following suggestions to delete client side default headers or researching server-side solutions to mask the problem… Googling for “livereload CORS” however will take you to some relevant information via Grunt livereload Server discussions.

In the end, it was just easiest to configure my development web server to allow the CORS operations, as I wanted to keep Live Reload capabilities with the least amount of fuss. There are some client side things that you can do (discussed in the linked thread), but as you will find, those are temporary and will need to be done over and over as you develop… I’ve also read some mention of configuring a Grunt proxy server to proxy these requests ‘locally’, but I’ve not been able to investigate that approach, so I can’t really speak to it, though I’d love to get some input on this approach if any readers have any…

Anywhos… I just wanted to put this out there in case “Ionic CORS” led anyone else on a wild goose chase.

Happy Developing!