Otter Browser

A test release of Otter Browser is now available for download.
It uses the RISC OS port of Qt5 (v5.4.1) which includes the WebKit backend.
Only the Javascript interpreter is turned on at the moment.

Otter browser 0.9.8

You’ll also need to download,

unixfont.zip

!UnixFC and !UnixFont need to be seen by the filer before !Otter-browser is
run otherwise you’ll get squares instead of text.
Merge the !Boot folder contained in unixfont.zip.
Copying !UnixFC and !UnixFont to a ram disc helps speed things up a bit.

SharedLibs.zip

Just drop the !SharedLibs folder into !Boot.Resources.

It seems to run ok on a Pandaboard ES and IGEPv5. Anything slower may stuggle a bit.
There are still lots of problems and it can be slow to load pages.
Most sites containing Javascript load and display ok. More complex sites cause a crash or lock up.
Routers should be configurable on RISC OS and the RISC OS OPEN Wiki is now editable.

When Otter Browser starts up the window is minimised. To resize just click and hold anywhere in the window
and hold down shift while moving the mouse.

Hi Chris on 5432EVM get this back trace
Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0×518a78 (Main Thread)
( 1007f34) pc: cd402a24 lr: cd402e40 sp: 1007f38 __write_backtrace()
( 1007fa0) pc: cd402b74 lr: cd4049f8 sp: 1007fa4 __unixlib_raise_signal()
( 1007fb0) pc: cd4048ac lr: e5ef8 sp: 100634c __h_cback()

I should’ve disabled that. It’s falling over because it’s trying to check for updates which makes no sense for RISC OS. A quick work around is to change !Boot.Choices.Qt5.config.otter.otter/conf. Just set the date far in the future.

[Updates]
LastCheck=2020-01-01

That worked but had to create otter/conf

I can confirm it also works on a PI with 512 MByte. You have to be (a little) patience though.

Not so much luck on iMx6 ..

I think it is still the update check. tried future datestamp on !Boot.choices.Qt5.config.otter.otter/conf to no avail

Any further thoughts?

debug file:

Fatal signal received: Segmentation fault

Stack backtrace:
Running thread 0×518a88 (Main Thread)

  ( 1007f34) pc: 48bd9a24 lr: 48bd9e40 sp:  1007f38  __write_backtrace()

  ( 1007fa0) pc: 48bd9b74 lr: 48bdb9f8 sp:  1007fa4  __unixlib_raise_signal()

  ( 1007fb0) pc: 48bdb8ac lr:    e5ed4 sp:  100633c  __h_cback()
Register dump at 01007fb4:
a1:        0 a2:   51c4bc a3: e59ff4c0 a4:        0
v1:   5eee30 v2:   606988 v3:   60698a v4:   606968
v5:   50e184 v6:  100633c sl:   f07208 fp:  1006624
ip:  100633c sp:  100633c lr:    e5ed4 pc:    e5ee8
cpsr: 20000110
000e5ed4 : .0 á : e1a03000 : MOV     R3,R0
000e5ed8 : . “å : e5932000 : LDR     R2,[R3,#0]
000e5edc : 8 ‚â : e2822038 : ADD     R2,R2,#&38         ; =“8”
000e5ee0 : . ’å : e5922000 : LDR     R2,[R2,#0]
000e5ee4 : ¦.‰â : e2891fa6 : ADD     R1,R9,#&0298       ; =664
000e5ee8 : .. á : e1a00001 : MOV     R0,R1
000e5eec : .. á : e1a01003 : MOV     R1,R3
000e5ef0 : .à á : e1a0e00f : MOV     R14,PC
000e5ef4 : .ð á : e1a0f002 : MOV     PC,R2
( 1006624) pc:    e5c00 lr:   27b190 sp:  1006628  Otter::UpdateChecker::runUpdateCheck()
( 1006654) pc:   27b120 lr: 4750d210 sp:  1006658  Otter::UpdateChecker::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)
( 1006718) pc: 4750cf00 lr: 4750db88 sp:  100671c  QMetaObject::activate(QObject*, int, int, void**)
( 1006734) pc: 4750db58 lr: 47cbeffc sp:  1006738  QMetaObject::activate(QObject*, QMetaObject const*, int, void**)
( 1006744) pc: 47cbefd4 lr: 47c14e18 sp:  1006748  QNetworkReply::finished()
( 10067c8) pc: 47c14cb8 lr: 47c15354 sp:  10067cc  QNetworkReplyHttpImplPrivate::finished()
( 10067d8) pc: 47c1533c lr: 47cc00e4 sp:  10067dc  QNetworkReplyHttpImplPrivate::replyFinished()
( 1006828) pc: 47cbf9f4 lr: 47509bf0 sp:  100682c  QNetworkReplyHttpImpl::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)
( 1006850) pc: 47509b54 lr: 4750e5a8 sp:  1006854  QMetaCallEvent::placeMetaCall(QObject*)
( 10068d8) pc: 4750e2d4 lr: 480d1f94 sp:  10068dc  QObject::event(QEvent*)
( 10068fc) pc: 480d1ee4 lr: 480d538c sp:  1006900  QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 1006c48) pc: 480d4a2c lr: 474c9838 sp:  1006c4c  QApplication::notify(QObject*, QEvent*)
( 1006c78) pc: 474c97c4 lr: 474cceec sp:  1006c7c  QCoreApplication::notifyInternal(QObject*, QEvent*)
( 1006ce4) pc: 474ccc80 lr: 48c594a4 sp:  1006ce8  QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
( 1006d00) pc: 48c5947c lr: 474c6cc0 sp:  1006d04  QRiscosEventDispatcher::processEvents(QFlags)
( 1006d14) pc: 474c6c8c lr: 474c72c4 sp:  1006d18  QEventLoop::processEvents(QFlags)
( 1006d5c) pc: 474c71bc lr: 474d0cf8 sp:  1006d60  QEventLoop::exec(QFlags)
( 1006d98) pc: 474d0c68 lr: 477d2664 sp:  1006d9c  QCoreApplication::exec()
( 1006da8) pc: 477d263c lr: 480cf0ac sp:  1006dac  QGuiApplication::exec()
( 1006db8) pc: 480cf0a0 lr:    3fd24 sp:  1006dbc  QApplication::exec()
( 1006fec) pc:    3f2ec lr: 48bf07c4 sp:  1006ff0  main()
Thread 0×686f18 (JavaScriptCore::BlockFree)

  ( 1007f14) pc: 48bbd0b0 lr: 48bba0c8 sp:   f01eac  __pthread_yield_return()

  (  f01eb8) pc: 48bbd018 lr: 48bba0c8 sp:   f01ebc  pthread_yield()

  (  f01ee0) pc: 48bb9fac lr: 4547b138 sp:   f01ee4  pthread_cond_timedwait()

  (  f01f08) pc: 4547b090 lr: 4522de68 sp:   f01f0c  WTF::ThreadCondition::timedWait(WTF::Mutex&, double)

  (  f01f28) pc: 4522de1c lr: 4522dedc sp:   f01f2c  JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock(double)

  (  f01f48) pc: 4522deac lr: 4522df60 sp:   f01f4c  JSC::BlockAllocator::waitForRelativeTime(double)

  (  f01f6c) pc: 4522df2c lr: 4522e120 sp:   f01f70  JSC::BlockAllocator::blockFreeingThreadMain()

  (  f01f7c) pc: 4522e114 lr: 45461fd4 sp:   f01f80  JSC::BlockAllocator::blockFreeingThreadStartFunc(void*)

  (  f01f98) pc: 45461f8c lr: 4547a920 sp:   f01f9c  WTF::threadEntryPoint(void*)

  (  f01fac) pc: 4547a900 lr: 48bba5f8 sp:   f01fb0  WTF::wtfThreadEntryPoint(void*)

  (  f01fbc) pc: 48bba5e0 lr:   610040 sp:   f01fc0  __pthread_create()
Thread 0×56abe8 (Thread (pooled))

  ( 1007f14) pc: 48bbd0b0 lr: 48bba0c8 sp:   f03eac  __pthread_yield_return()

  (  f03eb8) pc: 48bbd018 lr: 48bba0c8 sp:   f03ebc  pthread_yield()

  (  f03ee0) pc: 48bb9fac lr: 472368f4 sp:   f03ee4  pthread_cond_timedwait()

  (  f03f38) pc: 4723678c lr: 4723162c sp:   f03f3c  QWaitCondition::wait(QMutex*, unsigned long)

  (  f03f80) pc: 47231370 lr: 47234fdc sp:   f03f84  QThreadPoolThread::run()

  (  f03fbc) pc: 47234e74 lr: 48bba5f8 sp:   f03fc0  QThreadPrivate::start(void*)

  (  f03fcc) pc: 48bba5e0 lr:   6f0040 sp:   f03fd0  __pthread_create()
Thread 0×60fba8 (Qt HTTP thread)

  ( 1007f14) pc: 48bbd0b0 lr: 48bfe758 sp:   f05c00  __pthread_yield_return()

  (  f05c0c) pc: 48bbd018 lr: 48bfe758 sp:   f05c10  pthread_yield()

  (  f05dac) pc: 48bfe378 lr: 48bfd518 sp:   f05db0  select()

  (  f05de4) pc: 48bfd4a8 lr: 47536610 sp:   f05de8  pselect()

  (  f05e30) pc: 4753657c lr: 47536f00 sp:   f05e34  qt_safe_select(int, __fd_set*, __fd_set*, __fd_set*, timespec const*)

  (  f05e44) pc: 47536ed8 lr: 475385d4 sp:   f05e48  QEventDispatcherUNIX::select(int, __fd_set*, __fd_set*, __fd_set*, timespec*)

  (  f05ed0) pc: 475384e4 lr: 47538af8 sp:   f05ed4  QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*)

  (  f05f00) pc: 475389c4 lr: 474c6cc0 sp:   f05f04  QEventDispatcherUNIX::processEvents(QFlags)

  (  f05f14) pc: 474c6c8c lr: 474c72c4 sp:   f05f18  QEventLoop::processEvents(QFlags)

  (  f05f5c) pc: 474c71bc lr: 4722f70c sp:   f05f60  QEventLoop::exec(QFlags)

  (  f05f80) pc: 4722f65c lr: 4722f7d8 sp:   f05f84  QThread::exec()

  (  f05f90) pc: 4722f7cc lr: 47234fdc sp:   f05f94  QThread::run()

  (  f05fcc) pc: 47234e74 lr: 48bba5f8 sp:   f05fd0  QThreadPrivate::start(void*)

  (  f05fdc) pc: 48bba5e0 lr:        0 sp:   f05fe0  __pthread_create()
Thread 0×60f0e0 (Qt bearer thread)

  ( 1007f14) pc: 48bbd0b0 lr: 48bfe758 sp:   f06c40  __pthread_yield_return()

  (  f06c4c) pc: 48bbd018 lr: 48bfe758 sp:   f06c50  pthread_yield()

  (  f06dec) pc: 48bfe378 lr: 47536734 sp:   f06df0  select()

  (  f06e38) pc: 4753657c lr: 47536f00 sp:   f06e3c  qt_safe_select(int, __fd_set*, __fd_set*, __fd_set*, timespec const*)

  (  f06e4c) pc: 47536ed8 lr: 475385d4 sp:   f06e50  QEventDispatcherUNIX::select(int, __fd_set*, __fd_set*, __fd_set*, timespec*)

  (  f06ed8) pc: 475384e4 lr: 47538a8c sp:   f06edc  QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*)

  (  f06f08) pc: 475389c4 lr: 474c6cc0 sp:   f06f0c  QEventDispatcherUNIX::processEvents(QFlags)

  (  f06f1c) pc: 474c6c8c lr: 474c72c4 sp:   f06f20  QEventLoop::processEvents(QFlags)

  (  f06f64) pc: 474c71bc lr: 4722f70c sp:   f06f68  QEventLoop::exec(QFlags)

  (  f06f88) pc: 4722f65c lr: 4722f7d8 sp:   f06f8c  QThread::exec()

  (  f06f98) pc: 4722f7cc lr: 47234fdc sp:   f06f9c  QThread::run()

  (  f06fd4) pc: 47234e74 lr: 48bba5f8 sp:   f06fd8  QThreadPrivate::start(void*)

  (  f06fe4) pc: 48bba5e0 lr:   5ffd90 sp:   f06fe8  __pthread_create()

If you download just Otter Browser again. I’ve changed it so it doesn’t do the update check.

Thanks
Runs up on iMx6. looking good, though I’ve already managed to crash it .

Is there a simple answer to the complaint that an issuer certificate for something locally looked up cannot be found?

You get used to which sites crash after a while. It’s normally due to the Javascript engine. Also if you’re not using a RISC OS rom with the latest ‘PMP’ changes it could be due to running out of logical address space.

I’ve got a fix for the certificate complaints. Qt5 is using hard coded unix paths to look for the certificate authority file. I’ll upload an updated library which points to a valid RISC OS path and the ca-certificates.crt file from debian once I’ve done a bit more testing.

it could be due to running out of logical address space.

It uses that much memory? Safari (a WebKit browser) runs fairly nicely on my iPad Mini with only 512MiB RAM onboard.

It uses that much memory? Safari (a WebKit browser) runs fairly nicely on my iPad Mini with only 512MiB RAM onboard.

Used logical address space != used physical memory.

Before ‘PMP’ most of the logical address space was used up on machines with 2GB memory. Even with 1GB it could run out if several programs used Dynamic areas.

Is there a simple answer to the complaint that an issuer certificate for something locally looked up cannot be found?

The fixed library and included CA bundle is available here. Just merge it with !Boot.

The fixed library and included CA bundle is available here. Just merge it with !Boot.

Minor spelling mistake, that deposits libQt5Network into !ShredLibs

Minor spelling mistake, that deposits libQt5Network into !ShredLibs

That !ShredLibs looks a bit destructive!

Sorted. Now with the correct speeling. :-) Thanks.

Well. RISC OS has a browser with Javascript capability! Congratulations, Chris!

But I’ve tried it on the BBxM, Iyonix and RPi, in that order (and all from one download, done on the BBxM, and shared via ShareFS).

On the BBxM, all that happened was: the desktop stopped updating, there was activity on the SSD for a few seconds, then a pause, then more SSD activity that didn’t stop. I gave up waiting after half an hour. It clearly wasn’t going to run.

Then I copied the downloads onto the Iyonix and installed it there. It ran fine – somewhat slowly, as you said, but successfully. I used it to access my LB-Link Ethernet wifi adaptor (you’ve probably seen the other thread – Otter will be an important tool for this sort of thing), and configure it to connect to a different AP. So it really does do what we need.

Then I copied the downloads to the RPi and installed it there. I was going to say that it just stopped the desktop from updating, but in fact the desktop has come back after a couple of minutes or so, sadly without any evidence of Otter running.

So only one success out of three so far, sadly.

Pi B+ with RC14: Double-clicking the app resulted in the desktop not updating. I’ll give it a few more minutes and will edit this post if it comes back.

Edit: It loaded after about 7 minutes, and does appear to work (albeit extremely slowly).

[last edit/update: 00h07 CEST]

An application that loads a file of this type has not been found by the Filer. Blah-de-blah and try again.

It’s an ELF isn’t it? <clicky-clicky> Yup. <sigh>

Ah, it is a part of gccsdk-sharedlibs. Okay, I’ll install that and…

…wow, that’s a metric tonne of libraries there…

Okay, nothing is appearing on the screen. Lots of disc activity, first read/writes and now reading. Passing two three four five six (!) seven (?) minutes now and still reading. Is this a normal start-up or is this a one-off first time initialisation?

I’m using a 256MiB Pi Model B issue 2 with 170MiB free memory and a self-built ROM dating from… what was it? May? March? I forget. It predates ZeroPain, at any rate. Internet is via Vonets VAP11G WiFi adaptor. Pretty photos of it all on my blog (today’s entry).

Okay, this is taking a lesser eternity, so I’ll hit Save Reply and update when something actually happens.

Oh, nine minutes later we’re reading/writing instead of just reading and… nine and a half minutes, something appears (and the disc is continually being read?).

Right, RISC OS Open loads a little slower than on NetSurf, but looks okay and is laid out nicely.

David – don’t Alt-Break it. On my Pi it took nine and a half minutes to get started.

My blog loads, but the alignment of the right-hand column is off, it is as if the text is too large. Not a big deal right now, the same problem is evident in the Preferences window. That something like WebKit works on RISC OS is a big step forward.

I quit Otter, removed the support modules (and the HUGE ~93MiB Dynamic Area created for the Shared Libraries), and then restarted everything. Otter came up in about 12 seconds, and picked up where I left off (my blog, halfway down the page). That is a whole lot better than nine+ minutes!

Since people seem to think that copying to RAMdisc is the answer, I moved Otter, UnixFC, and UnixFont to a 52MiB RAMdisc and erased the Qt5 cache directory. Startup took about a minute.

Oops! Ctrl-F12 (TaskWindow) crashes Otter and now it’s refusing to start – twice failed to allocate memory in dynamic area for sprite area, then failed an assert "!image.isNull() in file qriscosbackingstore.cpp, line 233. I guess this is a polite way of saying I’m running out of available memory. ;-)

Since it has already started, everything moved from RAMdisc back to harddisc to free up that 52MiB of memory. It was getting “a bit tight” with only ~37MiB free!

And there you go. Continue session, and Otter returns with my blog.

Congratulations. In normal use, I have never had my free memory go below about 120MiB. Now? I think I have… oh, 39MiB free.

Holy crap! It’s slow and takes memory like you wouldn’t believe, but I’m not looking at my Yahoo! mailbox. On RISC OS!

Dare I? Dare I?

Oh what the hell. I’m going to have to delete Otter and copy the archives to USB key for storage (I can’t afford that much disc space right now) so let’s go for broke…

Trying to log into docs.google.com and the machine locks up with a request to fonts.gstatic.com and the drive activity LED hammering away. Whatever it is that creates these unbelievably long pauses (scanning fonts?) may become an big issue. I taskkilled Otter and copied UnixFC and UnixFont to RAMdisc but this has made no difference – I suspect the font that is being scanned is in the cache or something?
Went, had a bath, came back an hour and a half later, Otter (or UnixFC) was still busy.
Oh well.

On the BBxM, all that happened was: the desktop stopped updating, there was activity on the SSD for a few seconds, then a pause, then more SSD activity that didn’t stop. I gave up waiting after half an hour. It clearly wasn’t going to run.

I found it works on the BB -xM if you copy UnixFC & UnixFont to RAM disc. I suspect it may also run without but will take a millennium to complete.

It’s a no go here too on the Raspberry Pi, with the ROM 09-Sep-15. The desktop appears stiffed but alt-Break works. The debug file is blank but a Shared Libraries DA of 93MB has been created.

P.S. Just tried with !Otter, !UnixFC & !UnixFont all on a RAM Disc and Otter has run. (Previously on SCSI or Fat32 disc it had been left for quite a while and never did start.)

P.P.S Rebooted the Pi and Otter now runs with all three components on SCSI.

Copying !UnixFC and !UnixFont to a ram disc helps speed things up a bit.

Understatement of the year! This took it from about seven minutes down to less than one.

I created a relatively simple “map” site several years ago, where you can click on locations, zoom in, and query individual sites. It’s now working on RISC OS for the first time :)

With ARMX6 Otter works fairly well. Startup takes about 12 seconds.

It looks like it is caused by the font cacheing in combination with slow disc media. To speed things up if you look inside !UnixFC there is an executable called fc-cache.
After first copying !UnixFC and !UnixFont to the ram disc and double clicking both, double click fc-cache. This will pre-create the cache files for all the fonts. Should only take a few seconds from ram disc. Once done copy the !UnixFC folder back to normal media.
Next time !Otter-browser starts up it should be much quicker as the fonts won’t need to be re-cached.

I tried it on an RPi2 (944 MiB RAM) and it works there, so two successes out of 4.

How much RAM disc can one have that is big enough to speed Otter up, but small enough to leave enough RAM for Otter to run in?

I rebooted the first RPi to see how much RAM it has, and was surprised to see the value 192 MB as RO starts up. I presume that’s because some RAM is reserved by the pre-OS boot system for other stuff (graphics?) rather than a faulty RAM? Its something that I’ve not looked at in ages as there has always been oodles of RAM for what I need.

Dave – 192MiB RAM implies you have allocated 64MiB for the GPU.
Does this match the settings in config/txt?