[[!meta title="Developer Weekend (November 2018)"]] [[!meta author="Vincent Sanders"]] [[!meta date="2018-11-02 12:00:00"]] [[!toc]] Attendees ========= * Michael Drake * Vincent Sanders * Daniel Silverstone Apologies ========= * John-Mark Bell * Chris Young Topics ====== * Make monkey actually run functional tests * Discuss ick CI system * corewindow for browser window change requirements * javascript console logging * gtk download window Monkey ====== ## 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 test.netsurf-browser.org 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) Discussions =========== ## Monkey 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. Plan: 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. Activity ======== Bug Triage ---------- * Group bug for line breaking issues is [[!bug 467]] * Addressed reported FTBFS error [[!bug 2627]] * Site about Death and Dying kills Netsurf [[!bug 2626]] investigated. Opened [Duktape issue](https://github.com/svaarala/duktape/issues/1994). Daniel ------ Michael ------- Vincent ------- * 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 test.netsurf-browser.org and automated deployment with a CI job Frontends ========= We revisited the decisions made in [July](../jul-2018/) 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