QupZilla - Yet another RISC OS Webkit based browser

You wait around for ages for a decent ’ish web browser for RISC OS to turn up and and two come along at once.

Qupzilla uses the same back end as Qtter browser (Qt5Webkit). It’s got a few features that Otter browser doesn’t currently have. Although it’s not as configurable as Otter Browser and not updated as often.

Password Manager
Simple RSS feed reader
Extension Support
Spell Checker
‘Save as’ for Images

The user interface seems a bit more stable. Some of the windows and menus open at incorrect sizes in Otter Browser.
Once I’ve done a bit more testing I’ll make it available for download.

The official QupZilla website is here. The RISC OS port is based on version 1.8.9.

Next on the list is to add Qt5 Multimedia support to Otter Browser and QupZilla. This will hopefully mean streaming audio and video support. Maybe even youtube will work!

Sounds good! As it’s the same backend, is the speed more-or-less the same? Unfortunately Otter on a Pi 1 isn’t a great experience (even with UnixFont and UnixFC in RAM) so I’m not holding my breath at this stage.

On the other hand, audio/video support would be most welcome! I’ll certainly need to buy faster hardware for that though :)

It does seem a bit faster but still too slow for a RPi 1. It also needs 512 MiB ram to be comfortable. I’d say at least a RPi 2 using a RAM disc for the disc intensive bits.

Without any kind of hardware acceleration audio/video support will need as fast a machine as possible. Even the fastest RISC OS hardware will struggle.

Well in any case, thank you for taking the effort to port these. It’ll be great to have some more options! :)

Hi Chris. There were specific optimisations around Epiphany for the Pi, with ASM implied… WebKit is involved here too. Are these modifications present in your ports?

So javascript would be covered with Qupzilla, I suppose. I think there is a similar, but lighter browser called Arora. I don’t know much about either of them. But, Webkit will be the elephant in the room either way. They are putting the Duktape js engine into Netsurf. I’ll probably wait for that setup, as it’s sure to be speedier than anything using Webkit. On the other hand, Netsurf with Duktape isn’t here today :-(

as it’s sure to be speedier than anything using Webkit.

I won’t bet on it. WebKit as a JIT engine for JavaScript, even on ARM now. NetSurf will probably never have this.
One intermediate solution would be to use Webkit, without Qt, to get the maximum power from the system.
Not easy :)

I won’t bet on it. WebKit has a JIT
engine for JavaScript, even on ARM now.

@David: I see on the Duktape page they say that they probably won’t implement JIT. But, I wonder where the tradeoff is, relative to the average amount of javascript on a given webpage. For small amounts of javascript, perhaps Netsurf would be speedier due to having less overhead. It probably depends on the site.

There were specific optimisations around Epiphany for the Pi, with ASM implied… WebKit is involved here too. Are these modifications present in your ports?

It’s just a vanilla port so there are no RISC OS specific optimisations. Most of the slowness is due to Qt5.

The RISC port (Qt5.5) uses the older soon to be obsolete Qt5Webkit backend. This is being dropped for Qt5.6 which is due out soon. This uses the Qtwebengine back end. I believe this is the asynchronous Javascript engine as used in Chrome etc. I’m not sure if it will be possible to port this to RISC OS.

A test version of QupZilla 1.8.9 is available to download from here. It contains everything needed to get up and running. If you’re already using Otter browser it will just upgrade some of the libraries. There are two new application folders !CaCertificates and !Hunspell. Theses are both installed in !Boot.Resources when you copy/merge the supplied !Boot folder. Without them spell checking will not work and you’ll get certificate warnings if visiting sites using https.

Just copy or merge the !Boot folder over your existing one. !UnixFont and !UnixFC can be copied anywhere. They just need to be seen by the filer before QupZilla is run otherwise you’ll get squares instead of text. Copying them to a RAM disc speeds things up a bit.

It takes about 16 seconds to start up on Titanium and IGEPv5. Scrolling is fairly smooth on both these platforms and page loading is reasonably quick.

On a Pi Zero it takes about 40s to start up. Scrolling is very juddery and some pages can take a long time to load.

Good work. Thanks a lot.
Short try. Works a bit faster and better with many pages than Otter browser but any small problems are back (e.g. the text windows on arcsite).

It does indeed seem to be a bit faster than Otter on my Pi 1. A couple of sites that appeared to hang Otter (but probably were just really slow) are now accessible.

Out of interest, how easy/hard is it to make either of these browsers behave more like a normal app? Having no icon bar icon, and the whole app quitting when I close the window, results in my going back to NetSurf. I’m sure you can appreciate that I don’t really want to sit through a ~1 minute startup time every time I want to look at something … but I expect that it’s more complicated than it sounds!

David Feugey:

I won’t bet on it. WebKit as a JIT engine for JavaScript, even on ARM now. NetSurf will probably never have this.

As I’ve said before, the choice of JavaScript engine isn’t actually that important. We’ve already changed from SpiderMonkey to Duktape. The SpiderMonkey binding still exists in the code. We just aren’t publishing builds that use it now. We haven’t ruled out using a more heavyweight JavaScript engine on platforms that can handle it in the future. For us, most of the work is (re)writing the rest of the browser so that all the interfaces needed by JavaScript are available.

As for Duktape, they’re considering the best way to implement a JIT, but there are plenty of optimisations that can still be made to improve things without needing a JIT.

Of course, optimisations are possible. But it’s really not the same…

I see it everyday with BBCBasic4Win. Made in x86 ASM. Only a few cycles to run some instructions. Probably one of the fastest interpreter on earth (with BBC Basic for ARM :) ). And nowhere near the LLVM based engines we see today.

Anyway, for Otter and QupZilla, it could be interesting to check if the RPI specific changes to WebKit are used or not. A way to reduce links with Qt (at least a native interface around the QtWebKit component) would probably help too. Easier to say than to do :)

Chris: good work! I see that Edit-Preferences-Local Storage gives an option to set up storing a network cache on disk – is this likely to be worthwhile (I don’t think QupZilla caches stuff anywhere else as a default). Edit-Preferences also gives an option to disable Javascript (quite reminiscent of the RO port of Firefox, back in the day!). At the moment I’m running with JS on – it doesn’t seem to make the substantial difference noticeable with Otter. Initial impression on a Pi2 is that QupZilla (JS on) is about as responsive as Otter (JS off) – so progress is being made!

For us, most of the work is (re)writing the rest of the browser so that all the interfaces needed by JavaScript are available.

I think the problem comes with the DOM model, and realising quite how many tentacles JavaScript is willing to ram into the browser’s concept of reality.

A simple example is my blog – open it in a browser and try the Konami code. (^_^)
(if you aren’t familiar with the Konami code, watch this: https://www.youtube.com/watch?v=MjmnknmC8H0)

A midrange example is Yahoo! mail. Any version will do, they are all varying degrees of disaster-in-progress but one thing in common is that a lot of use is made of scripting to make it all “work” (that word in scare quotes).

A complicated example is Google Docs. How d’you fancy a word processor running in a window?

An insane example is the following button. If you have a fast computer and modern browser, click it. And once you’d wrapped your head around what is going on and what the scripting is expecting the browser to be capable of doing, you’ll understand why “adding JavaScript” is a very complicated thing indeed.

For those on RISC OS only, or with older/slower computers, I’ve uploaded a video of my iPad dealing with the above button so you can see what I mean about JavaScript doing insane things:

https://www.youtube.com/watch?v=pytCe4FyRcM

Rick: Are you sure your ‘button’ program is working?
On an i5 Windows 10 and latest Chrome or Firefox it does nothing!
Apart from Kaspersky I don’t think I’ve got anything that would interfere.

Apart from Kaspersky I don’t think I’ve got anything that would interfere.

I think firefox blocks cross-site scripting by default.

If you check the button is calling a script on a totally different server (or at least attempting to do so)

Works for me:

• Firefox 12.0 on XP SP3
• Safari on iOS7 (see video)
• Dolphin on iOS

Doesn’t work for me:

• Android (Stock / Chrome / Firefox)

Not my program. More info here: http://kathack.com/

It works for me in SeaMonkey (based on Firefox) but I had to give it permission to run first.

Firefox 12.0

Ah, perhaps I should rephrase and say: “current and recent versions of Firefox”
Firefox 12.0 ==> Apr 2012.

It works for me in SeaMonkey (based on Firefox) but I had to give it permission to run first.

i.e. set the permissions away from the default security model.

i.e. set the permissions away from the default security model.

Not permanently; it pops up a little “banner” asking whether you want to allow the script to run. Revisiting the page and clicking the button again asks a second time, so it isn’t actually changing any underlying settings.

Firefox 43.0.4
Chrome 47.0.2526.111 m
I had ‘Block pop-up windows’ ticked but unticking and reloading and it still doesn’t work!
No problem, other more important things to concentrate on.

I see that Edit-Preferences-Local Storage gives an option to set up storing a network cache on disk – is this likely to be worthwhile (I don’t think QupZilla caches stuff anywhere else as a default).

I turned it off by default as more often than not images don’t get reloaded from the cache. On slow media it probably won’t be worthwhile turning it on.

Edit-Preferences also gives an option to disable Javascript (quite reminiscent of the RO port of Firefox, back in the day!). At the moment I’m running with JS on – it doesn’t seem to make the substantial difference noticeable with Otter. Initial impression on a Pi2 is that QupZilla (JS on) is about as responsive as Otter (JS off) – so progress is being made!

If you run with JS turned off globally you can turn on/off Javascript temporarily for the current page by clicking on the ‘JS’ icon on the status bar at the bottom right of the window. The page is automatically reloaded. It’s not as flexible as Otter browser in that the setting only lasts as long as the browser session.