Following up on Build an Open Source Browser Based on AIR, even if I should not
Ok, little disclaimer, I gonna talk quite a bit about building software and there are not really only one way to do it, I may give insight or advices etc. that will not necessarily fit your way of doing at all, it would highly be influenced by my own experience and workflow which are more "my way of doing" that the ultimate best way of doing things.
Let’s start with the why, why build a browser in the first place?
When Flash EOL hit in 2020, not a single browser will be able to play Flash or SWF file.
It’s not because of Adobe (for stopping support) but because of the browsers,
all major browsers (Chrome, Firefox, Safari, MS Edge, etc.) will plain and simply remove the plugin mecanism.
It’s not that you will get your Flash plugin blocked or forced click-to-play, the browser will not be able to run plugin at all.
To counter that, you can either
find a way to play SWF files with browsers technology (and as such without any Plugin),
that’s the Shumway project from Mozilla that have been abandoned
find a way to convert SWF content to another format supporter by the browsers,
that’s the Swiffy project from Google that have been deprecated
find a way to still play those SWF files despite the browsers
simply put, you build your own browser that still supports to run the Flash plugin.
For reference you can also look at Some Thoughts on the HTML Target for AIR
To me, the simpler and faster and most straightforward and most compatible way is to just build a browser, but …
building a browser can be
- extremely hard to do from scratch (eg. writing all the code)
- very hard to do with “components”, for ex CEF
- just hard to compile a browser even when all the source code have already been written for you, and among all the browsers already existing the same major vendors will show up as open source layout engine
But lucky us, there is a quite easy to reuse browser component already builtin in Adobe AIR.
Yes, it is the Safari engine: WebKit, a bit outdated but we don’t really care because the main goal is to support playing SWF files.
Ok, great, we know why, but a web browser can do a hell lot of things, so what are we building exactly?, let’s put a bit of context in all that (that’s it the main features we want).
Let’s start very simple, this web browser should
- works and behave like the major browsers that users already know and use,
but focus principally on playing SWF files.
- works on the desktop for the most used operating systems,
that means Windows and macOS and possibly Linux
- we shoudl at the same time cut off the features to the essential:
no addons or extras, but keep things like navigation UI principle, favorites, etc.
- and add other features that help (improve the experience) to play SWF files:
maybe help to install the Flash plugin, check the version of the plugin, etc.
- maybe have some fun in the process, the goal is not to copy Chrome/whatever or compete with it
but more give a “big fuck you middle finger” to all those major browsers saying
“You can not play SWF files, we can”
In general, I try to limit the main features to 5, think about it, go back to it, till I’m happy.
Being happy means not falling for the features creep, as having a nice long list of hundreds of features that basically discourage you right from the start to even start the project.
Clear and focused goals help a lot, at best this web browser will be a v1.0, it is supposed to miss features, but software is like a living beast, you can always add other features later or never, it can go either way.
Now that we have the what, let’s see the how, how are we building it?
The details is already listed in Build an Open Source Browser Based on AIR, but let review it.
Adobe AIR already have this
HTMLLoader class and
StageWebView class and yeah we gonna reuse the shit out of them, and many others classes that are already there.
In fact, we gonna reuse everything that Adobe AIR already allow us to do easily (or without too much trouble), like for example drag’n drop a SWF file in the browser window and just play the damn SWF thansk to the
So it already been a couple of weeks and I made spikes, exploring what is possible or not.
By now, I know that technically we can interchange the use of
HTMLLoader has more features but we don’t interact that much between the HTML content and the AS3 content, we just navigate stuff, so the code could be organised in such a way to allow to pick one or another.
WIth some of the tests I faced pages where the
HTMLLoader got too many “bugs” that it can not even load an HTML page (JS bugs, CSS bugs, etc.), so yeah being able to switch to
StageWebView could be needed.
I also keep notes of how and where the Flash plugin is installed and configured digging into the Adobe Flash Player Administration Guide, for example if we want to play local SWF files then we need ot understand the FlashPlayerTrust directory, and copy what something like nw-flash-trust is doing in NW.js.
Another thing, which I viewed long time ago but completely forgotten in the mean time, is how to know the latest version of the Flash player plugin? eg. read the XML from https://fpdownload.macromedia.com/pub/flashplayer/masterversion/masterversion.xml
which basically gives that
<?xml version="1.0"?> <version> <release> <ActiveX_win8 version="31,0,0,122"/> <ActiveX_win10 version="31,0,0,122"/> <ActiveX_Edge version="31,0,0,122"/> <ActiveX_win version="31,0,0,122"/> <NPAPI_win version="31,0,0,122"/> <NPAPI_mac version="31,0,0,122"/> <NPAPI_linux version="31,0,0,122"/> <PPAPI_win version="31,0,0,122"/> <PPAPI_winchrome version="31,0,0,122"/> <PPAPI_mac version="31,0,0,122"/> <PPAPI_macchrome version="31,0,0,122"/> <PPAPI_linux version="31,0,0,122"/> <PPAPI_linuxchrome version="31,0,0,122"/> <PPAPI_chromeos version="31,0,0,122"/> </release> <releaseDebug> <ActiveX_win8 version="31,0,0,122"/> <ActiveX_win10 version="31,0,0,122"/> <ActiveX_Edge version="31,0,0,122"/> <ActiveX_win version="31,0,0,122"/> <NPAPI_win version="31,0,0,122"/> <NPAPI_mac version="31,0,0,122"/> <NPAPI_linux version="31,0,0,122"/> <PPAPI_win version="31,0,0,122"/> <PPAPI_winchrome version="31,0,0,122"/> <PPAPI_mac version="31,0,0,122"/> <PPAPI_macchrome version="31,0,0,122"/> <PPAPI_linux version="31,0,0,122"/> <PPAPI_linuxchrome version="31,0,0,122"/> <PPAPI_chromeos version="31,0,0,122"/> </releaseDebug> </version>
Basically, a lot of little things, little details, this and there, and filling notes about what is easy / medium / hard to do.
I did a bit of research on branding, naming, logo etc. too, yeah you can not call a web borwser just “web browser” or “AIR browser”, and you also need a landing page like the Firefox one.
But yeah the “how to do things” is basically approaching the project with the main goals (5 features), and go through everything first with small tests (the spikes), no framework, no external libraries, nothing really, just the basic raw Adobe AIR API and see how it goes.
All that, to have a good idea of the “effort” to build this projecgt, is it a 3 days, 3 weeks, 3 months project?
Now my time estimate would be within 3 months, but not at full time 8h/day, more like few hours this and there “when I have time”.
Other stuff, ideally I would like this web browser to be updatable/reusable in other context (eg. your own project) and also support multi languages (see for ex Download Firefox in your language).
FInally, this “research phase” is also here to indetify the difficults thing or the pain points, and the main cons of AIR is basically the packaging, not only build the app but also build the installer for it.
For macOS you can get away by using the command-line tools like pkgbuild etc. but for Windows you would want a nice installer, so I took upon the opportunity to try out Advanced Installer with a free license for OSS project
Free Advanced Installer License for Open-Source
As users of open-source solutions we like to give back to our community. We hope that Advanced Installer can help speed up the development for your projects and thus allow you to concentrate on the solution itself, not spend time on packaging and delivering it to the end users.
I would say that’s how you start, you search and research, you plan a little bit, you stay focused on the main goal, and then once you got all those infromations you can finally start the actual project.
Now the job is to take “all that” and define specifications (never ever start a project without a spec), start the basic like an automated build, puting in place VM and others stuff to actually test things ina clean/virgin environment, star the actual mockup and prototype.
Hopefully I’ll be able to talk a little bigt about that too but no guarantee, as again I’m always short on time.
I’m happy to talk more (or less) about specific parts if some people are interested by different aspect of it (why this, how’s that, etc. kind of things).