blob: 2cda3a293b35fd037ff350d76c7fc9e3e24b9424 (
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
|
[[!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
### Discussion
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.)
Activity
========
Bug Triage
----------
* Group bug for line breaking issues is [[!bug 467]]
Daniel
------
Michael
-------
Vincent
-------
* fixup CI workers to be operational again
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 .
It shall be at
|
