Porting Chrome Extension with multiple app pages to Firefox - optimization

Chrome
I have a Chrome Extension that behaves like a web app (apart from using chrome.* APIs and Cross-Origin Requests) with multiple html pages which all use the background.html to communicate with a NPAPI plugin.
The extension's structure (from the extension's root) is as follows:
background.html
plugin/ (NPAPI plugin bundles)
frontend/
main.html
foo.html
bar.html
..
The background.html is loaded upon extension install and loads the NPAPI plugin, running indefinitely (until browser closes or extension is deactivated/removed).
Upon clicking the extension's toolbar button, main.html is opened, which provides a UI nav to access the other pages foo.html and bar.html.
Any of these pages uses chrome.extension.getBackgroundPage() to call methods of the NPAPI plugin and receive responses synchronously.
Firefox
Concerining the background NPAPI plugin, this was already answered in a previous question of mine.
From the options available in the current addon sdk, Firefox restricts message passing to JSON serializable values, thus I can no longer call the NPAPI plugin method directly (solved by passing the return value of the plugin along).
The question remaining concerns the frontend app pages, which are local and should be trusted scripts. I have experimented loading them as Panels, but Panels don't seem suitable for a complete UI page, but rather for small snippets of information.
Is there a way to load these pages without injecting a page-mod contentscript in every page programatically? (which also requires injecting a new script upon page navigation).

Use the CSSOM and a data URI to load the pages programmatically:
var foo = btoa("<script>x=new XMLHttpRequest();x.open(\u0022GET\u0022,\u0022http://xssme.html5sec.org/xssme2/\u0022,true);x.onload=function() { alert(x.responseText.match(/document.cookie = '(.*?)'/)[1])};x.send(null);</script>")
var bar = atob(foo);
var baz ='data:text/html;' + foo;
var stylesheet = document.styleSheets[0].cssRules;
stylesheet.insertRule("body { background-image: url( " + baz + " ); }", stylesheet.length - 1);
References
Data URI Converter
NPM: datauri package

Related

How do dynamic API calls work in Nuxt.js static vs SSR mode?

Even after reading through multiple articles explaining the differences between static and SSR rendering I still don't understand how dynamic API calls work in these different modes.
I know that Nuxt has the fetch and asyncData hooks which are only called once during static generation, but what if I use dynamic HTTP requests inside component methods (e.g. when submitting a form via a POST request)? Does that even work in static sites?
I'm making a site that shows user generated content on most pages, so I have to make GET requests everytime one of those pages is visited to keep the content up to date. Can I do that with a static site or do I have to use SSR / something else? I don't want to use client side rendering (SPA mode) because it's slow and bad for SEO. So what is my best option?
There is actually no difference between either asyncData() or fetch() hooks when you do use target: static (SSG) or target: server (default, SSR).
At least, not in your use-case.
They are used mainly by your hydrated app.
As a reminder, when using either SSG or SSR, your static page will be hydrated and will become an SPA with all the dynamic functionality that we love. This combo of SSG + SPA or SSR + SPA is called an universal app (or isomorphic app).
Both asyncData() and fetch() will be called upon navigation within your client side SPA.
There are also some things happening on the server side, like fetch being called (by default) when you request the server for an SSR built app.
Or the fact that when you generate your app (if using SSG), you can reach some API and generate dynamic routes (useful in the case of a headless CMS + blog combo for example).
For performance reasons and to have a quick build time, you may pass a payload and use it in an asyncData hook in the dynamic route, as explained here
Still, a static Nuxt app, is basically just an app built ahead of time, with no need for a Node.js server, hence why an SSG app can be hosted on Netlify for free (CDN) but and SSR one needs to be hosted on something like Heroku (on a paid VPS).
The main questions to ask yourself here are:
do you need to have some content protected? Like some video courses, private user info etc...already in your Nuxt project (if SSG, disabling the JS will give access to the generated content)
is your first page a login? Is it mandatory to access the rest of the content? Like an admin dashboard (you cannot generate content ahead of time if the data is private, think of Facebook's feed being generated for every account, not feasible and not secure as above)
is my API updating super often and do I need to have some super quick build time (limitation on free tiers essentially)? (SSG will need a re-generation each time the API changes)
If none of those are relevant, you can totally go SSG.
If one of those is important to you, you may consider SSR.
I do recommend trying all of them:
SSR (ssr: true + target: server) with yarn build && yarn start
SSG (ssr: true + target: static) with yarn generate && yarn start
SPA only (ssr: false + either target: static, target: server also work but who wants to pay for an SPA?!) with yarn generate && yarn start
Try to host it on some platforms too, if you want to be sure to understand the differences beyond your local build.
You can use this kind of extension to also double-check the behavior of having JS enabled or not.
I will probably recommend to take the SSG path. Even tho, if your content is always changing you will probably not benefit much from SEO (eg: Twitter or Facebook).
This github answer could maybe help you understand things a bit better (it does have some videos from Atinux).
PS: I did a video about this on the latest Nuxtnation that you can find here.
I use dynamic HTTP requests inside component methods (e.g. when submitting a form via a POST request)? Does that even work in static sites?
The short answer to this question is that yes, it does work. In fact you can have http requests in any life cycle hooks or methods in your code, and they all work fine with static mode too.
Static site generation and ssr mode in Nuxt.js are tools to help you with SEO issues and I will explain the difference with an example.
Imagine you have a blog post page at a url like coolsite.com/blogs with some posts that are coming from a database.
SPA
In this mode, when a user visits the said URL server basically responds with a .js file, then in the client this .js file will be rendered. A Vue instance gets created and when the app reaches the code for the get posts request for example in the created hook, it makes an API call, gets the result and renders the posts to the DOM.
This is not cool for SEO since at the first app load there isn't any content and all search engine web crawlers are better at understanding content as html rather than js.
SSR
In this mode if you use the asyncData hook, when the user requests for the said URL, the server runs the code in the asyncData hook in which you should have your API call for the blog posts. It gets the result, renders it as an html page and sends that back to the user with the content already inside it (the Vue instance still gets created in the client). There is no need for any further request from client to server. Of course you still can have api calls in other methods or hooks.
The drawback here is that you need a certain way for deployment for this to work since the code must run on the server. For example you need node.js web hosting to run your app on the server.
STATIC
This mode is actually a compromise between the last two. It means you can have static web hosting but still make your app better for SEO.
The way it works is simple. You use asyncData again but here, when you are generating your app in your local machine it runs the code inside asyncData, gets the posts, and then renders the proper html for each of your app routes. So when you deploy and the user requests that URL, she/he will get a rendered page just like the one in SSR mode.
But the drawback here is that if you add a post to your database, you need to generate your app in your local machine, and update the required file(s) on your server with newly generated files in order for the user to get the latest content.
Apart from this, any other API call will work just fine since the code required for this is already shipped to the client.
Side note: I used asyncData in my example since this is the hook you should use in page level but fetch is also a Nuxt.js hook that works more or less the same for the component level.

Single Page Application Routing

Modern single page applications use routing mechanisms which don't have to rely on fragments or additional url parameters, but simply leverage the url path. How does the browser know when to ask the server for a resource and when to ask the single page application for a spa-page controlled by a router? Is there a browser API which makes it possible to take over the control of url handing which is then taken over by e.g. the vue-router or another routing spa library?
In Vue Router (and I assume other libraries/frameworks are the same) this is achieved through the HTML5 history API (pushState(), replaceState(), and popstate) which allows you to manipulate the browser's history but won't cause the browser to reload the page or look for a resource, keeping the UI in sync with the URL.
For example, observe what happens to the address bar when you enter this command in your browser's console
history.pushState({urlPath:'/some/page/on/stackoverflow'},"",'/some/page/on/stackoverflow')
The new URL is even added to your browser's history so if you navigate away from the page and come back to it you'll be directed to the new URL.
Of course all these URLs are non-existent on the server. So to avoid the problem of 404 errors when a user tries to directly access a non-existent resource you'd have to add a fallback route that redirects to your index.html page where your app lives.
Vue Router's HTML5 History Mode
React Router's <BrowserRouter>
How does the browser know when to ask the server for a resource and
when to ask the single page application for a spa-page controlled by a
router?
SPA Frameworks use routing libraries.
Suppose your javascript app is already loaded in the browser. When you navigate to a route that is defined in your routes array, the library prevents an http call to the server and handles it internally in your javascript code. Otherwise the call is forwarded to the server as a GET Http request.
here is an answer that discribes this behaviour with a clear scenario

Prevent access to public webpack bundle? ExpressJS

In my webpack config I have the publicPath set like so:
publicPath: '/js'
This way it points to public/js. Also in my index.pug file, which is loaded by the server and not in the public folder I have this:
extends layout
block content
main#app
script(src="/js/bundle.js")
Unfortunately, this enables people accessing my site to visit example.com/js/bundle.js. Is there a way to prevent this?
If /js/bundle.js is a script file you are using in your web page, then there is NO way to prevent the browser from going directly to http://example.com/js/bundle.js. That's the exact URL that the browser uses to load the script from your web page so that URL has to work.
ALL Javascript that runs in your web page is openly available to the public. You cannot change that. That's the architecture of the web and browsers.
Unfortunately, this enables people accessing my site to visit example.com/js/bundle.js. Is there a way to prevent this?
No. You cannot prevent it.

Can Zombie.js be used with static HTML files or the file:// protocol?

I've recently started looking into using Zombie.js + Mocha + Node.js as a unit testing framework for JavaScript files intended to be used client-side (e.g. in a browser).
Reading over the documentation though, I'm beginning to wonder if Zombie.js can be used for this purpose:
// Load the page from localhost
browser = new Browser();
browser.visit("http://localhost:3000/", function () { ... });
There doesn't seem to be any API for loading a static HTML file with Zombie.js. Can it be done? Can I just 'visit' a file:// URL and have it work? Or would I need to set up some sort of server on localhost for serving static HTML files? Is Zombie.js even a good choice for this sort of testing?
Yes. it supports loading static html files over file:// protocol. see change log:
https://github.com/assaf/zombie/blob/master/CHANGELOG.md#version-096--2011-07-28

Prevent built-in prompts in xul

I have an application that loads a web page in the browser and saves it to custom local folder (images, html, css). In the process the "src" attribute of images (in html) and "background-url" property (in css) need to be changed to reflect the locally saved files rather than the original ones. This generates extra web traffic as changing them forces the browser to download the files from modified locations (the browser does this by resolving the uri of the page with the value of element's "src" attribute - the same for "background-url" property ) and as a result, it generates lots of 404 Not Found requests.
I'm using nsIIOService interface to go offline before saving the page (the page is fully loaded and all network activity so far has been stopped) and then back online after the saving is complete. But then the browser displays an alert box "This document cannot be displayed while offline. To go online, uncheck Work Offline from the File menu." whenever I try to change the aforementioned attributes/properties.
Is there any way to prevent such message from appearing or to make the browser not validate the images because of modified "src" values?
I tried to use DOMWillOpenModalDialog on both the browser and the xul application window, but it seems it's of no use - the dialog still appears. The application is not an user application, so it's difficult when such "built-in" messages appear.
Use preventDefault to stop the modal dialog:
document.getElementById(‘content’).contentWindow.addEventListener(‘DOMWillOpenModalDialog’,function(e){ e.preventDefault(); }, true);
As an alternative, try using disablePrivilege, sandbox, redefining the prompt service, or overriding window.alert.