!Iris Half Crashing

I’ve got a reproduceable problem, where when accessing certain websites, (reproduceable on one website in particular), where !Iris partially crashes but does not display any warnings or anything it just becomes unusable, but does not bring down the entire OS.

On https://northernpowergrid.com/power-cuts-map the website loads fine, then when you click on one of the “power cut clisters” it zooms in on the location and map fine, but when you click on a particular power cut to load the details the process called “WebKitNetworkProcess” just closes itself down. I have reproduced this error on 2 different RasPi 4Bs running RiscOS with !Iris.

This doesnt result in !Iris browser closing down or locking the system up, it just ends up with !Iris still being graphically responsive but not doing anything at all.

What you are seeing is “normal”. Iris is a peculiar application in that every window has two tasks associated with it. There is the UI/front end, and there is all the background stuff.

I am not privvy to the inner workings of Iris so I don’t know exactly how this works, like if the background app renders into a sprite and the front-end displays it, or what, but when something upsets Iris, it is usually the background NetworkProcess that carks it. Unfortunately it doesn’t appear that the front end is (currently?) able to notice the back end dying, so it just sort of sits there like a half squeezed lemon.

Given that you have a reproducible problem, send a report to Andrew to pass along. It’s what I did regarding FlightRadar24 and it got fixed.

another incarnation of this effect is when the whole machine seems to be unresponsive. Alt-break shuts down “WebKitNetworkProcess”, at which point everything, including Iris returns to normal operation. I’ve encountered this a couple of times, but I don’t have a record of what triggered it.

I’ve reported the issue to RiscOS Developments, and they’ve already responded that they’ve passed it on to be looked into.

One of the areas that is being working on is allowing each tab to have its own networkprocess to avoid one failure bringing the whole lot down. However, this has created some unique challenges due to the nature of RISC OS, where the processes need to access the same files, potentially at the same time. It all makes development… challenging!

Maybe it can use a similar idea to Nemo idea for preemption in the desktop? Switching or creating tabs by using separate threads.

Wouldn’t be the long term solution to this, enable iris to be able to utilize another core on the processor to handle webkit and browsing in general, im not sure how far along we are to getting multicore functioning system wide, but if iris was able to tap in to using another core seperate to the OS, would this not stablize things somewhat? i understand in general that browsers are not multithreaded, but we have others cores sat there pretty much doing nothing, i haven’t been able to replicate the same issue on my titanium system, but have noticed the CPU temp spikes when iris is in use.

Wouldn’t be the long term solution to this, enable iris to be able to utilize another core on the processor to handle webkit and browsing in general

No. WebKit is designed to be multi-process, not multi-threaded. Threads are generally less stable because the whole app dies rather than a process. Making it use threads would be near-impossible, and take it further away from WebKit’s design.

The separation of Iris’s processes appears to match WebKit’s process separation. You want Iris to use a minimally-modified WebKit, otherwise upgrades become very complicated and many man-months of work.

https://docs.webkit.org/Deep%20Dive/Architecture/WebKit2.html#overview

I’m not sure I agree with Andrew’s recent comment about multiple Network Processes. That’s not a design I would consider, and the diagram on that URL shows the amount of information that would need to be synchronised.

You want Iris to use a minimally-modified WebKit

This. The more something deviates from the norm, the more effort is involved in dealing with updates and patches, the less likely it ever is to happen.

I would love for there to be a service call prior to actually fetching something so I could write a module to step in and say “for god’s sake don’t fetch that!”, but alas the more it is “different” to the standard distribution, the more problems that will cause.

Ideally, once the RISC OS specific stuff has been done, it’ll be mostly isolated from the rest of the browser, so that can be updated workout too much additional work.

You see, the problem is that browsers are a moving target. There’s always more stuff being added, exploits being patched, they’re practically a virtual OS these days rather than “here’s some text, make it look pretty”.

many man months of work? i guess we must be on the bare minimum then to have 1 update a year, no browser is perfect. the worst site at the moment is google search, it literally takes down the whole system since they did whatever they did making changes.

Wouldn’t be the long term solution to this, enable iris to be able to utilize another core on the processor to handle webkit and browsing in general

I suspect it would be easier to run an off the shelf browser using Linux on the other 3 unused cores, and blitting it on to the RISC OS desktop.

the worst site at the moment is google search, it literally takes down the whole system since they did whatever they did making changes.

I changed my user agent to Mozilla/5.0 (compatible; Firefox/96.0; RISC OS 5.30) and Google search works fine now as do most sites, a few moan I’m out of date but still work.

The more something deviates from the norm, the more effort is involved in dealing with updates and patches, the less likely it ever is to happen.

As I’m sure some people round here know, this is generally a solved problem. My day job involves keeping different streams of source code in sync, and it’s pretty straightforward with something like Git. Imagine the WebKit engine was in a Git repo (which I’m sure it is!) then you simply fork it and make the RISC OS specific mods in there. Git has facilities built-in for replaying the upstream/main/master changes into your own fork.

I couldn’t imagine working on anything non-trivial without doing this. WebKit would be the opposite of trivial!

As I’m sure some people round here know, this is generally a solved problem.

https://github.com/WebKit/WebKit/commits

WebKit has had 20-40 changes applied each day, this week (30 so far today). They intentionally change APIs and rearchitect as necessary, as opposed to try to maintain a consistent porting layer, to avoid it becoming clunky. Across a year, there’s a high chance a given patch fails to apply to an area of code that’s been rewritten, and then you need to understand that new code (and remind yourself of the old code) in order to recreate your patch – especially if it were as invasive as some of the ideas in this thread.

I think many people on this forum substantially underestimate the size of the WebKit and how fast it evolves. Iris must have been a lot of work, and they clearly took the sensible minimalistic patch approach since it’s the only multi-process RISC OS GUI application I’m aware of.

Browsers are my day job. I’ve worked on porting WebKit, including patching and upgrading ports, for 18 years now. I use git. I don’t consider it a solved problem, and presumably others agree otherwise I wouldn’t get paid to do it.

Browsers are my day job. I’ve worked on porting WebKit, including patching and upgrading ports, for 18 years now. I use git. I don’t consider it a solved problem, and presumably others agree otherwise I wouldn’t get paid to do it.

I don’t mean keeping on-track with WebKit is a solved problem – it’s clearly huge. It’s more the idea that mechanisms to support change tracking are there. Yes, there is still no getting away from managing the sheer volume of changes and even just the testing liability on that.

I wonder if WebKit is the largest thing ported to RISC OS? I never saw the previous Firefox attempt, but that was back when browsers were simpler (relatively!). I always thought your Java runtime was impressive as a RISC OS application – there must have been a fair bit required to make that work!