[[!meta title="Developer Weekend (May 2020)"]]
[[!meta author="NetSurf Developers"]]
[[!meta date="2020-05-22 09:00:00"]]

[[!toc]]

Attendees
=========

* Michael Drake
* Vincent Sanders
* Daniel Silverstone

Outstanding work (from Feb)
===========================

* General
    * Implement any appropriate auto fill auth handlers **IGNORING**
    * Continue styling the generated query pages. (Michael) **DONE**
    * Review TODOs. **IGNORING**
* Framebuffer
    * Listing of compiled-in surfaces (Daniel) **DONE**
* Internationalisation
    * Framebuffer front end.
    * Translations of all messages for the SSL/privacy internal query page.
    * Translations of all messages for the authentication internal query page.
    * Short of finding a native speaker there's not a lot we can do.  **Nothing**
* Text layout
  - Continue implementing. (Michael)
* Release 3.10
    * Which means do the work first needed to complete it
    * And then do Debian package releases, including removing framebuffer
      from Debian.
* Events
    * Michael to do more UI event support in NetSurf **SHITCANNED**

Pathway to 3.10
===============

* Complete RISC OS frontend support for pageinfo core window (vince) **DONE**
* Add url to about:query/ssl to launch cert viewer (the link needs _blank) (Daniel) **DONE**
* excise sslcert_viewer entirely (Daniel) **DONE**
  * Monkey doesn't need it, excise from farmer and driver **DONE**
  * Remove cert_verify from the `gui_misc_table` **DONE**
  * Email to developer list to say this has been done and that frontends
    will need to add padlock and page_info support **DONE**
* [[!bug 2752]] Building without openssl: acknowledged and assigned to Daniel. **DONE**
* [[!bug 2754]] GTK history delete menu options: acknowledged and assigned to Daniel. **DONE**
* [[!bug 2753]] RISC OS URL entry bug needs fixed. **DONE**


Bug Triage
==========

* [[!bug 2759]] To be closed when the web site doesn't mention MacOS any more.
* [[!bug 2740]] Wikipedia has its scrollbar on BODY instead of HTML.
* [[!bug 2755]] More Wikipedia scrollbars.
* [[!bug 2752]] Building without openssl: acknowledged and assigned to Daniel.
* [[!bug 2754]] GTK history delete menu options: acknowledged and assigned to Daniel.
* [[!bug 2753]] RISC OS URL entry bug needs fixed.
* [[!bug 2748]] Hubbub needs to know about these elements.
* [[!bug 2742]] Closed; no change required.

Topics
======

* HTML5 Canvas.
* Text layout (maybe).
* Selection cleanups.

Write ups
=========

Current Forms Handling
----------------------

### DOM / Gadget synchronization

Currently both the DOM and the NetSurf gadget for form input elements
store a representation of the current state of the form element.
JavaScript can modify the representation in the DOM.  Users can
modify the representation in the form gadget.

There is a `form_gadget_sync_with_dom()` in NetSurf's `form.c`.
This synchronizes the data both ways.  If the DOM has changed, then
the gadget representation is updated, and if the gadget has changed
then the DOM is updated.  If both have changed, the gadget version
wins.

The `form_gadget_sync_with_dom()` is called from:

* **[html/dom_event.c]** The DOMSubtreeModified callback.
* **[html/form.c]** The `form_gadget_update_value()` function, which is called
  from:
  * **[html/box_textarea.c]** The desktop/textarea widget callback for
    TEXTAREA_MSG_TEXT_MODIFIED.
  * **[html/html.c] The file upload handling in
    `html_set_file_gadget_filename()`.
* **[html/forms.c]** The `parse_input_element` function, which ends up getting
  called during box tree construction of the special box elements in
  **[html/box_special.c]**.

### NetSurf data structures

The `box` structure has a "gadget" member, which is a `struct form_control`
pointer.  These gadget pointers are set to the corresponding form_control
when the form_control is created during box construction.

The `html` content contains a forms linked list.  These are of type
`struct form`.  The linked list is created by `html_forms_get_forms()` in
**[html/forms.c]**, called from `html_begin_conversion()` in **[html/html.c]**.

Since box tree construction hasn't happened yet, this collects a list of
forms which are empty, containing no form controls.

The form controls are added to the form structures as the forms are created
during box construction.  Box construction happens later in the `dom_to_box`
call in `html_finish_conversion`.

The fact that the form controls are referenced in both the form structures
and from the box gadget member, and the fact that they aren't ref-counted
means that we often dare not free them.  So they leak everywhere.

It seems that the struct form is only created for the purposes of form
submission; to collect all the gadgets associated with the form.

Once more unto the breach dear friends…
---------------------------------------

### …or "how I learned to love HTML forms"

The goal is to fully replace the current HTML form handling with proper DOM
based forms.  To do this we need to resolve a number of operations.

1. Every kind of input element and so on needs its DOM behaviour writing
   if it is missing, or checking if it is present already
2. The form element needs to gain requisite methods for resetting and submitting
   which perform the flow including firing events as needed (or reacting to them)
3. The main HTML content needs to stop having a form construct entirely, instead
   deferring to the DOM in all matters form-related
4. Gadgets should be owned by the boxes and should entirely operate by means
   of the DOM nodes associated with their boxes.
5. The DOM becomes the canonical source of data.  If the DOM changes, then the
   gadgets react.  If the gadgets wish to change the DOM then they push their
   changed data into the DOM and cope if the DOM doesn't do entirely as they
   expected.

The final part is perhaps the hardest.  It will require gadget implementations
to register as event listeners on the dom nodes in question and cope with them
changing.  Done properly this will allow JS to change the options in a select
gadget at runtime etc.  An early part of dynamic content.

The various elements' specifications are here:

* [Categories of elements](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#form-categories)
  such as form-associated, reassociatable, submittable, labelable, etc.
* [`<form>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-form-element)
* [`<label>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-label-element)
* [`<input>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-input-element)
* [`<button>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-button-element)
* [`<select>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-select-element)
* [`<datalist>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-datalist-element)
* [`<optgroup>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-optgroup-element)
* [`<option>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-option-element)
* [`<textarea>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-textarea-element)
* [`<output>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-output-element)
* [`<progress>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-progress-element)
* [`<meter>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-meter-element)
* [`<fieldset>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-fieldset-element)
* [`<legend>`](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-legend-element)

Clearly when submitting a form, only the submittable elements are important for
computing the form submission variables.  Many of the above could reasonably be
ignored by us for now (e.g. `<output>`, `<meter>`, `<datalist>` etc).

One big piece of work will be in ensuring the form owner property of the
form-associated elements is managed properly.  The parser will need to collude
(via the treebuilder most likely) to suppress certain behaviours when inserting
a form element (or else will then have to reassociate the element on
insertion).  See [this
part](https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#association-of-controls-and-forms)
of the specification for more details on this.  This alone represents a large
chunk of work and nominally could be done without impacting on the current form
behaviour.

The [form submission algorithm][submitalgo] is not trivial - Some of it will
be done by the DOM and some of it will be done by the UA (NetSurf).  The act
of submission is managed by the UA though, including the firing of the submit
event.  The `.submit()` method on the form element has to somehow inform the
UA that submission is requested and how it is requested.  This could be done by
firing an internal event at the form which the HTML content is registered to
listen for, and that may indeed be the safest method.  i.e. the form fires
a libdom specific event saying "form wants to be submitted, this is why" and
the UA catches this in the `dom_event` part of the HTML content handler to
actually deal with the submission.

[submitalgo]: https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#form-submission-algorithm

In contrast the [form reset algorithm][resetalgo] is much simpler and is almost
entirely driven by the DOM instead.  Resetting elements are not supposed to fire
DOM events in the traditional sense, so it may make sense for there to be a
libdom event for this as well which gadgets can listen for.

[resetalgo]: https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#reset

All of the requisite bindings will need to be written to support the form
behaviours since driving this through the DOM may necessitate JS interactions
with the forms (e.g. validation).

## Unifying behaviour of `NodeList` and `HTMLCollection`

In order to support Forms properly, a `RadioNodeList` which inherits from
`NodeList` has to act as though it were a subview of an `HTMLFormControlsCollection`
which inherits from `HTMLCollection`.  Given that `NodeList` and `HTMLCollection`
are independent heirarchies (they are both top level types) there is nominally
no way for this to occur.

Plan:

1. Inside libdom, add the concept of a `_dom_live_node_view`
2. That type's API has ref/unref, implements the tree walker which takes a visitor
   function pointer.  The treewalker always returns the number of nodes it visited
   afterwards, to make counting easier.
3. The node visitor API is: `visitor(context, node, index) -> decision`
   where decision is one of `stop`, `traverse_siblings`, or `traverse_all`.
4. Rework `NodeList` in terms of this new API, the `NodeList` visitor method
   will be the current matching matching behaviour, plus the decision of whether
   to iterate deeply or not.  This will allow us to shake out the behaviours
   of the tree walker etc.
5. Rework `HTMLCollection` in terms of the new API.  The visitor method
   will, this time, need to match elements.  For named item lookup, the
   visitor will be able to stop iteration at that point since there's no point
   continuing.
6. a) Implement `HTMLFormControlsCollection` with its own `namedItem`
   method which, for the purposes of libdom, can return either an element or
   a radioitemlist - the client will have to deal with this.

   b) Implement `RadioItemList` so that it can be returned by (a).

   Note: These two will essentially have to share some logic in order to work
   compatibly.  Since (a) is sharing logic with `HTMLCollection` that ought
   to be moderately easy/safe to do.


Tasks
=====

* Review Vince's text selection change commit.
* Release 3.10:
  * Complete RISC OS page-info.
  * Any blockers from bug triage.
* Make some progress with text layout.
* Michael to update Wikipedia scrollbar bug.
* JavaScript / bindings stuff:
  - Upgrade Duktape.
  - Unimplemented JavaScript list.
  - Binding generator improvements.
  - Looking at NetSurf's JS error logs and see what we need to do.
  - Build time heap config for reuse.
* Remove MacOS from web site.

Activity
========

Mostly individual activity here

Michael
-------

* Rebuild on Ubuntu 20.04 and fixed some new compiler warnings.
* Fixed [[!bug 2748]]: Updated Hubbub to know about some more elements.

Daniel
------

* Performed `sslcert_viewer`-ectomy
* Reworked env to prefer cross-env
* Included link for query/ssl to display certs
* Made curl fetcher build without openssl again
* Made treeview cancellation behave right
* ...and made gtk global history and friends cope with select all
* Added `<canvas>` support
* Fixed bug in GTK Quit handling
* Altered logging in `fs_backing_store`
* Unbroke monkey driver timeout handling
* Added cookie counting to `browser_window`
* Reworked cookie presentation as a `guit->misc` callback
* ...for all the major frontends
* Fixed buffer overrun in idna
* Fixed leak in llcache when new cert chains turn up
* Wrote Game of Life test for Canvas
* Fixed int32 and ulong property setting in `html_element` in libdom
* Fixed title string handling in `html_title_element`
* Support more types in `_init()` handling in nsgenbind
* Used `output_ccode` in more places in nsgenbind
* Fixed AST generation for overloaded methods in nsgenbind


Vince
-----

* Clean up text selection code
* Implemenmt page infor core window for RISC OS
* fix core window implementation incorrectly (re)opening windows on resize
* fix [[!bug 2753]] and [[!bug 2762]]
* Update release process on wiki
* Release 3.10
* Update issue tracker for release

Statement of work
=================

If at all possible, we'd like to see some of the following addressed before
the next developer weekend…

* 

Next time
=========

* May 22nd to 26th (Fri through Tuesday)
* Remote / video conf / IRC.