Skip to content

may 2020

Jump to bottom
Michael Drake edited this page Jan 5, 2026 · 1 revision

!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:

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 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 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.

In contrast the form reset algorithm 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.

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.

Clone this wiki locally