summaryrefslogtreecommitdiff
path: root/developer-weekend/nov-2018.mdwn
blob: f296cd3281089022d1bb11e378915d98c7d95749 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
[[!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.

Next time
=========

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