• Michael Drake
  • Vincent Sanders
  • Daniel Silverstone


  • John-Mark Bell
  • Chris Young


  • Make monkey actually run functional tests
  • Discuss ick CI system
  • corewindow for browser window change requirements
  • javascript console logging
  • gtk download window


Vincents notes

It would be useful if monkey could run complete page fetch tests automatically.

I think that we create a jenkins job to export the netsurftest.git repo to hosted on the CI system. either on master node or a worker VM via redirect (like bugs)

A CI target that is triggered from a successful netsurf build (like the unit test target) which builds monkey frontend and uses automation to run through the tests served in the test server.

The test plan and criteria should be stored alongside the test data.

A minimum viable test corpus should include:

  • smoke test i.e. can browser actually start and find resources, messages etc.
  • page retrieval and render with at least http and https schemes
  • redirect tests
  • form tests
  • moving and executing the existing javascript tests from the netsurf codebase to test repo

Extra credit things

  • a coverage build
  • valgrind or similar to spot out of bounds memory accesses and leaks

Sunday Plan

  1. Webserver for test repo. CI job that runs make in the NetSurf test repo. make install DESTDIR=blah to somewhere served by the CI control machine somehow.
  2. CGI for test repo to turn POSTed form into JSON. With a test HTML FORM page thing (make a form that does everything in the HTML5 spec).
  3. CGI for 401 page testing.
  4. Monkey tests that use the netsurf-test repo, get put in netsurf-test repo.
  5. Test makefile generates a monkey test manifest from the .yaml files.
  6. Finishing up the famer and the driver to support the tests we have.

Stuff for future:

  1. Cert testing. (Various types of bad cert etc)



kinnison described five things that needed to be done:

  • extend C interface with vtable callbacks for certificate and 401 login
  • extend C interface with form interation
  • test driver in python
  • test plan language/definitions
  • events from the core browser window to frontends

Corewindow for browser window change requirements

Everything except browser window has been moved over to corewindow.

The API is OK, but a little cumbersome to use, but it needs to flexible enough for lots of use cases.

The main outstanding feature is that the browser window needs the front end to handle scaling at render time. This isn't supported by core window.

The reason for this is mostly due to HTML layout engine currently doing scale by resizing viewport available width according to scale, reflowing, and redrawing with the scale applied. This was an optimisation to avoid needing to redo layout (measuring text) on scale changes. But it doesn't really work except on the RISC OS font manager, where text size scales linearly with pt size.


  1. Sink scale into browser window, so gui_windows can only set and get scale.
  2. Restructure front ends to have correct separation of gui, browser and core window.
  3. Move browser windows over to core window.

So front ends will only know about scale for e.g. saying scale in the title bar. All the complexity will move to browser_window. (For now; we should be able to improve matters with the new layout engine.)

Javascript console

Currently console output gets NSLOG under netsurf context at INFO which is a both poor and unuseful. Daniel thinks that the JS console should be a property on browser_window.

  • Window needs to propagate html_content pointer into Console object on creation in Window::console().
  • console should fire content message when logging
  • browser window should consume content message (bubbling as required)
  • browser window api extended to support reading and clearing console and injecting js commands to run

subsequently add interface to frontends, possibly core window

GTK Download window

Many egregious function pointer related issues were found when Michael compiled with GCC 8. Vince wanted to point out that across all platforms, though GTK+ especially, our handling of unknown mime types is very bad.

The prevailing opinion is that behaviour ought to be more similar to firefox's approach, with a corewindow for handling general UI in order that the effort put in makes sense across all frontends.

A possible API rework could be as follows:

  • Core says to frontend "Here, a handle to a fetch, and some metadata about it. Whaddayouwant to do?"
  • Frontend either returns "No idea mate. abort." or "Ok, I'll deal with that."
  • In the second case, it can then present UI for "save or abort".
  • If aborting, frontend hands the handle and metadata back to the core for it to clean up.
  • If saving, frontend calls a "OK, let's save this" handing the handle, metadata and either an FD or filepath (to be decided) under which to save the result.
  • The "download" core window should have UI for "cancel" and "open location" type things. Progress, etc. All the goodness.

As an aside, it'd be handy to have a core->frontend call which allows the core to get hold of a bitmap representing a particular mime type. This way the download core window might display an appropriate icon, or we might be able to replace empty favicons with an appropriate mime type image.


Bug Triage




  • fixup CI workers to be operational again
  • CI cpu worker (number 2) for armhf had an incompatible gcc installed causing link failiures and contaminating teh ccache with bad objects. attempted dist-upgrade and node has stopped responding altogether - needs physical intervention.
  • Added 401 handling to monkey
  • Added certificate handling to monkey
  • configured and automated deployment with a CI job


We revisited the decisions made in July and decided they're all good so we're not changing them for now.

Statement of work

Within the fortnight we will:

  1. Have monkeyfarmer and monkey-driver updated to work with 401 and the full feature set thus-far defined.
  2. Have a set of tests in the netsurf-test repository along with their metadata.
  3. Have those tests aggregated during the build/install of the repo
  4. Have a CI job which downloads that aggregation, acquires a source-all tarball, and builds monkey from that, running the driver across the test set.

Next time

We have chosen the next developer weekend to be 15/16/17 Febuary 2019. It shall be at Males close