Category Archives: Tips & Tricks

Chrome Rendering Bug

There is a rendering bug in the Google Chrome browser that makes Ryuzine nearly unusable causing pages to display in blocks with some parts missing, some parts of the pages are transparent, and pieces of the User Interface are missing.

Whatever is causing it appears to only be affecting a very, very small number of websites and webapps, Ryuzine being one of them.  The bug has been present in Chrome for at least the last 10 versions.  It’s probably safe to say Google is never going to fix it.  The problem *only* exists in Chrome and the “blink” based Opera browser.  IE, Edge, Firefox, and Safari all render Ryuzine without issues. However, Chrome users represent a not insignificant number of people on the Internet, so at this time we are recommending turning some Ryuzine features OFF in order to better accommodate them.

Our best guess at this point is that layering too many CSS effects on top of each other triggers the problem, as disabling certain effects seems to minimize the problem or make it go away entirely.


  • iScroll – there is an issue with iScroll being “sticky” and for left/right mouse clicks to have become reversed after a recent Chrome update.

A number of other issues with iScroll have also arisen in recent browsers.  Until these are addressed you should disable it in your publications.

In your static Ryuzine publication “Config File” remove those two Add-Ons from the ones being loaded.  In Ryuzine Press you can do this from the Ryuzine Press –> Options –> Add-Ons section, simply uncheck iScroll in the list and Save the settings.

Note: iScroll is a third-party script created by Matteo Spinelli and maintained by  Ryuzine simply supports iScroll integration.  Ryu Maru is not involved in the development of iScroll, and the iScroll developers are not involved in Ryuzine development.

If you still notice problems with Ryuzine rendering, also consider disabling:

  • 3D Page Turns
  • Page Shadows
  • Depth Effects – the added layer of CSS shadows makes the Chrome rendering problem worse.

Ryuzine Version 1.1 is in the works and will completely change how the pages are handled, reducing the number of layered CSS effects, which will hopefully address this problem once and for all.  Until then, please use the work-around above or inform your visitors they should turn off those features themselves after loading your Ryuzine publications.

Ryuzine + Chrome + Mac = System Freeze [FIX!]

There is an issue being experienced by some users of Chrome on Mac OS X when viewing a Ryuzine publication.  What happens is the publication displays with glitchy graphics and any attempt to interact with it will cause the entire screen to glitch and the system to freeze, requiring a hard reset.

This is a known, recurring bug in Google Chrome involving hardware acceleration on some versions of Mac OS X, beginning with Mavericks.  Note that this is not a problem with Ryuzine or exclusive to viewing Ryuzine publications.  Other hardware accelerated web content can also trigger this problem.

Here is the work-around to prevent it from happening in the future:

  1. Type “chrome://settings/” in your browser’s address bar.
  2. Scroll to the bottom and click “Advanced Settings” to expand it.
  3. Find the “System” section and UNCHECK the “Use hardware acceleration when available” if it was already checked or CHECK it if it wasn’t (in other words try it both ways).
  4. Restart Google Chrome
  5. Return to the Ryuzine that crashed your system, it should no longer cause screen freezing.

However, the display of the Ryuzine publication may still be very blocky/glitchy!  This has also been observed in Google Chrome for Android.  Here’s how to fix that:

  1. Open the “Options” panel and look for “Depth FX” in the Add-Ons section.
  2. Make sure the switch is set to “OFF”
  3. If it’s still glitchy turn “Page Shadows” off as well.
  4. If it’s still glitchy turn “3D Page Turns” off too.
  5. The absolute last ditch effort is to turn off “Page Animations” as well.

You may need to change these settings for multiple publications if they are on different domain servers.


Restore Ryuzine Writer Full Screen View

When Ryuzine Writer 1.0 was released the “Maximize/Minimize Editor” button was removed from the toolbar.  This was like the “Fullscreen” or “Distraction Free” modes in various word processors.  It was removed because there were some reflow errors when you’d pop out of that mode that require you to resize the browser window or hide/unhide the sidebars.  Rather than requires people to do this (and know this) the problematic button was removed.

We didn’t actually remove it from the program entirely, just disabled it.  So if you liked it and want it back it’s fairly easy to re-enable it.  It’s actually a Xinha module and you can re-enable it by finding the file in:

ryuzine –> ryuzinewriter –> js –> editor.config.js

Change line 280 to:


That “popupeditor” will add back the view-fullscreen Fullscreen button.  It will be available in both WYSIWYG and HTML Editor modes.  To return from Fullscreen mode press the view-restore Restore button.  However, the Editor workspace may be squished into a narrow band across the center of the window.  If that happens panels Toggle Sidebars off/on or resize the browser window.

Note that the Sidebars no longer automatically toggle off/on when you (respectively) enter/exit Fullscreen mode as they did in earlier versions of Ryuzine Writer.

Ryuzine Press Missing Editions Work-Around

It has come to our attention that the current version of the Ryuzine Press plugin for WordPress will only automatically add the first 10 Ryuzine Press Editions to the plug-in’s Ryuzine Rack (Archive) page.

If you’ve noticed older Editions falling off your Rack/Archive newsstand page the current work-around  is to manually move/copy the “archive-ryuzine.php” file from:

~/wp-content/plugins/ryuzine-press/templates/ => ~/wp-content/themes/[current theme]/

The Ryuzine version 1.0 release is coming soon and will fix this problem, but in the meantime the work-around above will make sure your readers see all the Editions you want them to see.

Ryuzine Edition Cover Art: 3 Methods

As of version Ryuzine Press now has three different ways to create covers for your Editions.

1. Oldest Post

This one is pretty easy.  If you plan to have ALL your Edition covers work this way you go to:

Ryuzine Press > Options > Covers and set “Cover Source” to “Use Oldest Post.”

As the setting implies, the oldest post assigned to the Edition’s Ryuzine Issue(s) will be used as the cover of the Edition.  For regular posts just use the “Add Media” button to place an image to be used as cover art into the post body, assign it to the same Issue as the Edition, and (if necessary) edit the post date to make sure it is the oldest post.

If you are using one of the supported comic plugins that creates its own custom post_type you’d just need to “Add” a new comic and attach your cover art as the Featured/Comic Image for the post.  Again, make sure it is assigned to the same Issue as the Edition and the posting date will make it the “oldest” post.

If you want to over-ride the global setting mentioned above, you can now do so by using a Custom Configuration (it’s in the new section at the bottom of the post editing page for the Edition).


2. Edition Featured Image

If you intend ALL your Edition covers to use this method, go to:

Ryuzine Press > Options > Covers and set “Cover Source” to “Generate Automatically.”


If you also want other things – such as a Masthead Image or a list of “Featured Articles” superimposed on your cover image set those in the Options section named “Splash Screen & Auto-Generated Cover Settings.”  Setting these items is optional, but if you do use them remember they are “global” and will be applied to all Editions that use the default settings.


If you don’t plan to use the shortcode option (covered in the next section) you can also let the plugin know not to even look for it, or in a Edition-specific custom configuration to prefer the Featured Image:


On the post editing page for your Edition scroll down and look for the standard “Featured Image” section.


Click the link to open the Media Manager and select the image you would like to use for the cover art on this Edition.


That’s it!  Now that cover art will show up as the cover of the Edition and as the thumbnail in Ryuzine Rack (or if you are using the regular archive page it will appear in that list).


Again, you can over-ride the Cover settings on a per-Edition basis with the “Custom Configuration” section on the Edition edit page.  Result:


While this is easy, it doesn’t give you much control over how your cover art is displayed within the Edition.  For more control use the next method…

3. Cover Shortcode

Like method two above this one requires that the “Cover Source” is set to “Generate Automatically” but you’ll also need to go down into the “Splash Screen & Auto-Generated cover Settings” and find the item labeled “Cover Image” and make sure it is set to “Use [ryucover] shortcode.”


Now, on the edit page for your Edition, in the main post body section type out the opening and closing shortcodes:

[ryucover] [/ryucover]

Place the cursor in between the two bracketed items and use the “Add Media” button to select your cover art from the Media Manger.  You only need to place the “Medium” size image (do not place the “Thumbnail” since that will be cropped).


Without any parameters the shortcode will embed an image as the cover in the same way as the “Featured Image” method does.  However the shortcode has other options for how to display the image:

Example: [ryucover bleed=”cover” color=”blue” shift=”top left”] [/ryucover]

The “bleed” parameter will set it as a background image using CSS:

0 | null : zero or no value (or omitting “bleed” entirely) embeds the image with the <img> tag.


1 | cover : fits the image, maintaining the aspect ratio, so that it completely covers the entire page container, leaving no white space or border around it (the image may extend beyond either the right or the bottom edges).


2 | contain: fits the image, maintaining the aspect ratio, to the SMALLEST size that will fit BOTH the width and height without allowing any of the image to extend beyond the page container edges – though this will probably leave a white border around the image in one or both directions.


3 | width: centers and scales the image, fitting it by the width so it does not extend beyond the left or right edges of the page container, but may either go beyond the top and/or bottom or may have a white border above/below the image.


4 | height: center and scales the image, fitting it to the height of the page container, but may allow it to extend past the left/right edges or fall short of and leave a white border on the left/right of the image.


Generally “cover” and “width” give the similar results and “contain” and “height” give the similar results – but may render slightly different bordering if they are not an exact fit for the space.

You can also set a background color with the “color” parameter and a valid HEX code (either like #cccccc or #ccc shorthand), HTML color name, or an rgb/rgba color set. If you are using a cover bleed setting that is rendering white bars around your cover art you can set a background color to make it less obvious or to frame your cover art in a more pleasing way.

The “shift” parameter allows you to adjust the positioning of the background image.  The default position is top and center.  You can use either numerical value pairs ( such as “0 0” or words “top left”).  However you can end up shifting parts of the image so they go beyond the edges of the page container:


In the image above the setting was bleed=”height” shift=”center center” which allows the sides of the image to be cropped off. Changing the setting to bleed=”contain” wouldn’t do this.

However you may prefer to put your Ryuzine Press Editions together, we’ve got your covers covered. 😉

Chrome Extension Lockdown

Starting in January 2014 the Google Chrome web browser will no longer support installing Extensions that are not in the Google Chrome Store.  If you have been converting and packing your Ryuzine publications as Chrome Extensions people can download/install from your website you will now need to migrate them to the official Google store.  It does not appear Google will be allowing any way for users to override this installation source restriction.

Full details on the lockdown:

Our tutorial on converting Ryuzine publications into Chrome Extensions:

Note that the actual process of creating, testing, and packaging your extension remains unchanged, only the delivery/install method is being changed.  Also note that if you are only creating “Hosted” extensions there’s really little to no point in making them anymore.  Just let your readers come to your site URL like any other website.


Ryuzine Writer PHP Patch

Note: This patch is included in Build 20131101.01, go to the Help > About screen in Ryuzine Writer to see the build number.  If you don’t see that number your install is outdated.

PHP File Operations fail when Ryuzine Writer is being run from
a server with the latest version of PHP installed.

The PHP files included with Ryuzine Writer utilize a form action
that is no longer supported by PHP. This old method was dropped
because it could expose forms to injection attacks.


Download the Patch and unzip it.

Drag and drop all the files in the /patch folder to:

[Ryuzine PDK location]/DEV/ryuzinewriter/

For example, on our Mac OS X dev system it would be:


And replace/overwrite the PHP files already there.
Reload Ryuzine Writer in your web browser.

If you are still encountering PHP errors try to delete any “tmp” folder
that may be present in your Ryuzine PDK installation and reload the web app
in your web browser.

Patching Previous Versions

  1. Open each of the PHP files in the /ryuzinewriter sub-folder in a plain text or code editor
  2. Find the line with the <form> element (if present)
  3. Change action=“<?php echo $php_self ?>” to action=“”
  4. Save the file
  5. Reload the Ryuzine Writer web app in your browser

ePUB Export Add-On


We now have an experimental ePub Export Add-On for Ryuzine Writer!  You can now also export your Ryuzine publications to ePub 3.0 format with a couple button clicks.  You’ll need at least Ryuzine Writer and the 21KB zip archive with the add-on itself:


Once you’ve got it installed and have PHP File Operations enabled the process goes something like this:

1. Compose or Load a Ryuzine file into the rich-text editor (you don’t even need to “Build” it if you aren’t also creating one in Ryuzine format).
2. Press the [ > ] button and then the [ ePub Export ] button.  The new Workspace loads.
3. Press the “Auto Fill” button to automatically populate the form with information about your publication.
4. Press the “Build” button and wait for a shiny, new ePub file to drop into your downloads folder.

Be aware that this is a version 0.1 “Alpha” release of this Add-On, so there are no guarantees.  Make certain you read the “Known Issues” in the README file bundled with the Add-On.  Files produced with it were tested in Azardi 19, ePubView 1.2, Adobe Digital Editions 1.7.2, and Adobe Digital Editions 2.0 on a Mac.  All of the files produced could be opened, however some would occasionally, randomly crash the latter two Adobe reader apps (still investigating why).  The .epub files produced are unlikely to validate but generally do not contain major errors that prevent them from being opened and read.  Also be aware that rendering of EPUB 3.0 format can vary greatly from one e-reader app or device to another, meaning it is highly unlikely the ePub version of your publication will look exactly like your Ryuzine version.

Got skills and want to help improve it?  We’ve set up a GitHub Repository for this Add-On at: where you may find more recent stable and unstable versions.

UPDATE 2013-10-30 – updated to version 0.2 alpha which fixes a problem with form submission that prevented the add-on from building the epub package on servers running newer versions of PHP.  To update just trash/overwrite your existing file in ~/ryuzinewriter/addons/.

UPDATE 2015-08-30 – updated to version 0.3 alpha which is compatible with the new Add-On API for Ryuzine Writer v1.0.  It is included in the Ryuzine PDK download.

Five Tips for Building Better Ryuzine Publications

One of the cool features of the Ryuzine publishing platform is how you can create a traditional magazine or comic book reading experience through a web browser using nothing more than HTML5, Javascript, and CSS3 technologies.  But the best ways to leverage the format may not be readily apparent.  This article seeks to help you with building better Ryuzine publications that will work for both you and your readers, regardless of what device they prefer to use. Without further ado, here we go!


5. Don’t assume page order dictates the reader’s experience.

When you pick up a physical magazine you probably start at the front, see the Table of Contents, leaf through it, and if you ever do skip around it’s because an article you were reading (which probably broke over more than one consecutive page) was concluded in a column near the back. But you can’t assume that’s how someone will experience your Ryuzine publication (with the possible exception of webcomics, which really only work when experienced in the proper order).

Especially with Ryuzine Press Editions (which exist concurrently as blog posts outside the editions), but also for other publications where a specific page’s bookmark may have been shared, a reader may come into the publication almost anywhere. Ryuzine tries to help people get their bearings by always having a Table of Contents panel available, but you should consider each page of a Ryuzine publication is more like a miniature website unto itself – a sub-section that should only ever spill into another part of the publication if you did so for a reason (in our own sample magazine we show an article that is broken over sections, but the reason is the same as that used in print magazines – to lead readers deeper into the publication and to a page with advertising). As each and every page of a Ryuzine publication is theoretically of infinite length (just like any web page) there really is no technical reason to ever break a story over multiple pages.


4. Don’t go overboard on advertising.

Traditional magazine publishing has long been supported in large part by selling advertising space within the pages. You can place ads on pages in a Ryuzine publication just like you can in a print publication, but Ryuzine also incorporates some built-in web and app advertising options including a mobile style banner, a full-page “splash” ad, and an overlay “box” ad.

But don’t go overboard and make your readers wade through too much advertising to get to your content. The content should be the main focus and only include enough advertising to help cover your expenses in producing it. The ad model is a good fit for online publications given that people are accustomed to things being free (and advertising supported) online, but a site or publication that feels like it is “spamming” people with ads will chase the audience away.

Actually one of the best uses of Ryuzine may be situations where the entire publication itself IS the advertisement. For example using it to create a “sample” of a larger digital publication (perhaps in eBook format) or as an online sample of a print publication. It’s also a great format to adapt organization newsletters (which tend to be short and fast loading content in maybe 8 or 12 pages) or product sales brochures.


3. Don’t just duplicate print content.

If what you want is a digital version that is exactly like an existing print publication you’ll probably be happier with a PDF file. Your readers, however, may not be. Especially if they’re on a phone and have to zoom in and out and pan around just to read it. A Ryuzine publication uses a “responsive” layout that adapts to different screen sizes and allows users to adjust the font size to their personal preference.

You should think about how your publication will look when viewed on small screens and large screens and in both portrait (single page) and landscape (two-page spread) views. The “thisissue.css” file is where you can magically adjust the layout of your content to address the varied viewing scenarios.


2.  Don’t forget the “digital!”

Text and images can obviously be reporduced in a Ryuzine publication just like they can in print. But a Ryuzine publication, by being digital and online, can do things print media can’t. Leveraging the capabilities of the web browser is an important part of creating engaging content that will keep your readers attention, build your audience, and hopefully keep them coming back for more.

You can embed all sorts of “rich content” in a Ryuzine, either in the pages themselves or in the Lightbox Gallery. In fact the whole Lightbox feature was included exactly for this sort of use! Embed a YouTube video, an IFRAME with a linked website displayed in it, VR objects or panoramas, high resolution imagery. There are all sorts of ways you can enhance and expand the “magazine” content with dynamic and enaging WEB content.


1. Avoid running too long.

You’ve probably seen the abbreviation “tl:dr” online. It means “Too Long; Didn’t Read.” Especially on small screen devices a lot of text means a lot of scrolling, but there has long been a bias against presenting a “wall of text” online. Many people find reading on a screen more taxing than reading off of paper, so if you don’t want people to just tune you out don’t go long. They say a picture is worth a thousand words, and online people would rather see pictures on their screens than text. What text is presented is usually just skimmed, so adjust your writing (even consider editing or rewriting) just for your online audience.

Also don’t go too many pages! Nobody really wants to read hundreds of pages online and they want to load hundreds of pages of content even less than they want to read it. A Ryuzine publication is, when stripped of all it’s cool features, a single HTML web page. The entire publication technically exists as a single document and the longer it is the longer it takes to load. If you publication is taking too long to load your readers may think it either has frozen, crashed, or isn’t worth the wait. People online are incredibly impatient! Publications that are more like “newsletters” than a “compendium” will do better. They’ll also be less likely to crash mobile browsers! Most mobile browsers have limits on how much storage a specific web URL can use, and on iOS devices like the iPhone and iPad they’ll simply crash the browser (taking the user back to the Home Screen) instead of loading a really, really big document. The best way to remember that is “short is sweet, long is wrong.”

Build a Firefox OS App

There has been quite a bit of recent press about the upcoming Firefox OS mobile phone operating system.  One of the interesting things about this new operating system is that the “apps” are basically HTML5 webapps, which makes converting Ryuzine to Firefox OS apps a breeze!

Get the Simulator

Before we go any further, make sure you are using the Firefox desktop web browser and point it to the Firefox Marketplace page for the Firefox OS Simulator.  It’s a fairly large download for an add-on but it’s relatively simple to use.


When you install apps in the Simulator the “Dashboard” will tell you what kind of app it is – either a “Hosted” or “Packaged.”  If you are trying to install a manifest for either kind and it there is a problem with it you’ll see it installed as a “Generated app” instead, meaning you need to fix your manifest file.

Generated Apps

The simplest solution doesn’t require any work from you, the publisher.  The Ryuzine webapps are already coded to support being bookmarked to the home screen on various devices where they act more like an installed app than a web page.


The images above show you a Ryuzine publication in the Firefox OS web browser.  Press the star to bookmark it, select “Add to Homescreen,” edit the name (if necessary), and hit the “Add to Home Screen” button.


Generated apps appear with an automatically created icon.  When you open them you’ll see they don’t go fullscreen (the status bar still shows and a small toolbar is at the bottom).  The toolbar at the bottom gives you limited browser controls because, unlike bookmarking to the home screen on iOS, anything linked to within the publication will open within the Generated App context, not the web browser.

Hosted Apps

A hosted app for Firefox OS means you are hosting the content on a web server somewhere.  If you are publishing with Ryuzine Press this is your only option for creating a Firefox OS app.

Create a manifest file

In order to tell Firefox OS that what is hosted at your site is a webapp you need to create a “manifest” file.  This is just a simple text file and, if you’ve followed our tutorial on creating a Google Chrome Extension is pretty similar but not identical.  Here is the bare minimum you need in your manifest file to make it work:

     "name": "My App",
     "description": "Description of your webapp goes here."
     "launch_path": "/"

But you’re probably going to want a nice icon and maybe encode your publisher/developer info.  We turned our own “Library” on this site into a hosted Firefox OS webapp with the following manifest file:

    "version": "",
    "name": "Ryuzine Rack",
    "description": "The official Ryuzine newsstand at Ryu Maru",
    "launch_path": "/",
    "icons": {
        "16": "/images/app/icons/rack-favicon.png",
        "30": "/images/app/icons/rack-icon-30.png",
        "60": "/images/app/icons/rack-icon-60.png",
        "128": "/images/app/icons/rack-icon-128.png"
    "developer": {
        "name": "Ryu Maru",
        "url": ""
    "installs_allowed_from": ["*"],
    "default_locale": "en",
	"fullscreen": "true"

As you can see this one is a little more complex, but pretty self-explanatory.  Firefox OS uses 60×60 and 30×30 icons so we just resized the existing ones, and if we ever submit it to the official Firefox Marketplace they require the 128×128 icon, so we’re all set!


The “launch_path” parameter is set to the root level (“/”) of the webapp URL.  This would also be a good time to talk about an interesting requirement for a Firefox OS “Hosted” app – the “origin” of it. You can only have one app per origin!  What that means is you can’t just put them in sub-folders under your main domain name, they have to be under their own sub-domains.  So the following are NOT the same origin:

Even though they both point into the exact same folder they are not treated the same way by Firefox OS.  So, using your webhost control panel make sure you create a subdomain for each webapp you want to host for Firefox OS or it will cause you problems.  If you tried to reference each one in a sub-folder they are all considered part of the same origin.  The subdomains make each origin unique.

hostedapp_fsThe other important part is the “installs_allowed_from” parameter which, in our example, is still set to the default “[*]” which is a wildcard meaning “anywhere” (never, ever leave the brackets empty or it will disallow installation from everywhere, including your own site!).  Ideally you could put the URL of your own site if you’re hosting it for installation, or your site and the Firefox Market if you submit it, or any other sites you want to authorize to host your manifest for “installation.”  The primary purpose of this is to make sure only authorized sites can install and issue receipts for sales of your app, but the e-commerce component of Firefox OS apps is beyond the scope of this tutorial.  If you want to know more about it read the MDN documentation.

The “default_locale” simply tells it that the main language is English (“en”) but if that’s not the case for your content change it to the code for your language.  Note that it does not translate your publication’s text and should be the same as the language setting in the HTML file.

We included the optional “fullscreen” : “true”  to make our Firefox OS webapp use all the available space, because we think it looks nicer.  If you’d prefer that your webapp not hide the phone’s status bar omit this option.

Then you need to save it to the root location of your webapp, ideally with the filename “manifest.webapp” (though it can be more descriptive so long as it ends in .webapp).  You can use Mozilla’s manifest validator to make sure it is formatted correctly, though it will really only inform you if there are errors or it passes validation.  It doesn’t tell you what the error is or the line on which it occurs.  If you’re not very familiar with these kinds of files you can use the JSONLint validator, which is far more detailed.

Lastly, though the manifest files are just JSON format your web server may need to be configured to properly deliver .webapp files.

Once all of those things are in place you can test your hosted webapp in the Firefox OS Simulator by providing the full path to the manifest.  In the case of our Library this is  In the Simulator, if you don’t see it change the button from “Add URL” to “Add Manifest” it isn’t recognizing your manifest file for some reason.

Packaged Apps

packagedappThe packaged apps are nothing more than ZIP files containing all the assets.  Since Ryuzine Writer can produce these packages for you it’s pretty easy to export your publications, except they’ll be missing the important manifest file!  So you’ll have to unzip the package, add the manifest, and then re-zip it.

Ryuzine publications and newsstands don’t require any special permissions or use any Web APIs so you can create the simplest “Plain Packaged App” that doesn’t require or have enforced against it the Content Security Policy applied to “Priveleged” or “Certified” packaged apps, so we’re not going to cover adding a CSP to your package manifest.

For testing purposes we actually took the folder we used to create a packaged Chrome Extension of our “Add-Ons” manual supplement and all we did was duplicate and resize some icons and drop our manifest.webapp file into the folder:

    "version": "",
    "name": "Add-Ons Supplement",
    "description": "Supplemental developer manual for Ryuzine Writer",
    "launch_path": "/index.htm",
    "icons": {
        "16": "/images/app/icons/ryuzine-favicon.png",
        "30": "/images/app/icons/ryuzine-icon-30.png",
        "60": "/images/app/icons/ryuzine-icon-60.png",
        "128": "/images/app/icons/ryuzine-icon-128.png"
    "developer": {
        "name": "Ryu Maru",
        "url": ""
    "installs_allowed_from": ["*"],
    "default_locale": "en",
	"fullscreen": "true"

packagedapp_fsYou’ll notice the only major change was that we had to put the name of the HTML file in the launch_path (otherwise it would just show us a file list of what was in the package). Before we zip our package up again we can test it in the simulator by pointing the “Add Directory” to the manifest file in the unzipped package.

If you want to actually test the installation process from the ZIP package you need to do a bit more work using a development server on the same LAN as the device running Firefox OS, create something called a “mini-manifest” (this is outside your zipped packaged app), and an “install” HTML file with some javascript in it.  Full details on how to fully test installation of packaged apps is covered in the MDN Documentation.

Submit to Firefox Marketplace

If you want to submit your Firefox OS app to the official marketplace (i.e., “app store”) there are specific guidelines in the MDN Documentation on how to do this.  Remember, if you plan to charge for your app (which really only makes sense for packaged apps) you need to also purchase the Commercial Use License for Ryuzine from us.  If you’re just giving your webapp away, though, that doesn’t cost anything.