diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | 1/index.md | 6 | ||||
| -rw-r--r-- | 10/index.md | 12 | ||||
| -rw-r--r-- | 100/index.md | 6 | ||||
| -rw-r--r-- | 101/index.md | 6 | ||||
| -rw-r--r-- | 102/index.md | 7 | ||||
| -rw-r--r-- | 103/index.md | 8 | ||||
| -rw-r--r-- | 104/index.md | 8 | ||||
| -rw-r--r-- | 105/index.md | 33 | ||||
| -rw-r--r-- | 106/index.md | 24 | ||||
| -rw-r--r-- | 107/index.md | 8 | ||||
| -rw-r--r-- | 108/index.md | 8 | ||||
| -rw-r--r-- | 109/index.md | 26 | ||||
| -rw-r--r-- | 11/index.md | 6 | ||||
| -rw-r--r-- | 110/index.md | 14 | ||||
| -rw-r--r-- | 111/index.md | 12 | ||||
| -rw-r--r-- | 112/index.md | 6 | ||||
| -rw-r--r-- | 113/index.md | 12 | ||||
| -rw-r--r-- | 114/index.md | 12 | ||||
| -rw-r--r-- | 115/index.md | 5 | ||||
| -rw-r--r-- | 116/index.md | 13 | ||||
| -rw-r--r-- | 117/index.md | 6 | ||||
| -rw-r--r-- | 118/index.md | 8 | ||||
| -rw-r--r-- | 119/index.md | 62 | ||||
| -rw-r--r-- | 12/index.md | 22 | ||||
| -rw-r--r-- | 120/index.md | 6 | ||||
| -rw-r--r-- | 121/index.md | 8 | ||||
| -rw-r--r-- | 122/index.md | 17 | ||||
| -rw-r--r-- | 123/index.md | 9 | ||||
| -rw-r--r-- | 124/index.md | 11 | ||||
| -rw-r--r-- | 125/index.md | 6 | ||||
| -rw-r--r-- | 126/index.md | 6 | ||||
| -rw-r--r-- | 127/index.md | 67 | ||||
| -rw-r--r-- | 128/index.md | 8 | ||||
| -rw-r--r-- | 129/index.md | 16 | ||||
| -rw-r--r-- | 13/index.md | 11 | ||||
| -rw-r--r-- | 130/index.md | 6 | ||||
| -rw-r--r-- | 131/index.md | 6 | ||||
| -rw-r--r-- | 132/index.md | 6 | ||||
| -rw-r--r-- | 133/index.md | 6 | ||||
| -rw-r--r-- | 134/index.md | 6 | ||||
| -rw-r--r-- | 135/index.md | 19 | ||||
| -rw-r--r-- | 136/index.md | 6 | ||||
| -rw-r--r-- | 137/index.md | 6 | ||||
| -rw-r--r-- | 138/index.md | 6 | ||||
| -rw-r--r-- | 139/index.md | 8 | ||||
| -rw-r--r-- | 14/index.md | 10 | ||||
| -rw-r--r-- | 140/index.md | 10 | ||||
| -rw-r--r-- | 141/index.md | 6 | ||||
| -rw-r--r-- | 142/index.md | 6 | ||||
| -rw-r--r-- | 143/index.md | 6 | ||||
| -rw-r--r-- | 144/index.md | 6 | ||||
| -rw-r--r-- | 145/index.md | 10 | ||||
| -rw-r--r-- | 146/index.md | 6 | ||||
| -rw-r--r-- | 147/index.md | 49 | ||||
| -rw-r--r-- | 148/index.md | 9 | ||||
| -rw-r--r-- | 149/index.md | 25 | ||||
| -rw-r--r-- | 15/index.md | 76 | ||||
| -rw-r--r-- | 150/index.md | 6 | ||||
| -rw-r--r-- | 151/index.md | 5 | ||||
| -rw-r--r-- | 152/index.md | 34 | ||||
| -rw-r--r-- | 153/index.md | 12 | ||||
| -rw-r--r-- | 154/index.md | 5 | ||||
| -rw-r--r-- | 155/index.md | 16 | ||||
| -rw-r--r-- | 156/index.md | 38 | ||||
| -rw-r--r-- | 157/index.md | 14 | ||||
| -rw-r--r-- | 158/index.md | 20 | ||||
| -rw-r--r-- | 159/index.md | 41 | ||||
| -rw-r--r-- | 16/index.md | 6 | ||||
| -rw-r--r-- | 160/index.md | 6 | ||||
| -rw-r--r-- | 161/index.md | 12 | ||||
| -rw-r--r-- | 162/index.md | 9 | ||||
| -rw-r--r-- | 163/index.md | 6 | ||||
| -rw-r--r-- | 164/index.md | 14 | ||||
| -rw-r--r-- | 165/index.md | 22 | ||||
| -rw-r--r-- | 166/index.md | 50 | ||||
| -rw-r--r-- | 167/index.md | 55 | ||||
| -rw-r--r-- | 168/index.md | 30 | ||||
| -rw-r--r-- | 169/index.md | 44 | ||||
| -rw-r--r-- | 17/index.md | 6 | ||||
| -rw-r--r-- | 170/index.md | 81 | ||||
| -rw-r--r-- | 171/index.md | 30 | ||||
| -rw-r--r-- | 172/index.md | 263 | ||||
| -rw-r--r-- | 173/index.md | 8 | ||||
| -rw-r--r-- | 174/index.md | 44 | ||||
| -rw-r--r-- | 175/index.md | 28 | ||||
| -rw-r--r-- | 176/index.md | 57 | ||||
| -rw-r--r-- | 177/index.md | 37 | ||||
| -rw-r--r-- | 178/index.md | 11 | ||||
| -rw-r--r-- | 179/index.md | 28 | ||||
| -rw-r--r-- | 18/index.md | 53 | ||||
| -rw-r--r-- | 180/index.md | 11 | ||||
| -rw-r--r-- | 181/index.md | 51 | ||||
| -rw-r--r-- | 182/index.md | 10 | ||||
| -rw-r--r-- | 183/index.md | 16 | ||||
| -rw-r--r-- | 184/index.md | 8 | ||||
| -rw-r--r-- | 185/index.md | 8 | ||||
| -rw-r--r-- | 186/index.md | 6 | ||||
| -rw-r--r-- | 187/index.md | 143 | ||||
| -rw-r--r-- | 188/index.md | 9 | ||||
| -rw-r--r-- | 189/index.md | 72 | ||||
| -rw-r--r-- | 19/index.md | 8 | ||||
| -rw-r--r-- | 190/index.md | 29 | ||||
| -rw-r--r-- | 191/index.md | 8 | ||||
| -rw-r--r-- | 192/index.md | 16 | ||||
| -rw-r--r-- | 193/index.md | 128 | ||||
| -rw-r--r-- | 194/index.md | 6 | ||||
| -rw-r--r-- | 195/index.md | 52 | ||||
| -rw-r--r-- | 196/index.md | 44 | ||||
| -rw-r--r-- | 197/index.md | 12 | ||||
| -rw-r--r-- | 198/index.md | 12 | ||||
| -rw-r--r-- | 199/index.md | 14 | ||||
| -rw-r--r-- | 2/index.md | 18 | ||||
| -rw-r--r-- | 20/index.md | 216 | ||||
| -rw-r--r-- | 200/index.md | 6 | ||||
| -rw-r--r-- | 201/index.md | 6 | ||||
| -rw-r--r-- | 202/index.md | 5 | ||||
| -rw-r--r-- | 203/index.md | 34 | ||||
| -rw-r--r-- | 204/index.md | 289 | ||||
| -rw-r--r-- | 205/index.md | 8 | ||||
| -rw-r--r-- | 206/index.md | 8 | ||||
| -rw-r--r-- | 207/index.md | 37 | ||||
| -rw-r--r-- | 208/index.md | 8 | ||||
| -rw-r--r-- | 209/index.md | 8 | ||||
| -rw-r--r-- | 21/index.md | 44 | ||||
| -rw-r--r-- | 210/index.md | 26 | ||||
| -rw-r--r-- | 211/index.md | 38 | ||||
| -rw-r--r-- | 212/index.md | 10 | ||||
| -rw-r--r-- | 213/index.md | 22 | ||||
| -rw-r--r-- | 214/index.md | 6 | ||||
| -rw-r--r-- | 215/index.md | 19 | ||||
| -rw-r--r-- | 216/index.md | 82 | ||||
| -rw-r--r-- | 217/index.md | 14 | ||||
| -rw-r--r-- | 218/index.md | 15 | ||||
| -rw-r--r-- | 219/index.md | 14 | ||||
| -rw-r--r-- | 22/index.md | 6 | ||||
| -rw-r--r-- | 220/index.md | 6 | ||||
| -rw-r--r-- | 221/index.md | 6 | ||||
| -rw-r--r-- | 222/index.md | 133 | ||||
| -rw-r--r-- | 223/index.md | 101 | ||||
| -rw-r--r-- | 224/index.md | 12 | ||||
| -rw-r--r-- | 225/index.md | 10 | ||||
| -rw-r--r-- | 226/index.md | 79 | ||||
| -rw-r--r-- | 227/index.md | 14 | ||||
| -rw-r--r-- | 228/index.md | 34 | ||||
| -rw-r--r-- | 229/index.md | 177 | ||||
| -rw-r--r-- | 23/index.md | 13 | ||||
| -rw-r--r-- | 230/index.md | 528 | ||||
| -rw-r--r-- | 231/index.md | 11 | ||||
| -rw-r--r-- | 232/index.md | 14 | ||||
| -rw-r--r-- | 233/index.md | 208 | ||||
| -rw-r--r-- | 234/index.md | 100 | ||||
| -rw-r--r-- | 235/index.md | 6 | ||||
| -rw-r--r-- | 236/index.md | 50 | ||||
| -rw-r--r-- | 237/index.md | 8 | ||||
| -rw-r--r-- | 238/index.md | 8 | ||||
| -rw-r--r-- | 239/index.md | 109 | ||||
| -rw-r--r-- | 24/index.md | 10 | ||||
| -rw-r--r-- | 240/index.md | 21 | ||||
| -rw-r--r-- | 241/index.md | 10 | ||||
| -rw-r--r-- | 242/index.md | 42 | ||||
| -rw-r--r-- | 243/index.md | 99 | ||||
| -rw-r--r-- | 244/index.md | 12 | ||||
| -rw-r--r-- | 245/index.md | 9 | ||||
| -rw-r--r-- | 246/index.md | 196 | ||||
| -rw-r--r-- | 247/index.md | 23 | ||||
| -rw-r--r-- | 248/index.md | 20 | ||||
| -rw-r--r-- | 249/index.md | 67 | ||||
| -rw-r--r-- | 25/index.md | 12 | ||||
| -rw-r--r-- | 250/index.md | 64 | ||||
| -rw-r--r-- | 251/index.md | 15 | ||||
| -rw-r--r-- | 252/index.md | 62 | ||||
| -rw-r--r-- | 253/index.md | 73 | ||||
| -rw-r--r-- | 254/index.md | 9 | ||||
| -rw-r--r-- | 255/index.md | 6 | ||||
| -rw-r--r-- | 256/index.md | 44 | ||||
| -rw-r--r-- | 257/index.md | 12 | ||||
| -rw-r--r-- | 258/index.md | 152 | ||||
| -rw-r--r-- | 26/index.md | 170 | ||||
| -rw-r--r-- | 262/index.md | 104 | ||||
| -rw-r--r-- | 263/index.md | 618 | ||||
| -rw-r--r-- | 264/index.md | 8 | ||||
| -rw-r--r-- | 265/index.md | 45 | ||||
| -rw-r--r-- | 266/index.md | 12 | ||||
| -rw-r--r-- | 267/index.md | 10 | ||||
| -rw-r--r-- | 268/index.md | 22 | ||||
| -rw-r--r-- | 269/index.md | 34 | ||||
| -rw-r--r-- | 27/index.md | 10 | ||||
| -rw-r--r-- | 270/index.md | 8 | ||||
| -rw-r--r-- | 271/index.md | 8 | ||||
| -rw-r--r-- | 272/index.md | 12 | ||||
| -rw-r--r-- | 273/index.md | 12 | ||||
| -rw-r--r-- | 274/index.md | 6 | ||||
| -rw-r--r-- | 275/index.md | 31 | ||||
| -rw-r--r-- | 276/index.md | 6 | ||||
| -rw-r--r-- | 277/index.md | 8 | ||||
| -rw-r--r-- | 278/index.md | 6 | ||||
| -rw-r--r-- | 279/index.md | 107 | ||||
| -rw-r--r-- | 28/index.md | 14 | ||||
| -rw-r--r-- | 280/index.md | 8 | ||||
| -rw-r--r-- | 281/index.md | 18 | ||||
| -rw-r--r-- | 282/index.md | 7 | ||||
| -rw-r--r-- | 283/index.md | 6 | ||||
| -rw-r--r-- | 284/index.md | 49 | ||||
| -rw-r--r-- | 285/index.md | 73 | ||||
| -rw-r--r-- | 286/index.md | 32 | ||||
| -rw-r--r-- | 287/index.md | 8 | ||||
| -rw-r--r-- | 288/index.md | 11 | ||||
| -rw-r--r-- | 289/index.md | 32 | ||||
| -rw-r--r-- | 29/index.md | 30 | ||||
| -rw-r--r-- | 290/index.md | 18 | ||||
| -rw-r--r-- | 291/index.md | 10 | ||||
| -rw-r--r-- | 292/index.md | 12 | ||||
| -rw-r--r-- | 293/index.md | 13 | ||||
| -rw-r--r-- | 294/index.md | 5 | ||||
| -rw-r--r-- | 295/index.md | 25 | ||||
| -rw-r--r-- | 296/index.md | 30 | ||||
| -rw-r--r-- | 297/index.md | 109 | ||||
| -rw-r--r-- | 298/index.md | 35 | ||||
| -rw-r--r-- | 299/index.md | 15 | ||||
| -rw-r--r-- | 3/index.md | 6 | ||||
| -rw-r--r-- | 30/index.md | 60 | ||||
| -rw-r--r-- | 300/index.md | 14 | ||||
| -rw-r--r-- | 301/index.md | 6 | ||||
| -rw-r--r-- | 302/index.md | 37 | ||||
| -rw-r--r-- | 303/index.md | 13 | ||||
| -rw-r--r-- | 304/index.md | 70 | ||||
| -rw-r--r-- | 305/index.md | 420 | ||||
| -rw-r--r-- | 306/index.md | 27 | ||||
| -rw-r--r-- | 307/index.md | 12 | ||||
| -rw-r--r-- | 308/index.md | 20 | ||||
| -rw-r--r-- | 309/index.md | 34 | ||||
| -rw-r--r-- | 31/index.md | 14 | ||||
| -rw-r--r-- | 310/index.md | 8 | ||||
| -rw-r--r-- | 311/index.md | 14 | ||||
| -rw-r--r-- | 312/index.md | 118 | ||||
| -rw-r--r-- | 313/index.md | 9 | ||||
| -rw-r--r-- | 314/index.md | 26 | ||||
| -rw-r--r-- | 315/index.md | 168 | ||||
| -rw-r--r-- | 316/index.md | 67 | ||||
| -rw-r--r-- | 317/index.md | 14 | ||||
| -rw-r--r-- | 318/index.md | 39 | ||||
| -rw-r--r-- | 319/index.md | 14 | ||||
| -rw-r--r-- | 32/index.md | 6 | ||||
| -rw-r--r-- | 320/index.md | 6 | ||||
| -rw-r--r-- | 321/index.md | 6 | ||||
| -rw-r--r-- | 322/index.md | 136 | ||||
| -rw-r--r-- | 323/index.md | 37 | ||||
| -rw-r--r-- | 324/index.md | 18 | ||||
| -rw-r--r-- | 325/index.md | 8 | ||||
| -rw-r--r-- | 326/index.md | 20 | ||||
| -rw-r--r-- | 327/index.md | 45 | ||||
| -rw-r--r-- | 328/index.md | 16 | ||||
| -rw-r--r-- | 329/index.md | 27 | ||||
| -rw-r--r-- | 33/index.md | 199 | ||||
| -rw-r--r-- | 330/index.md | 15 | ||||
| -rw-r--r-- | 331/index.md | 9 | ||||
| -rw-r--r-- | 332/index.md | 57 | ||||
| -rw-r--r-- | 333/index.md | 132 | ||||
| -rw-r--r-- | 334/index.md | 116 | ||||
| -rw-r--r-- | 335/index.md | 31 | ||||
| -rw-r--r-- | 336/index.md | 5 | ||||
| -rw-r--r-- | 337/index.md | 266 | ||||
| -rw-r--r-- | 338/index.md | 107 | ||||
| -rw-r--r-- | 339/index.md | 8 | ||||
| -rw-r--r-- | 34/index.md | 424 | ||||
| -rw-r--r-- | 340/index.md | 6 | ||||
| -rw-r--r-- | 341/index.md | 12 | ||||
| -rw-r--r-- | 342/index.md | 18 | ||||
| -rw-r--r-- | 343/index.md | 15 | ||||
| -rw-r--r-- | 344/index.md | 16 | ||||
| -rw-r--r-- | 345/index.md | 5 | ||||
| -rw-r--r-- | 346/index.md | 24 | ||||
| -rw-r--r-- | 347/index.md | 12 | ||||
| -rw-r--r-- | 348/index.md | 30 | ||||
| -rw-r--r-- | 349/index.md | 8 | ||||
| -rw-r--r-- | 35/index.md | 6 | ||||
| -rw-r--r-- | 350/index.md | 25 | ||||
| -rw-r--r-- | 351/index.md | 6 | ||||
| -rw-r--r-- | 352/index.md | 19 | ||||
| -rw-r--r-- | 353/index.md | 73 | ||||
| -rw-r--r-- | 354/index.md | 12 | ||||
| -rw-r--r-- | 355/index.md | 28 | ||||
| -rw-r--r-- | 356/index.md | 180 | ||||
| -rw-r--r-- | 357/index.md | 23 | ||||
| -rw-r--r-- | 358/index.md | 20 | ||||
| -rw-r--r-- | 359/index.md | 74 | ||||
| -rw-r--r-- | 36/index.md | 45 | ||||
| -rw-r--r-- | 360/index.md | 8 | ||||
| -rw-r--r-- | 361/index.md | 10 | ||||
| -rw-r--r-- | 362/index.md | 6 | ||||
| -rw-r--r-- | 363/index.md | 673 | ||||
| -rw-r--r-- | 364/index.md | 6 | ||||
| -rw-r--r-- | 365/index.md | 12 | ||||
| -rw-r--r-- | 366/index.md | 52 | ||||
| -rw-r--r-- | 367/index.md | 39 | ||||
| -rw-r--r-- | 368/index.md | 12 | ||||
| -rw-r--r-- | 369/index.md | 50 | ||||
| -rw-r--r-- | 37/index.md | 125 | ||||
| -rw-r--r-- | 370/index.md | 18 | ||||
| -rw-r--r-- | 371/index.md | 6 | ||||
| -rw-r--r-- | 372/index.md | 8 | ||||
| -rw-r--r-- | 373/index.md | 285 | ||||
| -rw-r--r-- | 374/index.md | 14 | ||||
| -rw-r--r-- | 375/index.md | 6 | ||||
| -rw-r--r-- | 376/index.md | 5 | ||||
| -rw-r--r-- | 377/index.md | 8 | ||||
| -rw-r--r-- | 378/index.md | 6 | ||||
| -rw-r--r-- | 379/index.md | 8 | ||||
| -rw-r--r-- | 38/index.md | 32 | ||||
| -rw-r--r-- | 380/index.md | 130 | ||||
| -rw-r--r-- | 381/index.md | 20 | ||||
| -rw-r--r-- | 382/index.md | 49 | ||||
| -rw-r--r-- | 383/index.md | 10 | ||||
| -rw-r--r-- | 384/index.md | 8 | ||||
| -rw-r--r-- | 385/index.md | 6 | ||||
| -rw-r--r-- | 386/index.md | 6 | ||||
| -rw-r--r-- | 387/index.md | 7 | ||||
| -rw-r--r-- | 388/index.md | 235 | ||||
| -rw-r--r-- | 389/index.md | 6 | ||||
| -rw-r--r-- | 39/index.md | 110 | ||||
| -rw-r--r-- | 390/index.md | 6 | ||||
| -rw-r--r-- | 391/index.md | 6 | ||||
| -rw-r--r-- | 392/index.md | 27 | ||||
| -rw-r--r-- | 393/index.md | 11 | ||||
| -rw-r--r-- | 394/index.md | 27 | ||||
| -rw-r--r-- | 395/index.md | 5 | ||||
| -rw-r--r-- | 396/index.md | 6 | ||||
| -rw-r--r-- | 397/index.md | 5 | ||||
| -rw-r--r-- | 398/index.md | 13 | ||||
| -rw-r--r-- | 399/index.md | 10 | ||||
| -rw-r--r-- | 4/index.md | 61 | ||||
| -rw-r--r-- | 40/index.md | 46 | ||||
| -rw-r--r-- | 400/index.md | 12 | ||||
| -rw-r--r-- | 401/index.md | 8 | ||||
| -rw-r--r-- | 402/index.md | 62 | ||||
| -rw-r--r-- | 403/index.md | 40 | ||||
| -rw-r--r-- | 404/index.md | 26 | ||||
| -rw-r--r-- | 405/index.md | 85 | ||||
| -rw-r--r-- | 406/index.md | 32 | ||||
| -rw-r--r-- | 407/index.md | 6 | ||||
| -rw-r--r-- | 408/index.md | 6 | ||||
| -rw-r--r-- | 409/index.md | 12 | ||||
| -rw-r--r-- | 41/index.md | 199 | ||||
| -rw-r--r-- | 410/index.md | 71 | ||||
| -rw-r--r-- | 411/index.md | 6 | ||||
| -rw-r--r-- | 412/index.md | 66 | ||||
| -rw-r--r-- | 413/index.md | 48 | ||||
| -rw-r--r-- | 414/index.md | 55 | ||||
| -rw-r--r-- | 415/index.md | 16 | ||||
| -rw-r--r-- | 416/index.md | 6 | ||||
| -rw-r--r-- | 417/index.md | 38 | ||||
| -rw-r--r-- | 418/index.md | 36 | ||||
| -rw-r--r-- | 419/index.md | 12 | ||||
| -rw-r--r-- | 42/index.md | 6 | ||||
| -rw-r--r-- | 420/index.md | 10 | ||||
| -rw-r--r-- | 421/index.md | 6 | ||||
| -rw-r--r-- | 422/index.md | 13 | ||||
| -rw-r--r-- | 423/index.md | 9 | ||||
| -rw-r--r-- | 424/index.md | 14 | ||||
| -rw-r--r-- | 425/index.md | 10 | ||||
| -rw-r--r-- | 426/index.md | 6 | ||||
| -rw-r--r-- | 427/index.md | 6 | ||||
| -rw-r--r-- | 428/index.md | 16 | ||||
| -rw-r--r-- | 429/index.md | 253 | ||||
| -rw-r--r-- | 429/meta | 4 | ||||
| -rw-r--r-- | 43/index.md | 17 | ||||
| -rw-r--r-- | 430/index.md | 8 | ||||
| -rw-r--r-- | 431/index.md | 6 | ||||
| -rw-r--r-- | 432/index.md | 6 | ||||
| -rw-r--r-- | 433/index.md | 114 | ||||
| -rw-r--r-- | 434/index.md | 38 | ||||
| -rw-r--r-- | 435/index.md | 6 | ||||
| -rw-r--r-- | 436/index.md | 6 | ||||
| -rw-r--r-- | 437/index.md | 8 | ||||
| -rw-r--r-- | 438/index.md | 19 | ||||
| -rw-r--r-- | 439/index.md | 18 | ||||
| -rw-r--r-- | 44/index.md | 61 | ||||
| -rw-r--r-- | 440/index.md | 32 | ||||
| -rw-r--r-- | 441/index.md | 8 | ||||
| -rw-r--r-- | 442/index.md | 10 | ||||
| -rw-r--r-- | 443/index.md | 12 | ||||
| -rw-r--r-- | 444/index.md | 10 | ||||
| -rw-r--r-- | 45/index.md | 38 | ||||
| -rw-r--r-- | 46/index.md | 12 | ||||
| -rw-r--r-- | 47/index.md | 107 | ||||
| -rw-r--r-- | 48/index.md | 6 | ||||
| -rw-r--r-- | 49/index.md | 121 | ||||
| -rw-r--r-- | 5/index.md | 56 | ||||
| -rw-r--r-- | 50/index.md | 20 | ||||
| -rw-r--r-- | 500/index.md | 8 | ||||
| -rw-r--r-- | 501/index.md | 40 | ||||
| -rw-r--r-- | 502/index.md | 12 | ||||
| -rw-r--r-- | 51/index.md | 305 | ||||
| -rw-r--r-- | 52/index.md | 84 | ||||
| -rw-r--r-- | 53/index.md | 104 | ||||
| -rw-r--r-- | 54/index.md | 33 | ||||
| -rw-r--r-- | 55/index.md | 8 | ||||
| -rw-r--r-- | 56/index.md | 78 | ||||
| -rw-r--r-- | 57/index.md | 6 | ||||
| -rw-r--r-- | 58/index.md | 6 | ||||
| -rw-r--r-- | 59/index.md | 24 | ||||
| -rw-r--r-- | 6/index.md | 69 | ||||
| -rw-r--r-- | 60/index.md | 6 | ||||
| -rw-r--r-- | 61/index.md | 6 | ||||
| -rw-r--r-- | 62/index.md | 12 | ||||
| -rw-r--r-- | 63/index.md | 63 | ||||
| -rw-r--r-- | 64/index.md | 6 | ||||
| -rw-r--r-- | 65/index.md | 395 | ||||
| -rw-r--r-- | 66/index.md | 6 | ||||
| -rw-r--r-- | 67/index.md | 83 | ||||
| -rw-r--r-- | 68/index.md | 6 | ||||
| -rw-r--r-- | 69/index.md | 74 | ||||
| -rw-r--r-- | 7/index.md | 20 | ||||
| -rw-r--r-- | 70/index.md | 51 | ||||
| -rw-r--r-- | 71/index.md | 27 | ||||
| -rw-r--r-- | 72/index.md | 8 | ||||
| -rw-r--r-- | 73/index.md | 6 | ||||
| -rw-r--r-- | 74/index.md | 29 | ||||
| -rw-r--r-- | 75/index.md | 6 | ||||
| -rw-r--r-- | 76/index.md | 8 | ||||
| -rw-r--r-- | 77/index.md | 15 | ||||
| -rw-r--r-- | 78/index.md | 19 | ||||
| -rw-r--r-- | 79/index.md | 314 | ||||
| -rw-r--r-- | 8/index.md | 59 | ||||
| -rw-r--r-- | 80/index.md | 10 | ||||
| -rw-r--r-- | 81/index.md | 6 | ||||
| -rw-r--r-- | 82/index.md | 8 | ||||
| -rw-r--r-- | 83/index.md | 6 | ||||
| -rw-r--r-- | 84/index.md | 52 | ||||
| -rw-r--r-- | 85/index.md | 37 | ||||
| -rw-r--r-- | 86/index.md | 18 | ||||
| -rw-r--r-- | 87/index.md | 8 | ||||
| -rw-r--r-- | 88/index.md | 30 | ||||
| -rw-r--r-- | 89/index.md | 307 | ||||
| -rw-r--r-- | 9/index.md | 6 | ||||
| -rw-r--r-- | 90/index.md | 20 | ||||
| -rw-r--r-- | 91/index.md | 41 | ||||
| -rw-r--r-- | 92/index.md | 8 | ||||
| -rw-r--r-- | 93/index.md | 65 | ||||
| -rw-r--r-- | 94/index.md | 10 | ||||
| -rw-r--r-- | 95/index.md | 16 | ||||
| -rw-r--r-- | 96/index.md | 6 | ||||
| -rw-r--r-- | 97/index.md | 17 | ||||
| -rw-r--r-- | 98/index.md | 22 | ||||
| -rw-r--r-- | 99/index.md | 100 | ||||
| -rw-r--r-- | LICENSE | 674 | ||||
| -rw-r--r-- | Makefile | 44 | ||||
| -rw-r--r-- | README.md | 33 | ||||
| -rw-r--r-- | src/export.py | 44 | ||||
| -rw-r--r-- | src/issue-entry.awk | 21 | ||||
| -rw-r--r-- | src/issue.awk | 73 | ||||
| -rwxr-xr-x | src/mkindex.sh | 25 | ||||
| -rwxr-xr-x | src/mkissue.sh | 5 | ||||
| -rwxr-xr-x | src/mknew.sh | 18 | ||||
| -rwxr-xr-x | src/mkrow.sh | 10 | ||||
| -rw-r--r-- | src/style.css | 91 |
457 files changed, 19386 insertions, 0 deletions
diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..ab87873 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.out diff --git a/1/index.md b/1/index.md new file mode 100644 index 0000000..15254d4 --- /dev/null +++ b/1/index.md @@ -0,0 +1,6 @@ +Title: arXiv PDF download aborts +Author: rodarima +Created: Sun, 28 Jul 2019 23:28:23 +0000 +State: closed + +PDF cannot be downloaded from arXiv with dillo. It may be related to the User Agent or cookies. Example: https://arxiv.org/abs/astro-ph/9805121
\ No newline at end of file diff --git a/10/index.md b/10/index.md new file mode 100644 index 0000000..b5df238 --- /dev/null +++ b/10/index.md @@ -0,0 +1,12 @@ +Title: Enable HTTPS support by default +Author: rodarima +Created: Mon, 11 Dec 2023 00:25:32 +0000 +State: closed + +The --disable-ssl can be used to build dillo without https support. + +--%-- +From: rodarima +Date: Fri, 22 Dec 2023 20:21:24 +0000 + +Fixed in #27
\ No newline at end of file diff --git a/100/index.md b/100/index.md new file mode 100644 index 0000000..0cbf6f9 --- /dev/null +++ b/100/index.md @@ -0,0 +1,6 @@ +Title: Add Hacker News test +Author: rodarima +Created: Sun, 17 Mar 2024 19:31:09 +0000 +State: closed + +Add a table test for Hacker News (#99) and another for content being draw out of the viewport.
\ No newline at end of file diff --git a/101/index.md b/101/index.md new file mode 100644 index 0000000..f11b250 --- /dev/null +++ b/101/index.md @@ -0,0 +1,6 @@ +Title: Fix hackernews test +Author: rodarima +Created: Fri, 22 Mar 2024 23:39:43 +0000 +State: closed + +Fixes #99
\ No newline at end of file diff --git a/102/index.md b/102/index.md new file mode 100644 index 0000000..c974e6b --- /dev/null +++ b/102/index.md @@ -0,0 +1,7 @@ +Title: Free auxiliary string in File_normalize_path() +Author: rodarima +Created: Sat, 23 Mar 2024 11:12:07 +0000 +State: closed + +Fixes: https://github.com/dillo-browser/dillo/issues/87 +Reported-by: dogma
\ No newline at end of file diff --git a/103/index.md b/103/index.md new file mode 100644 index 0000000..744e353 --- /dev/null +++ b/103/index.md @@ -0,0 +1,8 @@ +Title: Use dGethomedir() to get the home directory +Author: rodarima +Created: Sat, 23 Mar 2024 23:18:10 +0000 +State: closed + +Other platforms don't use $HOME. + +Reported-by: dogma
\ No newline at end of file diff --git a/104/index.md b/104/index.md new file mode 100644 index 0000000..197b651 --- /dev/null +++ b/104/index.md @@ -0,0 +1,8 @@ +Title: Add build instructions for Windows with Cygwin +Author: rodarima +Created: Sun, 24 Mar 2024 16:51:11 +0000 +State: closed + + + +DPIs are not working fine, we probably need to change the extension to .exe as in this patch: https://github.com/cygwinports-extras/dillo/blob/master/3.0.2-exeext.patch
\ No newline at end of file diff --git a/105/index.md b/105/index.md new file mode 100644 index 0000000..dfee44e --- /dev/null +++ b/105/index.md @@ -0,0 +1,33 @@ +Title: Cannot run DPI plugins on Cygwin +Author: rodarima +Created: Thu, 28 Mar 2024 18:19:14 +0000 +State: closed + +``` +** WARNING **: preferred cursive font "URW Chancery L" not found. +Nav_open_url: new url='file:/' +** ERROR **: [Dpi_read_comm_keys] No such file or directory +[dpid]: get_file_type: Unknown file type for bookmarks.dpi.exe +[dpid]: get_dpi_attr: No dpi plug-in in /usr/local/lib/dillo/dpi/bookmarks +[dpid]: get_file_type: Unknown file type for cookies.dpi.exe +[dpid]: get_dpi_attr: No dpi plug-in in /usr/local/lib/dillo/dpi/cookies +[dpid]: get_file_type: Unknown file type for datauri.filter.dpi.exe +[dpid]: get_dpi_attr: No dpi plug-in in /usr/local/lib/dillo/dpi/datauri +Dpi_blocking_start_dpid: try 1 +[dpid]: get_file_type: Unknown file type for downloads.dpi.exe +[dpid]: get_dpi_attr: No dpi plug-in in /usr/local/lib/dillo/dpi/downloads +[dpid]: get_file_type: Unknown file type for file.dpi.exe +[dpid]: get_dpi_attr: No dpi plug-in in /usr/local/lib/dillo/dpi/file +[dpid]: get_file_type: Unknown file type for ftp.filter.dpi.exe +[dpid]: get_dpi_attr: No dpi plug-in in /usr/local/lib/dillo/dpi/ftp +[dpid]: get_file_type: Unknown file type for hello.filter.dpi.exe +[dpid]: get_dpi_attr: No dpi plug-in in /usr/local/lib/dillo/dpi/hello +[dpid]: get_file_type: Unknown file type for vsource.filter.dpi.exe +[dpid]: get_dpi_attr: No dpi plug-in in /usr/local/lib/dillo/dpi/vsource +[dpid]: a_Misc_mksecret: 7ce8fe12 +dpid started +Dpi_get_server_port: can't read server port from dpid. +Dillo: normal exit! +``` + +See https://github.com/cygwinports-extras/dillo/blob/master/3.0.2-exeext.patch
\ No newline at end of file diff --git a/106/index.md b/106/index.md new file mode 100644 index 0000000..11aa454 --- /dev/null +++ b/106/index.md @@ -0,0 +1,24 @@ +Title: Merge some patches from Livio Baldini +Author: rodarima +Created: Thu, 28 Mar 2024 18:28:17 +0000 +State: closed + +From: https://www.linux.ime.usp.br/~livio/dillo/ + +>- [save_scrolling_position.diff](https://www.linux.ime.usp.br/~livio/dillo/save_scrolling_position.diff) - (against 0.6.0) This adds a feature to Dillo. It records the last position the user scrolled to in a page, and when the user gets "Back" to that page, that position is used, instead of always going to the top! +> +>- [file.diff](https://www.linux.ime.usp.br/~livio/dillo/file.diff) - (against 0.3.0) This doesn't fix any bug, but fixes a Dillo behaviour which I consider to be wrong. When you type in an URL like: +>``` +> /home/livio/ +> ``` +> Dillo will try to search for the server http://home/livio. I think this is wrong, instead dillo should "guess" this is a local file and try to resolve file:/home/livio. + +[save_scrolling_position.diff.txt](https://github.com/dillo-browser/dillo/files/14793967/save_scrolling_position.diff.txt) +[file.diff.txt](https://github.com/dillo-browser/dillo/files/14793981/file.diff.txt) + + +--%-- +From: ghost +Date: Sat, 05 Oct 2024 13:40:47 +0000 + +These patches are ancient and for the gtk version of Dillo. The first one I think is unnecessary since that feature is already implemented. The second one may be a dupe of issue #88, and would need to be completely re-written anyway. I suggest closing this issue.
\ No newline at end of file diff --git a/107/index.md b/107/index.md new file mode 100644 index 0000000..ab3042b --- /dev/null +++ b/107/index.md @@ -0,0 +1,8 @@ +Title: Add windows CI +Author: rodarima +Created: Thu, 28 Mar 2024 19:15:23 +0000 +State: closed + +Add a Windows build to the CI using Cygwin and add the build process in the documentation. A small fix is also needed to let the DPI daemon find the DPI plugins when they have the ".dpi.exe" extension. + +Fixes #104
\ No newline at end of file diff --git a/108/index.md b/108/index.md new file mode 100644 index 0000000..651e574 --- /dev/null +++ b/108/index.md @@ -0,0 +1,8 @@ +Title: Make the Bookmarks page more readable +Author: rodarima +Created: Sun, 31 Mar 2024 19:57:13 +0000 +State: closed + +At least we should increase the contrast between text and background. Also, the design looks very old, maybe we can improve it a bit. + + diff --git a/109/index.md b/109/index.md new file mode 100644 index 0000000..3e2a2d8 --- /dev/null +++ b/109/index.md @@ -0,0 +1,26 @@ +Title: Main element doesn't behave like a div +Author: rodarima +Created: Sun, 31 Mar 2024 21:06:02 +0000 +State: closed + +```html +<!DOCTYPE html> +<html> + <head> + <title>Main should behave like a div</title> + </head> + <body> + <div style="margin-left: 20em; background: lightgreen"> + div + </div> + <main style="margin-left: 20em; background: lightgreen"> + main + </main> + <header style="margin-left: 20em; background: lightgreen"> + header + </header> + </body> +</html> +``` +Renders: + diff --git a/11/index.md b/11/index.md new file mode 100644 index 0000000..c4f6f7e --- /dev/null +++ b/11/index.md @@ -0,0 +1,6 @@ +Title: Add preliminary support for thead, tbody and tfoot +Author: rodarima +Created: Mon, 11 Dec 2023 01:07:30 +0000 +State: closed + +See [Walley master](https://github.com/rodarima/dillo/pull/7)
\ No newline at end of file diff --git a/110/index.md b/110/index.md new file mode 100644 index 0000000..f85a1d4 --- /dev/null +++ b/110/index.md @@ -0,0 +1,14 @@ +Title: Add support for the main HTML tag +Author: rodarima +Created: Sun, 31 Mar 2024 21:36:28 +0000 +State: closed + +Fixes: https://github.com/dillo-browser/dillo/issues/109 + +This was also affecting some pages that depended on styles applied to the `main` tag. + +## Before + + +## After + diff --git a/111/index.md b/111/index.md new file mode 100644 index 0000000..fd090b5 --- /dev/null +++ b/111/index.md @@ -0,0 +1,12 @@ +Title: Improve readability of bookmarks +Author: rodarima +Created: Mon, 01 Apr 2024 14:06:49 +0000 +State: closed + +Simplifies and increases the contrast of the Bookmark pages and menus. Tables are removed in favor of HTML5 elements. For styles we add a simple CSS style sheet, common for all pages. + +Fixes: https://github.com/dillo-browser/dillo/issues/108 + + + + diff --git a/112/index.md b/112/index.md new file mode 100644 index 0000000..69b8adc --- /dev/null +++ b/112/index.md @@ -0,0 +1,6 @@ +Title: Remove table styling in bookmarks +Author: rodarima +Created: Mon, 01 Apr 2024 19:09:07 +0000 +State: closed + +Reported-by: dogma
\ No newline at end of file diff --git a/113/index.md b/113/index.md new file mode 100644 index 0000000..4a2238e --- /dev/null +++ b/113/index.md @@ -0,0 +1,12 @@ +Title: Update HTML validator links +Author: rodarima +Created: Mon, 01 Apr 2024 19:34:00 +0000 +State: closed + +The old method "http://validator.w3.org/check?uri=%s" no longer works. + +--%-- +From: rodarima +Date: Mon, 01 Apr 2024 20:22:11 +0000 + +We can only do it by manually selecting HTML 5 or 4.01, otherwise their redirection to Nu forces JS.
\ No newline at end of file diff --git a/114/index.md b/114/index.md new file mode 100644 index 0000000..2d50fb1 --- /dev/null +++ b/114/index.md @@ -0,0 +1,12 @@ +Title: Fix HTML validator menu +Author: rodarima +Created: Mon, 01 Apr 2024 20:34:11 +0000 +State: closed + +The W3C validator is now protected under a CloudFlare JavaScript challenge. However, it can be bypassed by opening directly the link after the redirection. It doesn't work if an HTML 5 page is loaded, as that would redirect to the Nu validator which will attempt to run the challenge again. + +So the current solution is to use the "legacy" W3C validator for HTML 4.01 or older documents and the W3C Nu validator for HTML 5 documents only. Users would need to choose which one to use manually (at least for now). + +The WDG validator at https://www.htmlhelp.org/tools/validator/ is gone, the server reports "Server unable to read htaccess file, denying access to be safe", so it has been removed. + +Fixes: https://github.com/dillo-browser/dillo/issues/113
\ No newline at end of file diff --git a/115/index.md b/115/index.md new file mode 100644 index 0000000..6d1fdf6 --- /dev/null +++ b/115/index.md @@ -0,0 +1,5 @@ +Title: Fix minor issues with bookmarks +Author: rodarima +Created: Mon, 01 Apr 2024 20:50:46 +0000 +State: closed + diff --git a/116/index.md b/116/index.md new file mode 100644 index 0000000..feda5c4 --- /dev/null +++ b/116/index.md @@ -0,0 +1,13 @@ +Title: Prepare release 3.1.0-rc1 +Author: rodarima +Created: Mon, 01 Apr 2024 21:40:14 +0000 +State: closed + +I need to decide some things before releasing 3.1.0, but at least all blockers are gone (for now). + +- [x] Decide release signing key: 3EE6BA977EB2A253 +- [x] Decide version scheme: 3.1.0 following Semver. +- [x] Decide which .zip/.tar.gz would be included and if we autogen the configure: Both tar.gz and zip, with `make dist-$fmt` +- [x] Decide if we want to make a release candidate first (probably good idea, at least for some weeks) or no. Yes. +- [x] Prepare release notes for the release page and also the website. The changelog is going to be gigantic, so we may want a summary. +- [x] Change version to 3.1.0-rc1 in configure.ac
\ No newline at end of file diff --git a/117/index.md b/117/index.md new file mode 100644 index 0000000..6598877 --- /dev/null +++ b/117/index.md @@ -0,0 +1,6 @@ +Title: The user manual has some HTML5 errors and warnings +Author: rodarima +Created: Mon, 01 Apr 2024 22:24:52 +0000 +State: closed + +https://validator.w3.org/nu/?doc=https%3A%2F%2Fdillo-browser.github.io%2Fuser_help.html
\ No newline at end of file diff --git a/118/index.md b/118/index.md new file mode 100644 index 0000000..2e2a754 --- /dev/null +++ b/118/index.md @@ -0,0 +1,8 @@ +Title: tls_openssl.c:(.text+0xc70): undefined reference to `SSL_get_peer_certificate' on NetBSD +Author: rodarima +Created: Tue, 02 Apr 2024 22:38:17 +0000 +State: closed + +We shouldn't be using SSL_get_peer_certificate(): + +https://www.openssl.org/docs/manmaster/man3/SSL_get_peer_certificate.html
\ No newline at end of file diff --git a/119/index.md b/119/index.md new file mode 100644 index 0000000..45a826d --- /dev/null +++ b/119/index.md @@ -0,0 +1,62 @@ +Title: Relative goto actions +Author: rodarima +Created: Wed, 03 Apr 2024 09:46:12 +0000 +State: open + +From #88 + +> I would rather want a "relative mode". For example, if the current URL is http://example.net/examples/42.html and you type / then it will go to http://example.net/ and if you type ~/ then it will go to http://example.net/examples/~/. It would do this with all URLs, not only those ones. If you include the scheme then it is an absolute URL. (I have managed to modify Firefox to work like this.) + +This can be made by adding two extra actions that select a partial segment of the path, allowing the user to type a replacement: + +- `goto-path` would select only `https://example.org`<b>`/foo/bar.html`</b> +- `goto-filename` would select only `https://example.org/foo/`<b>`bar.html`</b> +- `goto` would select the whole thing, as we currently do with Ctrl+L + +Then the user can type there whatever you need. Mapping those actions to `/` and `~` in `~/.dillo/keysrc` would cause a similar effect as what you describe. + +CC @zzo38 + +--%-- +From: zzo38 +Date: Wed, 08 May 2024 20:59:29 +0000 + +This is a rather more complicated and messy way of an actual relative mode. Rather, it should be a separate option (or possibly a binding which can be mapped to the enter key while the URL is focused), which treats any entered URL as relative to the current URL. (This is also what line mode browser does, and it is more useful than what most modern browsers do, in my opinion.) + +--%-- +From: rodarima +Date: Wed, 08 May 2024 22:09:19 +0000 + +> This is a rather more complicated and messy way of an actual relative mode. Rather, it should be a separate option (or possibly a binding which can be mapped to the enter key while the URL is focused), which treats any entered URL as relative to the current URL. (This is also what line mode browser does, and it is more useful than what most modern browsers do, in my opinion.) + +I think I understand what you mean, but it would be nice if you provide some more extra examples of how you would use it, as I'm not familiar with the relative addressing in the line mode browser. Specifically, where do you "type" the relative address, at the end of the URL? In another buffer? Or the URL is cleared? + +I guess that when you are in the location bar you could enter a "relative addressing mode" and then you type in a special buffer (not necessarily editting the URL), and based on what you type the location is changed accordingly when you press enter. + +Or you can just press a key binding to enter relative addressing by reusing the location bar, which is erased and then what you type there is a relative URL and will be applied when you press enter (assuming you don't need to see the previous address). + +We could also assume that having the location URL selected via Ctrl+L allows relative addressing, so if at that point you type ~, the file part of the url is removed and you can begin typing your relative path. And the same for /. If you would like to instead type ~ or /, you simple erase the location bar first. + +Apart from / and ~, are there any other special addressing symbols? Also, do you expect it to be able to paste a relative address? Does it have to be those symbols?, in non US keyboards, the tilde ~ requires Alt Gr, so I would rather prefer to have a configurable keybinding instead. As I will access the location bar with Ctrl+L, while I keep the Ctrl key pressed, I could use Ctrl+L and then Ctrl+R (for example) to select the URL and then erase the current file in the path, and begin typing the next one. + +In any case, I believe that having a visual guidance would be more easy to understand for non-expert users. + +As a side note, if you press Ctrl+Shift and then the arrow keys you can select the URL by parts, like in other browsers. + +--%-- +From: zzo38 +Date: Fri, 10 May 2024 22:57:19 +0000 + +> I'm not familiar with the relative addressing in the line mode browser. Specifically, where do you "type" the relative address, at the end of the URL? + +Line mode browser uses command-line interface; the `g` command will go to a specified relative URL (or absolute if it includes a scheme). + +> Apart from / and ~, are there any other special addressing symbols? + +Any text entered would be treated as a relative URL (unless it includes a scheme, in which case it is absolute), regardless of the symbols used. + +(It is effectively the same as though you are following a link from the current document that has a `<a href>` with the user-entered URL, except that `<base>` is ignored and security features restricting cross-site linking are ignored; e.g. if you type `G.html` and you are currently at `http://example.org/y.html` then you will go to `http://example.org/G.html`.) + +> in non US keyboards, the tilde ~ requires Alt Gr, so I would rather prefer to have a configurable keybinding instead + +I agree with this; the keybinding could be mapped to "go to relative URL"; if you use that keybinding and then type a URL that includes a scheme, then it has the same effect as "go to absolute URL". (Alternatively, it could be a separate setting which affects the behaviour of the location bar. Another alternative would be a key binding which is attached to the location bar (if it supports attaching key bindings to widgets in this way; I don't know if it does) so only works if the location bar is focused; the enter key would be mapped to "go to absolute URL" by default, but you can remap it to "go to relative URL" if you prefer.)
\ No newline at end of file diff --git a/12/index.md b/12/index.md new file mode 100644 index 0000000..4677f7e --- /dev/null +++ b/12/index.md @@ -0,0 +1,22 @@ +Title: Dropped from Gentoo +Author: rodarima +Created: Sun, 17 Dec 2023 18:18:11 +0000 +State: closed + +We could merge the leftover patches and maybe ping Gentoo to keep it afloat. + +https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=98573254e171f5de8c91588ea39c4fa2f499e563 + +--%-- +From: Kangie +Date: Sat, 01 Jun 2024 00:51:21 +0000 + +Resolved! + +https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b07732fc411f73372f4dda5241cbfe80c2cbfbf1 + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 11:05:38 +0000 + +Thanks! I'm happy to see it coming back to Gentoo.
\ No newline at end of file diff --git a/120/index.md b/120/index.md new file mode 100644 index 0000000..3a9c9a8 --- /dev/null +++ b/120/index.md @@ -0,0 +1,6 @@ +Title: Fix manual typos and clarify some parts +Author: rodarima +Created: Thu, 04 Apr 2024 18:52:01 +0000 +State: closed + +Reported-by: dogma, monkeybusiness
\ No newline at end of file diff --git a/121/index.md b/121/index.md new file mode 100644 index 0000000..8c5db60 --- /dev/null +++ b/121/index.md @@ -0,0 +1,8 @@ +Title: Use SSL_get1_peer_certificate() in OpenSSL 3 +Author: rodarima +Created: Thu, 04 Apr 2024 22:00:33 +0000 +State: closed + +The function SSL_get_peer_certificate() is deprecated in 3.0.0, but still defined as a compatibility macro. + +Fixes: https://github.com/dillo-browser/dillo/issues/118
\ No newline at end of file diff --git a/122/index.md b/122/index.md new file mode 100644 index 0000000..80ce04e --- /dev/null +++ b/122/index.md @@ -0,0 +1,17 @@ +Title: Reverse scroll wheel tab switching +Author: rodarima +Created: Fri, 05 Apr 2024 09:45:18 +0000 +State: closed + +Via email: + +> In my opinion the behavior of the mouse wheel tab switching is +backwards. Scrolling up switches to the previous tab, and down goes to +the next tab. This seems unintuitive and I find myself frequently +scrolling in the wrong direction. + +--%-- +From: rodarima +Date: Mon, 08 Apr 2024 18:51:09 +0000 + +Patch: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/F2EF4NHF3CBMJ3XZII2TFIE6MSXEE5AD/
\ No newline at end of file diff --git a/123/index.md b/123/index.md new file mode 100644 index 0000000..20cbc35 --- /dev/null +++ b/123/index.md @@ -0,0 +1,9 @@ +Title: Control the direction of tab scrolling +Author: rodarima +Created: Mon, 08 Apr 2024 19:30:23 +0000 +State: closed + +Adds the `scroll_switches_tabs_reverse` option in dillorc to allows reversing the direction of tab switching based on the movement of the mouse wheel. + +Fixes: #122 +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/F2EF4NHF3CBMJ3XZII2TFIE6MSXEE5AD/
\ No newline at end of file diff --git a/124/index.md b/124/index.md new file mode 100644 index 0000000..243ca16 --- /dev/null +++ b/124/index.md @@ -0,0 +1,11 @@ +Title: Allow opening a custom page when opening a new tab +Author: rodarima +Created: Mon, 08 Apr 2024 19:46:36 +0000 +State: closed + +As reported by Alex, it can be useful to allow the user to open a custom page when opening a new tab, like the bookmarks. + +> Another feature I would be interested in is setting a new tab +destination. For instance, it would be neat to show bookmarks +automatically when opening a new tab. Is this something which has been +looked at already?
\ No newline at end of file diff --git a/125/index.md b/125/index.md new file mode 100644 index 0000000..8041b99 --- /dev/null +++ b/125/index.md @@ -0,0 +1,6 @@ +Title: Clarify building instructions +Author: rodarima +Created: Mon, 08 Apr 2024 19:52:28 +0000 +State: closed + +The steps for the build process recommend performing the build in the source directory, which is not a good idea. Also, we should list all packages for Debian to build Dillo, so they can be installed easily.
\ No newline at end of file diff --git a/126/index.md b/126/index.md new file mode 100644 index 0000000..29837bf --- /dev/null +++ b/126/index.md @@ -0,0 +1,6 @@ +Title: Improve build docs +Author: rodarima +Created: Mon, 08 Apr 2024 20:50:10 +0000 +State: closed + +Fixes #125
\ No newline at end of file diff --git a/127/index.md b/127/index.md new file mode 100644 index 0000000..742bcff --- /dev/null +++ b/127/index.md @@ -0,0 +1,67 @@ +Title: bookmark sections' title lines look confusing +Author: drawkula +Created: Tue, 09 Apr 2024 15:14:59 +0000 +State: closed + +The titles of the bookmark sections look like progress bars. +Probably a side effect of their title length. + + + + +--%-- +From: rodarima +Date: Tue, 09 Apr 2024 15:19:38 +0000 + +This should be fixed in master (see https://github.com/dillo-browser/dillo/pull/111 and https://github.com/dillo-browser/dillo/pull/115). + +--%-- +From: drawkula +Date: Tue, 09 Apr 2024 16:02:25 +0000 + +According to `git log` it is a fresh source ... but I still may have 20 left thumbs with GUIs... + + + + +--%-- +From: rodarima +Date: Tue, 09 Apr 2024 16:20:47 +0000 + +How are you installing Dillo after building it?, and what is the value of the path of `dpi_dir` in `~/.dillo/dpidrc`? + +You may be running the bookmark plugin from another installation where `dpi_dir` is pointing to. If so, try setting `dpi_dir` it to the location you installed the new Dillo (see the `--prefix=...` flag at configure time). + +--%-- +From: drawkula +Date: Wed, 10 Apr 2024 02:30:46 +0000 + +Can (under some strange circumstances) `dpid` and the old `/opt/dillo/lib/dillo/dpi/bookmarks/bookmarks.dpi` have been still running? + +Despite rebuilding several times I could not see the new bookmarks yesterday, gave up, but today I see a change without rebuilding. In between the system only was suspended, not rebooted and since the last try where I still saw the old bookmarks there was no new rebuild/install. + +I closed a freshly started `dillo` again and still see... +``` +$ ps U$USER | egrep 'dpi|dillo' +1281453 ? S 0:00 dpid +1281454 ? S 0:00 /opt/dillo/lib/dillo/dpi/bookmarks/bookmarks.dpi +1281604 pts/2 S+ 0:00 grep -E dpi|dillo +``` +Not waiting for a timeout or such now... killing them. + +That's my best candidate for an explanation so far. + + +--%-- +From: rodarima +Date: Wed, 10 Apr 2024 18:52:18 +0000 + +> Can (under some strange circumstances) `dpid` and the old `/opt/dillo/lib/dillo/dpi/bookmarks/bookmarks.dpi` have been still running? + +Yes, dpid keeps running for some time as well as the bookmarks.dpi (or any other *server* plugin recently used). To stop the daemon and the plugins you can use: + +``` +$ dpidc stop +``` + +Dillo will start dpid again next time and load the new plugins.
\ No newline at end of file diff --git a/128/index.md b/128/index.md new file mode 100644 index 0000000..00d9e6e --- /dev/null +++ b/128/index.md @@ -0,0 +1,8 @@ +Title: The libgif library is not a dependency +Author: rodarima +Created: Tue, 09 Apr 2024 16:27:26 +0000 +State: closed + +Dillo comes with a builtin GIF decoder, we don't need libgif. + +Reported-by: dogma.
\ No newline at end of file diff --git a/129/index.md b/129/index.md new file mode 100644 index 0000000..949de42 --- /dev/null +++ b/129/index.md @@ -0,0 +1,16 @@ +Title: Remove libgif dependency from docs +Author: rodarima +Created: Wed, 10 Apr 2024 19:33:26 +0000 +State: closed + +The libgif library is not needed as Dillo has a builtin GIF support. + +Fixes: https://github.com/dillo-browser/dillo/issues/128 +Reported-by: dogma + +--%-- +From: rodarima +Date: Wed, 10 Apr 2024 19:46:13 +0000 + +Windows build failing due to cygwin.com [being down](https://github.com/cygwin/cygwin-install-action/issues/9#issuecomment-2048176827): +> There is some sort of incident with sourceware connectivity presently: https://fosstodon.org/@sourceware/112247941377987967
\ No newline at end of file diff --git a/13/index.md b/13/index.md new file mode 100644 index 0000000..752a0e5 --- /dev/null +++ b/13/index.md @@ -0,0 +1,11 @@ +Title: Update README +Author: rodarima +Created: Sun, 17 Dec 2023 18:55:07 +0000 +State: closed + +Tidy REAME: + +- [x] update the README and move some internal details to some other documents +- [x] mention the current state of the dillo.org website +- [x] describe the state of this repo +- [x] place links to other forks of dillo
\ No newline at end of file diff --git a/130/index.md b/130/index.md new file mode 100644 index 0000000..ba75f61 --- /dev/null +++ b/130/index.md @@ -0,0 +1,6 @@ +Title: Use current version as user agent in downloads +Author: rodarima +Created: Thu, 11 Apr 2024 17:32:29 +0000 +State: closed + +The hardcoded version 3.0.5 is used.
\ No newline at end of file diff --git a/131/index.md b/131/index.md new file mode 100644 index 0000000..68a2c77 --- /dev/null +++ b/131/index.md @@ -0,0 +1,6 @@ +Title: Use the current version in wget user agent +Author: rodarima +Created: Thu, 11 Apr 2024 18:20:16 +0000 +State: closed + +Fixes: https://github.com/dillo-browser/dillo/issues/130
\ No newline at end of file diff --git a/132/index.md b/132/index.md new file mode 100644 index 0000000..99326ef --- /dev/null +++ b/132/index.md @@ -0,0 +1,6 @@ +Title: Release version 3.1.0-rc1 +Author: rodarima +Created: Thu, 11 Apr 2024 18:47:57 +0000 +State: closed + +Closes #116
\ No newline at end of file diff --git a/133/index.md b/133/index.md new file mode 100644 index 0000000..56e89c1 --- /dev/null +++ b/133/index.md @@ -0,0 +1,6 @@ +Title: Add nex plugin +Author: rodarima +Created: Thu, 11 Apr 2024 20:53:58 +0000 +State: open + +Test and create a Nex plugin from @drawkula under dillo-browser: https://yeti.tilde.institute/dillo/
\ No newline at end of file diff --git a/134/index.md b/134/index.md new file mode 100644 index 0000000..acbbe66 --- /dev/null +++ b/134/index.md @@ -0,0 +1,6 @@ +Title: Use uppercase "Dillo" for the user agent +Author: rodarima +Created: Fri, 12 Apr 2024 16:09:39 +0000 +State: closed + +Reported-by: dogma
\ No newline at end of file diff --git a/135/index.md b/135/index.md new file mode 100644 index 0000000..10bc7da --- /dev/null +++ b/135/index.md @@ -0,0 +1,19 @@ +Title: Fingerprinting +Author: rodarima +Created: Sun, 14 Apr 2024 13:27:44 +0000 +State: open + +We may want to have some estimate in the amount of entropy we are leaking to find out what is the current fingerprinting capability of a given adversary when using Dillo. Setting the user agent to Dillo already cuts the whole population to probably less than 1ppm, but that is easily solvable. + +Not having support for JavaScript certainly helps, but we may be still leaking some information in HTTP headers or in the way we deal with the sockets. + +AFAIK, there is no tool to measure uniqueness that works without JS. + +https://www.w3.org/TR/fingerprinting-guidance/ +https://2019.www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 15:16:11 +0000 + +Related: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/6C5K4F6NBRUDSPNPWTXLQXCK3U3SI7DM/
\ No newline at end of file diff --git a/136/index.md b/136/index.md new file mode 100644 index 0000000..6199d73 --- /dev/null +++ b/136/index.md @@ -0,0 +1,6 @@ +Title: Splash and manual must mention the version of Dillo +Author: rodarima +Created: Fri, 19 Apr 2024 22:48:43 +0000 +State: closed + +They are missing.
\ No newline at end of file diff --git a/137/index.md b/137/index.md new file mode 100644 index 0000000..d033986 --- /dev/null +++ b/137/index.md @@ -0,0 +1,6 @@ +Title: Fix table with relative width columns +Author: rodarima +Created: Sat, 20 Apr 2024 19:52:59 +0000 +State: closed + +Fixes https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/H7JEBC2HYNJ6FUPQM7ILBP7I5FLU33IZ/
\ No newline at end of file diff --git a/138/index.md b/138/index.md new file mode 100644 index 0000000..680b262 --- /dev/null +++ b/138/index.md @@ -0,0 +1,6 @@ +Title: ** WARNING **: preferred cursive font "URW Chancery L" not found. +Author: rodarima +Created: Sat, 20 Apr 2024 20:56:04 +0000 +State: closed + +Can we finally fix this warning from almost a decade? URW Chancery L is not likely to be available.
\ No newline at end of file diff --git a/139/index.md b/139/index.md new file mode 100644 index 0000000..6bb4e33 --- /dev/null +++ b/139/index.md @@ -0,0 +1,8 @@ +Title: Use DejaVu Sans for cursive by default +Author: rodarima +Created: Sat, 20 Apr 2024 21:09:47 +0000 +State: closed + +The URW Chancery L font is not likely to be installed, so by default we use the same as for serif and sans, DejaVu. + +Fixes: https://github.com/dillo-browser/dillo/issues/138
\ No newline at end of file diff --git a/14/index.md b/14/index.md new file mode 100644 index 0000000..e8e0bfa --- /dev/null +++ b/14/index.md @@ -0,0 +1,10 @@ +Title: Fix DuckDuckGo search links +Author: rodarima +Created: Sun, 17 Dec 2023 19:15:33 +0000 +State: closed + +The DuckDuckGo service that redirects the links from the search page is returning a broken page for non-javascript browsers. They have a meta refresh tag in the body, instead of in the head. + +Adding the kd=-1 argument causes the DuckDuckGo search results to point directly to the target page avoiding the redirection. + +Fixes: #8
\ No newline at end of file diff --git a/140/index.md b/140/index.md new file mode 100644 index 0000000..0909eee --- /dev/null +++ b/140/index.md @@ -0,0 +1,10 @@ +Title: Improve quirk for text/xhtml content type +Author: rodarima +Created: Tue, 23 Apr 2024 21:21:35 +0000 +State: closed + +When a <meta> tag reports the "text/xhtml" content, we were correcting it to the type guessed in TypeDet. However, the current implementation to guess XHTML and HTML pages fails if the doctype is not at the start of the document, falling back to text/plain. + +A more robust solution is to set the TypeNorm to "application/xhtml+xml", which can be handled by a_Mime_get_viewer() as an HTML-like document. + +Fixes: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/7GJ4AAMFFPEHOIYEOH4NHVMSXMJDFYXG/
\ No newline at end of file diff --git a/141/index.md b/141/index.md new file mode 100644 index 0000000..7b562a1 --- /dev/null +++ b/141/index.md @@ -0,0 +1,6 @@ +Title: Add desktop launcher +Author: rodarima +Created: Wed, 24 Apr 2024 22:29:55 +0000 +State: closed + +It is missing from the installation and it would be useful for users that use a graphical launcher. We need to also keep in mind the logs won't be visible.
\ No newline at end of file diff --git a/142/index.md b/142/index.md new file mode 100644 index 0000000..962ed96 --- /dev/null +++ b/142/index.md @@ -0,0 +1,6 @@ +Title: Fix scroll step docs +Author: rodarima +Created: Thu, 25 Apr 2024 19:50:14 +0000 +State: closed + +https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/5DGCSCREF2SMOADHBHJVCB33BMYDSBHG/
\ No newline at end of file diff --git a/143/index.md b/143/index.md new file mode 100644 index 0000000..8338d94 --- /dev/null +++ b/143/index.md @@ -0,0 +1,6 @@ +Title: Add desktop file and icons +Author: rodarima +Created: Sat, 27 Apr 2024 19:48:37 +0000 +State: closed + +Fixes: https://github.com/dillo-browser/dillo/issues/141
\ No newline at end of file diff --git a/144/index.md b/144/index.md new file mode 100644 index 0000000..a6240df --- /dev/null +++ b/144/index.md @@ -0,0 +1,6 @@ +Title: Add version in docs +Author: rodarima +Created: Sat, 27 Apr 2024 20:40:47 +0000 +State: closed + +Fixes #136
\ No newline at end of file diff --git a/145/index.md b/145/index.md new file mode 100644 index 0000000..c43d4e4 --- /dev/null +++ b/145/index.md @@ -0,0 +1,10 @@ +Title: Implement force https mode. +Author: zlqrvx +Created: Sun, 28 Apr 2024 03:07:25 +0000 +State: closed + +This pull request implements an option to force all http urls to be upgraded to https, similar to [HTTPS-Only Mode](https://support.mozilla.org/en-US/kb/https-only-prefs) in Firefox. + +This is implemented by changing all http urls to https when they are created in a_Url_new. + +A http_force_https preference is provided as well as a menu bar item to toggle this mode.
\ No newline at end of file diff --git a/146/index.md b/146/index.md new file mode 100644 index 0000000..3578a5f --- /dev/null +++ b/146/index.md @@ -0,0 +1,6 @@ +Title: Move version to first paragraph of the manual +Author: rodarima +Created: Mon, 29 Apr 2024 18:59:55 +0000 +State: closed + +When using "git describe" the resulting length of the version is too long for the header. As we only need to store the version somewhere in the manual, we place it at the end of the first paragraph.
\ No newline at end of file diff --git a/147/index.md b/147/index.md new file mode 100644 index 0000000..81f595d --- /dev/null +++ b/147/index.md @@ -0,0 +1,49 @@ +Title: Add custom new tab page +Author: zlqrvx +Created: Tue, 30 Apr 2024 03:06:23 +0000 +State: closed + +Adds the new_tab_page option which sets the page to be opened when opening a new tab. + +Fixes: https://github.com/dillo-browser/dillo/issues/124 + +--%-- +From: rodarima +Date: Thu, 02 May 2024 18:55:32 +0000 + +Thanks, there is a thread in the mailing list regarding this topic: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/ARQTHK24NEMENZFM6TU524FWNMWFO2GA/ + +Your patch doen't seem to work when a user opens a new tab by going to the File menu and clicking on the "New tab" button. It also has the problem that when setting `new_tab_page=""`, it tries to open `http:/`. + +This solves it: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/RNCABGTGNYIOD3DABLL2GHMNQG3AMMIE/ + +```diff +diff --git a/src/uicmd.cc b/src/uicmd.cc +index 88bc9b7d..fd3bd74e 100644 +--- a/src/uicmd.cc ++++ b/src/uicmd.cc +@@ -770,6 +770,9 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUrl *url) + + static void UIcmd_open_url_nbw(BrowserWindow *new_bw, const DilloUrl *url) + { ++ if (!url && strcmp(URL_STR(prefs.new_tab_page), "about:blank") != 0) ++ url = prefs.new_tab_page; ++ + /* When opening a new BrowserWindow (tab or real window) we focus + * Location if we don't yet have an URL, main otherwise. + */ +``` + +In any case, I think I will leave this feature for the next release, so we don't block 3.1.0 for longer. + +--%-- +From: otonoton +Date: Sat, 04 May 2024 20:39:07 +0000 + +Would it be better to switch to `strncmp`? + +--%-- +From: rodarima +Date: Sun, 09 Jun 2024 10:25:18 +0000 + +Merged in https://github.com/dillo-browser/dillo/pull/188 after modifying Alex patch.
\ No newline at end of file diff --git a/148/index.md b/148/index.md new file mode 100644 index 0000000..80dfc22 --- /dev/null +++ b/148/index.md @@ -0,0 +1,9 @@ +Title: Disable "Layout::resizeIdle calls" message +Author: rodarima +Created: Fri, 03 May 2024 16:35:43 +0000 +State: closed + +It is always shown, even when messages are turned of by "show_msg=NO", as the preferences are not available to dw. For now we disable it permanently by using the _MSG() macro. + +Reported-by: Kevin Koster <dillo@ombertech.com> +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/PPNR5FTO3YFDVAQCM4SDNVAF22JEV22W/
\ No newline at end of file diff --git a/149/index.md b/149/index.md new file mode 100644 index 0000000..21f31c9 --- /dev/null +++ b/149/index.md @@ -0,0 +1,25 @@ +Title: Implement support for CSS variables +Author: rodarima +Created: Fri, 03 May 2024 23:18:41 +0000 +State: open + +Websites often use variables to store CSS values that have a large impact in how the page is rendered. As we simply ignore all variables, pages don't layout properly even if we support most of the underlying CSS properties. + +Example for https://gwern.net/search where most CSS rules use variables: +```CSS +... +body { + max-width: var(--GW-body-max-width); + padding: 0 var(--GW-body-side-padding); + margin: 0 auto; +} +... +``` + +This is how is rendered in Firefox without JS enabled: + + + +But it looks like this in Dillo: + + diff --git a/15/index.md b/15/index.md new file mode 100644 index 0000000..e853867 --- /dev/null +++ b/15/index.md @@ -0,0 +1,76 @@ +Title: Add a test infrastructure +Author: rodarima +Created: Sun, 17 Dec 2023 19:22:59 +0000 +State: closed + +There are no automatic tests. We have some small tests in `test/` but we should be adding much more to cover the HTML and CSS specs. + +Additionally, we should have some way to automate some clicks to avoid human intervention in tests. For example, in #14 we cannot test it in CI as of now, as we would need to open a duckduckgo search test, then click in one of the links and then ensure that a non-broken page is loaded. + +--%-- +From: rodarima +Date: Wed, 20 Dec 2023 19:29:30 +0000 + +Using Xvfb to create a virtual Xorg framebuffer, we can run dillo in the GitHub CI. We can also take screenshots of the window and compare them to reference ones. Here is an example: + +Launch a virtual display at :33 +``` +$ Xvfb :33 -screen 5 1024x768x8 & +``` +Run dillo in that display: +``` +$ DISPLAY=:33 dillo google.es +``` +Take screenshot of the whole screen: +``` +$ DISPLAY=:33 xwd -root -silent | convert xwd:- png:screenshot.png +``` +Or if the window id is specified to take only Dillo window: +``` +DISPLAY=:33 xwd -id 0x200009 -silent | convert xwd:- png:screenshot.png +``` + +And here is the result: +<img src="https://github.com/dillo-browser/dillo/assets/3866127/3114fb12-45f1-46f8-b519-2d9767f9b683" width="60%" /> + +However, we still need to prepare most of the tests to use automatic feedback, as they are mostly designed to be run by a human. + +--%-- +From: rodarima +Date: Wed, 20 Dec 2023 20:46:41 +0000 + +I'll first focus on unit tests and defer the automatization of more complex tests for another MR. Most unit tests also lack automatic checks, example: + +```c +void testHashTable () +{ + puts ("--- testHashTable ---"); + + HashTable<String, Integer> h(true, true); + + h.put (new String ("one"), new Integer (1)); + h.put (new String ("two"), new Integer (2)); + h.put (new String ("three"), new Integer (3)); + + puts (h.toString()); + + h.put (new String ("one"), new Integer (4)); + h.put (new String ("two"), new Integer (5)); + h.put (new String ("three"), new Integer (6)); + + puts (h.toString()); +} + +``` + +--%-- +From: rodarima +Date: Thu, 28 Dec 2023 00:28:34 +0000 + +In order to test several properties of HTML and CSS layout, we can make a reference test, in which the feature to test is not used. Then, we generate a screenshot of both renders and compare them to be exactly the same. + +--%-- +From: rodarima +Date: Sat, 30 Dec 2023 18:10:56 +0000 + +One of the current problems with the `make check` target is that it should work before `make install`. However, dillo would need a working dpi directory in order to run the tests, so we can use the file plugin. Currently, the test pages are failing to render because dillo cannot start the file plugin to access the local pages.
\ No newline at end of file diff --git a/150/index.md b/150/index.md new file mode 100644 index 0000000..085a94b --- /dev/null +++ b/150/index.md @@ -0,0 +1,6 @@ +Title: Update online manual URL +Author: rodarima +Created: Sat, 04 May 2024 18:58:58 +0000 +State: closed + +The old manual page is no longer needed as we have the latest manual rendered in the new website.
\ No newline at end of file diff --git a/151/index.md b/151/index.md new file mode 100644 index 0000000..c60c0f5 --- /dev/null +++ b/151/index.md @@ -0,0 +1,5 @@ +Title: Release version 3.1.0 +Author: rodarima +Created: Sat, 04 May 2024 19:55:11 +0000 +State: closed + diff --git a/152/index.md b/152/index.md new file mode 100644 index 0000000..786b888 --- /dev/null +++ b/152/index.md @@ -0,0 +1,34 @@ +Title: Provide prebuilt releases +Author: niutech +Created: Sun, 05 May 2024 09:43:09 +0000 +State: closed + +Please provide prebuilt binary releases for Linux/MacOS/Windows using existing CI by [storing artifacts](https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts) and uploading them to releases. Thanks! + +--%-- +From: rodarima +Date: Sun, 05 May 2024 11:27:54 +0000 + +Why?, what is wrong with building from source? + +Providing binaries for all Linux/BSD distros and ensuring they work well would require a lot of work, which is often done by their maintainers. I'm not familiar with MacOS packaging, so I cannot comment on that one. For Windows you'll need Cywgin, so I don't think we can easily package an executable. + +--%-- +From: niutech +Date: Sun, 05 May 2024 21:32:17 +0000 + +Why? Because they are already being auto-built as CI by Github Actions, so the added cost is low and the entry threshold for users is significantly lower. For Windows, it's a matter of including *.dll files and for Linux it could be an AppImage. + +--%-- +From: rodarima +Date: Sun, 05 May 2024 22:15:55 +0000 + +> Why? Because they are already being auto-built as CI by Github Actions, so the added cost is low and the entry threshold for users is significantly lower. For Windows, it's a matter of including *.dll files and for Linux it could be an AppImage. + +Sorry but I don't agree. + +Dillo should be distributed via a package manager, the same you would install any other dependency. On MacOS you have Homebrew and on Windows you can add it to a Cygwin recipe. If you want to help, adopt it as a maintaner in any system you like. This way security fixes are propagated quickly without involving us and ABI change rebuilds are managed by the package maintainers. + +In the case of a user that wants to try something that is not available as a package yet, I consider the entry point of downloading the source and executing the few commands to build and install Dillo an acceptable threshold. + +Shiping TLS code in a AppImage bundle that never gets updates is a no-go.
\ No newline at end of file diff --git a/153/index.md b/153/index.md new file mode 100644 index 0000000..018764c --- /dev/null +++ b/153/index.md @@ -0,0 +1,12 @@ +Title: Problems with Wayland +Author: rodarima +Created: Sun, 05 May 2024 13:55:48 +0000 +State: closed + +As reported by [Peter on Fedi](https://fosstodon.org/@peterkotrcka@mastouille.fr/112386847584568234), there is a problem when enabling the "Load background images" option from the menu and trying to change the location bar URL. It seems to be happening on OpenSUSE with FLTK 1.3.9-2.2 and KDE on Wayland. + +--%-- +From: rodarima +Date: Wed, 08 May 2024 18:41:14 +0000 + +Closing as per https://mastouille.fr/@peterkotrcka/112404478900616377
\ No newline at end of file diff --git a/154/index.md b/154/index.md new file mode 100644 index 0000000..c2da8bb --- /dev/null +++ b/154/index.md @@ -0,0 +1,5 @@ +Title: Add link to Mobilized Dillo fork +Author: rodarima +Created: Sun, 05 May 2024 17:40:05 +0000 +State: closed + diff --git a/155/index.md b/155/index.md new file mode 100644 index 0000000..9288014 --- /dev/null +++ b/155/index.md @@ -0,0 +1,16 @@ +Title: Update macOS install instructions +Author: yincrash +Created: Sun, 05 May 2024 18:02:47 +0000 +State: closed + +On macOS, Homebrew will install OpenSSL to different locations depending on which architecture you're on (Intel or ARM). It also doesn't put the headers and library files in the default search path for `gcc`. + +This added instruction in the `doc/install.md` aligns with a similar instruction for BSD and is architecture and OpenSSL version agnostic (because it just asks Homebrew to tell us what the prefix is). + +`pkg-config` could easily work across platforms or the lookup could be configured to test for homebrew, but I didn't want to make a much bigger change to the autoconf script. + +--%-- +From: yincrash +Date: Sun, 05 May 2024 21:14:12 +0000 + +Done
\ No newline at end of file diff --git a/156/index.md b/156/index.md new file mode 100644 index 0000000..f9c8a0d --- /dev/null +++ b/156/index.md @@ -0,0 +1,38 @@ +Title: Add zoom control +Author: rodarima +Created: Sun, 05 May 2024 18:36:05 +0000 +State: closed + +Fixes #21 + +--%-- +From: rodarima +Date: Sun, 05 May 2024 18:37:03 +0000 + +Control-+ doesn't seem work in US keyboard layouts. + +--%-- +From: niutech +Date: Sun, 05 May 2024 22:45:32 +0000 + +@rodarima Please use `Ctrl =` instead of `Ctrl +`, so that it doesn't require pressing `Shift`, which is consistent with major web browsers. + +Also please add `Ctrl 0` to reset zoom to 100%. + +--%-- +From: rodarima +Date: Sun, 09 Jun 2024 19:58:06 +0000 + +> @rodarima Please use `Ctrl =` instead of `Ctrl +`, so that it doesn't require pressing `Shift`, which is consistent with major web browsers. + +It should work now both for US and EU keyboards. Both Ctrl + and Ctrl = cause a zoom increase. + +> Also please add `Ctrl 0` to reset zoom to 100%. + +Should be working too. + +--%-- +From: niutech +Date: Mon, 10 Jun 2024 09:09:09 +0000 + +@rodarima Thank you!
\ No newline at end of file diff --git a/157/index.md b/157/index.md new file mode 100644 index 0000000..18c756b --- /dev/null +++ b/157/index.md @@ -0,0 +1,14 @@ +Title: Please provide binaries +Author: eugenialoli +Created: Mon, 06 May 2024 00:21:02 +0000 +State: closed + +Thank you very much for resurrecting Dillo. I always loved this little browser! + +I understand that the main way to distribute Linux apps is via source (both for practical, and philosophical reasons), but it's going to be a long time since Dillo gets updated in most distros. The best way to get bug reports is for people to use the app by downloading an appimage (maybe the easiest to build?), or a flatpack (most difficult to build), a plain binary zip file, or an rpm/deb package. I personally want to try Dillo very much, but I don't really feel like building it from source. I used to build apps under linux in the early 2000s a lot, but I've made a point in recent years of not wanting to do that anymore. It's inconvenient, and archaic. + +--%-- +From: rodarima +Date: Wed, 08 May 2024 18:38:27 +0000 + +Duplicated of https://github.com/dillo-browser/dillo/issues/152.
\ No newline at end of file diff --git a/158/index.md b/158/index.md new file mode 100644 index 0000000..0a25012 --- /dev/null +++ b/158/index.md @@ -0,0 +1,20 @@ +Title: Fix mbed TLS 3.6.0 +Author: rodarima +Created: Mon, 06 May 2024 09:32:58 +0000 +State: closed + +Dillo is not working well with Mbed TLS 3.6.0: +``` +% src/dillo https://dillo-browser.github.io/ +dillo_dns_init: Here we go! (threaded) +TLS library: Mbed TLS 3.6.0 +Trusting 147 TLS certificates. +Enabling cookies as from cookiesrc... +Nav_open_url: new url='https://dillo-browser.github.io/' +Dns_server [0]: dillo-browser.github.io is 185.199.110.153 185.199.109.153 185.199.111.153 185.199.108.153 +Connecting to 185.199.110.153:443 +mbedtls_ssl_handshake() failed with error -0x6c00 +fd 6 is done and failed +``` + +See https://gitlab.alpinelinux.org/alpine/aports/-/issues/16088
\ No newline at end of file diff --git a/159/index.md b/159/index.md new file mode 100644 index 0000000..7380af7 --- /dev/null +++ b/159/index.md @@ -0,0 +1,41 @@ +Title: Issuer Certificate of an Untrusted Certificate +Author: ktnb-netbsd +Created: Mon, 06 May 2024 17:15:42 +0000 +State: closed + +Hi, + +I'm working on updating the version of dillo in pkgsrc (for NetBSD) and I'm receiving this error every time I attempt to go to an site via HTTPS: +> The issuer certificate of an untrusted certificate cannot be found. Issuer: /C=US/O=DigiCertInc/OU=www.digicert.com/CN=DigiCert Global Root G2 + +Is this normal? + +EDIT: It's not always DigiCert but the error is the same otherwise. + +--%-- +From: rodarima +Date: Mon, 06 May 2024 17:29:36 +0000 + +No, is not normal. It can happen if Dillo cannot find the CA bundle. Does it show some messages in the console at the start? + +Check also the configure options --with-ca-certs-file and --with-ca-certs-dir. We may need to add a note in the install docs. + +--%-- +From: ktnb-netbsd +Date: Mon, 06 May 2024 17:45:19 +0000 + +> No, is not normal. It can happen if Dillo cannot find the CA bundle. Does it show some messages in the console at the start? + +No, there isn't any warning about certs. Just missing configs. + +> Check also the configure options --with-ca-certs-file and --with-ca-certs-dir. We may need to add a note in the install docs. + +I'll give this a try and get back to you. + +--%-- +From: ktnb-netbsd +Date: Mon, 06 May 2024 17:59:42 +0000 + +> Check also the configure options --with-ca-certs-file and --with-ca-certs-dir. + +Setting --with-ca-certs-dir fixes it. Thank you!
\ No newline at end of file diff --git a/16/index.md b/16/index.md new file mode 100644 index 0000000..6af2ec3 --- /dev/null +++ b/16/index.md @@ -0,0 +1,6 @@ +Title: Missing .gitignore +Author: rodarima +Created: Sun, 17 Dec 2023 19:44:06 +0000 +State: closed + +Originally dillo was stored in a mercurial repo, so we should move the .hgignore to a .gitignore.
\ No newline at end of file diff --git a/160/index.md b/160/index.md new file mode 100644 index 0000000..3fa33ef --- /dev/null +++ b/160/index.md @@ -0,0 +1,6 @@ +Title: Changelog missing release date +Author: rodarima +Created: Mon, 06 May 2024 19:26:22 +0000 +State: closed + +Forgot to update the release date for 3.1.0.
\ No newline at end of file diff --git a/161/index.md b/161/index.md new file mode 100644 index 0000000..eb4f08c --- /dev/null +++ b/161/index.md @@ -0,0 +1,12 @@ +Title: Convert some old files from iso8859-1 to utf-8 encoding +Author: tim77 +Created: Mon, 06 May 2024 19:40:55 +0000 +State: closed + +This also prevent RPM linter warns, error. + +--%-- +From: rodarima +Date: Mon, 06 May 2024 19:44:21 +0000 + +Thanks!
\ No newline at end of file diff --git a/162/index.md b/162/index.md new file mode 100644 index 0000000..199073b --- /dev/null +++ b/162/index.md @@ -0,0 +1,9 @@ +Title: Disable TLSv1.3 in MbedTLS 3.6.0 for now +Author: rodarima +Created: Mon, 06 May 2024 19:57:46 +0000 +State: closed + +In Mbed TLS 3.6.0 there is now support for TLSv1.3, but it requires special handling so for now we disable it. + +See: https://gitlab.alpinelinux.org/alpine/aports/-/commit/4dc36afaa81a4d73758b29fa77981d07dbae0080.patch +Fixes: https://github.com/dillo-browser/dillo/issues/158
\ No newline at end of file diff --git a/163/index.md b/163/index.md new file mode 100644 index 0000000..0ac2bf3 --- /dev/null +++ b/163/index.md @@ -0,0 +1,6 @@ +Title: Add release date for 3.1.0 in ChangeLog +Author: rodarima +Created: Mon, 06 May 2024 20:11:38 +0000 +State: closed + +Fixes: https://github.com/dillo-browser/dillo/issues/160
\ No newline at end of file diff --git a/164/index.md b/164/index.md new file mode 100644 index 0000000..55d6fbf --- /dev/null +++ b/164/index.md @@ -0,0 +1,14 @@ +Title: Update macOS dillo install instructions +Author: yincrash +Created: Wed, 08 May 2024 16:33:09 +0000 +State: closed + +Dillo is now packaged (bottled) in Homebrew as seen here - +https://github.com/Homebrew/homebrew-core/blob/master/Formula/d/dillo.rb + + +--%-- +From: yincrash +Date: Wed, 08 May 2024 16:36:08 +0000 + +The package is built from source in Homebrew's CI system - https://github.com/Homebrew/homebrew-core/pull/171004
\ No newline at end of file diff --git a/165/index.md b/165/index.md new file mode 100644 index 0000000..885e209 --- /dev/null +++ b/165/index.md @@ -0,0 +1,22 @@ +Title: Installation guide: building and plugins Makefile template +Author: tkapias +Created: Wed, 08 May 2024 16:54:24 +0000 +State: open + +The examples in the installation guide (doc/install.md) will install the config files in `/usr/local/etc/dillo`. + +But most other tutorials and the Makefile template in every official plugins expect `/etc/dillo`. + +The examples should be `../configure --prefix=/usr/local --sysconfdir=/etc`. + +--%-- +From: rodarima +Date: Wed, 08 May 2024 18:33:56 +0000 + +> The examples should be ../configure --prefix=/usr/local --sysconfdir=/etc. + +Plugins should accept non-standard installation paths for /etc (including others than /usr/local/etc), so we don't need to pollute /etc with non-packaged files. + +We can search in /etc and /use/local/etc for dpidrc by default for now. + +Maybe also add a make variable so we can specify where to look for dpidrc to support other installation prefixes.
\ No newline at end of file diff --git a/166/index.md b/166/index.md new file mode 100644 index 0000000..5edf3d6 --- /dev/null +++ b/166/index.md @@ -0,0 +1,50 @@ +Title: Presentations with Dillo in plain HTML +Author: rodarima +Created: Wed, 08 May 2024 21:19:28 +0000 +State: open + +It would be nice if we can use Dillo to show slides too (specially if the presentation is about Dillo itself). + +One option could be to design the HTML document in such a way that has pages of the viewport size, and then an anchor link to the next element. This would involve some kind of automatic tool to inject the HTML links, so the document must be prepared to be presented. + +Another, maybe simpler, solution is to simply rely on header sections h1, h2... as the delimiters of a page, which is also set to the viewport size. Then we just need to automatically add a virtual anchor to each section and a keymap to jump to the next/previous section of the same level. This will also allow multiple levels, so we can go up, then skip a few parts and go down again. Ideally, a markdown document could be converted to HTML and directly rendered in Dillo as slides. + +This may also open the door to read Ebooks or other documents by well delimited pages. Avoiding the scroll can lead to significant power save, as we only need to render once per page instead of once per mouse wheel step. + +Manually adding anchors to specific sections doesn't require any special machinery. + +--%-- +From: rodarima +Date: Tue, 01 Oct 2024 19:04:52 +0000 + +I've have implemented a proof of concept, which jumps to the next fragment of the page. This is probably the most portable way to do it, as we can link to a given slide from any browser. + +However, it requires users to write HTML with id tags, which it is a bit cumbersome to do by hand. + +The implementation adds two new keys for next and previous fragment, but it doesn't take into account the current position of the viewport. + +There is a problem with the layout engine an the 100% height, which makes creating slides almost impossible, as they need to know the size of the Dillo window. The idea is to be able to adjust the size as the user needs, in contrast with PDF slides. + +--%-- +From: rodarima +Date: Tue, 01 Oct 2024 21:13:48 +0000 + +The slides problem can be solved by implemented the vh and vw units, which should be easy to do. + +--%-- +From: rodarima +Date: Sat, 05 Oct 2024 07:53:19 +0000 + +We don't really need any extra machinery to jump from one slide to the next if we can define elements to occupy exactly one slide. The only change we need is for prev/next page to really move one whole page. + +We may just add a toggle to remove the margin when advancing pages. Maybe we can also transform the navigation into whole pages only, so the scroll bar and scroll wheel navigate full slides. This will make it possible to quickly jump to a given slide. + +Slides must keep the content inside the slide page, otherwise we risk shifting all pages. + +--%-- +From: rodarima +Date: Sun, 12 Jan 2025 13:49:33 +0000 + +Making it screen based is risky, as any overflow will cause next slides to misalign. Making it fragment based is self correcting and allows slides larger than the screen. This plays good with multiple zoom levels. + +Let's not rush this on 3.2.0 and leave it for a future release.
\ No newline at end of file diff --git a/167/index.md b/167/index.md new file mode 100644 index 0000000..2de0120 --- /dev/null +++ b/167/index.md @@ -0,0 +1,55 @@ +Title: Enable IPv6 support by default +Author: suffieldacademy +Created: Sun, 12 May 2024 03:14:13 +0000 +State: closed + +This is a feature enhancement request. I am using a device (macOS) that is IPv6-only, and testing Dillo as installed with homebrew. Homebrew uses the default compilation options, which do not include IPv6 (`configure.ac` requires a flag to enable IPv6, and this is not on by default). + +With IPv6 becoming more prevalent (and in Apple's case, mandatory), could you invert the configuration so that IPv6 is enabled by default, and can only be disabled by passing a flag? That would prevent downstream package managers from having to add the flag to each of their build scripts. + +If IPv6 support is not fully tested or ready for default deployment, then I completely understand and I can build my own manually with support enabled. + +--%-- +From: rodarima +Date: Sun, 12 May 2024 10:38:02 +0000 + +Yeah, this was in my long TODO list. + +Ideally we should detect if IPv6 support is available on the system and enable it accordingly at configure time. Shouldn't be too hard to do. + +Either way, we may want to allow users to disable IPv6 in the dillorc configuration at runtime, as it may cause connection delays while we fallback to IPv4 in some networks that don't support IPv6. + +--%-- +From: suffieldacademy +Date: Sun, 12 May 2024 21:21:40 +0000 + +Thank you; I'm sorry to dump more on but figured we could at least track it as an eventual TODO. Great work on getting the new release out the door! + +A runtime switch might be even better; we could have it on by default (or at least easily switchable without needing to rebuild). + +Thanks! + +--%-- +From: Kangie +Date: Sat, 01 Jun 2024 00:44:11 +0000 + +> Ideally we should detect if IPv6 support is available on the system and enable it accordingly at configure time. Shouldn't be too hard to do. + +Please don't implement this via configure automagic. IPv6 is one of those features that should just be turned on by default, relying on runtime logic to determine whether or not IPv6 is suitable. + + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 09:38:38 +0000 + +> > Ideally we should detect if IPv6 support is available on the system and enable it accordingly at configure time. Shouldn't be too hard to do. +> +> Please don't implement this via configure automagic. IPv6 is one of those features that should just be turned on by default, relying on runtime logic to determine whether or not IPv6 is suitable. + +I don't mean to detect if IPv6 is enabled in the network if that is your worry. + +By "available on the system" I mean if `struct sockaddr_in6` and `struct in6_addr` are defined by `<netinet/in.h>` and `<sys/socket.h>`, otherwise the build will fail. This is only regarding building support of IPv6 at *build time* and should also work if cross-compiling to a different machine. + +At runtime, I plan on adding a switch in the dillorc configuration file, as sometimes it is required to turn off IPv6, even if it is available. + +I need to do more testing to determine if we can switch it on by default at runtime (at build time there is no problem), as I remember this could cause an unexpected long delay on the DNS resolver until if fails back to IPv4, and novice users will have a hard time figuring out this is caused by IPv6.
\ No newline at end of file diff --git a/168/index.md b/168/index.md new file mode 100644 index 0000000..b70b054 --- /dev/null +++ b/168/index.md @@ -0,0 +1,30 @@ +Title: Add support for Content-Disposition header +Author: rodarima +Created: Mon, 13 May 2024 22:16:23 +0000 +State: closed + +The Content-Disposition header defines the name of the file when downloading a file and is being used by GitHub for Dillo releases: + +``` +% curl -sLI https://github.com/dillo-browser/dillo/releases/download/v3.1.0/dillo-3.1.0.tar.gz | grep -i content-disposition: +content-disposition: attachment; filename=dillo-3.1.0.tar.gz +``` + +Otherwise, the default filename is something like this: +``` +/tmp/866a6385-0be9-4636-8299-9bb2867298d3?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetpr +``` + +https://datatracker.ietf.org/doc/html/rfc6266 + +--%-- +From: rodarima +Date: Tue, 28 May 2024 21:16:48 +0000 + +Tests: http://test.greenbytes.de/tech/tc2231/ + +--%-- +From: rodarima +Date: Thu, 01 May 2025 17:17:18 +0000 + +Closing as per #373. Full support of the Content-Disposition can be tracked in a new issue.
\ No newline at end of file diff --git a/169/index.md b/169/index.md new file mode 100644 index 0000000..14f6dd0 --- /dev/null +++ b/169/index.md @@ -0,0 +1,44 @@ +Title: Scaling for hidpi/4k screens +Author: Munchotaur +Created: Tue, 14 May 2024 17:06:24 +0000 +State: open + +I just installed 3.1.0 and it's great but for the scaling on my 4k work monitor. Is there a make option to set a different scale for Dillo? + +--%-- +From: rodarima +Date: Tue, 14 May 2024 17:17:21 +0000 + +We don't really have support for DPI yet. + +As a workaround, you can use the [`font_factor` option](https://github.com/dillo-browser/dillo/blob/b0f558ce519107a37f0b7cfd5a5a4f6b3d4ae64b/dillorc#L74) and can put arbitrary [CSS in ~/.dillo/style.css](https://dillo-browser.github.io/user_help.html#style-css) to increase the font size like this: + +```css +body { + font-size: 20px !important; +} +``` + +There is also a work in progress for zoom, see PR #156. + +--%-- +From: Munchotaur +Date: Tue, 14 May 2024 17:27:12 +0000 + +Thanks. At least that should sort out the page itself -- I guess the UI is a whole other can of worms? + +--%-- +From: rodarima +Date: Tue, 14 May 2024 18:58:56 +0000 + +> I guess the UI is a whole other can of worms? + +FLTK 1.4 should [support DPI out of the box](https://www.fltk.org/doc-1.4/group__fl__screen.html#gab1f3def038ace55315391d484be2d294), but AFAIK, FLTK 1.3 doesn't support it (didn't test). Not sure how long it will take to have the [release ready](https://github.com/fltk/fltk/milestone/1), but hopefully not too long. + +But if you want to explore other options in the meanwhile feel free to do so :-) + +--%-- +From: Munchotaur +Date: Tue, 14 May 2024 19:22:46 +0000 + +I'll see what I can see! However that note on FLTK 1.4 sounds promising so here's looking forward to the next release.
\ No newline at end of file diff --git a/17/index.md b/17/index.md new file mode 100644 index 0000000..bcf54e0 --- /dev/null +++ b/17/index.md @@ -0,0 +1,6 @@ +Title: Port .hgignore to .gitignore +Author: rodarima +Created: Sun, 17 Dec 2023 19:55:33 +0000 +State: closed + +Fixes #16
\ No newline at end of file diff --git a/170/index.md b/170/index.md new file mode 100644 index 0000000..807a07f --- /dev/null +++ b/170/index.md @@ -0,0 +1,81 @@ +Title: Crash on Mac +Author: bouncepaw +Created: Wed, 15 May 2024 20:37:35 +0000 +State: closed + +1. Installed `dillo` via homebrew +2. Open dillo +3. Visit http://bouncepaw.com +4. Browser crashes + +It's the same for HTTPS as well. + +``` +~ --> dillo -v +Dillo version 3.2.0 +``` + +Mac version: Sonoma 14.4.1 (the most recent one, I think). + +Terminal printout: + +``` +~ --> dillo +dillo_dns_init: Here we go! (threaded) +Failed to parse certificates from /etc/ssl/certs/ca-certificates.crt +Failed to parse certificates from /etc/pki/tls/certs/ca-bundle.crt +Failed to parse certificates from /usr/share/ssl/certs/ca-bundle.crt +Failed to parse certificates from /usr/local/share/certs/ca-root.crt +Loaded TLS certificates. +Disabling cookies. +** WARNING **: preferred sans-serif font "DejaVu Sans" not found. +** WARNING **: preferred serif font "DejaVu Serif" not found. +** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. +** WARNING **: preferred cursive font "DejaVu Serif" not found. +** WARNING **: preferred fantasy font "DejaVu Sans" not found. +Nav_open_url: new url='about:splash' +2024-05-15 23:34:16.233 dillo[67618:2738233] TSM AdjustCapsLockLEDForKeyTransitionHandling - _ISSetPhysicalKeyboardCapsLockLED Inhibit +Nav_open_url: new url='http://bouncepaw.com' +Dns_server [0]: bouncepaw.com is 88.214.236.204 +Connecting to 88.214.236.204:80 +zsh: segmentation fault dillo +``` + +``` +~ --> dillo https://bouncepaw.com +dillo_dns_init: Here we go! (threaded) +Failed to parse certificates from /etc/ssl/certs/ca-certificates.crt +Failed to parse certificates from /etc/pki/tls/certs/ca-bundle.crt +Failed to parse certificates from /usr/share/ssl/certs/ca-bundle.crt +Failed to parse certificates from /usr/local/share/certs/ca-root.crt +Loaded TLS certificates. +Disabling cookies. +** WARNING **: preferred sans-serif font "DejaVu Sans" not found. +** WARNING **: preferred serif font "DejaVu Serif" not found. +** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. +** WARNING **: preferred cursive font "DejaVu Serif" not found. +** WARNING **: preferred fantasy font "DejaVu Sans" not found. +Nav_open_url: new url='https://bouncepaw.com' +Dns_server [0]: bouncepaw.com is 88.214.236.204 +Connecting to 88.214.236.204:443 +bouncepaw.com TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +zsh: segmentation fault dillo https://bouncepaw.com +``` + +--%-- +From: rodarima +Date: Wed, 15 May 2024 20:44:53 +0000 + +Thanks for testing it, but I don't think that one is our Dillo, as the latest version is 3.1.0, and you should see the OpenSSL message on start. Check that you have this one: https://formulae.brew.sh/formula/dillo + +Maybe you can use `which -a` to see where it is coming from. + +I loaded your page just fine. + +--%-- +From: bouncepaw +Date: Wed, 15 May 2024 20:48:41 +0000 + +<img width="892" alt="Снимок экрана 2024-05-15 в 23 47 25" src="https://github.com/dillo-browser/dillo/assets/22562024/d29a221e-f9c2-4ee2-91c5-e81f57ffe1f4"> + +OK now we're talking! I indeed had a different Dillo installation. Thank you @rodarima! This Dillo works great, closing the issue.
\ No newline at end of file diff --git a/171/index.md b/171/index.md new file mode 100644 index 0000000..c662949 --- /dev/null +++ b/171/index.md @@ -0,0 +1,30 @@ +Title: Avoid reaching into X509_ALGOR +Author: botovq +Created: Thu, 16 May 2024 20:16:56 +0000 +State: closed + +It would be nice if X509_ALGOR could be made opaque at some point. There is a somewhat clumsy accessor X509_ALGOR_get0() that allows obtaining the ASN1_OBJECT sitting inside an X509_ALGOR. Use this instead. + +--%-- +From: botovq +Date: Thu, 16 May 2024 20:22:56 +0000 + +Here's the documentation: https://www.openssl.org/docs/manmaster/man3/X509_ALGOR_get0.html +and here's the implementation: +https://github.com/openssl/openssl/blob/85ccbab216da245cf9a6503dd327072f21950d9b/crypto/asn1/x_algor.c#L72-L76 + +There was a signature change (const qualifiers were added) between OpenSSL 1.0.2 and 1.1, but dillo seems to assume availability of at least the OpenSSL 1.1 API. + +--%-- +From: rodarima +Date: Sat, 18 May 2024 18:52:20 +0000 + +Thanks for the patch. + +> Here's the documentation: https://www.openssl.org/docs/manmaster/man3/X509_ALGOR_get0.html and here's the implementation: https://github.com/openssl/openssl/blob/85ccbab216da245cf9a6503dd327072f21950d9b/crypto/asn1/x_algor.c#L72-L76 + +I will assume the other parameters can be NULL based on the implementation, even if the OpenSSL documentation doesn't mention it. + +> There was a signature change (const qualifiers were added) between OpenSSL 1.0.2 and 1.1, but dillo seems to assume availability of at least the OpenSSL 1.1 API. + +Yes. OpenSSL 1.0 needs more patches to work, but I prefer not to add support for unmaintaned versions.
\ No newline at end of file diff --git a/172/index.md b/172/index.md new file mode 100644 index 0000000..4c213d7 --- /dev/null +++ b/172/index.md @@ -0,0 +1,263 @@ +Title: Dillo 3.1.0: Freeze on Nav_open_url in Cygwin +Author: Isles487 +Created: Sun, 19 May 2024 18:06:47 +0000 +State: closed + +In updated Cygwin, using 3.1.0 release of Dillo, I am encountering process freezes when attempting to open Urls: + +Windows 11, 64 bit +Cygwin64 terminal +VcXsrv 1.20.14.0 + +Console: + +$ DISPLAY=:0.0 dillo +paths: Cannot open file '/home/someuser/.dillo/dillorc': No such file or directory +paths: Using /usr/local/etc/dillo/dillorc +paths: Cannot open file '/home/someuser/.dillo/keysrc': No such file or directory +paths: Using /usr/local/etc/dillo/keysrc +paths: Cannot open file '/home/someuser/.dillo/domainrc': No such file or directory +paths: Using /usr/local/etc/dillo/domainrc +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.0.13 30 Jan 2024 +Disabling cookies. +paths: Cannot open file '/home/someuser/.dillo/hsts_preload': No such file or directory +paths: Using /usr/local/etc/dillo/hsts_preload +Nav_open_url: new url='about:splash' +Nav_open_url: new url='https://dillo-browser.github.io/' +Dns_server [0]: dillo-browser.github.io is 185.199.108.153 185.199.110.153 185.199.109.153 185.199.111.153 +Connecting to 185.199.108.153:443 +dillo-browser.github.io: TLSv1.3, cipher TLS_AES_128_GCM_SHA256 +sha256 2048-bit RSA: /C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*.github.io +sha256 2048-bit RSA: /C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 +root: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 +Nav_open_url: new url='https://www.fltk.org/' + +At this point the application becomes unresponsive and I need to kill via Task Manager. + + +--%-- +From: rodarima +Date: Sun, 19 May 2024 18:19:35 +0000 + +Does it also happen with Xorg? https://github.com/dillo-browser/dillo/blob/master/doc/install.md#windows-via-cygwin + +--%-- +From: Isles487 +Date: Sun, 19 May 2024 18:22:01 +0000 + +> Does it also happen with Xorg? https://github.com/dillo-browser/dillo/blob/master/doc/install.md#windows-via-cygwin + +Yes it does, same issue after using startxwin and then connecting to the X server via a different cygwin terminal window. + +--%-- +From: rodarima +Date: Sun, 19 May 2024 19:06:04 +0000 + +> Yes it does, same issue after using startxwin and then connecting to the X server via a different cygwin terminal window. + +I cannot reproduce it when using mbedTLS 2.23.0, I will try with OpenSSL too. + +--%-- +From: rodarima +Date: Sun, 19 May 2024 19:17:50 +0000 + +I can reproduce it with OpenSSL 3.0.13. I will take a look and see if I can find the problem, thanks for reporting. + +In the meanwhile, you can install mbedTLS (mbedtls-devel) and configure Dillo with `--disable-openssl` so it uses it instead of OpenSSL, which seems to be working fine. + +--%-- +From: Isles487 +Date: Sun, 19 May 2024 19:19:54 +0000 + +> I can reproduce it with OpenSSL 3.0.13. I will take a look and see if I can find the problem, thanks for reporting. +> +> In the meanwhile, you can install mbedTLS (mbedtls-devel) and configure Dillo with `--disable-openssl` so it uses it instead of OpenSSL, which seems to be working fine. + +Thank you for looking into this and confirming! + +--%-- +From: rodarima +Date: Sun, 19 May 2024 19:40:47 +0000 + +There seems to be a problem which only occurs with OpenSSL and when the threaded DNS resolver is enabled. + +When building with OpenSSL, you can disable the threaded DNS resolver by configuring Dillo with `--disable-threaded-dns`. That seems to be working fine too. + +I cannot see where the problem is coming from, as the stack seems corrupted from GDB: +``` +... +[New Thread 3376.0x3e0] +[New Thread 3376.0x1b60] +[New Thread 3376.0x223c] +[New Thread 3376.0x2b50] +Nav_open_url: new url='about:splash' +[New Thread 3376.0x2e58] +Nav_open_url: new url='https://dillo-browser.github.io/' +[New Thread 3376.0x5ec] +Dns_server [0]: dillo-browser.github.io is 185.199.109.153 185.199.110.153 185.199.108.153 185.199.111.153 + +Thread 11 "dillo" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 3376.0x5ec] +0x0000000000000000 in ?? () +(gdb) bt +#0 0x0000000000000000 in ?? () +#1 0x00007ffdcc659a03 in cygwin1!.getreent () from /usr/bin/cygwin1.dll +#2 0x00007ffdcc73a3bb in timegm () from /usr/bin/cygwin1.dll +#3 0x000000007ffe0385 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) +``` + +--%-- +From: rodarima +Date: Sun, 19 May 2024 20:11:29 +0000 + +So, I took a look and what seems to be happening is that after a thread is spawned to resolve a host, the thread finishes and exits by returning NULL. The control is returned to cygwin, at which point the `rbp` (the base of the stack) is set to zero: + +``` +(gdb) p $rbp +$12 = (void *) 0x0 +``` + +Causing a SEGFAULT in the next push instruction. + +I'm not sure if this is a problem on Cygwin or on Dillo side. I cannot enable Asan on Cygwin, as it doesn't seem to be supported. With the stack protector enabled, there is no warning of any kind. + +--%-- +From: rodarima +Date: Sun, 19 May 2024 20:23:05 +0000 + +Here is the bug, the thread has overwritten the stored rbp register in the stack with 0, causing the `pop %rbp` instruction to set the value of rbp to zero. + + + +I just need to see what is causing it, probably an stack overflow. + +--%-- +From: rodarima +Date: Sun, 19 May 2024 20:56:42 +0000 + +Well, it seems the rbp register is not the problem, as it enters the Dns_server function with value zero. The problem seems to be the [detached state](https://github.com/dillo-browser/dillo/blob/ea2263231abc770d5d87fcdb95fddd80679c5906/src/dns.c#L356): + +``` +pthread_attr_setdetachstate(&thrATTR, PTHREAD_CREATE_DETACHED); +``` + +When that line is removed, the thread works fine. But when it is set, the alloca call done by cywgin after the thread finishes is failing. This starts to look like a bug in Cygwin. + +As a workaround, disabling DNS threads seems to be the best solution for now. + +--%-- +From: Isles487 +Date: Sun, 19 May 2024 20:58:58 +0000 + +> Well, it seems the rbp register is not the problem, as it enters the Dns_server function with value zero. The problem seems to be the [detached state](https://github.com/dillo-browser/dillo/blob/ea2263231abc770d5d87fcdb95fddd80679c5906/src/dns.c#L356): +> +> ``` +> pthread_attr_setdetachstate(&thrATTR, PTHREAD_CREATE_DETACHED); +> ``` +> +> When that line is removed, the thread works fine. But when it is set, the alloca call done by cywgin after the thread finishes is failing. This starts to look like a bug in Cygwin. +> +> As a workaround, disabling DNS threads seems to be the best solution for now. + +I don't know if this information is useful in determining whether Cygwin is the issue or not, but interestingly when I compile the links2 browser: http://links.twibright.com/, I need to run with -async-dns disabled otherwise the browser crashes after loading more than one page - also using same openssl. + +--%-- +From: rodarima +Date: Sun, 19 May 2024 21:15:00 +0000 + +Here is a reproducer which causes a SEGFAULT with OpenSSL only: + +``` +$ cat p.c +#include <pthread.h> +#include <unistd.h> +#include <stdio.h> + +#include <openssl/ssl.h> + +#define N 4 + +static void *foo(void *data) +{ + printf("hello th %d\n", (int) data); + return NULL; +} + +int main() +{ + SSL_library_init(); + pthread_t th[N]; + pthread_attr_t attr; + pthread_attr_init(&attr); + pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); + + for (int i = 0; i < N; i++) + pthread_create(&th[i], &attr, foo, (void *) i); + + sleep(5); +} + +$ gcc p.c -lssl -pthread -o p + +$ gdb ./p +GNU gdb (GDB) (Cygwin 13.2-1) 13.2 +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-pc-cygwin". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from ./p... +(gdb) r +Starting program: /home/PC/dillo/build-openssl/p +[New Thread 7332.0x1f2c] +[New Thread 7332.0x99c] +[New Thread 7332.0x27d4] +[New Thread 7332.0x35e0] +[New Thread 7332.0x21dc] +[New Thread 7332.0x3170] +[New Thread 7332.0x1ea4] +[New Thread 7332.0x3180] +hello th 0 +hello th 1 +hello th 2 +[Thread 7332.0x3170 exited with code 0] +hello th 3 + +Thread 6 "p" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 7332.0x21dc] +0x0000000000000000 in ?? () +``` + +This is likely a bug in Cygwin triggered by OpenSSL, so I will report it to them. In the meanwhile I will modify the documentation for Windows to disable the threaded DNS resolver, + +--%-- +From: rodarima +Date: Mon, 20 May 2024 18:32:47 +0000 + +Confirmed: https://cygwin.com/pipermail/cygwin/2024-May/255975.html + +--%-- +From: Isles487 +Date: Mon, 20 May 2024 19:23:55 +0000 + +Thank you again for looking into this so quickly and keeping me updated on this! Appreciate your work. Let me know if appropriate to close now. + +--%-- +From: rodarima +Date: Mon, 20 May 2024 19:28:12 +0000 + +> Thank you again for looking into this so quickly and keeping me updated on this! Appreciate your work. Let me know if appropriate to close now. + +Don't worry, it will be closed automatically when I merge https://github.com/dillo-browser/dillo/pull/173 :-)
\ No newline at end of file diff --git a/173/index.md b/173/index.md new file mode 100644 index 0000000..8aa09de --- /dev/null +++ b/173/index.md @@ -0,0 +1,8 @@ +Title: Add workaround for OpenSSL in Cygwin +Author: rodarima +Created: Mon, 20 May 2024 19:21:40 +0000 +State: closed + +Cygwin doesn't seem to support detached threads used by the threaded DNS resolver at the same time the dynamic OpenSSL library is used. As a workaround we suggest disabling the threaded DNS (will use the same thread) if building with OpenSSL on Cygwin. + +Fixes: https://github.com/dillo-browser/dillo/issues/172
\ No newline at end of file diff --git a/174/index.md b/174/index.md new file mode 100644 index 0000000..7e7e5c0 --- /dev/null +++ b/174/index.md @@ -0,0 +1,44 @@ +Title: Use fixed width integers for CSS length type +Author: rodarima +Created: Sat, 25 May 2024 23:10:31 +0000 +State: closed + +The current type for a CSS "length" like `80px` or `20%` is represented internally as a single `int` type, which doesn't have a fixed length. In C and C++, there is only a guarantee that an int will hold at least 16 bits, but the current assumption is that it will hold at least 32 bits. +``` +| <------ integer value ------> | + ++---+ - - - +---+---+- - - - - -+---+---+---+---+ +| integer part | type | ++---+ - - - +---+---+- - - - - -+---+---+---+---+ +| integer part | decimal fraction | type | ++---+ - - - +---+---+- - - - - -+---+---+---+---+ + n-1 15 14 3 2 1 0 + +| <------ fixed point value ------> | +``` + +Furthermore, as we introduce more length types we are going to run out of length bits for the value itself. A simple option could be to define the length as something like this: + +```c +typedef struct CssLength { + CssLengthType type; + union { + int i; + float f; + }; +} CssLength; +``` + +Which will duplicate the size required to store lengths to 64 bits, as the type will likely use 32 bits with padding and another 32 bits for the integer/float value (on 64 bits machines). It has the benefit that on 16 bits machines, the size will halve to 32 bits, as all members will reduce their size. + +--%-- +From: kalvdans +Date: Wed, 12 Jun 2024 20:44:41 +0000 + +As a first step maybe use `int32_t` for the type to make sure we get 32 bits even on 16-bit platforms? + +--%-- +From: rodarima +Date: Sat, 05 Oct 2024 17:28:01 +0000 + +Merged in #264
\ No newline at end of file diff --git a/175/index.md b/175/index.md new file mode 100644 index 0000000..749b65c --- /dev/null +++ b/175/index.md @@ -0,0 +1,28 @@ +Title: SSL_read() failed: SSL_get_error() returned 6 while loading reddit.com +Author: rodarima +Created: Fri, 31 May 2024 19:57:04 +0000 +State: closed + +``` +% dillo reddit.com +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.0 9 Apr 2024 +Enabling cookies as from cookiesrc... +Nav_open_url: new url='http://reddit.com' +Dns_server [0]: reddit.com is 151.101.193.140 151.101.129.140 151.101.1.140 151.101.65.140 +Connecting to 151.101.193.140:80 +** ERROR **: [Dpi_read_comm_keys] No such file or directory +Dpi_blocking_start_dpid: try 1 +[dpid]: a_Misc_mksecret: c8a6f211 +dpid started +[cookies dpi]: Enabling cookies as per cookiesrc... +[cookies dpi]: Cookies loaded: 53. +[cookies dpi]: (v.1) accepting connections... +Nav_open_url: new url='https://reddit.com/' +Connecting to 151.101.193.140:443 +reddit.com: TLSv1.3, cipher TLS_AES_128_GCM_SHA256 +sha256 2048-bit RSA: /C=US/ST=California/L=SAN FRANCISCO/O=REDDIT, INC./CN=*.reddit.com +sha256 2048-bit RSA: /C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1 +root: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA +SSL_read() failed: SSL_get_error() returned 6 +```
\ No newline at end of file diff --git a/176/index.md b/176/index.md new file mode 100644 index 0000000..7fd49dc --- /dev/null +++ b/176/index.md @@ -0,0 +1,57 @@ +Title: tests: add HTML test items to EXTRA_DIST +Author: Kangie +Created: Fri, 31 May 2024 23:36:00 +0000 +State: closed + +This will enable tests to be easily run by downstream distributions. + +These files are not included in the 3.1.0 release tarball, resulting in errors like: + +``` +make[4]: Entering directory '/var/tmp/portage/www-client/dillo-3.1.0/work/dillo-3.1.0/test/html' +make[4]: *** No rule to make target 'render/b-div.html', needed by 'render/b-div.html.log'. Stop +``` + +When distributions try to package and test the software. + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 11:16:46 +0000 + +Thanks! I was not planning on adding the rendering tests in the release, as they may increase a lot the tarball size, but as we don't have many tests so far, the size increase is not too big: +``` +% ls -l releases/dillo-3.1.0.tar.gz git/release/dillo-3.1.0.tar.gz +-rw-r--r-- 1 ram ram 1275663 Jun 1 11:43 git/release/dillo-3.1.0.tar.gz +-rw-r--r-- 1 ram ram 1198855 Jun 1 11:42 releases/dillo-3.1.0.tar.gz +``` +So I will add them for now, and if we see the tarball size gets too big we may need to create a minimal release tarball without them (still fits in a floppy disk). + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 11:38:37 +0000 + +Hmm, I tested you patch, but it seems to be still failing. The tests are included in the tarball, but they are not found by make check. I'll try to add a test to the CI so it fails there too, as `make distcheck` doesn't enable the tests by default. + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 11:48:22 +0000 + +Tried to push my CI commit into your branch but GitHub closed the PR when I accidentally pushed our master branch, so I cannot update it now. I'll create another PR using this branch: https://github.com/dillo-browser/dillo/tree/make-distcheck-html-tests. + +--%-- +From: Kangie +Date: Sun, 02 Jun 2024 23:05:08 +0000 + +> Thanks! I was not planning on adding the rendering tests in the release, as they may increase a lot the tarball size, but as we don't have many tests so far, the size increase is not too big: +> +> ``` +> % ls -l releases/dillo-3.1.0.tar.gz git/release/dillo-3.1.0.tar.gz +> -rw-r--r-- 1 ram ram 1275663 Jun 1 11:43 git/release/dillo-3.1.0.tar.gz +> -rw-r--r-- 1 ram ram 1198855 Jun 1 11:42 releases/dillo-3.1.0.tar.gz +> ``` +> +> So I will add them for now, and if we see the tarball size gets too big we may need to create a minimal release tarball without them (still fits in a floppy disk). + +Thanks for merging! + +Consider switching to xz for compression, it's widely available and will give you a little more breathing room with that hard limit. :)
\ No newline at end of file diff --git a/177/index.md b/177/index.md new file mode 100644 index 0000000..2ea9e65 --- /dev/null +++ b/177/index.md @@ -0,0 +1,37 @@ +Title: Ensure the release tarball can run HTML rendering tests +Author: rodarima +Created: Sat, 01 Jun 2024 11:52:06 +0000 +State: closed + +This is a continuation of https://github.com/dillo-browser/dillo/pull/176 as I accidentally closed it while trying to add a commit to test the CI, and prevented me from updating it further. + +Original comment by @Kangie: +> This will enable tests to be easily run by downstream distributions. +> +> These files are not included in the 3.1.0 release tarball, resulting in errors like: +> +> ``` +> make[4]: Entering directory '/var/tmp/portage/www-client/dillo-3.1.0/work/dillo-3.1.0/test/html' +> make[4]: *** No rule to make target 'render/b-div.html', needed by 'render/b-div.html.log'. Stop +> ``` +> +> When distributions try to package and test the software. + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 13:01:34 +0000 + +The render HTML files seem to be placed in the wrong subdirectory: +``` +% tar tf dillo-3.1.0.tar.gz | grep render | head +dillo-3.1.0/test/html/render/ +dillo-3.1.0/test/html/render/render/ +dillo-3.1.0/test/html/render/render/pre-code.html +dillo-3.1.0/test/html/render/render/table-td-width-percent-img.html +dillo-3.1.0/test/html/render/render/pic.png +dillo-3.1.0/test/html/render/render/margin-auto.ref.html +dillo-3.1.0/test/html/render/render/span-padding.ref.html +dillo-3.1.0/test/html/render/render/max-width-div.ref.html +dillo-3.1.0/test/html/render/render/max-width-nested-div.ref.html +dillo-3.1.0/test/html/render/render/css-units.html +```
\ No newline at end of file diff --git a/178/index.md b/178/index.md new file mode 100644 index 0000000..557edc4 --- /dev/null +++ b/178/index.md @@ -0,0 +1,11 @@ +Title: Handle SSL_ERROR_ZERO_RETURN in OpenSSL +Author: rodarima +Created: Sat, 01 Jun 2024 18:39:15 +0000 +State: closed + +It may be returned when the server closes the connection, see: +https://www.openssl.org/docs/manmaster/man3/SSL_get_error.html + +We simply handle it as if there was no error and return zero bytes read. + +Fixes: https://github.com/dillo-browser/dillo/issues/175
\ No newline at end of file diff --git a/179/index.md b/179/index.md new file mode 100644 index 0000000..a5b8fbc --- /dev/null +++ b/179/index.md @@ -0,0 +1,28 @@ +Title: iCCP: known incorrect sRGB profile +Author: rodarima +Created: Sat, 01 Jun 2024 19:22:19 +0000 +State: closed + +``` +Png_error_handling: https://emoji.redditmedia.com/1xwpxlk1cr3d1_t5_3l98x/wuwa_ico: iCCP: known incorrect sRGB profile +``` + +It seems to be a proper PNG file and sxiv can open it: + +``` +% file wuwa_ico.png +wuwa_ico.png: PNG image data, 64 x 64, 8-bit/color RGBA, non-interlaced +``` + +Attached here: + + + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 19:25:14 +0000 + +Fixed in mobilized dillo by issuing a warning: +``` +** WARNING **: Png warning: iCCP: known incorrect sRGB profile in file:///tmp/wuwa_ico.png +```
\ No newline at end of file diff --git a/18/index.md b/18/index.md new file mode 100644 index 0000000..76fa4ad --- /dev/null +++ b/18/index.md @@ -0,0 +1,53 @@ +Title: Consider porting devdocs to markdown +Author: rodarima +Created: Mon, 18 Dec 2023 22:19:31 +0000 +State: closed + +The *devdocs* provide very detailed explanations of algorithms, design ideas and other topics and should be easily reachable. They are currently written in Doxygen .doc format, which is nice to link with the API-like documentation but they require a place to live compiled in HTML (or other formats). They cannot be easily read as-is. + +On the other hand, GitHub can render Markdown including Math directly from the repository. This increases quite a lot the accessibility from others to the detailed explanations without leaving the repository. + +I did some tests with *dw-line-breaking.doc* and they seem to render quite nicely: + + + +The blame is also not very much affected: + + + +Which preserves the original authors. + +Here is the [permalink](https://github.com/rodarima/dillo/blob/a60881f18a291c31ffc68e46901ad32bfce42268/devdoc/dw-line-breaking.md) + +--%-- +From: rodarima +Date: Mon, 18 Dec 2023 23:17:08 +0000 + +However, this makes the devdocs unable to be opened in dillo itself, which would be quite sad. Here is the same document rendered in dillo using Doxygen (take a closer look at the 77 HTML errors in the bottom right): + + + + +--%-- +From: rodarima +Date: Sat, 09 Mar 2024 18:54:38 +0000 + +For now this is being rendered at https://dillo-browser.github.io/doxygen/index.html from the Doxygen with a new theme. Even if we rewrite the standalone pages in Markdown, there is still a lot of information attached to the source code classes and namespaces that is better represented as-is. It also includes cross references which Doxygen handles gracefully. + +Here are some examples: +- https://dillo-browser.github.io/doxygen/classdw_1_1Image.html#details +- https://dillo-browser.github.io/doxygen/classdw_1_1Table.html#details +- https://dillo-browser.github.io/doxygen/namespacedw_1_1core_1_1style.html#a65610d57c89e5bee02e4e539fdc989de + +Apart from that, Doxygen also allows pages to be written in Markdown, including from the source code itself. + +The math formulas are currently rendered as images by LaTeX, but Doxygen also allows the usage of MathJax, which renders them in the browser with Javascript. Here is an example with `USE_MATHJAX = YES`: + + + +Which is very similar to the quality of GitHub and Markdown. + +However, the reason they are not shown very well is that the size of the images is too small, so it may be doable to fix it in Doxygen. + +For now there is no need to switch to Markdown or other formats, so I'll close this. + diff --git a/180/index.md b/180/index.md new file mode 100644 index 0000000..b5ecc32 --- /dev/null +++ b/180/index.md @@ -0,0 +1,11 @@ +Title: Handle PNG warnings as non-fatal +Author: rodarima +Created: Sat, 01 Jun 2024 19:39:26 +0000 +State: closed + +The libpng library may emit warnings when decoding a PNG image, which are non-fatal. So far we were handling them as errors and stopping the decoding process, which prevents Dillo from decoding some images. In particular, images that emit the warning: + +> iCCP: known incorrect sRGB profile + +Fixes: https://github.com/dillo-browser/dillo/issues/179 +Authored-by: dogma
\ No newline at end of file diff --git a/181/index.md b/181/index.md new file mode 100644 index 0000000..af7611a --- /dev/null +++ b/181/index.md @@ -0,0 +1,51 @@ +Title: Custom CSS overrides per page +Author: rodarima +Created: Sat, 01 Jun 2024 22:09:08 +0000 +State: open + +The [dillo-plus](https://github.com/crossbowerbt/dillo-plus?tab=readme-ov-file#reader-mode-css-style) fork has implemented a reader mode allows pages to optionally load custom CSS styles without any remote or embeded CSS rules. + +Currently we only allow loading a single style.css file that is always loaded. + +I've been playing a bit with the current implementation of user CSS in `~/.dillo/style.css` and I observe that a single CSS file (or two with the reader mode) won't be able to solve some of the problems I see. + +For example, in Hacker News, as they use tables to layout the content, and the tables have an implicit rule that restores the font size, we need special rules to make the text more legible for tables. However, those rules don't work well with tables in Wikipedia pages. + +Another example is the long list of navigation links that some pages put in the top, that can be hidden or make smaller by clever CSS rules, but those need to be made per page to prevent them from hiding content where they shouldn't. + +Ideally, we should be able to define per-page CSS rule. I was thinking if we could invent a `@media` syntax that could match a regex against the current page (and it only works in local override CSS files): + +```CSS +@media (host: "*.reddit.com|*.wikipedia.com") { + /* Rules for reddit and wikipedia */ +} + +@import url("./reddit.css") only (host: "*.reddit.com"); +``` + +Ideally, those rules should live in a repository on their own, so they can be maintaned by a community. + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 22:16:32 +0000 + +Here is an example from Greasemonkey extension to make Wikipedia automatically switch to dark mode: + +https://openuserjs.org/scripts/navchandar/Wikipedia_Auto_Dark_Mode/source + +We probably can reuse most of those. + +--%-- +From: rodarima +Date: Sun, 02 Jun 2024 17:53:12 +0000 + +Another example by the Stylish extension that uses `@-moz-document`: + +https://github.com/UserStyles/hacker-news-solarized-dark/blob/master/user-style.css +```CSS +@-moz-document domain("news.ycombinator.com") { + /* ... */ +} +``` + +See also: https://developer.mozilla.org/en-US/docs/Web/CSS/@document
\ No newline at end of file diff --git a/182/index.md b/182/index.md new file mode 100644 index 0000000..321ec19 --- /dev/null +++ b/182/index.md @@ -0,0 +1,10 @@ +Title: Remove undefined floatRef debug line in RTFL +Author: rodarima +Created: Sun, 02 Jun 2024 18:03:03 +0000 +State: closed + +Fixes: https://bugs.gentoo.org/933361 + +CC @asarubbo @Kangie + +**Note:** The `--enable-rtfl` flag will cause *a lot* of printf lines which are used to debug the rendering engine (with another tool called RTFL). They are not recommended while browsing as a user as they will slowdown the browser a lot.
\ No newline at end of file diff --git a/183/index.md b/183/index.md new file mode 100644 index 0000000..1157635 --- /dev/null +++ b/183/index.md @@ -0,0 +1,16 @@ +Title: Make headers self-contained +Author: rodarima +Created: Mon, 03 Jun 2024 19:24:31 +0000 +State: open + +In the current state of the implementation, headers are not self-contained. That is, when a header is included it may not include itself some other required headers, assuming the caller would have included it. + +There shouldn't be any prior dependency on any other header, so they can be easily changed and moved around. This also helps identify dependencies among code. + +This tool can help: https://include-what-you-use.org/ + +--%-- +From: kalvdans +Date: Mon, 03 Jun 2024 20:42:14 +0000 + +It's a common practise for `foo.cc` to include `foo.hh` as its first include. That way, the compilation will test that the header is self-containing. Would you accept a pull request that changes all source files to include "their" header file first?
\ No newline at end of file diff --git a/184/index.md b/184/index.md new file mode 100644 index 0000000..4771c20 --- /dev/null +++ b/184/index.md @@ -0,0 +1,8 @@ +Title: Compute ntags instead of harcoding them +Author: rodarima +Created: Mon, 03 Jun 2024 20:12:41 +0000 +State: closed + +This is likely broken: + +https://github.com/dillo-browser/dillo/blob/09b83d718a1edaa10d6947dcba5e4093637a88b8/src/css.hh#L485-L490
\ No newline at end of file diff --git a/185/index.md b/185/index.md new file mode 100644 index 0000000..d4c4395 --- /dev/null +++ b/185/index.md @@ -0,0 +1,8 @@ +Title: Ensure the same number of tags for CSS and HTML +Author: rodarima +Created: Fri, 07 Jun 2024 20:50:40 +0000 +State: closed + +The Tags array can be modified without changing the "ntags" number in the CSS side. To prevent errors, an static assert ensures the same number is used in both sides, which is known at compilation time. + +Fixes: https://github.com/dillo-browser/dillo/issues/184
\ No newline at end of file diff --git a/186/index.md b/186/index.md new file mode 100644 index 0000000..84a2ba2 --- /dev/null +++ b/186/index.md @@ -0,0 +1,6 @@ +Title: Release version 3.1.1 +Author: rodarima +Created: Fri, 07 Jun 2024 23:35:52 +0000 +State: closed + +Closes milestone [3.1.1](https://github.com/dillo-browser/dillo/milestone/2)
\ No newline at end of file diff --git a/187/index.md b/187/index.md new file mode 100644 index 0000000..aeb82fc --- /dev/null +++ b/187/index.md @@ -0,0 +1,143 @@ +Title: Configure should stop when no compiler is found +Author: rodarima +Created: Sat, 08 Jun 2024 13:00:13 +0000 +State: closed + +From https://fosstodon.org/@peterderslowake@troet.cafe/112581116611364553: +``` +peter@letytjud:~/build/dillo-3.1.1/build> ../configure +checking build system type... x86_64-pc-linux-gnu +checking host system type... x86_64-pc-linux-gnu +checking target system type... x86_64-pc-linux-gnu +checking for a BSD-compatible install... /usr/bin/install -c +checking whether build environment is sane... yes +checking for a race-free mkdir -p... /usr/bin/mkdir -p +checking for gawk... gawk +checking whether make sets $(MAKE)... yes +checking whether make supports nested variables... yes +checking for gcc... gcc +checking whether the C compiler works... yes +checking for C compiler default output file name... a.out +checking for suffix of executables... +checking whether we are cross compiling... no +checking for suffix of object files... o +checking whether the compiler supports GNU C... yes +checking whether gcc accepts -g... yes +checking for gcc option to enable C11 features... none needed +checking whether gcc understands -c and -o together... yes +checking whether make supports the include directive... yes (GNU style) +checking dependency style of gcc... gcc3 +checking for g++... no +checking for c++... no +checking for gpp... no +checking for aCC... no +checking for CC... no +checking for cxx... no +checking for cc++... no +checking for cl.exe... no +checking for FCC... no +checking for KCC... no +checking for RCC... no +checking for xlC_r... no +checking for xlC... no +checking for clang++... no +checking whether the compiler supports GNU C++... no +checking whether g++ accepts -g... no +checking for g++ option to enable C++11 features... unsupported +checking for g++ option to enable C++98 features... unsupported +checking dependency style of g++... none +checking for ranlib... ranlib +checking how to run the C preprocessor... gcc -E +checking for stdio.h... yes +checking for stdlib.h... yes +checking for string.h... yes +checking for inttypes.h... yes +checking for stdint.h... yes +checking for strings.h... yes +checking for sys/stat.h... yes +checking for sys/types.h... yes +checking for unistd.h... yes +checking size of char... 1 +checking size of short... 2 +checking size of long... 8 +checking size of int... 4 +checking size of void *... 8 +checking for int16_t... yes +checking for uint16_t... yes +checking for int32_t... yes +checking for uint32_t... yes +checking for gethostbyname... yes +checking for setsockopt... yes +checking for socklen_t... socklen_t +checking for fltk-config... /usr/bin/fltk-config +checking FLTK 1.3... yes +checking whether to link to X11... no +checking for jpeglib.h... yes +checking for jpeg_destroy_decompress in -ljpeg... yes +checking for zlib.h... yes +checking for zlibVersion in -lz... yes +checking for libpng-config... /usr/bin/libpng16-config +checking for libpng version... 1.6.43 +checking for openssl/ssl.h... yes +checking for SSL_write in -lssl... yes +configure: Using OpenSSL as TLS library. +checking for iconv.h... yes +checking for iconv_open in -liconv... no +checking for iconv_open in -lc... yes +checking for pthread_create in -lpthread... yes +checking for fcntl.h... yes +checking for unistd.h... (cached) yes +checking for sys/uio.h... yes +checking that generated files are newer than configure... done +configure: creating ./config.status +config.status: creating Makefile +config.status: creating dlib/Makefile +config.status: creating dpip/Makefile +config.status: creating dpid/Makefile +config.status: creating dpi/Makefile +config.status: creating doc/Makefile +config.status: creating dw/Makefile +config.status: creating lout/Makefile +config.status: creating src/Makefile +config.status: creating src/IO/Makefile +config.status: creating test/Makefile +config.status: creating test/unit/Makefile +config.status: creating test/dw/Makefile +config.status: creating test/html/Makefile +config.status: creating config.h +config.status: executing depfiles commands + +Configuration summary: + + CXX : g++ + CXXFLAGS: -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions + + TLS enabled: yes + TLS library: OpenSSL + TLS flags : -lcrypto -lssl + + Cookies enabled: yes + XEmbed enabled : yes + RTFL enabled : no + JPEG enabled : yes + PNG enabled : yes + GIF enabled : yes + + HTML tests : no + +peter@letytjud:~/build/dillo-3.1.1/build> make +make all-recursive +make[1]: Entering directory '/home/peter/build/dillo-3.1.1/build' +Making all in lout +make[2]: Entering directory '/home/peter/build/dillo-3.1.1/build/lout' +source='../../lout/container.cc' object='container.o' libtool=no \ +DEPDIR=.deps depmode=none /bin/sh ../../depcomp \ +g++ -DHAVE_CONFIG_H -I. -I../../lout -I.. -I../.. -DCUR_WORKING_DIR='"/home/peter/build/dillo-3.1.1/build/lout"' -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -c -o container.o ../../lout/container.cc +../../depcomp: riadok 772: exec: g++: nenájdené +make[2]: *** [Makefile:399: container.o] Error 127 +make[2]: Leaving directory '/home/peter/build/dillo-3.1.1/build/lout' +make[1]: *** [Makefile:559: all-recursive] Error 1 +make[1]: Leaving directory '/home/peter/build/dillo-3.1.1/build' +make: *** [Makefile:381: all] Error 2 +peter@letytjud:~/build/dillo-3.1.1/build> +```
\ No newline at end of file diff --git a/188/index.md b/188/index.md new file mode 100644 index 0000000..1c58afc --- /dev/null +++ b/188/index.md @@ -0,0 +1,9 @@ +Title: Add new_tab_page option +Author: rodarima +Created: Sat, 08 Jun 2024 22:54:08 +0000 +State: closed + +Adds support to load a custom page when a new tab is opened. The current behavior is set as the default, load a blank page. The location bar is only selected when the new tab page is the blank page, otherwise the page loaded gets the focus. + + +Fixes: https://github.com/dillo-browser/dillo/issues/124
\ No newline at end of file diff --git a/189/index.md b/189/index.md new file mode 100644 index 0000000..4956957 --- /dev/null +++ b/189/index.md @@ -0,0 +1,72 @@ +Title: Handle link media in https://html.duckduckgo.com/html/ +Author: rodarima +Created: Sun, 09 Jun 2024 10:40:08 +0000 +State: open + +When loading https://html.duckduckgo.com/html/, there is a <link> with a media tag which includes "all" in a comma separated value: + +```html +<link rel="stylesheet" media="handheld, all" href="//duckduckgo.com/dist/h.a4820b3a129c734fee40.css" type="text/css"/> +``` + +Dillo doesn't seem to load the CSS style at all. + +Here is the interesting part: + +https://github.com/dillo-browser/dillo/blob/d8cc59e18d6bf90c91e5d9cf1f9c36587f4ab26c/src/html.cc#L1742-L1750 + + +--%-- +From: louis77 +Date: Sat, 22 Jun 2024 00:11:38 +0000 + +I would expect Dillo to load the CSS when either "all" or "screen" is present in a list of media types. Btw. "handheld" is deprecated. However, I tried it with duckduckgo, the result is not encouraging :-). + + +--%-- +From: rodarima +Date: Sat, 22 Jun 2024 08:34:23 +0000 + +Hi Louis, + +> I would expect Dillo to load the CSS when either "all" or "screen" is +> present in a list of media types. + +Yeah, the current code only tries to find the substring "screen" or +match the exact value "all". The relevant function is +Html_tag_open_link not Html_tag_open_style (which also has the same +problem). + +> Btw. "handheld" is deprecated. However, I tried it with duckduckgo, +> the result is not encouraging :-). + +Yeah, I saw it. The lite version seems to be a bit better, but it +doesn't appear centered with CSS: + +https://lite.duckduckgo.com/lite/ + +Maybe we can defer this until we improve a bit the CSS support, so we +don't make it worse that it currently is. The lite version is the +default search engine, so we probably want that to make it work +reasonably well. + +The rule that seems to be moving the elements to the left is the +text-align of the query input: + +```css +.query { + border-color:#dc5e47; + border-style:solid solid solid solid; + border-width:1px 1px 1px 1px; + -moz-border-radius:3px; + border-radius:3px; + font-size:20px; + padding:5px 6px; + /*text-align:left;*/ + width:60%; + max-width:600px; + height:28px +} +``` + +It is aligning the input itself instead of the text inside it. diff --git a/19/index.md b/19/index.md new file mode 100644 index 0000000..83b69d7 --- /dev/null +++ b/19/index.md @@ -0,0 +1,8 @@ +Title: Update README.md with dillo.org dead notice +Author: rodarima +Created: Tue, 19 Dec 2023 00:38:33 +0000 +State: closed + +The official server is lost. Move install instructions to its own document. + +Closes #13
\ No newline at end of file diff --git a/190/index.md b/190/index.md new file mode 100644 index 0000000..8a4683a --- /dev/null +++ b/190/index.md @@ -0,0 +1,29 @@ +Title: Segfault when loading https://github.com/dillo-browser/dillo/ +Author: rodarima +Created: Sun, 09 Jun 2024 11:00:26 +0000 +State: closed + +The function a_Url_new() can return NULL if the url is not parsed correctly, but is not being handled properly: +``` +[Thread 0x7ffff60006c0 (LWP 2813416) exited] + +Thread 1 "dillo" received signal SIGSEGV, Segmentation fault. +0x00005555555c3f3d in a_Html_url_new (html=0x555555a4d980, url_str=0x555555af2c60 "", base_url=0x0, use_base_url=0) at ../../src/html.cc:180 +180 if ((n_ic = URL_ILLEGAL_CHARS(url)) != 0) { +(gdb) bt +#0 0x00005555555c3f3d in a_Html_url_new (html=0x555555a4d980, url_str=0x555555af2c60 "", base_url=0x0, use_base_url=0) at ../../src/html.cc:180 +#1 0x00005555555d146c in Html_tag_open_form (html=0x555555a4d980, + tag=0x555555c152ae "<form id=\"query-builder-test-form\" action=\"\" accept-charset=\"UTF-8\" method=\"get\">\n <query-builder data-target=\"qbsearch-input.queryBuilder\" id=\"query-builder-query-builder-test\" data-filter-key=\":\" d"..., tagsize=81) at ../../src/form.cc:364 +#2 0x00005555555ceb16 in Html_process_tag (html=0x555555a4d980, + tag=0x555555c152ae "<form id=\"query-builder-test-form\" action=\"\" accept-charset=\"UTF-8\" method=\"get\">\n <query-builder data-target=\"qbsearch-input.queryBuilder\" id=\"query-builder-query-builder-test\" data-filter-key=\":\" d"..., tagsize=81) at ../../src/html.cc:4053 +#3 0x00005555555cfbe9 in Html_write_raw (html=0x555555a4d980, + buf=0x555555c0da8b "<path d=\"M1.75 1h12.5c.966 0 1.75.784 1.75 1.75v9.5A1.75 1.75 0 0 1 14.25 14H8.061l-2.574 2.573A1.458 1.458 0 0 1 3 15.543V14H1.75A1.75 1.75 0 0 1 0 12.25v-9.5C0 1.784.784 1 1.75 1ZM1.5 2.75v9.5c0 .13"..., bufsize=64188, Eof=0) at ../../src/html.cc:4383 +#4 0x00005555555c526d in DilloHtml::write (this=0x555555a4d980, + Buf=0x555555c04d70 "\n\n\n\n\n\n\n<!DOCTYPE html>\n<html\n lang=\"en\"\n \n data-color-mode=\"auto\" data-light-theme=\"light\" data-dark-theme=\"dark\"\n data-a11y-animated-images=\"system\" data-a11y-link-underlines=\"true\"\n >\n\n\n <head"..., BufSize=100311, Eof=0) at ../../src/html.cc:587 +``` + +--%-- +From: rodarima +Date: Sun, 09 Jun 2024 11:40:01 +0000 + +The fact I introduced this bug shows that the current tests are lacking a lot of cases. Maybe we can add a list of sites to test so we can check that Dillo can parse those sites without a segfault.
\ No newline at end of file diff --git a/191/index.md b/191/index.md new file mode 100644 index 0000000..1629c80 --- /dev/null +++ b/191/index.md @@ -0,0 +1,8 @@ +Title: Allow empty URLs with base URL set +Author: rodarima +Created: Sun, 09 Jun 2024 11:30:50 +0000 +State: closed + +They are used for href="" in links or action="" in forms. + +Fixes: https://github.com/dillo-browser/dillo/issues/190
\ No newline at end of file diff --git a/192/index.md b/192/index.md new file mode 100644 index 0000000..5b59ad3 --- /dev/null +++ b/192/index.md @@ -0,0 +1,16 @@ +Title: Load a list of sites when running the tests +Author: rodarima +Created: Sun, 09 Jun 2024 11:46:00 +0000 +State: open + +Regarding #190, we should add some lists of sites which will be used to ensure Dillo can parse them without a segfault. + +Rather than making the pages local in a test repository, we can just try to open them online and fail if they cannot be loaded. Those pages that go down must be taken out of the test suite. This will also exercise the TLS and other network facing code. + +We can begin with a 5 minute CI test, so we don't increase too much the test run times. We need to be able to signal the test driver that the site has loaded properly. + +--%-- +From: rodarima +Date: Sun, 09 Jun 2024 12:00:48 +0000 + +Here are some: https://github.com/scrapy/protego/blob/master/tests/top-10000-websites.txt
\ No newline at end of file diff --git a/193/index.md b/193/index.md new file mode 100644 index 0000000..03b4e88 --- /dev/null +++ b/193/index.md @@ -0,0 +1,128 @@ +Title: *** [dillo/3.1.1] Not implemented: OOFFloatsMgr::tellIncompletePosition1 *** +Author: rodarima +Created: Sun, 09 Jun 2024 14:11:33 +0000 +State: open + +Managed to make Dillo abort: +``` +% gdb --args src/dillo www.citibank.com +... +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.0 9 Apr 2024 +Enabling cookies as from cookiesrc... +Nav_open_url: new url='http://www.citibank.com' +[New Thread 0x7ffff60006c0 (LWP 2852263)] +Dns_server [0]: www.citibank.com is 95.100.123.225 +Connecting to 95.100.123.225:80 +[Thread 0x7ffff60006c0 (LWP 2852263) exited] +Nav_open_url: new url='https://www.citi.com/' +[New Thread 0x7ffff60006c0 (LWP 2852264)] +Dns_server [0]: www.citi.com is 95.100.123.225 +Connecting to 95.100.123.225:443 +[Thread 0x7ffff60006c0 (LWP 2852264) exited] +www.citi.com: TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384 +sha256 2048-bit RSA: /jurisdictionC=US/jurisdictionST=Delaware/businessCategory=Private Organization/serialNumber=2154254/C=US/ST=New York/L=New York/O=Citigroup Inc./CN=www.citi.com +sha256 2048-bit RSA: /C=US/O=DigiCert Inc/CN=DigiCert EV RSA CA G2 +root: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 +no values for shorthand property 'padding' +no values for shorthand property 'padding' +NumPendingStyleSheets=1 +*** [dillo/3.1.1] Not implemented: OOFFloatsMgr::tellIncompletePosition1 *** + +Thread 1 "dillo" received signal SIGABRT, Aborted. +0x00007ffff6eac194 in ?? () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff6eac194 in ?? () from /usr/lib/libc.so.6 +#1 0x00007ffff6e58d70 in raise () from /usr/lib/libc.so.6 +#2 0x00007ffff6e404c0 in abort () from /usr/lib/libc.so.6 +#3 0x0000555555616ce1 in lout::misc::notImplemented (name=0x55555566d4b0 "OOFFloatsMgr::tellIncompletePosition1") at ../../dw/../lout/misc.hh:58 +#4 0x0000555555618eb2 in dw::oof::OOFFloatsMgr::tellIncompletePosition1 (this=0x555555907cf0, generator=0x555555a3cc60, widget=0x555555a3ad90, x=0, y=0) at ../../dw/ooffloatsmgr.cc:861 +#5 0x000055555562f823 in dw::Textblock::wrapWordInFlow (this=0x555555a3ad90, wordIndex=1, wrapAll=true) at ../../dw/textblock_linebreaking.cc:774 +#6 0x000055555562f149 in dw::Textblock::wordWrap (this=0x555555a3ad90, wordIndex=1, wrapAll=true) at ../../dw/textblock_linebreaking.cc:578 +#7 0x0000555555632d8c in dw::Textblock::showMissingLines (this=0x555555a3ad90) at ../../dw/textblock_linebreaking.cc:2187 +#8 0x000055555562345c in dw::Textblock::sizeRequestImpl (this=0x555555a3ad90, requisition=0x555555ab7e50, numPos=0, references=0x555555af0540, x=0x555555af0560, y=0x555555af0500) + at ../../dw/textblock.cc:347 +#9 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x555555a3ad90, requisition=0x555555ab7e50, numPos=0, references=0x555555af0540, x=0x555555af0560, y=0x555555af0500) + at ../../dw/widget.cc:580 +#10 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x555555a38e40, wordIndex=2, widget=0x555555a3ad90, size=0x555555ab7e50) at ../../dw/textblock.cc:2338 +#11 0x000055555563259c in dw::Textblock::rewrap (this=0x555555a38e40) at ../../dw/textblock_linebreaking.cc:1940 +#12 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x555555a38e40, requisition=0x555555a39700, numPos=0, references=0x555555af0380, x=0x555555af0420, y=0x555555af0400) + at ../../dw/textblock.cc:346 +#13 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x555555a38e40, requisition=0x555555a39700, numPos=0, references=0x555555af0380, x=0x555555af0420, y=0x555555af0400) + at ../../dw/widget.cc:580 +#14 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x555555a34150, wordIndex=6, widget=0x555555a38e40, size=0x555555a39700) at ../../dw/textblock.cc:2338 +#15 0x000055555563259c in dw::Textblock::rewrap (this=0x555555a34150) at ../../dw/textblock_linebreaking.cc:1940 +#16 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x555555a34150, requisition=0x555555a347d0, numPos=0, references=0x555555af02c0, x=0x555555af02a0, y=0x555555af0280) + at ../../dw/textblock.cc:346 +#17 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x555555a34150, requisition=0x555555a347d0, numPos=0, references=0x555555af02c0, x=0x555555af02a0, y=0x555555af0280) + at ../../dw/widget.cc:580 +#18 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x555555a334c0, wordIndex=0, widget=0x555555a34150, size=0x555555a347d0) at ../../dw/textblock.cc:2338 +#19 0x000055555563259c in dw::Textblock::rewrap (this=0x555555a334c0) at ../../dw/textblock_linebreaking.cc:1940 +#20 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x555555a334c0, requisition=0x555555a33f90, numPos=0, references=0x555555af0120, x=0x555555af0100, y=0x555555af0200) + at ../../dw/textblock.cc:346 +#21 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x555555a334c0, requisition=0x555555a33f90, numPos=0, references=0x555555af0120, x=0x555555af0100, y=0x555555af0200) + at ../../dw/widget.cc:580 +#22 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x555555a32f90, wordIndex=0, widget=0x555555a334c0, size=0x555555a33f90) at ../../dw/textblock.cc:2338 +#23 0x000055555563259c in dw::Textblock::rewrap (this=0x555555a32f90) at ../../dw/textblock_linebreaking.cc:1940 +#24 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x555555a32f90, requisition=0x555555ae4500, numPos=0, references=0x555555af0140, x=0x555555af01a0, y=0x555555af0180) + at ../../dw/textblock.cc:346 +#25 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x555555a32f90, requisition=0x555555ae4500, numPos=0, references=0x555555af0140, x=0x555555af01a0, y=0x555555af0180) + at ../../dw/widget.cc:580 +#26 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x555555a2f230, wordIndex=4, widget=0x555555a32f90, size=0x555555ae4500) at ../../dw/textblock.cc:2338 +#27 0x000055555563259c in dw::Textblock::rewrap (this=0x555555a2f230) at ../../dw/textblock_linebreaking.cc:1940 +#28 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x555555a2f230, requisition=0x555555a2f8a0, numPos=0, references=0x555555af0080, x=0x555555af0060, y=0x555555af0040) + at ../../dw/textblock.cc:346 +#29 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x555555a2f230, requisition=0x555555a2f8a0, numPos=0, references=0x555555af0080, x=0x555555af0060, y=0x555555af0040) + at ../../dw/widget.cc:580 +#30 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x555555a2e610, wordIndex=0, widget=0x555555a2f230, size=0x555555a2f8a0) at ../../dw/textblock.cc:2338 +#31 0x000055555563259c in dw::Textblock::rewrap (this=0x555555a2e610) at ../../dw/textblock_linebreaking.cc:1940 +#32 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x555555a2e610, requisition=0x555555aedfc0, numPos=0, references=0x555555aeff60, x=0x555555aefca0, y=0x555555aefd40) + at ../../dw/textblock.cc:346 +#33 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x555555a2e610, requisition=0x555555aedfc0, numPos=0, references=0x555555aeff60, x=0x555555aefca0, y=0x555555aefd40) +--Type <RET> for more, q to quit, c to continue without paging-- + at ../../dw/widget.cc:580 +#34 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x555555a2deb0, wordIndex=0, widget=0x555555a2e610, size=0x555555aedfc0) at ../../dw/textblock.cc:2338 +#35 0x000055555563259c in dw::Textblock::rewrap (this=0x555555a2deb0) at ../../dw/textblock_linebreaking.cc:1940 +#36 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x555555a2deb0, requisition=0x555555a2e4e0, numPos=0, references=0x555555aefd80, x=0x555555aefee0, y=0x555555aeff20) + at ../../dw/textblock.cc:346 +#37 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x555555a2deb0, requisition=0x555555a2e4e0, numPos=0, references=0x555555aefd80, x=0x555555aefee0, y=0x555555aeff20) + at ../../dw/widget.cc:580 +#38 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x5555559f4b40, wordIndex=0, widget=0x555555a2deb0, size=0x555555a2e4e0) at ../../dw/textblock.cc:2338 +#39 0x000055555563259c in dw::Textblock::rewrap (this=0x5555559f4b40) at ../../dw/textblock_linebreaking.cc:1940 +#40 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x5555559f4b40, requisition=0x555555a2dd80, numPos=0, references=0x555555aefde0, x=0x555555aeff00, y=0x555555aefd00) + at ../../dw/textblock.cc:346 +#41 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x5555559f4b40, requisition=0x555555a2dd80, numPos=0, references=0x555555aefde0, x=0x555555aeff00, y=0x555555aefd00) + at ../../dw/widget.cc:580 +#42 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x5555559f41f0, wordIndex=0, widget=0x5555559f4b40, size=0x555555a2dd80) at ../../dw/textblock.cc:2338 +#43 0x000055555563259c in dw::Textblock::rewrap (this=0x5555559f41f0) at ../../dw/textblock_linebreaking.cc:1940 +#44 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x5555559f41f0, requisition=0x5555559f4840, numPos=0, references=0x555555aefd60, x=0x555555aefce0, y=0x555555aefda0) + at ../../dw/textblock.cc:346 +#45 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x5555559f41f0, requisition=0x5555559f4840, numPos=0, references=0x555555aefd60, x=0x555555aefce0, y=0x555555aefda0) + at ../../dw/widget.cc:580 +#46 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x5555559f3620, wordIndex=0, widget=0x5555559f41f0, size=0x5555559f4840) at ../../dw/textblock.cc:2338 +#47 0x000055555563259c in dw::Textblock::rewrap (this=0x5555559f3620) at ../../dw/textblock_linebreaking.cc:1940 +#48 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x5555559f3620, requisition=0x555555aeeb00, numPos=0, references=0x555555aefe60, x=0x555555aefec0, y=0x555555aeffc0) + at ../../dw/textblock.cc:346 +#49 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x5555559f3620, requisition=0x555555aeeb00, numPos=0, references=0x555555aefe60, x=0x555555aefec0, y=0x555555aeffc0) + at ../../dw/widget.cc:580 +#50 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x55555581b610, wordIndex=8, widget=0x5555559f3620, size=0x555555aeeb00) at ../../dw/textblock.cc:2338 +#51 0x000055555563259c in dw::Textblock::rewrap (this=0x55555581b610) at ../../dw/textblock_linebreaking.cc:1940 +#52 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x55555581b610, requisition=0x555555aef8e0, numPos=0, references=0x555555aefbc0, x=0x555555aefbe0, y=0x555555aefc00) + at ../../dw/textblock.cc:346 +#53 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x55555581b610, requisition=0x555555aef8e0, numPos=0, references=0x555555aefbc0, x=0x555555aefbe0, y=0x555555aefc00) + at ../../dw/widget.cc:580 +#54 0x000055555562942c in dw::Textblock::calcSizeOfWidgetInFlow (this=0x55555581fb40, wordIndex=0, widget=0x55555581b610, size=0x555555aef8e0) at ../../dw/textblock.cc:2338 +#55 0x000055555563259c in dw::Textblock::rewrap (this=0x55555581fb40) at ../../dw/textblock_linebreaking.cc:1940 +#56 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x55555581fb40, requisition=0x55555591dcf0, numPos=0, references=0x0, x=0x0, y=0x0) at ../../dw/textblock.cc:346 +#57 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x55555581fb40, requisition=0x55555591dcf0, numPos=0, references=0x0, x=0x0, y=0x0) at ../../dw/widget.cc:580 +#58 0x0000555555629598 in dw::Textblock::calcSizeOfWidgetInFlow (this=0x55555583b7d0, wordIndex=0, widget=0x55555581fb40, size=0x55555591dcf0) at ../../dw/textblock.cc:2394 +#59 0x000055555563259c in dw::Textblock::rewrap (this=0x55555583b7d0) at ../../dw/textblock_linebreaking.cc:1940 +#60 0x0000555555623450 in dw::Textblock::sizeRequestImpl (this=0x55555583b7d0, requisition=0x7fffffffd554, numPos=0, references=0x0, x=0x0, y=0x0) at ../../dw/textblock.cc:346 +#61 0x000055555564bdf6 in dw::core::Widget::sizeRequest (this=0x55555583b7d0, requisition=0x7fffffffd554, numPos=0, references=0x0, x=0x0, y=0x0) at ../../dw/widget.cc:580 +#62 0x000055555563ea4e in dw::core::Layout::resizeIdle (this=0x55555592f410) at ../../dw/layout.cc:911 +#63 0x00005555555e9635 in dw::fltk::FltkPlatform::generalIdle (this=0x55555591cab0) at ../dw/../../dw/fltkplatform.cc:630 +#64 0x00005555555e9598 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x55555591cab0) at ../dw/../../dw/fltkplatform.cc:620 +#65 0x00007ffff7dae011 in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 +#66 0x00007ffff7dae12a in Fl::run() () from /usr/lib/libfltk.so.1.3 +#67 0x00005555555a9c55 in main (argc=2, argv=0x7fffffffd7c8) at ../../src/dillo.cc:582 +```
\ No newline at end of file diff --git a/194/index.md b/194/index.md new file mode 100644 index 0000000..189ca6c --- /dev/null +++ b/194/index.md @@ -0,0 +1,6 @@ +Title: Ignore empty page title for tab labels +Author: rodarima +Created: Tue, 11 Jun 2024 18:27:39 +0000 +State: closed + +When a page has an empty title like <title></title>, don't use it to set the tab label, but instead rely on the default tab label, which is computed from the file name.
\ No newline at end of file diff --git a/195/index.md b/195/index.md new file mode 100644 index 0000000..b767161 --- /dev/null +++ b/195/index.md @@ -0,0 +1,52 @@ +Title: Add support for relative reference URLs +Author: rodarima +Created: Tue, 11 Jun 2024 20:49:05 +0000 +State: closed + +Example in duckduckgo: + +```html +<link rel="stylesheet" media="handheld, all" href="//duckduckgo.com/dist/lr.7ea0bec6b92cbc81590a.css" type="text/css"/> +``` + +Should load the stylesheet using the same scheme as the current page. See https://www.rfc-editor.org/rfc/rfc3986#section-4.2 + +--%-- +From: rodarima +Date: Tue, 11 Jun 2024 20:51:40 +0000 + +Also: https://stackoverflow.com/a/4832046 + +> I could only find one that did not handle the protocol relative URL correctly: _an obscure *nix browser called Dillo_. + +--%-- +From: louis77 +Date: Fri, 21 Jun 2024 23:13:48 +0000 + +Dillo resolves protocol-relative URLs, I've prepared an example here: +https://faq.emacs.ch/test.html + +The reason that Dillo doesn't load the duckduckgo.com css above is, that Dillo does't like the media type is "handheld, all" as references in #189 . + +Can you verify this? + +--%-- +From: rodarima +Date: Sat, 22 Jun 2024 08:42:33 +0000 + +Hi, + +> @rodarima Dillo resolves protocol-relative URLs, I've prepared an +> example here: +> https://faq.emacs.ch/test.html +> +> The reason that Dillo doesn't load the duckduckgo.com css above is, +> that the media type is "handheld". Dillo only loads media type +> "screen". +> +> Can you verify this? + +Yeah it works fine, not sure how I came to that conclusion without +testing it first :-) + +Thanks for the test, we can close this now. diff --git a/196/index.md b/196/index.md new file mode 100644 index 0000000..fffe765 --- /dev/null +++ b/196/index.md @@ -0,0 +1,44 @@ +Title: Segfault when clicking the Done button on downloads dialog +Author: rodarima +Created: Wed, 12 Jun 2024 19:00:01 +0000 +State: closed + +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/IPWQYKTYTO5G2BH3UU5224FRUFWCVGSO/ + +Steps to reproduce: + +- Download a file. +- Wait until it completes. +- Click the "Done" button on the downloads dialog. + +``` +** ERROR **: [Dpi_read_comm_keys] No such file or directory +Dpi_blocking_start_dpid: try 1 +[dpid]: a_Misc_mksecret: d4839d11 +dpid started +[downloads dpi]: started... +[downloads dpi]: wget status 0 +AddressSanitizer:DEADLYSIGNAL +================================================================= +==3393563==ERROR: AddressSanitizer: SEGV on unknown address 0x64ecf64712d0 (pc 0x7870ef628f74 bp 0x64ecf64712d0 sp 0x7ffc09ebd860 T0) +==3393563==The signal is caused by a WRITE memory access. + #0 0x7870ef628f74 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order) /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:81 + #1 0x7870ef628f74 in __asan::Allocator::AtomicallySetQuarantineFlagIfAllocated(__asan::AsanChunk*, void*, __sanitizer::BufferedStackTrace*) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_allocator.cpp:610 + #2 0x7870ef628f74 in __asan::Allocator::Deallocate(void*, unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_allocator.cpp:685 + #3 0x7870ef628f74 in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_allocator.cpp:944 + #4 0x7870ef6ddd71 in __interceptor_free /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:53 + #5 0x64ecf646b2d3 in dFree ../../dlib/dlib.c:68 + #6 0x64ecf6461fe1 in DLItem::~DLItem() ../../dpi/downloads.cc:436 + #7 0x64ecf6465ebf in DLWin::del(int) ../../dpi/downloads.cc:970 + #8 0x64ecf646548a in update_cb ../../dpi/downloads.cc:822 + #9 0x7870ef519f9b in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4af9b) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #10 0x7870ef51a129 in Fl::run() (/usr/lib/libfltk.so.1.3+0x4b129) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #11 0x64ecf6466b0d in main ../../dpi/downloads.cc:1122 + #12 0x7870eec41d49 (/usr/lib/libc.so.6+0x25d49) (BuildId: 915eeec6439cfded1125deefc44a8d73e57873d9) + #13 0x7870eec41e0b in __libc_start_main (/usr/lib/libc.so.6+0x25e0b) (BuildId: 915eeec6439cfded1125deefc44a8d73e57873d9) + #14 0x64ecf645e274 in _start (/usr/local/lib/dillo/dpi/downloads/downloads.dpi+0x8274) (BuildId: 528bdd343ccff0d5114daa60d785f9caa56bb59c) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:81 in bool __sanitizer::atomic_compare_exchange_strong<__sanitizer::atomic_uint8_t>(__sanitizer::atomic_uint8_t volatile*, __sanitizer::atomic_uint8_t::Type*, __sanitizer::atomic_uint8_t::Type, __sanitizer::memory_order) +==3393563==ABORTING +```
\ No newline at end of file diff --git a/197/index.md b/197/index.md new file mode 100644 index 0000000..beabf31 --- /dev/null +++ b/197/index.md @@ -0,0 +1,12 @@ +Title: Fix segfault in Done button of downloads +Author: rodarima +Created: Wed, 12 Jun 2024 19:26:13 +0000 +State: closed + +The destructor was using a harcoded index to the elements to free from the original array of arguments used to call the wget program. When the user agent was introduced, the index of the elements that require free() shifted, causing the free() call to operate on the constant string of the user agent instead. + +Rather than relying on the hardcoded index, two new pointers hold the values of the strings that need to be free()'d in the destructor. Further additions in the argument array won't cause more problems. + +Reported-by: pastebin +Fixes: https://github.com/dillo-browser/dillo/issues/196 +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/IPWQYKTYTO5G2BH3UU5224FRUFWCVGSO/
\ No newline at end of file diff --git a/198/index.md b/198/index.md new file mode 100644 index 0000000..59badf7 --- /dev/null +++ b/198/index.md @@ -0,0 +1,12 @@ +Title: Integrate a search mode in the location bar +Author: rodarima +Created: Fri, 14 Jun 2024 20:18:26 +0000 +State: open + +The current UX of opening a search engine is a bit cumbersome when using the search dialog (Ctrl+S). While we have the shortcuts that we can use to prefix a search in the location bar, for example "dd flying ducks" would search "flying ducks" on DuckDuckGo. + +Most of the search begin from an already loaded page, so I would suggest a different (optional) workflow. Press Ctrl+S to switch the location bar to search mode (we can mark it properly as such, and add the search engine menu to change the default). Then type the search query "flying ducks" and then decide if you want to open the results in the current page (Enter) or in another tab (Shift+Enter). + +This is a quicker method to do a search without changing the current context in which the search is done. It also allows the user to copy or read information from the current page while typing the query. It also has the benefit that the user will know at any time if the location bar is in URL or search mode, so **you can search for an url without worrying it will try to open it**. + +We can retain the current search prefixes in the search mode too, so we can switch to other search engines in the same way as before too.
\ No newline at end of file diff --git a/199/index.md b/199/index.md new file mode 100644 index 0000000..92f6990 --- /dev/null +++ b/199/index.md @@ -0,0 +1,14 @@ +Title: Allow actions to be defined to handle URLs +Author: rodarima +Created: Fri, 14 Jun 2024 20:32:45 +0000 +State: closed + +Implements the logic to read rules from ~/.dillo/rulesrc which define custom actions to handle a URL. Here is an example: + + action "Open with MPV" shell "mpv $url" + action "Open with MPV (only audio)" shell "mpv --no-video $url" + action "Open with Firefox" shell "firefox $url" + +The standard input and output is still redirected to the same file descriptor as Dillo. + +The commands are spawned in a forked process using the system() call, which uses the shell to expand any variable. In particular, the $url variable is set to the current URL being opened.
\ No newline at end of file diff --git a/2/index.md b/2/index.md new file mode 100644 index 0000000..77c0289 --- /dev/null +++ b/2/index.md @@ -0,0 +1,18 @@ +Title: GIF animation support +Author: rodarima +Created: Sun, 08 Nov 2020 10:48:30 +0000 +State: closed + +Can we add GIF support for animation? Here is a test: http://www.lcdf.org/gifsicle/logo.gif + +--%-- +From: rodarima +Date: Sun, 08 Nov 2020 12:19:03 +0000 + +One way may be to allow external programs to be executed when opening certain files. For example we can run mpv from a dpi filter using something like `dpi:/mpv/:http://www.lcdf.org/gifsicle/logo.gif` + +This would allow all kinds of formats available into libmpv, and we don't clutter the rendering mechanism in dillo. + +See [plumb](http://man.cat-v.org/plan_9/6/plumb) and [rifle](https://github.com/ranger/ranger/blob/master/ranger/config/rifle.conf). These tools could also handle hard-to-scrape websites such as youtube. + +So, let's generalize this issue in a general url opener.
\ No newline at end of file diff --git a/20/index.md b/20/index.md new file mode 100644 index 0000000..a122aab --- /dev/null +++ b/20/index.md @@ -0,0 +1,216 @@ +Title: Support for other SSL libraries +Author: rodarima +Created: Tue, 19 Dec 2023 18:56:44 +0000 +State: closed + +On 2016, corvid [changed the SSL implementation](https://github.com/dillo-browser/dillo/commit/b6247cde66c1450a6fccde9bfb100ee776af2571) from OpenSSL to [mbedTLS](https://github.com/Mbed-TLS/mbedtls) (previously polarSSL). The change makes Dillo depend on mbedTLS only, while before it was possible to link it with LibreSSL and OpenSSL. Other forks like [dillo-plus](https://github.com/crossbowerbt/dillo-plus/commits/main/src/IO/tls.c) have changed back to OpenSSL. + +We may want to reevaluate which SSL libraries we want Dillo to support. + +Here is a useful comparison from Curl: + +https://curl.se/docs/ssl-compared.html + +The good point of mbedTLS is that is small, so we can build Dillo with TLS support on small (embeded) devices. However, the WolfSSL library is also small and suitable for embedded devices while at the same time it has an API compatible with OpenSSL. + +On the other hand, a lot of packages already have a dependency with OpenSSL, so if we can link with it we wouldn't need to pull any extra dependencies on desktops. + +Supporting at least OpenSSL and wolfSSL seems to be a good tradeoff. + +--%-- +From: rodarima +Date: Tue, 19 Dec 2023 23:35:00 +0000 + +Here is the mailing list thread that initiated the switch to mbedTLS (eocene = corvid): + +https://groups.google.com/g/dillo/c/pFOpRyMcr20/m/i3kfLdbYAQAJ + +<details> + <summary>Here is a (partial) copy of the thread</summary> + +eocene +Jun 19, 2016, 10:50:59 PM +to dill...@dillo.org + +I wanted to see what it would take to use mbed tls with dillo. + +I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff +and I mention it here in case someone should want that one day. + + +That said, it looks like netsurf uses curl, and curl can use any +tls library you care to mention. And I'm pretty sure netsurf does +javascript. + +--- + +Jorge Arellano Cid +unread, +Jun 20, 2016, 4:12:06 AM +to dill...@dillo.org +Hi, + +On Sun, Jun 19, 2016 at 08:48:28PM +0000, eocene wrote: +> +> I wanted to see what it would take to use mbed tls with dillo. +> +> I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff +> and I mention it here in case someone should want that one day. + +What's the main point/difference in using mbedtls vs OpenSSL? + + +> That said, it looks like netsurf uses curl, and curl can use any +> tls library you care to mention. And I'm pretty sure netsurf does +> javascript. + +Sorry, I don't get the point here. + + +-- +Cheers +Jorge.- + +--- + +eocene +unread, +Jun 20, 2016, 5:33:51 AM +to dill...@dillo.org +> What's the main point/difference in using mbedtls vs OpenSSL? + +OpenSSL is such a notorious nightmare--one gets the distinct +impression that the developers have not taken their responsibility +seriously--that I was curious to try a different one that is +supposed to be more comprehensible. + +mbed tls had been on my mind as something I might want to try +someday after they implement OCSP stapling, but then I was just in +the mood for it the other day. + +As for how practical it would ever be to have this code in the real +dillo someday, I think that comes down to: How good are distributions +at making security updates available for their more obscure packages? + +> > That said, it looks like netsurf uses curl, and curl can use any +> > tls library you care to mention. And I'm pretty sure netsurf does +> > javascript. +> +> Sorry, I don't get the point here. + +I was thinking how if someone did get the idea in their head that +they wanted a small browser that works with mbed tls, dillo might +not be the first choice. + +--- + +Johannes Hofmann +unread, +Jun 20, 2016, 10:13:12 AM +to dill...@dillo.org +On Sun, Jun 19, 2016 at 08:48:28PM +0000, eocene wrote: +> +> I wanted to see what it would take to use mbed tls with dillo. +> +> I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff +> and I mention it here in case someone should want that one day. + +Excellent. I like mbedtls (formerly known as PolarSSL). The code +looks much saner to me than openssl. + +Cheers, +Johannes + +--- + +eocene's profile photo +eocene +unread, +Jun 20, 2016, 7:43:22 PM +to dill...@dillo.org +I wrote: +> As for how practical it would ever be to have this code in the real +> dillo someday, I think that comes down to: How good are distributions +> at making security updates available for their more obscure packages? + +I realized this is an exceedingly trivial concern when compared with the +fact that distributions have configured dillo with --enable-ssl for +years despite the state of the old dpi and our all-caps warnings, thereby +causing users to trust something they shouldn't. + +--- + +Jorge Arellano Cid +unread, +Jun 24, 2016, 5:36:44 PM +to dill...@dillo.org +On Mon, Jun 20, 2016 at 10:10:54AM +0200, Johannes Hofmann wrote: +> On Sun, Jun 19, 2016 at 08:48:28PM +0000, eocene wrote: +> > +> > I wanted to see what it would take to use mbed tls with dillo. +> > +> > I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff +> > and I mention it here in case someone should want that one day. +> +> Excellent. I like mbedtls (formerly known as PolarSSL). The code +> looks much saner to me than openssl. + +If you both agree it's a better lib than OpenSSL, +1. + +-- +Cheers +Jorge.- + +--- + +eocene's profile photo +eocene +unread, +Jul 3, 2016, 6:40:12 PM +to dill...@dillo.org +Jorge wrote: +> On Mon, Jun 20, 2016 at 10:10:54AM +0200, Johannes Hofmann wrote: +> > On Sun, Jun 19, 2016 at 08:48:28PM +0000, eocene wrote: +> > > +> > > I wanted to see what it would take to use mbed tls with dillo. +> > > +> > > I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff +> > > and I mention it here in case someone should want that one day. +> > +> > Excellent. I like mbedtls (formerly known as PolarSSL). The code +> > looks much saner to me than openssl. +> +> If you both agree it's a better lib than OpenSSL, +1. + +All right, then. *commits* + +If you need mbed TLS 2.x: https://tls.mbed.org/download + + +If you watch the MSGs, you'll see I've turned off the certificate chain +printing and instead show a more concise summary at shutdown of which +root certificates were used to verify communication with which servers. + +And at startup it'll tell you how many such certificates you are trusting. +By default, I had 174, but I've trimmed them down on this computer to...twenty +at the moment because I never need the ones from certificate authorities in +China, Turkey, Hungary, etc. + +</details> + +Which caused the initial commit: + +``` +commit b6247cde66c1450a6fccde9bfb100ee776af2571 +Author: corvid <devnull@localhost> +Date: Sun Jul 3 16:09:21 2016 +0000 + + use mbed TLS + + AUTHORS | 2 - + ChangeLog | 7 +- + configure.ac | 11 +- + src/IO/IO.c | 23 ++- + src/IO/tls.c | 1389 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------------------------- + 5 files changed, 674 insertions(+), 758 deletions(-) +```
\ No newline at end of file diff --git a/200/index.md b/200/index.md new file mode 100644 index 0000000..f82ad65 --- /dev/null +++ b/200/index.md @@ -0,0 +1,6 @@ +Title: Check build with old C++ standards +Author: rodarima +Created: Fri, 21 Jun 2024 18:25:05 +0000 +State: closed + +The static_assert fails with standards older than C++11, so we may want to only enable it if available. So far it seems to build with C++03.
\ No newline at end of file diff --git a/201/index.md b/201/index.md new file mode 100644 index 0000000..bc021b2 --- /dev/null +++ b/201/index.md @@ -0,0 +1,6 @@ +Title: Add CI job to build with old C and C++ standards +Author: rodarima +Created: Fri, 21 Jun 2024 20:17:09 +0000 +State: closed + +Closes #200
\ No newline at end of file diff --git a/202/index.md b/202/index.md new file mode 100644 index 0000000..547c095 --- /dev/null +++ b/202/index.md @@ -0,0 +1,5 @@ +Title: Fix tbody Flags +Author: rodarima +Created: Sat, 22 Jun 2024 19:00:35 +0000 +State: closed + diff --git a/203/index.md b/203/index.md new file mode 100644 index 0000000..efe7214 --- /dev/null +++ b/203/index.md @@ -0,0 +1,34 @@ +Title: Dissapearing content in FLTK website +Author: rodarima +Created: Sun, 23 Jun 2024 13:06:36 +0000 +State: closed + + + + +--%-- +From: ghost +Date: Sat, 05 Oct 2024 10:37:37 +0000 + +This issue appears to be resolved, the site looks fine now. + + +--%-- +From: rodarima +Date: Sat, 05 Oct 2024 11:17:44 +0000 + +Not sure if it is related, but I still trigger the infinite layout bug if I resize the window enough times: + +``` +>>>> a_Nav_repush <<<< +Nav_open_url: new url='https://www.fltk.org/' +IO_write, closing with pending data not sent: "GET /images/rss-feed-icon.png HTTP/1.1\x0D..." +a_Nav_expect_done: repush! +** ERROR **: Emergency layout stop after 1000 iterations +** ERROR **: Please file a bug report with the complete console output +** ERROR **: Emergency layout stop after 1000 iterations +** ERROR **: Please file a bug report with the complete console output +** ERROR **: Emergency layout stop after 1000 iterations +``` + +But let's cover that on https://github.com/dillo-browser/dillo/issues/236.
\ No newline at end of file diff --git a/204/index.md b/204/index.md new file mode 100644 index 0000000..2d9337c --- /dev/null +++ b/204/index.md @@ -0,0 +1,289 @@ +Title: Dillo is changing URL and appending a 0. +Author: rouilj +Created: Mon, 24 Jun 2024 06:17:33 +0000 +State: closed + +When I try to go to https://rouilj.dynamic -dns.net/demo/. It looks like the server responds with a +200 code and 14k of data. However I never see the data. Instead dillo displays a 403 error by +accessing: https://rouilj.dynamic -dns.net/demo/0. (Just remove the space before the dash to get the +actual url. Just trying to cut down on traffic to the url.) + +The site does return a cookie using SameSite that dillo complains about, but it seems to save the +cookie. + +Dillo logging does show both urls in a Nav_open_url log line. + +Other URL's on the site work. Other browsers (firefox, chrome, links, w3m) on the original URL operate +correctly as well. + +Any ideas on how I can figure out why dillo is "rewriting" and "redirecting" to an invalid URL? + +I looked at the docs, the dillo help text and the dillorc. There doesn't seem to be a more verbose +mode I can set. dillorc is the default with no changes. cookiesrc is default accept (but it failed the same way with default deny). ~/.dillo has no other config files. + +Thanks. + + +--%-- +From: rodarima +Date: Mon, 24 Jun 2024 10:19:47 +0000 + +Thanks for the report, it seems to be caused by the meta tag without the redirect URL. Here is a reproducer: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test empty URL refresh</title> + <meta http-equiv="Refresh" content="0"> + </head> + <body> + <p>Refresh</p> + </body> +</html> +``` + +``` +% dillo /tmp/meta-redirect.html +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.0 9 Apr 2024 +Enabling cookies as from cookiesrc... +Nav_open_url: new url='file:/tmp/meta-redirect.html' +... +Nav_open_url: new url='file:/tmp/0' +``` +I'll see if I can fix the parser. + +--%-- +From: rouilj +Date: Mon, 24 Jun 2024 14:20:56 +0000 + +Hello: + +In message ***@***.***>, +rodarima writes: + +>Thanks for the report, it seems to be caused by the meta tag without +>the redirect URL. Here is a reproducer: +> +>```html +><!DOCTYPE html> +><html> +> <head> +> <title>Test empty URL refresh</title> +> <meta http-equiv="Refresh" content="0"> +> </head> +> <body> +> <p>Refresh</p> +> </body> +></html> +>``` + +Ah, that makes sense. I was wondering where 0 was comming from. Dillo +is interpreting the refresh delay time as the url value. + +>``` +>% dillo /tmp/meta-redirect.html +>dillo_dns_init: Here we go! (threaded) +>TLS library: OpenSSL 3.3.0 9 Apr 2024 +>Enabling cookies as from cookiesrc... +>Nav_open_url: new url='file:/tmp/meta-redirect.html' +>... +>Nav_open_url: new url='file:/tmp/0' +>``` + +Yup that's what I saw. + +>I'll see if I can fix the parser. + +Sounds good. The refresh is part of the technique for detecting if +javascript is available/enabled. See: + + https://wiki.roundup-tracker.org/IsJavascriptAvailable + +for details. + +This allows the server to replace javascript driven interactions with +native element. For example replace an multiple value autocomplete +widget with a select multiple element. + +-- + -- rouilj +John Rouillard +=========================================================================== +My employers don't acknowledge my existence much less my opinions. + + +--%-- +From: rodarima +Date: Mon, 24 Jun 2024 17:45:26 +0000 + +Hi, + +>Sounds good. The refresh is part of the technique for detecting if +>javascript is available/enabled. See: +> +> https://wiki.roundup-tracker.org/IsJavascriptAvailable +> +>for details. +> +>This allows the server to replace javascript driven interactions with +>native element. For example replace an multiple value autocomplete +>widget with a select multiple element. + +This would not work in Dillo, even with my proposed patch. It will just +ignore the meta refresh tag. + +You could redirect the page to another URL like this: + +<noscript> +<meta http-equiv="Refresh" content="0;URL=https://your.site/demo/?nojs=1"> +</noscript> + +And then set the cookie when the nojs parameter is set. + +Also you can probably load the non-JS version by default, and then +enhance the site replacing the elements you want (or the whole page) +when JS is enabled. + +Another question is if Dillo should support redirects to the same page +or not, as these could cause loops. + + +--%-- +From: rouilj +Date: Mon, 24 Jun 2024 21:55:40 +0000 + +Hello: + +In message ***@***.***>, +rodarima writes: +>>Sounds good. The refresh is part of the technique for detecting if +>>javascript is available/enabled. See: +>> +>> https://wiki.roundup-tracker.org/IsJavascriptAvailable +>> +>>for details. +>> +>>This allows the server to replace javascript driven interactions with +>>native element. [...] +> +>This would not work in Dillo, even with my proposed patch. It will just +>ignore the meta refresh tag. + +So dillo will just ignore the tag if it doesn't explicitly specify the +url? + +>You could redirect the page to another URL like this: +> +><noscript> +><meta http-equiv="Refresh" content="0;URL=https://your.site/demo/?nojs=1"> +></noscript> +> +>And then set the cookie when the nojs parameter is set. + +I did try something similar originally. However modifying the URL +isn't a great UI. + +The url that is presented may or may not have query parameters and a +fragment. I have to create the new URL (with @no_js=1) on the server +and preserve the original query args. But IIRC a bigger issue was that +the server doesn't see the fragment. The redirect ended up removing +the fragment from the URL. + +Using a refresh content="0" kept the fragment because the browser was +just reusing the current page url and it had access to the fragment. +I didn't find anything documented that specified that was required, +but it worked for the browsers and OS's I tested on. + +Also the URL, unlike cookies, can be saved. I prefer to not put +settings like that in the URL where it could end up in a bookmark. + +>Also you can probably load the non-JS version by default, and then +>enhance the site replacing the elements you want (or the whole page) +>when JS is enabled. + +The default supplied web interface works on text based browsers by not +requiring JS. It is very much a web 1.0 application. + +However people can redefine the web interface and choose JS first with +a non-js fallback if they wish. IIRC that's the scenario that +IsJavascriptAvailable was trying to solve. + +>Another question is if Dillo should support redirects to the same page +>or not, as these could cause loops. + +I would think it should. Other browsers detect redirect loops. I don't +know the mechanism, but think they use some mechanism of checking the +number of times the same url has been redirected to in a row (possibly +within some short period of time). I assume dillo has some method of +detecting redirect loops via 3XX redirects. Maybe that could be used +here pretending a "0" second meta redirect is like a 307 redirect +status? + +Redirecting to the same page with a longer period of time is also +useful. For example the user can set the page I referenced to refresh +after 60 seconds. This makes sure that the list of issues is kept up +to date. + +Sorry I don't have any other ideas on how other browsers handle this +valid HTML meta tag. + +Have a great week. + +-- + -- rouilj + + +--%-- +From: rodarima +Date: Tue, 25 Jun 2024 19:23:46 +0000 + +Hi, + +>So dillo will just ignore the tag if it doesn't explicitly specify the +>url? + +Dillo will only try to follow the redirect if the following properties +are all met: + +- It has delay zero +- The destination is not to the same URL +- The current URL doesn't have the URL_SpamSafe flag. +- The new URL is considered safe (doesn't start with "dpi:") + +The URL_SpamSafe is set in some cases like for local files and other +less common cases, but is not very well documented. + +When the delay is greater than zero, it will show a message in the top +of the page to let the user follow the redirect manually. + +>>Another question is if Dillo should support redirects to the same page +>>or not, as these could cause loops. +> +>I would think it should. Other browsers detect redirect loops. I don't +>know the mechanism, but think they use some mechanism of checking the +>number of times the same url has been redirected to in a row (possibly +>within some short period of time). I assume dillo has some method of +>detecting redirect loops via 3XX redirects. Maybe that could be used +>here pretending a "0" second meta redirect is like a 307 redirect +>status? +> +>Redirecting to the same page with a longer period of time is also +>useful. For example the user can set the page I referenced to refresh +>after 60 seconds. This makes sure that the list of issues is kept up +>to date. +> +>Sorry I don't have any other ideas on how other browsers handle this +>valid HTML meta tag. + +I opened issue #206 to implement support for redirects controlled by a +configuration option, so we let the users choose what they want. I will +leave this issue to focus on the bug that it was redirecting to /0 +because it was parsing the delay as the new url. + +I also think it has some good use cases, but not sure if it should be +enabled by default. For example, some pages create a long list of +redirects to try to trick the user into being unable to go back +(easily). On the other hand, having a monitoring page that refreshes +every minute is a good use case. diff --git a/205/index.md b/205/index.md new file mode 100644 index 0000000..b41f767 --- /dev/null +++ b/205/index.md @@ -0,0 +1,8 @@ +Title: Ignore meta refresh content without URL +Author: rodarima +Created: Mon, 24 Jun 2024 12:35:20 +0000 +State: closed + +The content="0" attribute was wrongly parsed as the URL "0". The change makes the parser ignore a redirect with a content value that doesn't have ";" or "url=" after the delay number. + +Fixes: https://github.com/dillo-browser/dillo/issues/204
\ No newline at end of file diff --git a/206/index.md b/206/index.md new file mode 100644 index 0000000..1559c28 --- /dev/null +++ b/206/index.md @@ -0,0 +1,8 @@ +Title: Handle http-equiv refresh if the user wants to +Author: rodarima +Created: Tue, 25 Jun 2024 18:56:41 +0000 +State: open + +Some users may want to enable support for the meta http-equiv refresh tag, which allows pages to automatically refresh or redirect to another URL. This is particularly useful to make Dillo work as a monitor panel in a page that shows information and [refreshes from time to time](https://forums.raspberrypi.com/viewtopic.php?t=330705) or to [redirect to a non-JS page](https://github.com/dillo-browser/dillo/issues/204). + +We can implement an option that allows users to choose what to do, with the current default of ignoring refreshes and showing a message for redirects.
\ No newline at end of file diff --git a/207/index.md b/207/index.md new file mode 100644 index 0000000..240ac00 --- /dev/null +++ b/207/index.md @@ -0,0 +1,37 @@ +Title: Long alt text makes image too wide +Author: rodarima +Created: Wed, 26 Jun 2024 21:55:54 +0000 +State: open + +Long alt text in images should be split into lines, but they are not. + +Reproducer: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test image with long alt text</title> + <style> + div {margin: 20px; max-width: 400px; background: lightyellow; } + img {background: lightgreen; } + </style> + </head> + <body> + <div> + This should be 400 px wide. + </div> + <div> + The following image should fail to load and show the alt text instead. + However, the text is longer than the div width and must be split into + multiple lines to avoid making the div longer. + <img alt="This is the image alt text and as you can see it is longer than the containing div." src="not-existing-image.png"> + </div> + </body> +</html> +``` + + + + +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/PDDFE5T43OEDQOH33SDKJXCX72GN3VUI/
\ No newline at end of file diff --git a/208/index.md b/208/index.md new file mode 100644 index 0000000..d205159 --- /dev/null +++ b/208/index.md @@ -0,0 +1,8 @@ +Title: Ensure Dillo fits in a floppy disk +Author: rodarima +Created: Sat, 29 Jun 2024 10:39:47 +0000 +State: closed + +One of the ways in which we can test we don't add too much complexity to Dillo is to limit the size of the release. As it is currently around 1 MiB, I though a good limit would be a [3½-inch floppy disk of 1.44 MB](https://en.wikipedia.org/wiki/Floppy_disk#3%C2%BD-inch_disk) (actually 1440 KiB = 1.41 MiB). That would be 1474560 bytes. + +As we already make the distributable releases, we only need to check the file size. Compression algorithms will produce different sizes, but let see if we can manage with gzip or bzip2, which are widely available.
\ No newline at end of file diff --git a/209/index.md b/209/index.md new file mode 100644 index 0000000..d149009 --- /dev/null +++ b/209/index.md @@ -0,0 +1,8 @@ +Title: Check release fits in a floppy disk of 1.44 MB +Author: rodarima +Created: Sat, 29 Jun 2024 11:12:16 +0000 +State: closed + +For now we check gzip as it is widely available and has a medium compression ratio. + +Fixes: https://github.com/dillo-browser/dillo/issues/208
\ No newline at end of file diff --git a/21/index.md b/21/index.md new file mode 100644 index 0000000..f3a31e9 --- /dev/null +++ b/21/index.md @@ -0,0 +1,44 @@ +Title: Change font size with Control +/- +Author: rodarima +Created: Wed, 20 Dec 2023 00:01:43 +0000 +State: closed + +The default font size factor in Dillo is fixed until the browser is closed and open again. However, some pages have very small font sizes and it would be convenient if we can allow the factor to be modified live. + +The shortcuts <kbd>Control</kbd><kbd>+</kbd> and <kbd>Control</kbd><kbd>-</kbd> are typically used for this end in other browsers. + +--%-- +From: ToyKeeper +Date: Wed, 03 Jan 2024 21:46:32 +0000 + +Another effective solution for this: Dillo-plus has a book reader mode, which is basically just another stylesheet which can be added or removed on the fly. When a site isn't readable with default settings, I find it usually looks good after I disable remote and inline CSS and enable book reader mode instead. + +It would be cool if there were hotkeys to do this, or ideally, the ability to define multiple different stylesheets and switch between them with hotkeys. Then the user could change anything they want, not just limited to the font size. + +As another stretch goal, so to speak, it'd be awesome if user stylesheets could be enabled automatically if the URL prefix matches... like, if the URL starts with a particular string, then enable a particular stylesheet. That way, they could permanently override things per site. + +If someone feels especially ambitious, there could even be a repository of site-specific or platform-specific overrides, to make popular sites work better in Dillo. For example, I use a stylesheet to fix the layout of Discourse forums. I've been meaning to do one for Github too. Something like this could be done in a DPI, perhaps. + +At minimum though, it'd be helpful to have hotkeys to toggle remote and inline CSS and reader mode CSS. + + +--%-- +From: rodarima +Date: Wed, 03 Jan 2024 22:02:35 +0000 + +> Another effective solution for this: Dillo-plus has a book reader mode, which is basically just another stylesheet which can be added or removed on the fly. When a site isn't readable with default settings, I find it usually looks good after I disable remote and inline CSS and enable book reader mode instead. + +Nice to know, I haven't tested much dillo-plus. However I would like to still have a way to increase *everything* on the page easily and temporarily, including images. Specially for users that are not familiar with CSS (or they are too lazy to write it, like me when is late at night). + +I have a patch that works kind of okay, but there are some problems to fix still. + +> +> It would be cool if there were hotkeys to do this, or ideally, the ability to define multiple different stylesheets and switch between them with hotkeys. Then the user could change anything they want, not just limited to the font size. +> +> As another stretch goal, so to speak, it'd be awesome if user stylesheets could be enabled automatically if the URL prefix matches... like, if the URL starts with a particular string, then enable a particular stylesheet. That way, they could permanently override things per site. + +I had some idea to do this already, and also to run some filter script too, in case you need to also patch the HTML of certain sites. Regarding switching styles I also wanted to include a dark/light theme (at least) so you can switch colors for surfing the web at night (much like Dark Reader). But one step at a time :-) + +> If someone feels especially ambitious, there could even be a repository of site-specific or platform-specific overrides, to make popular sites work better in Dillo. For example, I use a stylesheet to fix the layout of Discourse forums. I've been meaning to do one for Github too. Something like this could be done in a DPI, perhaps. + +I'll be surprised if this is not a thing already. I know for example Firefox has some quirks to fix some websites, but is built in the browser.
\ No newline at end of file diff --git a/210/index.md b/210/index.md new file mode 100644 index 0000000..ca0db76 --- /dev/null +++ b/210/index.md @@ -0,0 +1,26 @@ +Title: Reduce floppy disk size after formatting +Author: rodarima +Created: Sat, 29 Jun 2024 14:40:21 +0000 +State: closed + +The useful space to store files inside a floppy is less than the capacity of the floppy itself: +``` + % mkfs.msdos -C floppy.img 1440 + mkfs.fat 4.2 (2021-01-31) + % stat -c %s floppy.img + 1474560 + % mkdir floppy + % sudo mount -o loop,uid=$USER floppy.img floppy + % dd if=/dev/zero bs=1 count=100M of=floppy/test + dd: error writing 'floppy/test': No space left on device + 1457665+0 records in + 1457664+0 records out + 1457664 bytes (1,5 MB, 1,4 MiB) copied, 0,912079 s, 1,6 MB/s + % echo $((1474560 - 1457664)) + 16896 +``` +It needs a bit more than 16K to store the FAT table, so round it to 32K to allow some clearance for changes in FAT header size. +``` + % echo $((1474560 - 32*1024)) + 1441792 +```
\ No newline at end of file diff --git a/211/index.md b/211/index.md new file mode 100644 index 0000000..8665036 --- /dev/null +++ b/211/index.md @@ -0,0 +1,38 @@ +Title: Add primitive SVG support +Author: rodarima +Created: Sun, 30 Jun 2024 15:13:13 +0000 +State: closed + +Adds primitive SVG suport by using a modified nanosvg library that can render Wikipedia equations. Many other features of the SVG standard are not implemented. + +The idea is to provide a self-contained small implementation for SVG which can later be optionally replaced by a more complete implementation. + +The initial version was taken from the mobilized fork: https://www.toomanyatoms.com/software/mobilized_dillo.html + +Increases the floppy occupation from 87% to 89%. + +--%-- +From: rodarima +Date: Sun, 07 Jul 2024 09:29:28 +0000 + +Cannot render equations that use `<symbol>`: https://mathworld.wolfram.com/images/equations/FourierTransform/NumberedEquation10.svg + +--%-- +From: rodarima +Date: Sun, 07 Jul 2024 19:09:43 +0000 + +Added primitive support for symbols too. + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 15:16:57 +0000 + +PEC badges in SVG are broken too: https://dillo-browser.github.io/pec/ + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 15:34:44 +0000 + +> PEC badges in SVG are broken too: https://dillo-browser.github.io/pec/ + +This can be "solved" by converting the SVG to paths, which is enough for now.
\ No newline at end of file diff --git a/212/index.md b/212/index.md new file mode 100644 index 0000000..923b0f7 --- /dev/null +++ b/212/index.md @@ -0,0 +1,10 @@ +Title: Fix ASan new-delete-type-mismatch error +Author: rodarima +Created: Sat, 06 Jul 2024 10:02:23 +0000 +State: closed + +With the adreess sanitizer enabled there was an error: + +> AddressSanitizer: new-delete-type-mismatch + +Caused by a size mismatch in the delete operator as the called destructor was the incorrect one.
\ No newline at end of file diff --git a/213/index.md b/213/index.md new file mode 100644 index 0000000..648a47a --- /dev/null +++ b/213/index.md @@ -0,0 +1,22 @@ +Title: Improve message reporting +Author: rodarima +Created: Sat, 06 Jul 2024 17:29:12 +0000 +State: open + +The current way in which Dillo reports problems is divided into several categories: + +- HTML bugs go to the bug window. +- Errors, warnings and other informational messages go to the standard output/error. +- Some information messages go to the status bar. +- Debug messages are commented and only enabled by manually changing the code. + +This ends up in a non clean console output, as well as users missing any important message when they don't open Dillo from a console. + +On the other hand, it is important that we continue to have a simple standard error/output method of reporting problems, as a crash will cause the error console to be inaccesible. + +So I suggest we do the following: + +- Always compile all messages execept those debug messages that may be in a critical path and may affect a lot the performance (unlikely), +- Allow the bug window (or another window) to receive messages from diferent parts of the code. +- Let the user filter messages in the console window by severity (error, warning, info, debug). +- By default, propagate error messages to the stderr too (allowing the user to increase the verbosity)
\ No newline at end of file diff --git a/214/index.md b/214/index.md new file mode 100644 index 0000000..74284f0 --- /dev/null +++ b/214/index.md @@ -0,0 +1,6 @@ +Title: Allow linking to a given line in HTML source view +Author: rodarima +Created: Sat, 06 Jul 2024 20:56:40 +0000 +State: closed + +When reporting bugs in the bug window it would be convenient to allow them to be clicked to open the specific line in which they occur. This could be easily implemented by adding anchors to each line (like `#L123`) and then building an appropriate link in the bug window.
\ No newline at end of file diff --git a/215/index.md b/215/index.md new file mode 100644 index 0000000..ecca01f --- /dev/null +++ b/215/index.md @@ -0,0 +1,19 @@ +Title: Improve Wikipedia math rendering +Author: rodarima +Created: Sat, 06 Jul 2024 21:04:52 +0000 +State: open + +We'll have to fix several problems: +- [x] Implement support for SVG with references: #211 +- [ ] Improve support for ex units as they are used to control math equation sizes and currently they are sometimes too small. +- [x] Add support for rem units as they are used to set the padding: #264 +- [ ] Implement support for `var()` custom variables as they control the line-height. + +Test pages: +- https://en.wikipedia.org/wiki/Maxwell%27s_equations +- https://en.wikipedia.org/wiki/Quantum_entanglement +- https://en.wikipedia.org/wiki/Wave_function +- https://en.wikipedia.org/wiki/Dirac_delta_function +- https://en.wikipedia.org/wiki/Fourier_transform +- https://mathworld.wolfram.com/FourierTransform.html +- https://en.wikisource.org/wiki/On_Einstein%27s_Theory_of_gravitation
\ No newline at end of file diff --git a/216/index.md b/216/index.md new file mode 100644 index 0000000..df70ecb --- /dev/null +++ b/216/index.md @@ -0,0 +1,82 @@ +Title: Debian package +Author: rodarima +Created: Sun, 07 Jul 2024 09:33:01 +0000 +State: open + +Try to update the current Debian package, as it still is using the old 3.0.5 version which has TLS problems. + +Here is a test package for Debian 12 (amd64 architecture): [dillo_3.1.1-1_amd64.deb.gz](https://github.com/user-attachments/files/16118717/dillo_3.1.1-1_amd64.deb.gz) + +To install: + +```sh +$ wget https://github.com/user-attachments/files/16118717/dillo_3.1.1-1_amd64.deb.gz +$ gunzip dillo_3.1.1-1_amd64.deb.gz +$ sudo dpkg -i dillo_3.1.1-1_amd64.deb +$ dpidc stop # To ensure we don't have any Dillo plugin running +``` + +--%-- +From: ghost +Date: Sun, 07 Jul 2024 10:15:36 +0000 + +Looks OK on 12.6, installing through apt even pulls the correct dependency (libfltk1.3), I've tried a bunch of websites and it seems to be stable. + +--%-- +From: bbbhltz +Date: Sun, 07 Jul 2024 10:34:39 +0000 + +Also on 12.6 and it works on the websites I've tried. + +--%-- +From: rodarima +Date: Sun, 07 Jul 2024 19:05:15 +0000 + +(I'm waiting on the debian GitLab repository to activate my account so I can open a MR there) + +--%-- +From: rodarima +Date: Sat, 13 Jul 2024 10:37:00 +0000 + +Openned merge request on Debian: https://salsa.debian.org/debian/dillo/-/merge_requests/1 + +--%-- +From: steinarb +Date: Sat, 13 Jul 2024 17:19:04 +0000 + +Running on 12.6 bookworm now. + +CSS seems a clear improvement to [dillo 3.0.5-7](https://packages.debian.org/bookworm/dillo) but not yet good enough to handle https://gridbyexample.com/examples/page-layout/listing-with-thumbnails/ (most notably, the thumbnails are blown up to gigantic size: they get the width of the browser window). + +I am trying to make https://oldalbum.bang.priv.no/ show something more interesting than "This page requires javascript" ([project described here](https://steinar.bang.priv.no/2022/02/12/1990-ies-picture-archives-in-modern-skin/)) + +I currently have something similar to the original https://www.bang.priv.no/sb/pics/ running but I was trying to style it up to look better but what I tried was maybe a bit advanced for dillo's current state. + +Are there plans for CSS improvements? (should I remove the flexbox/grid formatting and try something simpler or is there radical improvements on the way for dillo?) + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 12:19:07 +0000 + +> Running on 12.6 bookworm now. +> ... + +This issue is about updating the Debian package, I opened another one to discuss the CSS topic: https://github.com/dillo-browser/dillo/issues/223 + +--%-- +From: steinarb +Date: Sun, 14 Jul 2024 13:18:48 +0000 + +> This issue is about updating the Debian package, I opened another one to discuss the CSS topic: #223 + +Thanks! This was mostly me thinking out loud. + + +--%-- +From: arpinux +Date: Tue, 16 Sep 2025 12:30:26 +0000 + +hi, +dillo debian stable version cannot open debian.org website but your version (3.2.0) can open it successfully. +so i report this bug on debian, hoping someone could take your git version to build dillo for debian. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1114901
\ No newline at end of file diff --git a/217/index.md b/217/index.md new file mode 100644 index 0000000..a4bf245 --- /dev/null +++ b/217/index.md @@ -0,0 +1,14 @@ +Title: Defaulted and deleted functions only available with ‘-std=c++11’ +Author: rodarima +Created: Sun, 07 Jul 2024 16:51:38 +0000 +State: closed + +The `= default` is C++11: + +``` +container.hh:254:25: warning: defaulted and deleted functions only available with ‘-std=c++11’ or ‘-std=gnu++11’ + 254 | virtual ~Node() = default; + | ^~~~~~~ +``` + +Let's try to keep the std requirement at C++98.
\ No newline at end of file diff --git a/218/index.md b/218/index.md new file mode 100644 index 0000000..cbd5f98 --- /dev/null +++ b/218/index.md @@ -0,0 +1,15 @@ +Title: The old std check doesn't fail if newer features are used +Author: rodarima +Created: Sun, 07 Jul 2024 16:52:41 +0000 +State: closed + +See https://github.com/dillo-browser/dillo/actions/runs/9818421298/job/27110999157#step:6:11 + +--%-- +From: rodarima +Date: Sat, 13 Jul 2024 11:17:48 +0000 + +This seems to make it fail, but it also uncovers some other problems: +``` +../configure 'CFLAGS=-std=c99' 'CXXFLAGS=-pedantic -std=c++98 -Werror=c++11-extensions' +```
\ No newline at end of file diff --git a/219/index.md b/219/index.md new file mode 100644 index 0000000..eb2168c --- /dev/null +++ b/219/index.md @@ -0,0 +1,14 @@ +Title: Add anchor to HTML source lines and improve the design +Author: rodarima +Created: Wed, 10 Jul 2024 20:12:15 +0000 +State: closed + +Adds a line anchor so we can make hyperlinks to an specific line. + +Additionally improves a bit the design of the line number colors: + +Here is the old style: + + +And new: +
\ No newline at end of file diff --git a/22/index.md b/22/index.md new file mode 100644 index 0000000..25a238a --- /dev/null +++ b/22/index.md @@ -0,0 +1,6 @@ +Title: Allow users to change mouse wheel scroll step +Author: rodarima +Created: Wed, 20 Dec 2023 00:05:15 +0000 +State: closed + +When using the mouse wheel to scroll a page, I feel it only moves a very short amount in each step. This parameter may be different in other mouses/systems so it should be user controlled. A simple solution is to add a configuration option that specifies the scroll step.
\ No newline at end of file diff --git a/220/index.md b/220/index.md new file mode 100644 index 0000000..0d92fed --- /dev/null +++ b/220/index.md @@ -0,0 +1,6 @@ +Title: Scroll past the page boundaries +Author: rodarima +Created: Sat, 13 Jul 2024 08:19:04 +0000 +State: open + +We may want to consider adding the capability of scrolling the page further down (and maybe up) so we can place every pixel of content in any position, rather than having to force the eyes go to the bottom of the screen to read the content there.
\ No newline at end of file diff --git a/221/index.md b/221/index.md new file mode 100644 index 0000000..c632938 --- /dev/null +++ b/221/index.md @@ -0,0 +1,6 @@ +Title: Keep scroll position after zooming +Author: rodarima +Created: Sat, 13 Jul 2024 08:20:57 +0000 +State: open + +https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/DDBQTIQMZ4PBULGJMWER2MRTB5Z2GCTO/
\ No newline at end of file diff --git a/222/index.md b/222/index.md new file mode 100644 index 0000000..937f08a --- /dev/null +++ b/222/index.md @@ -0,0 +1,133 @@ +Title: Dillo should allow <div> inside <a> +Author: steinarb +Created: Sat, 13 Jul 2024 17:58:00 +0000 +State: closed + +I was trying to create the structure shown here with an <ul> containing <li> elements containing an <a> which in turns contains some <div> elements for formatting. + +But dillo 3.1.1 didn't like that: +``` +HTML warning: line 37, Bad nesting: <a> can't contain <div>. -- closing <a>. +HTML warning: line 46, Unexpected closing tag: </a> -- expected </ul>. +``` +I think there is a lot of modern CSS stuff that can't be made to look good if <div>s aren't allowed almost anywhere, so it might be good to allow more stuff in different element contents (at least in <a> but probably elsewhere as well). + +Shooting for HTML5 is probably a good idea (<div> is allowed in <a> in HTML5), but I don't know how feasible it is? + + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 11:48:57 +0000 + +Dillo already allows authors to use `div` elements inside `a` (anchor) elements **in HTML5**. For HTML 4.01 this is not allowed, so Dillo complains and closes the anchor. See https://stackoverflow.com/a/1828032. + +Here are the tests, for HTML5: +```html +<!DOCTYPE html> +<html> + <head> + <title>Div inside a in HTML5</title> + </head> + <body> + <a href="#"> + <div> + <img src=pic.png> + <p>This paragraph along with the picture should be hyperlink.</p> + </div> + </a> + </body> +</html> +``` + +For HTML 4.01: +```html +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" + "http://www.w3.org/TR/html4/strict.dtd"> +<html> + <head> + <title>Div inside a in HTML4</title> + </head> + <body> + <a href="#"> + <div> + <img src=pic.png> + <p>This paragraph along with the picture should fail to be an hyperlink.</p> + </div> + </a> + </body> +</html> +``` + + + + +If you are reading that error lines in the bug meter, your document has not the proper HTML 5 doctype so it is not being parsed as HTML 5. Ensure the first line of your document is this: + +```html +<!DOCTYPE html> +``` + +--%-- +From: steinarb +Date: Sun, 14 Jul 2024 13:17:39 +0000 + +Ah! Right I should have read the first error line better and googled a little better: +``` +HTML warning: line 1, The required DOCTYPE declaration is missing. Handling as HTML4. +``` + +No DOCTYPE at all in my HTML, so that's easy to fix. + +Correction: I used XHTML (a long time back): +``` +<html xmlns="http://www.w3.org/1999/xhtml" prefix="og: https://ogp.me/ns#"> +``` + + +(but it is hard to find the current state of things in dillo by googling) + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 13:57:24 +0000 + +> Ah! Right I should have read the first error line better and googled a little better: +> +> ``` +> HTML warning: line 1, The required DOCTYPE declaration is missing. Handling as HTML4. +> ``` +> +> No DOCTYPE at all in my HTML, so that's easy to fix. +> +> Correction: I used XHTML (a long time back): +> +> ``` +> <html xmlns="http://www.w3.org/1999/xhtml" prefix="og: https://ogp.me/ns#"> +> ``` +> +> (but it is hard to find the current state of things in dillo by googling) + +AFAIK, XHTML 1.0 doesn't allow anything that is not inline inside an anchor: + +https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd +``` +<!-- content is %Inline; except that anchors shouldn't be nested --> +``` +But `div` is a block element, so it is not allowed inside an anchor in XHTML 1.0 either. + +Also, XHTML documents also must have a doctype. The validator will help you: https://validator.w3.org/ + +--%-- +From: steinarb +Date: Sun, 14 Jul 2024 16:49:06 +0000 + +For now I've removed the XML namepace from <html> and given the template file an HTML5 DOCTYPE (as indicated by you in https://github.com/dillo-browser/dillo/issues/222#issuecomment-2227316952 ) and things are behaving much nicer in dillo as well as continuing to work as before in WebKit browsers (vivaldi and chromium) and Firefox. + +(in WebKit and Firefox the app is a react app, but I am aiming to have a similar experience in dillo (at least eventually), and in the process I will make https://github.com/steinarb/oldalbum more web crawler friendly) + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 16:57:52 +0000 + +> For now I've removed the XML namepace from <html> and given the template file an HTML5 DOCTYPE (as indicated by you in https://github.com/dillo-browser/dillo/issues/222#issuecomment-2227316952 ) and things are behaving much nicer in dillo as well as continuing to work as before in WebKit browsers (vivaldi and chromium) and Firefox. + +Nice, closing this then.
\ No newline at end of file diff --git a/223/index.md b/223/index.md new file mode 100644 index 0000000..5935ee9 --- /dev/null +++ b/223/index.md @@ -0,0 +1,101 @@ +Title: Support for CSS grid and flexbox +Author: rodarima +Created: Sun, 14 Jul 2024 12:02:05 +0000 +State: open + +CSS seems a clear improvement to [dillo 3.0.5-7](https://packages.debian.org/bookworm/dillo) but not yet good enough to handle https://gridbyexample.com/examples/page-layout/listing-with-thumbnails/ (most notably, the thumbnails are blown up to gigantic size: they get the width of the browser window). + +I am trying to make https://oldalbum.bang.priv.no/ show something more interesting than "This page requires javascript" ([project described here](https://steinar.bang.priv.no/2022/02/12/1990-ies-picture-archives-in-modern-skin/)) + +I currently have something similar to the original https://www.bang.priv.no/sb/pics/ running but I was trying to style it up to look better but what I tried was maybe a bit advanced for dillo's current state. + +Are there plans for CSS improvements? (should I remove the flexbox/grid formatting and try something simpler or is there radical improvements on the way for dillo?) + +_Originally posted by @steinarb in https://github.com/dillo-browser/dillo/issues/216#issuecomment-2227000999_ + + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 12:16:53 +0000 + +> CSS seems a clear improvement to [dillo 3.0.5-7](https://packages.debian.org/bookworm/dillo) but not yet good enough to handle https://gridbyexample.com/examples/page-layout/listing-with-thumbnails/ (most notably, the thumbnails are blown up to gigantic size: they get the width of the browser window). + +The CSS grid feature is not implemented in Dillo, so it get's ignored. What remains seems to follow what the CSS says for the wrapper: +```html +<div class="wrapper"> +<h1>Responsive listing with thumbnails</h1> + <ul class="imagegrid"> + <li><img src="/img/pattern-2-3.jpg" alt="Image at mobile view"></li> + <li><img src="/img/pattern-2-1.jpg" alt="Image at wide view"></li> + <li><img src="/img/pattern-2-2.jpg" alt="Image at medium view"></li> + </ul> +``` +```CSS +.wrapper { + margin: 0 auto; + width: 90%; + max-width: 1600px; } +``` + +> I am trying to make https://oldalbum.bang.priv.no/ show something more interesting than "This page requires javascript" ([project described here](https://steinar.bang.priv.no/2022/02/12/1990-ies-picture-archives-in-modern-skin/)) +> +> I currently have something similar to the original https://www.bang.priv.no/sb/pics/ running but I was trying to style it up to look better but what I tried was maybe a bit advanced for dillo's current state. +> +> Are there plans for CSS improvements? (should I remove the flexbox/grid formatting and try something simpler or is there radical improvements on the way for dillo?) + +There are no plans. It would be good to support more advanced CSS features, but they won't happen any time soon (unless Dillo gets a surge in developers ready to focus on implementing new features). + +Your website should fall back to something readable when you disable CSS, which Dillo would benefit from when features like the grid or flexbox are missing. See https://en.wikipedia.org/wiki/Progressive_enhancement + +If you cannot provide that guarantee, you may want to use other approaches. Here is an example of Dillo gallery: https://dillo-browser.github.io/gallery/index.html + +--%-- +From: steinarb +Date: Sun, 14 Jul 2024 13:21:18 +0000 + +On a CSS side note: is there a way to make dillo re-read CSS files without stopping and starting dillo? + + (stopping and starting dillo is the only way I've found for reloading CSS so far) + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 13:45:06 +0000 + +> On a CSS side note: is there a way to make dillo re-read CSS files without stopping and starting dillo? +> +> (stopping and starting dillo is the only way I've found for reloading CSS so far) + +Try opening the remote CSS file in another tab and reloading it to refresh the cache, then reloading the HTML page that uses it (I haven't tested this, but it should work). + +--%-- +From: steinarb +Date: Sun, 14 Jul 2024 13:53:59 +0000 + +> Try opening the remote CSS file in another tab and reloading it to refresh the cache, then reloading the HTML page that uses it (I haven't tested this, but it should work). + +Thanks! Loading oldalbum.css in a different pane, and reloading that pane worked. New CSS changes were picked up. + + + +--%-- +From: Mechtilde +Date: Mon, 05 Aug 2024 04:36:38 +0000 + +Hello, +please slow down. +First the package will be removed from testing because the build failed with gcc-14. + +You can create a bugreport against dillo and provide your help. +You can start to learn to build a proper Debian package, esp with git-buildpackage and the other used tools. +For this you can start at mentors.debian.net ad follow that description. + +I saw your MR at salsa.debian.org. It doesn't build. So it can't be accepted. + +For more information please ask. + + +--%-- +From: Mechtilde +Date: Mon, 05 Aug 2024 04:39:42 +0000 + +sorry my comment was for issue 230
\ No newline at end of file diff --git a/224/index.md b/224/index.md new file mode 100644 index 0000000..27c5000 --- /dev/null +++ b/224/index.md @@ -0,0 +1,12 @@ +Title: Render JSON content as plain text +Author: rodarima +Created: Sun, 14 Jul 2024 15:11:05 +0000 +State: closed + +Some website endpoints return information in JSON, which is helpful to be read as plain text in some situations. + +An example is the following endpoint https://tls.browserleaks.com/tls, which provides TLS fingerprinting information in JSON, which will change when reloading the page (only when Dillo is linked with LibreSSL). + +The original page https://tls.browserleaks.com/ uses JS and cannot be used in Dillo. + +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/message/6C5K4F6NBRUDSPNPWTXLQXCK3U3SI7DM/
\ No newline at end of file diff --git a/225/index.md b/225/index.md new file mode 100644 index 0000000..a7af816 --- /dev/null +++ b/225/index.md @@ -0,0 +1,10 @@ +Title: Mitigations against RCE vulnerabilities +Author: rodarima +Created: Sun, 14 Jul 2024 15:50:14 +0000 +State: open + +We may want to explore the posibility of using pledge(2) or a similar technology to limit the syscalls that can be used by the parser, or any code facing external information. The network facing code should be separated from the processing side. + +The idea is to constraint posible RCE vulnerabilities to limit the posible damage it could do. + +See: https://man.openbsd.org/pledge.2 https://justine.lol/pledge/
\ No newline at end of file diff --git a/226/index.md b/226/index.md new file mode 100644 index 0000000..373fd4a --- /dev/null +++ b/226/index.md @@ -0,0 +1,79 @@ +Title: Improve Concomitant Control Chain (CCC) design +Author: rodarima +Created: Sun, 14 Jul 2024 20:26:49 +0000 +State: open + +This may require a RFC. + +The CCC has several problems, and they will become blockers to design a flexible mechanism to allow intercepting traffic along the path of the chain. + +- Doesn't support multiple threads/processes operating concurrently or reentrancy. This prevents us from using external tools to manipulate the flow of information through the chains. + +- It is designed to handle all connections from and to a node, which makes it really hard to understand which connection is which: + +``` + +---+ +--->---| |--->--- + | X | +---<---| |---<--- + +---+ +``` + +- The control commands are coupled with the I/O operations. + +```c +/* + * Supported CCC operations + */ +#define OpStart 1 +#define OpSend 2 +#define OpStop 3 +#define OpEnd 4 +#define OpAbort 5 +``` +This causes very long switches to control what we should do on each case: +https://github.com/dillo-browser/dillo/blob/8f0909b7ae431a0c4a8e5b49ed4348624fdfe11e/src/IO/IO.c#L367-L469 + +--- + +A posible solution is to split the chain into two bidirectional channels, much like in Go: + +``` ++---+ +| |--->--- +| X | +| |---<--- ++---+ +``` + +And use the methods write and read to determine the direction of the data. This allows defining a callback function that will encode only one case of the switch and encourages a simpler design. + +Example of a simple callback that forwards a received message in a channel to either a "filter" channel if it is configured to intercept them, or directly to the output channel if not: + +```c +/* Called on new data */ +int io_read_cb(Chan *c, Msg *m) +{ + Foo *foo = c->context; + if (foo->intercept) + return chan_write(foo->filter, m); + else + return chan_write(foo->output, m); +} +``` + +The errors are propagated by simply returning the proper error code. + +It also would allow using an internal FIFO or similar file descriptor, which is transparently used when the endpoint is in another process. + +--%-- +From: rodarima +Date: Mon, 15 Jul 2024 19:24:09 +0000 + +Another problem with the current design is that every time some new data is passed along the http step of the chain, there is the need to find out the context of that chain, which is done using a number (key) for the Http chain link. This requires having a global table where to perform a lookup to get the information of the current chain data. + +https://github.com/dillo-browser/dillo/blob/8f0909b7ae431a0c4a8e5b49ed4348624fdfe11e/src/IO/http.c#L884 + +https://github.com/dillo-browser/dillo/blob/8f0909b7ae431a0c4a8e5b49ed4348624fdfe11e/src/IO/http.c#L924 + +This is not required, as we could just store a pointer in the chain link itself, one for each side. They each side just uses that pointer to hold context information to the chain, like with IO and Capi. This has O(1) complexity.
\ No newline at end of file diff --git a/227/index.md b/227/index.md new file mode 100644 index 0000000..04afa7c --- /dev/null +++ b/227/index.md @@ -0,0 +1,14 @@ +Title: Add table of contents +Author: rodarima +Created: Wed, 17 Jul 2024 18:57:33 +0000 +State: open + +It would be handy to have Dillo automatically create a table of contents based on the document headers. This would also allow jumping to a given header which doesn't have any anchor link, but it does have a unique id. + +This would also allow a new entry in the context menu to copy a link to the current section (or element). + +--%-- +From: khlsvr +Date: Mon, 02 Sep 2024 09:02:21 +0000 + +Even without trying I can tell that this would be a really good feature! I would even go so far as to add an option to have a fixed sidebar or top bar that would show me this toc constantly. That is.. if dillo is able to have a part of a page to stay on fixed position while another part is being scrolled. I could then quickly jump from one header to another on the page without needing to use scrolling so much. I vote for highest possible priority on implementing this one :)
\ No newline at end of file diff --git a/228/index.md b/228/index.md new file mode 100644 index 0000000..9cbd213 --- /dev/null +++ b/228/index.md @@ -0,0 +1,34 @@ +Title: Copy and paste don't work +Author: marchuffnagle +Created: Fri, 19 Jul 2024 01:08:20 +0000 +State: closed + +I'm running Dillo version 3.1.1 (installed from the .deb file) in Xfce on Debian. If I try to copy or paste text in the URL bar, or copy text from the page, it does not work. I'm using `C-c` and `C-v`. + +--%-- +From: marchuffnagle +Date: Fri, 19 Jul 2024 01:14:08 +0000 + +I see from [the docs](https://dillo-browser.github.io/user_help.html#copy-and-paste) that it _can_ be done, but not in the way that I (as a random user) would have expected. Would it be possible to add support for using the system's copy and paste functionality? + +--%-- +From: rodarima +Date: Fri, 19 Jul 2024 18:05:47 +0000 + +Control+V seems to be working fine for me, I suspect the problem is that Control+C is not copying anything to the clipboard, which is a bug. + +#### Details + +There are two "clipboards" called selections in Xorg parlance: https://wiki.archlinux.org/title/clipboard#Selections + +> - PRIMARY +> Used for the currently selected text, even if it is not explicitly copied, and for middle-mouse-click pasting. In some cases, pasting is also possible with a keyboard shortcut. +> - CLIPBOARD +> Used for explicit copy/paste commands involving keyboard shortcuts or menu items. Hence, it behaves like the single-clipboard system on Windows. Unlike PRIMARY, it can also handle [multiple data formats](https://stackoverflow.com/questions/3571179/how-does-x11-clipboard-handle-multiple-data-formats). + +In Dillo, ideally you should be able to use both. When you select anything it gets copied into the "primary" selection, which you can paste pressing the middle button or wheel (also Shift+Insert). + +The "clipboard" selection is the one people outside UNIX are most used to, and works with the Control+C / Control+V shortcuts. On Dillo web forms and in the location bar, this seems to be working fine. The problem is when a chunk of text is selected from the page text and copied with Control+C which doesn't do anything right now, but should also place the text in the "clipboard" selection so it can be pasted with Control+V. + +Regardless, Dillo has a history of encouraging users to use the "primary" selection where only the middle mouse button is required to paste. Middle clicking the red X on the location bar causes the "primary" selection to be opened as URL, see https://dillo-browser.github.io/user_help.html#location-bar. Copying any link via the context menu will place it in the "primary" selection, not in the "clipboard", so it won't be available via Control+V. + diff --git a/229/index.md b/229/index.md new file mode 100644 index 0000000..9f67833 --- /dev/null +++ b/229/index.md @@ -0,0 +1,177 @@ +Title: magnet: link plugin +Author: rakoo +Created: Fri, 19 Jul 2024 02:36:19 +0000 +State: open + +Hey there, thanks for dillo it's nice to see it alive and well ! + +I made a plugin for `magnet:` links: https://sr.ht/~rakoo/dillo-plugin-magnet/. It is pretty naive and straightforward, made mostly to understand how this whole thing feels; I plan to add other protocols and semi-apps in the future. That thing is amazing ! + +--%-- +From: rodarima +Date: Fri, 19 Jul 2024 17:37:06 +0000 + +> Hey there, thanks for dillo it's nice to see it alive and well ! +> +> I made a plugin for `magnet:` links: https://sr.ht/~rakoo/dillo-plugin-magnet/. It is pretty naive and straightforward, made mostly to understand how this whole thing feels; I plan to add other protocols and semi-apps in the future. That thing is amazing ! + +Very nice :-) + +I tested it and it seems to work fine after some time, for some reason aria2c takes a while in my computer. + +I recommend you add a Makefile so people only have to do a `make install` command, regardless of the language you use. Example: https://github.com/dillo-browser/dillo-plugin-ipfs/blob/master/Makefile + +--%-- +From: rakoo +Date: Fri, 19 Jul 2024 18:22:21 +0000 + +Thank you :) + +There's no magic: aria2c takes a while because it has to find peers that share the given swarm before downloading from them. Once found, they tend to be fast though. + +This exhibits another problem: what if an external process is slow ? From dpi's point of view another tag can be sent, so it should be interceptable. For example a DpiBye should kill not just the filter but also all sub-processes. Right ? + +The Makefile is a really nice idea, I will add that ! + + +--%-- +From: rodarima +Date: Thu, 25 Jul 2024 19:56:12 +0000 + +Hi, + +>There's no magic: aria2c takes a while because it has to find peers +>that share the given swarm before downloading from them. Once found, +>they tend to be fast though. + +I'm using this one: + + magnet:?xt=urn:btih:0cd42065571809961e9661db2123a87d77c33964&dn=archlinux-2024.07.01-x86_64.iso + +For me it takes around 30 seconds to fetch the .torrent file, while if I +open it in qbittorrent it goes very quickly, in less than 500 ms. Not +sure if qb has some swarm already cached somewhere or NAT hole punching +or some other technique to increase the speed. + +>This exhibits another problem: what if an external process is slow ? +>From dpi's point of view another tag can be sent, so it should be +>interceptable. For example a DpiBye should kill not just the filter but +>also all sub-processes. Right ? + +You can make the plugin as a "server" type, instead of just a filter, +see: + +https://dillo-browser.github.io/user_help.html#plugins + +This way you can start the plugin on the first magnet request and leave +it running so subsequent requests are faster. + +And yes, the DpiBye should kill all processes spawned by the plugin. + + +--%-- +From: rakoo +Date: Fri, 26 Jul 2024 15:36:27 +0000 + +rodarima ***@***.***> wrote: +> I'm using this one: +> +> magnet:?xt=urn:btih:0cd42065571809961e9661db2123a87d77c33964&dn=archlinux-2024.07.01-x86_64.iso +> +> For me it takes around 30 seconds to fetch the .torrent file, while if I +> open it in qbittorrent it goes very quickly, in less than 500 ms. Not +> sure if qb has some swarm already cached somewhere or NAT hole punching +> or some other technique to increase the speed. + +If you let qbittorrent run continuously then it probably has a +more accurate routing table, so querying is definitely going to +be faster. That's another argument for letting the dpi run +continuously in the background + +> You can make the plugin as a "server" type, instead of just a filter, +> see: +> +> https://dillo-browser.github.io/user_help.html#plugins +> +> This way you can start the plugin on the first magnet request and leave +> it running so subsequent requests are faster. + +Indeed, I need to switch to that. I just didn't see an easy-to-grasp +server dpi (and the facility provided by the go lib didn't seem to +work, but I need to try again) + +> And yes, the DpiBye should kill all processes spawned by the plugin. + +Good. In server mode does that also mean that the server should die ? + +-- +Matthieu Rakotojaona + + +--%-- +From: rodarima +Date: Fri, 26 Jul 2024 20:31:41 +0000 + +Hi, + +>If you let qbittorrent run continuously then it probably has a +>more accurate routing table, so querying is definitely going to +>be faster. That's another argument for letting the dpi run +>continuously in the background + +The test was done by opening qbittorrent for the first time in the day. + +Out of curiosity, I did another test where I open qbittorrent from a new +user, so it is the first time ever it is opened, and it also is able to +load the metadata in less than a few seconds. + +For some reason I cannot just open qbittorrent with the magnet for the +first time as an argument otherwise it gets stuck forever (likely a +bug), so I make it sleep for two seconds before adding the magnet to +download: + +$ ssh -X ***@***.*** 'rm -rf ~/.{config,cache,local}; \ + qbittorrent &; \ + sleep 2; \ + qbittorrent "magnet:?xt=urn:btih:0cd42065571809961e9661db2123a87d77c33964&dn=archlinux-2024.07.01-x86_64.iso"' + +I also verified with strace that is reading the data from /home/guest +rather than my normal user. + +So I don't think it is because qbittorrent has some information saved on +on disk, but I think it has some other search mechanism to query magnets +which is much faster than aria2c. + +I tried with transmission too, but it is also very slow. + +>> You can make the plugin as a "server" type, instead of just a filter, +>> see: +>> +>> https://dillo-browser.github.io/user_help.html#plugins +>> +>> This way you can start the plugin on the first magnet request and leave +>> it running so subsequent requests are faster. +> +>Indeed, I need to switch to that. I just didn't see an easy-to-grasp +>server dpi (and the facility provided by the go lib didn't seem to +>work, but I need to try again) + +Here is an example of a Go server plugin written by Charles E. Lehner +for IPFS: + +https://github.com/dillo-browser/dillo-plugin-ipfs + +Inside Dillo itself you can also find some server plugins (the ones that +don't have "filter" in the name): + +https://github.com/dillo-browser/dillo/blob/master/dpi/Makefile.am#L48-L55 + +> +>> And yes, the DpiBye should kill all processes spawned by the plugin. +> +>Good. In server mode does that also mean that the server should die ? + +Yes, the server plugin should exit the main loop. Here is an example for +the file plugin: + +https://github.com/dillo-browser/dillo/blob/master/dpi/file.c#L1097 diff --git a/23/index.md b/23/index.md new file mode 100644 index 0000000..bfcdb56 --- /dev/null +++ b/23/index.md @@ -0,0 +1,13 @@ +Title: Add scroll_step option +Author: rodarima +Created: Wed, 20 Dec 2023 00:43:33 +0000 +State: closed + +When using the mouse wheel to scroll a page, the default scroll step was causing a very slow scrolling speed. The new option "scroll_step" allows the user to define how many pixels the page is moved in every step of the mouse wheel. The default is increased to 100 pixels per step. + +Here is an example where a [large page](https://html.spec.whatwg.org/#a-quick-introduction-to-html) is loaded in the original Dillo in the left and the version with the increased scroll step to 100 in the right. When using the mouse wheel the screen is moved much faster now: + +[video.webm](https://github.com/dillo-browser/dillo/assets/3866127/592b7d1c-b62a-492f-80ab-6bf3ded3689d) + + +Fixes #22
\ No newline at end of file diff --git a/230/index.md b/230/index.md new file mode 100644 index 0000000..b79dd8c --- /dev/null +++ b/230/index.md @@ -0,0 +1,528 @@ +Title: Dillo will be removed from Debian testing on August 23rd +Author: rodarima +Created: Thu, 25 Jul 2024 20:03:18 +0000 +State: closed + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074911 + +> Version 3.0.5-7 of dillo is marked for autoremoval from testing on Fri 23 Aug 2024. It is affected by [#1074911](https://bugs.debian.org/1074911). The removal of dillo will also cause the removal of (transitive) reverse dependency: [claws-mail](https://tracker.debian.org/pkg/claws-mail). You should try to prevent the removal by fixing these RC bugs. + +It seems clear now that the package is not maintained anymore (see #216), so before it goes into the abyss we may be able to find someone who can adopt it. + +--%-- +From: rodarima +Date: Mon, 29 Jul 2024 19:46:42 +0000 + +Hi @xtaran, are you aware of this? + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074911 + +If I understand correctly, the Dillo package in Debian will be removed for the next release due a failure to build. + +The 3.0.5 release is 9 years old so I recommend you update it, rather than continue to patch it, as there are a lot of changes that were not released [until 3.1.0 which were written by the original developers](https://dillo-browser.github.io/release/3.1.0/) (specially related to TLS). + +[The original upstream is gone](https://dillo-browser.github.io/dillo.org.html) and this repository is an effort to continue the project, with the last release being 3.1.1. + +I opened a MR in the Debian repository two weeks ago, with an updated package to 3.1.1 that builds and seems to run fine based on my tests and what people have reported (see #216), which also should get rid of the FTBFS problem: + +https://salsa.debian.org/debian/dillo/-/merge_requests/1 + +If you cannot take care of it, would you be open for someone else to adopt it? I'm not familiar with Debian packaging but I could ask around. + +It seems this is also taking down claws-mail (CC @mones), due to the dependency with Dillo. + +I'll also CC @johnraff from BunsenLabs, as for the context of: + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022726 + +For reference, here is the packaging state on other distros, which shows most have updated to 3.1.1 already: + +https://repology.org/project/dillo/history + +--%-- +From: johnraff +Date: Tue, 30 Jul 2024 02:08:26 +0000 + +I have forked this repository and added some packaging content here: +https://github.com/BunsenLabs/dillo-browser +I imported the 3.1.1 tarball [here](https://github.com/BunsenLabs/dillo-browser), made a few [changes](https://github.com/BunsenLabs/dillo-browser/commits/v3.1.1) and successfully built (on pbuilder) a package from that: +https://pkg.bunsenlabs.org/debian/pool/main/d/dillo/dillo_3.1.1-0.1~bl3_amd64.deb + +The dillo code from dillo-browser has not been touched at all, and most of the packaging is @xtaran's work. + +But this package has been built for BunsenLabs and will likely not be acceptable in Debian as-is. + +The ideal would be if @xtaran were willing to continue maintaining the package, but he seems to be very busy with other projects and it would be understandable if he wanted to drop it at this point. + +I'm not a Debian Maintainer and could not take over, but I would be willing to co-operate with someone with the necessary credentials. There were not so many changes needed to make the package buildable. + +--%-- +From: rodarima +Date: Sun, 04 Aug 2024 11:26:33 +0000 + +> I have forked this repository and added some packaging content here: https://github.com/BunsenLabs/dillo-browser I imported the 3.1.1 tarball [here](https://github.com/BunsenLabs/dillo-browser), made a few [changes](https://github.com/BunsenLabs/dillo-browser/commits/v3.1.1) and successfully built (on pbuilder) a package from that: https://pkg.bunsenlabs.org/debian/pool/main/d/dillo/dillo_3.1.1-0.1~bl3_amd64.deb + +Oh, thanks! I didn't see this before. + +> The dillo code from dillo-browser has not been touched at all, and most of the packaging is @xtaran's work. +> +> But this package has been built for BunsenLabs and will likely not be acceptable in Debian as-is. +> +> The ideal would be if @xtaran were willing to continue maintaining the package, but he seems to be very busy with other projects and it would be understandable if he wanted to drop it at this point. +> +> I'm not a Debian Maintainer and could not take over, but I would be willing to co-operate with someone with the necessary credentials. There were not so many changes needed to make the package buildable. + +I'm also not able to maintain it myself, as I'm not too familiar with Debian packages, but maybe I can find someone who does, I'll ask around. + +--%-- +From: rodarima +Date: Sun, 04 Aug 2024 11:51:27 +0000 + +Relevant: + +https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa +https://wiki.debian.org/qa.debian.org/MIATeam + +--%-- +From: ArrayBolt3 +Date: Sun, 04 Aug 2024 16:51:08 +0000 + +Ubuntu dev with Debian developer connections here. I depend on Claws Mail for my workflow so I'm willing to pick up Dillo. (Actually I build Claws from source so my workflow doesn't *totally* depend on Dillo, but nonetheless I want Claws to remain in Debian and Dillo also seems very useful.) + +--%-- +From: rodarima +Date: Sun, 04 Aug 2024 19:27:11 +0000 + +It looks @mirabilos is going to address the "failure to build" problem: + +https://toot.mirbsd.org/@mirabilos/statuses/01J4FCY6M75VFD1HB0ZS2QYV5A + +One of the other problems that prevents the update to 3.1.1 is the lack of trust to change the upstream, which is understandable. Not sure if we can do much on our side to solve that, other than waiting for trusted Debian developers to review the changes. + +--%-- +From: ArrayBolt3 +Date: Sun, 04 Aug 2024 23:52:42 +0000 + +For what it's worth v3.1.1 builds with GCC14 as-is for me, in a Debian Sid build environment. + +--%-- +From: Mechtilde +Date: Mon, 05 Aug 2024 04:38:45 +0000 + +now in the right issue + +Hello, +please slow down. +First the package will be removed from testing because the build failed with gcc-14. + +You can create a bugreport against dillo and provide your help. +You can start to learn to build a proper Debian package, esp with git-buildpackage and the other used tools. +For this you can start at mentors.debian.net ad follow that description. + +I saw your MR at salsa.debian.org. It doesn't build. So it can't be accepted. + +For more information please ask. + + +--%-- +From: johnraff +Date: Mon, 05 Aug 2024 06:42:48 +0000 + +There is my attempt at a "proper Debian package" as referenced above, here: https://github.com/BunsenLabs/dillo-browser/tree/v3.1.1 +This builds in a pbuilder Trixie environment with no Lintian errors, just two Pedantic warnings. + +So most of the Debianizing work has already been done. What remains is the [FTBFS with GCC-14](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074911) which presumably arises when building on Sid, although judging by @ArrayBolt3 's post, the 3.1.1 code may already have that covered. + +--%-- +From: johnraff +Date: Mon, 05 Aug 2024 06:46:27 +0000 + +> It looks @mirabilos is going to address the "failure to build" problem: +> +> https://toot.mirbsd.org/@mirabilos/statuses/01J4FCY6M75VFD1HB0ZS2QYV5A +> + +That link shows 404 for me unfortunately. + +> One of the other problems that prevents the update to 3.1.1 is the lack of trust to change the upstream, which is understandable. Not sure if we can do much on our side to solve that, other than waiting for trusted Debian developers to review the changes. + +I think this is probably the big one. + + +--%-- +From: Mechtilde +Date: Mon, 05 Aug 2024 07:06:35 +0000 + +How did you build it? Where are the sources files, which can be uploaded? Where do you provide them, Why do you want to do an Non-Maintainer-Upload? + +Why didn't you do an update of the existing package? + +Please contact me for more information +Regards + +Am 5. August 2024 08:43:10 MESZ schrieb John Crawley ***@***.***>: +>There is my attempt at a "proper Debian package" as referenced above, here: https://github.com/BunsenLabs/dillo-browser/tree/v3.1.1 +>This builds in a pbuilder Trixie environment with no Lintian errors, just two Pedantic warnings. +> +>So most of the Debianizing work has already been done. What remains is the [FTBFS with GCC-14](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074911) which presumably arises when building on Sid. +> +>-- +>Reply to this email directly or view it on GitHub: +>https://github.com/dillo-browser/dillo/issues/230#issuecomment-2268293898 +>You are receiving this because you commented. +> +>Message ID: ***@***.***> +-- +Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. + +--%-- +From: ArrayBolt3 +Date: Mon, 05 Aug 2024 07:07:00 +0000 + +I also have a working Dillo 3.1.1 package, which builds against Sid (with GCC-14) without issues. It does not silence *all* warnings, however this is intentional on my part since some Debian Developers are willing to accept packages with warnings but unwilling to accept packages with warnings unnecessarily overridden even if those warnings aren't actually indicative of packaging issues or Debian policy violations. + +> One of the other problems that prevents the update to 3.1.1 is the lack of trust to change the upstream, which is understandable. Not sure if we can do much on our side to solve that, other than waiting for trusted Debian developers to review the changes. + +Whoever submits the package to Debian will have to do a copyright review anyway. Integrating a quick scan to make sure there are no malicious changes is probably no big deal there. + +--%-- +From: ArrayBolt3 +Date: Mon, 05 Aug 2024 07:11:57 +0000 + +@Mechtilde Ahem, excuse me for asking, but who are you? Why do you want people to contact you for more information? + +> How did you build it? + +He said, with pbuilder. Debian packagers oftentimes have their own favorite build tools. I use sbuild myself. + +> Where are the source files, which can be uploaded? + +Um, he linked to the package source tree? Most any Debian package maintainer knows how to build a source package from that. + +> Where do you provide them? + +Again, he linked to a Debian source tree which you can build a source package from. + +> Why do you want to do a Non-Maintainer Upload + +Because he isn't the maintainer, and Debian requires (or at least highly recommends) these kinds of uploads to be done as non-maintainer uploads. See https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu + +> Why didn't you do an update of the existing package? + +He did. + +Respectfully, do you know how Debian packaging is done? + +--%-- +From: johnraff +Date: Mon, 05 Aug 2024 07:30:53 +0000 + +> I also have a working Dillo 3.1.1 package, which builds against Sid (with GCC-14) without issues. + +Did you use the dillo-browser code untouched, adding only a debian/ directory? If so, we have reason for optimism! +Maybe @rodarima 's code changes have already dealt with the GCC-14 isue. + +> It does not silence _all_ warnings, however this is intentional on my part since some Debian Developers are willing to accept packages with warnings but unwilling to accept packages with warnings unnecessarily overridden even if those warnings aren't actually indicative of packaging issues or Debian policy violations. + +The lintian-overrides I added were to suppress warnings about long lines in html files (embedded base64 images), bugs #1017966 #1019980 #864555 possibly. I also edited a couple of existing overrides so they would work. The overrides could be removed, though. No Lintian Errors have been overridden. + + + +--%-- +From: ArrayBolt3 +Date: Mon, 05 Aug 2024 07:33:14 +0000 + +@johnraff Correct. I basically took the existing Dillo packaging (pulled using `pull-debian-source` on my Ubuntu machine), wiped out everything except the `debian` dir, unpacked Dillo 3.1.1 untouched into the source tree alongside the `debian` dir, and then adjusted the Debian packaging as appropriate (dropping old patches, fixing mismatched Lintian overrides, no longer trying to install doc files that don't exist anymore, etc). I haven't published my source tree anywhere, but I have it and could publish it. + +--%-- +From: Mechtilde +Date: Mon, 05 Aug 2024 08:01:26 +0000 + +> @Mechtilde Ahem, excuse me for asking, but who are you? Why do you want people to contact you for more information? +> +> > How did you build it? +> +> He said, with pbuilder. Debian packagers oftentimes have their own favorite build tools. I use sbuild myself. +> +> > Where are the source files, which can be uploaded? +> +> Um, he linked to the package source tree? Most any Debian package maintainer knows how to build a source package from that. +> +> > Where do you provide them? +> +> Again, he linked to a Debian source tree which you can build a source package from. +> +> > Why do you want to do a Non-Maintainer Upload +> +> Because he isn't the maintainer, and Debian requires (or at least highly recommends) these kinds of uploads to be done as non-maintainer uploads. See https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu +> +> > Why didn't you do an update of the existing package? +> +> He did. +> +> Respectfully, do you know how Debian packaging is done? + +Yes I know, how to create Debian packages. That's the reason of that questions. To get software into the Debian distribution you have to prepare the source files which can be uploaded to the archive and then build there. + +I want to help you to maintain dillo yourself for the Debian project. That's the reason why i provided more help + +Regards + + + +--%-- +From: Mechtilde +Date: Mon, 05 Aug 2024 08:04:02 +0000 + +> @johnraff Correct. I basically took the existing Dillo packaging (pulled using `pull-debian-source` on my Ubuntu machine), wiped out everything except the `debian` dir, unpacked Dillo 3.1.1 untouched into the source tree alongside the `debian` dir, and then adjusted the Debian packaging as appropriate (dropping old patches, fixing mismatched Lintian overrides, no longer trying to install doc files that don't exist anymore, etc). I haven't published my source tree anywhere, but I have it and could publish it. + +you can provide the source files via mentors.debian.net + +--%-- +From: johnraff +Date: Mon, 05 Aug 2024 08:15:29 +0000 + +> @johnraff I basically took the existing Dillo packaging (pulled using `pull-debian-source` on my Ubuntu machine), wiped out everything except the `debian` dir, unpacked Dillo 3.1.1 untouched into the source tree alongside the `debian` dir, and then adjusted the Debian packaging as appropriate (dropping old patches, fixing mismatched Lintian overrides, no longer trying to install doc files that don't exist anymore, etc). + +It sounds as if we both did pretty much the same thing. + +I did take some care to preserve the git histories of both @rodarima 's and @xtaran 's code, though. If you go back in the commits on the repo I published, after @rodarima you'll eventually come to @xtaran's packaging commits, then the original dillo developers' work. It's all there. + +For whatever it's worth, the notes I kept: +``` +How to merge in the debian/ directory from eg debian salsa, +into an existing eg github repo, keeping history: + +( this was forked from https://github.com/dillo-browser/dillo ) +git clone git@github.com:BunsenLabs/dillo-browser.git +(on branch master) +git checkout -b packaging +make debian/ directory (git will ignore it) +git remote add salsa git@salsa.debian.org:debian/dillo.git +git fetch salsa +git merge --allow-unrelated-histories -s ours --no-commit salsa/master +git read-tree --prefix=debian/ -u salsa/master:debian +git commit -m 'Add debian directory from https://salsa.debian.org/debian/dillo' +(check that only debian/ files have been added) +git diff --name-only master + +see: +https://stackoverflow.com/questions/1214906/how-do-i-merge-a-sub-directory-in-git +https://stackoverflow.com/questions/62927619/git-error-not-a-valid-object-name-when-merging-subfolder-of-repository-into-sub + +(if a merge gets messed up) +git merge --abort +(revert the last commit) +git reset --hard HEAD~1 +``` + + + + + + +--%-- +From: ArrayBolt3 +Date: Mon, 05 Aug 2024 08:25:51 +0000 + +On Mon, Aug 5, 2024 at 3:04 AM Mechtilde ***@***.***> wrote: + +> @johnraff <https://github.com/johnraff> Correct. I basically took the +> existing Dillo packaging (pulled using pull-debian-source on my Ubuntu +> machine), wiped out everything except the debian dir, unpacked Dillo +> 3.1.1 untouched into the source tree alongside the debian dir, and then +> adjusted the Debian packaging as appropriate (dropping old patches, fixing +> mismatched Lintian overrides, no longer trying to install doc files that +> don't exist anymore, etc). I haven't published my source tree anywhere, but +> I have it and could publish it. +> +> you can provide the source files via mentors.debian.net +> + +I am aware. I haven't done so yet since I would like to test the package +before requesting sponsorship, and am not sure who exactly is going to take +maintainership of it in the event the original maintainer is absent. (It +looks like Dillo's call for help on Mastodon got more than one person +interested, and I don't want to end up "fighting" anyone +for maintainership.) + +— +> Reply to this email directly, view it on GitHub +> <https://github.com/dillo-browser/dillo/issues/230#issuecomment-2268429478>, +> or unsubscribe +> <https://github.com/notifications/unsubscribe-auth/AZAFFEWD5OYXWYAZZXP4YFLZP4WYTAVCNFSM6AAAAABLPHB5ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRYGQZDSNBXHA> +> . +> You are receiving this because you were mentioned.Message ID: +> ***@***.***> +> + + +--%-- +From: Mechtilde +Date: Mon, 05 Aug 2024 08:36:43 +0000 + +There is no need to fear ending up "fighting" anyone for maintainership. +We know each other ;-) + + +--%-- +From: johnraff +Date: Mon, 05 Aug 2024 08:57:31 +0000 + +> It looks like Dillo's call for help on Mastodon got more than one person interested, and I don't want to end up "fighting" anyone for maintainership. + +Still less me. My code is there if anyone should want to borrow bits. Very happy if someone wants to take on the maintainership of dillo so it remains in the Debian repositories. :) + +--%-- +From: ArrayBolt3 +Date: Mon, 05 Aug 2024 09:20:59 +0000 + +On Mon, Aug 5, 2024 at 3:57 AM John Crawley ***@***.***> +wrote: + +> It looks like Dillo's call for help on Mastodon got more than one person +> interested, and I don't want to end up "fighting" anyone for maintainership. +> +> Still less me. My code is there if anyone should want to borrow bits. Very +> happy if someone wants to take on the maintainership of dillo so it remains +> in the Debian repositories. :) +> +Ah, ok. If no one's taken it by the time I wake up next, I'll very likely +upload my results. I will be using your Git magic though, that was really +neat :) + +> — +> Reply to this email directly, view it on GitHub +> <https://github.com/dillo-browser/dillo/issues/230#issuecomment-2268533964>, +> or unsubscribe +> <https://github.com/notifications/unsubscribe-auth/AZAFFEXCBZCV5BKOZLUPIUTZP45BDAVCNFSM6AAAAABLPHB5ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRYGUZTGOJWGQ> +> . +> You are receiving this because you were mentioned.Message ID: +> ***@***.***> +> + + +--%-- +From: Mechtilde +Date: Mon, 05 Aug 2024 10:30:01 +0000 + +Dillo ist still in the Debian Repo. +To get the update into the Debian Repo, too, the best way is to provide the source packages of the new version and a sponsor can pick it up, review and upload it. +That can be done via mentors.debian.net + +--%-- +From: xtaran +Date: Mon, 05 Aug 2024 13:20:14 +0000 + +> Dillo ist still in the Debian Repo. + +There is no "the Debian repo". + +And it is neither endangered to be removed from Debian Unstable nor Stable. The removal will be just from Testing. + +> To get the update into the Debian Repo, too, the best way is to provide the source packages of the new version and a sponsor can pick it up, review and upload it. That can be done via mentors.debian.net + +In that case, the sponsor will have a lot of work and a great responsibility in avoiding an xz situation as we're talking about the switch of upstream towards a repo where not any of the previous upstream developers seems to be involved: https://chaos.social/@xtaran/112905124915743612 + +--%-- +From: rodarima +Date: Mon, 05 Aug 2024 15:09:20 +0000 + +> And it is neither endangered to be removed from Debian Unstable nor Stable. The removal will be just from Testing. + +I updated the issue title. Sorry for the confusion, I'm not familiar with Debian packaging. + +> > To get the update into the Debian Repo, too, the best way is to provide the source packages of the new version and a sponsor can pick it up, review and upload it. That can be done via mentors.debian.net +> +> In that case, the sponsor will have a lot of work and a great responsibility in avoiding an xz situation as we're talking about the switch of upstream towards a repo where not any of the previous upstream developers seems to be involved: https://chaos.social/@xtaran/112905124915743612 + +I understand not trusting a change in upstream. I'll be happy if any of the previous developers wants to join the organization (that was the main point to create one). I have invited Johannes and Jeremy to the Dillo organization, but I don't think others are on GitHub. + +But I also don't want it to become stuck in 3.0.5 forever, as we have users in Debian or Debian-derived distros who are not capable of building it from source on their own, and they are experiencing broken sites or problems with TLS that are solved in 3.1.1. + +I think it is posible to review the changes I introduced since the last trusted commit in a reasonable time frame, as most of the work was done by Sebastian but never made it into an official release. You can see it [here](https://dillo-browser.github.io/release/3.1.0/): + + + +If you trust other Debian maintaners, I can ask them to take a look too if you don't have the time to do yourself. I don't think any of the original developers will be involved in Dillo anymore, but [I have mailed them anyway](https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/HCADTQQAT52ARCFRPVR7ANS7BID3MD4X/). + +--%-- +From: ArrayBolt3 +Date: Mon, 05 Aug 2024 21:23:49 +0000 + +@xtaran I don't see how this will be all that difficult to audit. We know the existing Dillo code is trusted, there aren't that many changes from older Dillo to newer Dillo, and whoever updates the package (I'm intending to do that) will have to do a copyright review, putting them in a rather good position to do a code safety review. Does that seem like a valid assessment to you? I'm happy to be the one who checks the diff between the two. + +(FWIW I've seen this continuation of Dillo around for a while, this isn't a new thing suddenly springing up in order to compromise Dillo in Debian to my awareness. I do not yet trust the authors, but I can fix that easily enough by looking at their code.) + +--%-- +From: mirabilos +Date: Mon, 05 Aug 2024 21:43:49 +0000 + +@all, + +why am I on this totally pointless discussion? + +1. the maintainer is @xtaran, so right now he decides what goes in +2. I already said I’m going to jump in and help with fixing the + current rc bug, so dillo can stay in Debian + ⇒ you can close this issue, full stop. +3. the package has an active maintainer, so nobody should get up + trying to suggest a different packaging as that would be an + inadmissible hostile takeover +4. we’re having to try to avoid a Jia Tan situation +5. the entire situation with the domain going away (which, yes, + is not the fault of the new developers), the old developers + vanishing (same), etc. doesn’t make this easy + + +Aaron Rainbolt dixit: + +>@xtaran I don't see how this will be all that difficult to audit. We + +Why are you trying to pressure him so much about this? + +*Are* you, perchance, a Jia Tan? + +We’ve already stated in the thread around +***@***.***/statuses/01J4FBZDZRRWTDFNKKQSGFDET7 +what’s happening, how to proceed, etc. and what not to do. + +I fully expect this discussion to finish here right now. +Those not involved with the new Dillo project should, please, +just shut up, and those involved better not be involved in +pressuring the Debian maintainer and other Debian Developers +and packagers lest their behaviour be judged to be akin to +a Hans Jansen situation. + +Thank you. + + +Note: all this time spent discussing things uses up spoons. +Spoons which then aren’t available to do the actual work any +more. I’ve dealt with xloadimage yesterday, whose deadline +was even closer (a few days). I can ensure that, if I don’t +need to waste effort on discussing pointless things, I’ll have +dillo fixed and uploaded in time to avoid the autoremoval. + +bye, +//mirabilos +-- +>> Why don't you use JavaScript? I also don't like enabling JavaScript in +> Because I use lynx as browser. ++1 + -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel + + +--%-- +From: rodarima +Date: Mon, 05 Aug 2024 22:01:04 +0000 + +@mirabilos I locked the issue, but I will keep it open util the RC problem is solved so I don't forget. + +@ArrayBolt3 mirabilos is going to address the RC build problem. Pressing the maintainers is not gonna change their lack of trust about updating to 3.1.1. Let's leave them some time to study the changes, and see what they decide. + +--%-- +From: rodarima +Date: Fri, 09 Aug 2024 11:36:52 +0000 + +Fixed by mirabilos in 3.0.5-7.1, closing.
\ No newline at end of file diff --git a/231/index.md b/231/index.md new file mode 100644 index 0000000..487d14c --- /dev/null +++ b/231/index.md @@ -0,0 +1,11 @@ +Title: Constraint cache memory usage to a configurable limit +Author: rodarima +Created: Sun, 28 Jul 2024 14:03:57 +0000 +State: open + +After a long session of browsing, the cache may increase its memory requirement to a considerable amount. We should constraint the cache usage to a reasonable default (by evicting old entries) and let the user change the limit or disable it in the configuration. + +Reported-by: Klaus Zimmermann + +See: https://fosstodon.org/@kzimmermann/112864419033919007 +See: https://kzimmermann.0x.no/articles/2024_old_computer_challenge.html
\ No newline at end of file diff --git a/232/index.md b/232/index.md new file mode 100644 index 0000000..db0de49 --- /dev/null +++ b/232/index.md @@ -0,0 +1,14 @@ +Title: Make Dillo strictly compliant with C90, C++11 and POSIX-2001 +Author: rodarima +Created: Sun, 28 Jul 2024 14:41:56 +0000 +State: closed + +This PR changes the default flags in CFLAGS and CXXFLAGS to enable pedantic warnings and making Dillo strictly compliant with C90, C++11 and POSIX-2001. + +Several non-portable code had to be modified to either use dlib functions or alternative portable functions. + +Additionally, in the CI we enable `-Werror` so any pedantic warning makes the pipeline fail. It is important to allow other compilers to add pedantic warnings without breaking the build for users. + +We can lower the C++11 to C++03 by getting rid of the macros, but it doesn't seem to be worth it for now. + +Fixes #217 #218
\ No newline at end of file diff --git a/233/index.md b/233/index.md new file mode 100644 index 0000000..4dc2085 --- /dev/null +++ b/233/index.md @@ -0,0 +1,208 @@ +Title: Dillo developers, please don't ask literally the entire Fediverse for someone to take over the Dillo Debian package when the maintainer is still around. +Author: ArrayBolt3 +Created: Mon, 05 Aug 2024 22:40:23 +0000 +State: closed + +Continuation of https://github.com/dillo-browser/dillo/issues/230 since it was locked before I had a chance to reply and bring up the shortcomings that led to the mess there. + +Why did the Dillo developers make a post on Mastodon asking for someone to adopt the Debian package for Dillo? Why was there not ample time left for the maintainer to respond before asking the entire Fediverse if someone could take over the package? + +The entire time I've been interacting in https://github.com/dillo-browser/dillo/issues/230, I've been under the impression that Dillo is abandoned in Debian. Between the appearance of multiple external helpers and Debian Developers, and the actions of the Dillo developers here, I had no way of knowing the maintainer was in this conversation short of checking to see if anyone in the conversation happened to be listed as the maintainer in the Dillo Debian packaging code (which I did not do because I thought the maintainer was gone). I had no idea xtaran was the maintainer of Dillo in Debian until mirabilos's reply. + +This should have been handled by contacting the maintainer *first* and giving him ample time to reply before asking for external help. As it is, y'all made it sound like Dillo was on the chopping block in Debian and no one except an external volunteer could save it from certain death. I took (scarce and valuable) time out of my life to try to save it because I find Dillo valuable, only to discover my help is not needed, not wanted, and now even considered potentially malicious. If I was the one to get this whole thread started, I can see this being a valid concern, but given the fact that the Dillo developers literally *lured* me into coming here with a cry for help, I feel like this is unwarranted. + +I would suggest whoever is in charge of the Mastodon account for Dillo read through https://github.com/dillo-browser/dillo/issues/230 to see the results, and take these events under account in the future before making any post on behalf of the Dillo development team. This has stolen many hours from me, hours I would have much rather preferred spending working on any one of the other open-source projects I'm involved in. It's taken time from johnraff too, It made xtaran have to deal with what appears to be a sudden effort to take over a package he maintains, something I would find deeply frustrating and alarming were I in his position. It's left multiple people angry, and it even roped in a random Debian Developer who doesn't seem to even be related to Dillo into the picture. + +As for the answers to mirabilos' questions in their last post: + +1. Perfect. Then there's no further action needed from me. +2. I was unable to see what exactly you were doing with fixing a build failure. I saw one somewhat confusing comment by @rodarima about fixing the build failure (in what version of Dillo, I did not know), and the toot they linked to 404s for me and at least one other person. Additionally my Mastodon server didn't let me see any activity you had in the thread, I had to look at a different server to see that. +3. Agreed. So why did the Dillo Mastodon account call for people to come take over the package when the maintainer was here? "Is there a Debian maintainer who could help us by adopting it?" is *very* strong wording, explicitly asking someone to take over the package. This is entirely inappropriate since the maintainer is here. +4. Makes sense. + +> Why are you trying to pressure him so much about this? + +I had no idea he was the maintainer. I thought he was just another random DD who showed up here, probably from Mastodon or perhaps from GitLab (which is where Mechtilde came over here from). + +> *Are* you, perchance, a Jia Tan? + +Again, if I had started this thread, I can see this being a very valid concern. I didn't, I came over here in response to an explicit request for someone to adopt the package. + +You and anyone else can feel free to Google my account name or full name to see who I am and what I do. I have MOTU upload rights into the Ubuntu repositories (meaning I can change anything in the Universe and Multiverse repositories by myself in the development release). If I was interested in compromising things I'd be able to do it without having to interact with the Dillo team or Debian at all. + +> We’ve already stated in the thread around ... what’s happening, how to proceed, etc. and what not to do. + +GitHub conveniently mangled the link you put here so I have no good way of knowing what you're referencing. + +> I fully expect this discussion to finish here right now. Those not involved with the new Dillo project should, please, just shut up + +I do not know if you're a Dillo developer or not. If you're not, this is rather uncalled for given how this thread got started. If you are, this is infuriating to say after *your own team* asked for people to come get involved. If you want to push away potential helpers or maintainers, this is the quickest and easiest way to do it. I will not be contributing to Dillo in the foreseeable future after this and will likely actively avoid attempts to contribute to it now that I've been through this mess. + +--%-- +From: rodarima +Date: Tue, 06 Aug 2024 00:18:44 +0000 + +> Why did the Dillo developers make a post on Mastodon asking for someone to adopt the Debian package for Dillo? Why was there not ample time left for the maintainer to respond before asking the entire Fediverse if someone could take over the package? + +The reason I asked on Fedi is because I was under the impression the package was abandoned in Debian. + +> This should have been handled by contacting the maintainer first and giving him ample time to reply before asking for external help. + +I have emailed the maintaner in April, May and June about my intentions to update the package to this upstream: + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022726 + +Although the maintaner replied privately to me on Fedi in April that he would try to look into it, I did not see any other news on the bug tracker. + +I learnt how to prepare a Debian package and made one myself (I'm not a Debian user or developer), which I proposed in their salsa repo, although I'm sure it was not very good I did my best: + +https://salsa.debian.org/debian/dillo/-/merge_requests/1 + +But I got no feedback. + +When I saw the RC bug, I assumed it will be taken down from the Debian repositories before it gets fixed. After two weeks of no changes, I decided to ask for help in case someone can help with maintanership. + +It was not my intention to do any hostile takeover, but to cooperate with the current maintainer to update the package to 3.1.1 (which would also fix the RC bug). + +> The entire time I've been interacting in https://github.com/dillo-browser/dillo/issues/230, I've been under the impression that Dillo is abandoned in Debian + +That was my impression too in sight of the previous events. + +> I took (scarce and valuable) time out of my life to try to save it because I find Dillo valuable, only to discover my help is not needed, not wanted, and now even considered potentially malicious. + +When I asked for help, I had no idea that one of the problems to update Dillo is the lack of trust on this upstream (which is understandable) which [was reported yesterday](https://fosstodon.org/@xtaran@chaos.social/112905124967939203). So I assumed that help from other maintainers would be appreciated, as I understood the maintaner was busy. + +>> Why are you trying to pressure him so much about this? +> +> I had no idea he was the maintainer. + +Sorry, I should have provided a summary of the situation in the issue. + +> I do not know if you're a Dillo developer or not. If you're not, this is rather uncalled for given how this thread got started. If you are, this is infuriating to say after your own team asked for people to come get involved. If you want to push away potential helpers or maintainers, this is the quickest and easiest way to do it. I will not be contributing to Dillo in the foreseeable future after this and will likely actively avoid attempts to contribute to it now that I've been through this mess. + +Mirabilos seems to be a Debian maintainer that jumped to fix the RC problem by patching the 3.0.5 version, but I have not seen any other contribution to Dillo code from that user. + +The misunderstanding is my fault, as I should have provided more information before reaching that point. + +Keep in mind that I would like for Dillo to be updated in Debian, but my main focus is maintaining Dillo itself, which is not an easy task at all that I'm also doing on my free time. There is no need to actively try to harm the project, it was already pretty dead on its own, and I was just trying to avoid it from dissapearing. See: + +https://news.ycombinator.com/item?id=38847613 + +--%-- +From: ArrayBolt3 +Date: Tue, 06 Aug 2024 00:34:21 +0000 + +Thanks, this helps clear up a lot of things. + +For what it's worth, I wasn't trying to harm the project. That paragraph is just me expressing that this was painful enough that I don't want to be a contributor. It felt bad to be accused of potential malicious activity (not by you of course) when I had come to help, and it left a sour enough taste in my mouth I just would rather spend my time elsewhere. (I also had the awkward situation of having no idea what was happening with mirabilos or the rest of the exchange on Mastodon because my server apparently is glitchy and didn't show me any of the other conversations - all of mirabilos's and xtaran's toots don't show up for me unless I view them from a different Mastodon server.) + +--%-- +From: ArrayBolt3 +Date: Tue, 06 Aug 2024 00:51:58 +0000 + +Also, I'm sorry for how upset I was above. I didn't have context, nor did I realize that the Dillo team was mostly you working on it. I sincerely want the project to succeed, just the hostile message mirabilos directed mostly at me hurt, and I didn't understand how things went down the path they did. I wish you and the Dillo project the best, and will try to stay out of everyone's way so that I don't cause or prolong any other problems on accident. + +--%-- +From: johnraff +Date: Tue, 06 Aug 2024 06:40:36 +0000 + +Since the original thread is locked, I'll just add here that I was also taken aback by the tone of @mirabilos 's last post, where he walked into the room like a teacher addressing a group of noisy schoolchildren. + +It seems there were multiple misunderstandings all round. + +While I knew @xtaran was the dillo maintainer and that @rodarima had tried to contact him, also posting on a related Debian [bug report](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022726) where xtaran said "...also in the long run to me maybe remove Dillo from Debian". It's also true that he is very busy on multiple other tasks - his name appears often - so it might have been reasonable to think he was prepared to allow dillo to be dropped. I now realise that's not the case. + +I also had no knowlege of the discussions taking place on Mastodon about fixing the GCC-14 issue, or mirabilos's explanation of "what’s happening, how to proceed, etc. and what not to do". The links do not open except by a circuitous process of logging in to one's own Mastodon server, then trying to find the post... + +Anyway, I think this is inappropriate for a forum where everyone is trying to help: +> I fully expect this discussion to finish here right now. +Those not involved with the new Dillo project should, please, +just shut up... + +--- +I'd just like to mention one other issue with the current dillo 3.0.5 as it is in Debian, is that it cannot display a number of websites, including Debian's own, due to outdated TLS support. That is fixed in both @rodarima 's and @w00fpack 's dillo upgrades, and might well be easily patchable without shifting to another upstream source for the code body. + +Anyway, @rodarima thank you for your work on dillo, which I have long been fond of and intend to keep packaging for [BunsenLabs](https://github.com/BunsenLabs), at least until the Debian package has caught up a bit. + + + +--%-- +From: rodarima +Date: Tue, 06 Aug 2024 10:09:32 +0000 + +> Also, I'm sorry for how upset I was above. I didn't have context, nor did I realize that the Dillo team was mostly you working on it. I sincerely want the project to succeed, just the hostile message mirabilos directed mostly at me hurt, and I didn't understand how things went down the path they did. I wish you and the Dillo project the best, and will try to stay out of everyone's way so that I don't cause or prolong any other problems on accident. + +Thanks!, I'll try to be more clear when addressing this issue in the future to prevent more misunderstandings. + +> I also had no knowlege of the discussions taking place on Mastodon about fixing the GCC-14 issue, or mirabilos's explanation of "what’s happening, how to proceed, etc. and what not to do". The links do not open except by a circuitous process of logging in to one's own Mastodon server, then trying to find the post... + +I tried to make the thread publicly available, but the web archive doesn't seem to be able to index it either. I could take a long screenshot but I'm not sure if that would be appropriate under Mastodon policies. + +> I'd just like to mention one other issue with the current dillo 3.0.5 as it is in Debian, is that it cannot display a number of websites, including Debian's own, due to outdated TLS support. + +Yeah, there are several problems with 3.0.5. At that time the support for HTTPs was experimental and was implemented in a plugin, which had several shortcomings. + +https://github.com/dillo-browser/dillo/blob/v3.0.5/dpi/https.c#L34-L44 + +https://github.com/dillo-browser/dillo/blob/84196030146a30110ba53c86d1e1fed156b2359e/dpi/https.c#L34-L44 + +I could enumerate one by one all the problems with the 3.0.5 version, and point out how they are fixed either by the original developers in the commits after 3.0.5, or in my own fixes. But that would take a non-negligible amount of time, so I'll wait and see if they become evident on their own. + +In the meanwhile, if all concerns were addressed, please @ArrayBolt3 feel free to close this issue. + +--%-- +From: mirabilos +Date: Tue, 06 Aug 2024 14:11:17 +0000 + +> Continuation of #230 since it was locked + +Aaaaaaargh! + +I’m out here. I don’t have the time to bother even reading this thread. + +--%-- +From: johnraff +Date: Wed, 07 Aug 2024 01:28:27 +0000 + +@mirabilos please take it easy. + +Your comments on Mastodon all look reasonable, and I think it would not hurt to show a more friendly attitude to people here, who mean the best for dillo, for Debian and for Linux users. + + + +--%-- +From: mirabilos +Date: Wed, 07 Aug 2024 09:05:25 +0000 + +Kindly stop @-ing me after I have **explicitly** said I don’t have the nerve to discuss this here and unsubscribed. 🤬 + +--%-- +From: xtaran +Date: Wed, 07 Aug 2024 09:36:00 +0000 + +> While I knew @xtaran was the dillo maintainer and that @rodarima had tried to contact him, also posting on a related Debian [bug report](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10227269) + +It's [#1022726](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022726), not #10227269 + +> where xtaran said "...also in the long run to me maybe remove Dillo from Debian". + +Please don't quote me out of context. This quote is from a time where I neither was aware of https://github.com/w00fpack/dilloNG/ nor of https://github.com/dillo-browser/dillo/ and hence neither reflects the current state nor intentions. (Yes I became aware of https://github.com/w00fpack/dilloNG/ shortly afterwards, but Debian bug reports are append-only respectively already existing entries are immutable.) + +--%-- +From: johnraff +Date: Thu, 08 Aug 2024 05:29:29 +0000 + +> > While I knew @xtaran was the dillo maintainer and that @rodarima had tried to contact him, also posting on a related Debian [bug report](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10227269) +> +> It's [#1022726](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022726), not #10227269 + +Thanks for catching that. + +> > where xtaran said "...also in the long run to me maybe remove Dillo from Debian". +> +> Please don't quote me out of context. This quote is from a time where I neither was aware of https://github.com/w00fpack/dilloNG/ nor of https://github.com/dillo-browser/dillo/ and hence neither reflects the current state nor intentions. + +I'm sorry - I was not clear enough in my language. It's true that the following day you mentioned other contributors' code as looking "sane", and I should have paid more attention to that. Anyway, I now understand that you have no intention of dropping dillo, which is great news as far as I'm concerned. + +I never had any intention of pressuring you - or anyone else - but having been CC'd to the original thread, thought my Debianization of dillo-browser's current 3.1.1 might have useful snippets and save someone some time somewhere. + diff --git a/234/index.md b/234/index.md new file mode 100644 index 0000000..0b07ae9 --- /dev/null +++ b/234/index.md @@ -0,0 +1,100 @@ +Title: Blurry font rendering [Mac] +Author: philocalyst +Created: Tue, 06 Aug 2024 03:34:08 +0000 +State: closed + +Sometimes without interaction, but always with, the text will appear blurry when rendering in dillo (3.1.1). I'm on macos 14.6, FLTK 1.3.9. Attached is an example. any help would be appreciated! +<img width="1512" alt="71157" src="https://github.com/user-attachments/assets/9be5ec78-9876-4224-a2b0-8173cb71f600"> + + +--%-- +From: rodarima +Date: Tue, 06 Aug 2024 08:46:08 +0000 + +That is an interesting bug. Here is a 8x magnified picture of the issue: + +<img width="776" alt="2" src="https://github.com/user-attachments/assets/81165e41-1a4f-4ec7-9685-715d4925db76"> + +I don't have any Apple computer to test myself. If you used homebrew, could you test if you can reproduce the same issue with the [HEAD (master) version of FLTK](https://formulae.brew.sh/formula/fltk)? You probably need to remove FLTK 1.3.9 first to be sure is not used. + +--%-- +From: philocalyst +Date: Tue, 06 Aug 2024 19:46:51 +0000 + +Getting this error preventing me from doing so: + +`configure: error: FLTK 1.3 required; version found: 1.4.0 ` + +I tried also switching my dillo install to HEAD but to no avail :( +Is there anything else I can do from my side to help debug? + + +--%-- +From: rodarima +Date: Tue, 06 Aug 2024 22:54:41 +0000 + +> configure: error: FLTK 1.3 required; version found: 1.4.0 + +This is caused by a check in the configure.ac which you can adjust to work with +1.4.0. + +To test it yourself, you would need to build Dillo from source yourself, which shouldn't be hard. + +You can probably get it done with these commands (assuming you already installed FLTK fomr HEAD): + +``` +$ git clone https://github.com/dillo-browser/dillo.git +$ cd dillo +$ sed -i 's/1\.3\.\*)/1.4.*)/' configure.ac +$ ./autogen.sh +$ mkdir build +$ cd build +$ brew install autoconf automake openssl@3 +$ ../configure --prefix=/usr/local LDFLAGS="-L`brew --prefix openssl`/lib" CPPFLAGS="-I`brew --prefix openssl`/include" +$ make +$ sudo make install +``` + +--%-- +From: amandasystems +Date: Mon, 09 Sep 2024 09:05:11 +0000 + +Note: the sed command assumes GNU sed, but that's available in homebrew too as `gsed`. + +It looks great on my machine (macOS 14.6.1 (23G93)) with FLTK HEAD: + +<img width="892" alt="image" src="https://github.com/user-attachments/assets/d5e13dd7-a9fd-4805-8c65-3bf1d6e00514"> + + +--%-- +From: rodarima +Date: Mon, 09 Sep 2024 18:58:06 +0000 + +> Note: the sed command assumes GNU sed, but that's available in homebrew too as gsed. + +Oops :-) + +> It looks great on my machine (macOS 14.6.1 (23G93)) with FLTK HEAD: + +Nice!, can you also reproduce the same blurry font problem with FLTK 1.3.9? If so, it would probably be a bug in FLTK that is fixed in 1.4, which would be no work for us. + +--%-- +From: amandasystems +Date: Thu, 12 Sep 2024 10:08:33 +0000 + +The blurry text is triggered only when resizing the window _and letting go of the drag handle_ for me. While the window is resizing, the blur is absent. As soon as I release it, it's there, and stays there even if I resize again. I haven't checked if it appears if I reload the page. + +It happens both with the package from Homebrew and git master. + +It does not happen with latest FLTK (HEAD), so I can confirm that it's an FLTK issue at least for me. + + + + +--%-- +From: rodarima +Date: Sat, 14 Sep 2024 06:53:23 +0000 + +> It does not happen with latest FLTK (HEAD), so I can confirm that it's an FLTK issue at least for me. + +Thanks for testing. Then I'll close this and focus on supporting FLTK 1.4 properly (https://github.com/dillo-browser/dillo/issues/246).
\ No newline at end of file diff --git a/235/index.md b/235/index.md new file mode 100644 index 0000000..aed28d7 --- /dev/null +++ b/235/index.md @@ -0,0 +1,6 @@ +Title: Add icon for controlling the zoom +Author: rodarima +Created: Tue, 06 Aug 2024 11:23:33 +0000 +State: open + +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/JPPTM43Q3JBVTI7A337BADZP737KZ7FG/#AUZVEMIP7N54XIIGVBGVZ7BDWB54N2DY
\ No newline at end of file diff --git a/236/index.md b/236/index.md new file mode 100644 index 0000000..269f7cb --- /dev/null +++ b/236/index.md @@ -0,0 +1,50 @@ +Title: Infinite layout loop with github.com after loging in +Author: rodarima +Created: Wed, 07 Aug 2024 00:01:32 +0000 +State: open + +Infinite Layout::resizeIdle() loop when loading github.com after login in. + +``` +$ dillo github.com +... +Layout::resizeIdle calls = 404 +Layout::resizeIdle calls = 405 +Layout::resizeIdle calls = 406 +... +``` + +--%-- +From: rodarima +Date: Wed, 07 Aug 2024 10:24:03 +0000 + +Here is the isolated problem: + +```html +<!DOCTYPE html> +<html lang="en"> + <head> + <title>GitHub infinite layout loop</title> + </head> + <body> + <div style="display:inline-block"> + <form style="float:left"> + <input type="hidden"/> + <button type="submit" style="white-space:nowrap; float:left">Hello</button> + </form> + </div> + </body> +</html> +``` + +--%-- +From: rodarima +Date: Sun, 25 Aug 2024 16:29:51 +0000 + +Another case seems to be: https://en.m.wikipedia.org/w/index.php?title=OpenVSP&action=history, https://en.m.wikipedia.org/w/index.php?title=Dillo&action=history + +--%-- +From: rodarima +Date: Thu, 29 Aug 2024 22:44:24 +0000 + +The current workaround is triggered when resizing the window.
\ No newline at end of file diff --git a/237/index.md b/237/index.md new file mode 100644 index 0000000..d97399a --- /dev/null +++ b/237/index.md @@ -0,0 +1,8 @@ +Title: Workaround for infinite layout loop +Author: rodarima +Created: Wed, 07 Aug 2024 11:54:59 +0000 +State: closed + +Workaround for #236, it stops the layout loop if we have reached 1000 iterations, so we don't enter an infinite loop and hoard the CPU forever. It also stops the layouting loop each 100 iterations to return the control to the FLTK event loop, so we keep the window responsive. + +There is a bug in the layouting process involving floats and white-space wrapping that should be fixed. To debug it we will probably need the debug window merged first.
\ No newline at end of file diff --git a/238/index.md b/238/index.md new file mode 100644 index 0000000..7a763ff --- /dev/null +++ b/238/index.md @@ -0,0 +1,8 @@ +Title: Stick to POSIX make rules +Author: rodarima +Created: Sun, 11 Aug 2024 11:21:38 +0000 +State: closed + +Using $< in a non-suffix rule context is a GNUmake idiom + +Reported-by: Alex <a1ex@dismail.de> diff --git a/239/index.md b/239/index.md new file mode 100644 index 0000000..dc5dadf --- /dev/null +++ b/239/index.md @@ -0,0 +1,109 @@ +Title: Missing entity expansion inside PRE +Author: rodarima +Created: Sun, 11 Aug 2024 12:48:34 +0000 +State: closed + +From https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html + +The `<pre>` content is rendered: + + .SUFFIXES: .o .c .y .l .a .sh .f .c˜ .y˜ .l˜ .sh˜ .f˜ + +While the `˜` entity must be rendered as `~`, even inside a `pre` block. + +Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pre + +> If you have to display reserved characters such as <, >, &, and " within the +> `<pre>` tag, the characters must be escaped using their respective character +> references. +> +> `<pre>` elements commonly contain `<code>`, `<samp>`, and `<kbd>` elements, to +> represent computer code, computer output, and user input, respectively. + + +--%-- +From: rodarima +Date: Sun, 11 Aug 2024 14:23:32 +0000 + +Dillo reports: + +> HTML warning: line 11, Numeric character reference `'˜'` is not valid. + +Which is handled by `Html_parse_numeric_charref()`: + +```c +if ((codepoint < 0x20 && codepoint != '\t' && codepoint != '\n' && + codepoint != '\f') || + (codepoint >= 0x7f && codepoint <= 0x9f) || + (codepoint >= 0xd800 && codepoint <= 0xdfff) || codepoint > 0x10ffff || + ((codepoint & 0xfffe) == 0xfffe) || + (!(html->DocType == DT_HTML && html->DocTypeVersion >= 5.0f) && + codepoint > 0xffff)) { + /* this catches null bytes, errors, codes out of range, disallowed + * control chars, permanently undefined chars, and surrogates. + */ + char c = *s; + *s = '\0'; + BUG_MSG("Numeric character reference '&#%s' is not valid.", tok); + *s = c; + + codepoint = (codepoint >= 145 && codepoint <= 151) ? + Html_ms_stupid_quotes_2ucs(codepoint) : -1; +} +``` + +However the tilde character seems to have the Unicode value U+007e or 126 in +decimal. + +>>> hex(ord('~')) +'0x7e + +Which matches the [ISO-8859-1 character set](https://en.wikipedia.org/wiki/ISO/IEC_8859-1) + +From the Wikipedia: + +> The popular Windows-1252 character set adds all the missing characters +> provided by ISO/IEC 8859-15, plus a number of typographic symbols, by +> replacing the rarely used C1 controls in the range 128 to 159 (hex 80 to 9F). +> It is very common to mislabel Windows-1252 text as being in ISO-8859-1. A +> common result was that all the quotes and apostrophes (produced by "smart +> quotes" in word-processing software) were replaced with question marks or +> boxes on non-Windows operating systems, making text difficult to read. Many +> Web browsers and e-mail clients will interpret ISO-8859-1 control codes as +> Windows-1252 characters, and that behavior was later standardized in +> HTML5.[20] + + +In the [Windows-1252](https://en.wikipedia.org/wiki/Windows-1252) table I can +see that the symbol is not the common tilde `~` but a "small tilde" U+02DC `˜`. + +So, this seems to be one of those cases where the charset is wrongly set to +ISO-8859-1 instead of Windows-1252. The document content type seems to be wrong: + +```html +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> +``` + +Also, the based on the [HTML 4.01 +spec](https://www.w3.org/TR/html4/charset.html), the numeric entities must refer +to the "document character set": + +> Occasional characters that fall outside this encoding may still be represented +> by character references. These always refer to the document character set, not +> the character encoding. + +And the character set is *not* the `charset`, but Unicode: + +> The ASCII character set is not sufficient for a global information system such +> as the Web, so HTML uses the much more complete character set called the +> Universal Character Set (UCS), defined in [ISO10646]. This standard defines a +> repertoire of thousands of characters used by communities all over the world. + +So the entity `˜` is pointing to the [Unicode symbol for "Start Of +String"](https://www.codetable.net/decimal/152), which is non printable. + +Therefore, there is no bug on Dillo side, but two bugs on the POSIX manual +page. + +- The entity for small tilde must be `˜` or `˜` +- They probably mean ~ not the small tilde. diff --git a/24/index.md b/24/index.md new file mode 100644 index 0000000..5e30e45 --- /dev/null +++ b/24/index.md @@ -0,0 +1,10 @@ +Title: Split tests into directories and run them with "make check" +Author: rodarima +Created: Thu, 21 Dec 2023 00:13:00 +0000 +State: closed + +Graphical tests for the Dillo Widget (dw) are moved into test/dw, the rest of unit tests are in test/unit. + +Most of the tests require manual intervention from humans. This MR makes some of the unit tests work on their own. + +See #15
\ No newline at end of file diff --git a/240/index.md b/240/index.md new file mode 100644 index 0000000..5c93a1e --- /dev/null +++ b/240/index.md @@ -0,0 +1,21 @@ +Title: Zooming out makes 1 px border dissapear +Author: rodarima +Created: Sun, 11 Aug 2024 20:20:31 +0000 +State: closed + +When zooming out of a page that uses a 1 px border, the border disappears. We +could make a rule to prevent applying the zoom to the border. + +The problem is likely coming from the zoom computation: + +```c +bool StyleEngine::computeValue (int *dest, CssLength value, Font *font) { + switch (CSS_LENGTH_TYPE (value)) { + case CSS_LENGTH_TYPE_PX: + *dest = (int) (CSS_LENGTH_VALUE (value) * zoom); + return true; +``` + +As soon as the floating point value drops below 1, the value is converted to 0. +However, if we round it, it will need to at least drop below 0.5, at which point +it would be fine if it disappears. diff --git a/241/index.md b/241/index.md new file mode 100644 index 0000000..1f7b9fc --- /dev/null +++ b/241/index.md @@ -0,0 +1,10 @@ +Title: Round CSS value after applying zoom level +Author: rodarima +Created: Sun, 11 Aug 2024 20:24:41 +0000 +State: closed + +When a 1px value is used for the border, any zoom level that makes it +smaller makes the resulting size 0, so it disappears. Using round +instead leaves more room for zooming out before it disappears. + +Fixes: https://github.com/dillo-browser/dillo/issues/240 diff --git a/242/index.md b/242/index.md new file mode 100644 index 0000000..12cb25c --- /dev/null +++ b/242/index.md @@ -0,0 +1,42 @@ +Title: Preserve aspect ratio of images +Author: rodarima +Created: Mon, 12 Aug 2024 22:01:47 +0000 +State: closed + +A common problem for images is that only one dimension is given {height,width} +or that a range is set by {min,max}-{height,width}. Previously, the original +size of the image was used to compute the aspect ratio and then fill the missing +dimension. + +But the procedure requires more steps to fulfill all constraints. This PR tries +to cover all posible cases of constrained images while preserving the aspect +ratio. When is not posible, the aspect ratio is distorted to fit the size +constraints. + + +### TODO + +- [x] Test several combinations of padding and margins to check we continue to + compute the image size correctly. -> Tested manually, but we may want to add more render tests to the suite. +- [x] Test floating images and cases where they might not have a parent. +- [x] Check the problem with gigantic images is not introduced by this PR. + +--- + +<details> +<summary>How it looks</summary> +Before: + + + +After: + + + +</details> + +--%-- +From: rodarima +Date: Thu, 17 Oct 2024 18:47:53 +0000 + +Testing with float images improves when compared with the previous behavior, but continues to show problems when computing the parent requisition. I think we can leave this for a future PR, to avoid stalling this one forever.
\ No newline at end of file diff --git a/243/index.md b/243/index.md new file mode 100644 index 0000000..01f394d --- /dev/null +++ b/243/index.md @@ -0,0 +1,99 @@ +Title: Navigate with keyboard only +Author: rodarima +Created: Tue, 13 Aug 2024 14:51:04 +0000 +State: open + +While the mouse is often convenient to navigate the web, it may be doable to use +the keyboard only as well. + +We already support controlling the viewport position with configurable keys, so +HJKL navigation is posible. Similarly, switching tabs or going back and forward +in time. + +The missing piece is to be able to follow hyperlinks with the keyboard too. + +One approach may be to follow a bit the Tab behavior for forms. But as +hyperlinks may be scattered all around the viewport, I'm thinking in a better +solution. + +Instead of pressing Tab several times to jump to the next element, we press a +key once to enter a "selection mode". In this mode, the HJKL keys no longer move +the viewport, but allow the user to navigate in 2D jumping across the hyperlinks +in the screen towards the direction determined by the HJKL keys (or arrow keys). + +Once the hyperlink is found, it is just opened by pressing enter (or space) and +the view may reset the mode to the normal navigation mode. + +We probably would need to define a formal ordering of hyperlinks, so all can be +reached from any other hyperlink with a finite sequence of HJKL movements. + +This mechanism is more intuitive than tagging hyperlinks and having to type the +specific label for the one to open next. As the brain doesn't need to process +any label, it can preload a chain of operations and adjust it in case the +selection chain is going off-course. + +No more Tab Tab Tab. + + +--%-- +From: bohwaz +Date: Sun, 18 Aug 2024 00:14:20 +0000 + +Opera (Presto) had this, and Vivaldi has it as well, but it seems to work a bit worse than in Opera. They both use Shift+arrows. + +https://blog.codinghorror.com/spatial-navigation-and-opera/ +https://help.vivaldi.com/desktop/shortcuts/spatial-navigation/ + +--%-- +From: rodarima +Date: Sun, 18 Aug 2024 00:33:26 +0000 + +> Opera (Presto) had this, and Vivaldi has it as well, but it seems to work a +> bit worse than in Opera. They both use Shift+arrows. + +Nice to know! + +I'm not sure which method will be easier to use. Coming from vim I would +personally choose the two modes approach (normal navigation vs link select) and +then just reuse the HJKL in the middle row for both. + +I'll have to do some experiments when I implement this to test it. I suspect it +could be made configurable in keysrc to fit the user preferences. + + +--%-- +From: khlsvr +Date: Sun, 01 Sep 2024 21:41:20 +0000 + +Would it be making dillo too heavy to use "link hinting"? Qutebrowser and some other keyboard-driven browsers use this method and it's really useful. + +Depending on the key I press I use it to: open link in same tab, open link in new tab, copy URL of the link, open the link in mpv etc. Many qutebrowser users use it all the time, but yeah maybe it's not that simple to implement it into Dillo? + +--%-- +From: rodarima +Date: Sun, 01 Sep 2024 22:14:48 +0000 + +>Would it be making dillo too heavy to use "link hinting"? Qutebrowser +>and some other keyboard-driven browsers use this method and it's really +>useful. +> +>Depending on the key I press I use it to: open link in same tab, open +>link in new tab, copy URL of the link, open the link in mpv etc. Many +>qutebrowser users use it all the time, but yeah maybe it's not that +>simple to implement in Dillo? + +It is probably doable, but let's focus first on having a simple and +working implementation for link selection with arrows and then the rest. + + +--%-- +From: khlsvr +Date: Mon, 02 Sep 2024 11:53:43 +0000 + +> It is probably doable, but let's focus first on having a simple and working implementation for link selection with arrows and then the rest. + +I must have been tired last night as I didn't notice you already mentioned my proposed method in the original post. You could be right too with the extra brain processing with the labels but maybe I have gotten used to it so I haven't thought about it so much. + +Also I haven't tried the hjkl-arrows approach planned here. Maybe it could turn out to be a better way to pick the hyperlinks in dillo. + +Would it make sense to add the following extra behaviour on your hjkl-arrows approach when implementing it, or left out at first and consider it later. Often times people want to open the link in the current tab and also often times they want to open it in a new tab. Also often you just want to copy the URL of the link. So I'm thinking if "enter" is the default key for opening the selected link in the current tab, should there be another key for opening it in a new tab or copying the URL to primary/clipboard? Best of course would be a configurable system where you could write in your keysrc what to do with the selected link and with what key.
\ No newline at end of file diff --git a/244/index.md b/244/index.md new file mode 100644 index 0000000..69fac67 --- /dev/null +++ b/244/index.md @@ -0,0 +1,12 @@ +Title: Bad background for cached image with transparency +Author: rodarima +Created: Wed, 14 Aug 2024 12:30:27 +0000 +State: open + +When two or more copies of the same image with transparency appear in a single +document, the transparent pixels are mixed with the background of the first +image container. However, subsequent images take the image buffer from the cache +inheriting the same background, regardless of the background where the rest of +images are placed. + +The cache should not be used if the background is different. diff --git a/245/index.md b/245/index.md new file mode 100644 index 0000000..e346a92 --- /dev/null +++ b/245/index.md @@ -0,0 +1,9 @@ +Title: Stylesheet repush kills initial image requests +Author: rodarima +Created: Thu, 15 Aug 2024 16:30:08 +0000 +State: open + +Images are requested twice when style sheets cause a repush of the page. They +should continue using the original requests. + +Reported-by: dogma diff --git a/246/index.md b/246/index.md new file mode 100644 index 0000000..cb8676c --- /dev/null +++ b/246/index.md @@ -0,0 +1,196 @@ +Title: Prepare Dillo for FLTK 1.4 +Author: rodarima +Created: Thu, 15 Aug 2024 17:45:38 +0000 +State: open + +We should prepare Dillo to be compatible with FLTK 1.4, as currently the +configure prevents building with other than FLTK 1.3. + +There may be some other changes to do with the transition. + + +--%-- +From: rodarima +Date: Sat, 14 Sep 2024 06:50:29 +0000 + +Related: https://github.com/dillo-browser/dillo/issues/258 + +--%-- +From: rodarima +Date: Mon, 21 Oct 2024 18:51:37 +0000 + +FLTK 1.4rc1 released: https://www.fltk.org/newsgroups.php?s22210+gfltk.coredev+v22223 + +One of the main changes with FLTK 1.4 is that they switched the units [to "scale units", which are DPI independent](https://www.fltk.org/doc-1.4/drawing.html#drawing_DrawingUnit). This will cause problems with images and text that is currently rendered to be shown at an specific size. + +We probably will need to adjust the rendering of elements to take into the account the DPI, so they are properly rendered on the screen. Similarly, icons will need to have higher resolutions, so we can properly scale them on high DPI screens. + +So far FLTK 1.4 causes gliches when scrolling, so it will remain not compatible until we can fix them: + + + + +--%-- +From: ghost +Date: Mon, 28 Oct 2024 13:20:22 +0000 + +FLTK 1.4.0rc2 has been released: +https://www.fltk.org/articles.php?L1949 + +I don't see any scrolling glitches as you mentioned above, so hopefully thats fixed now. + + +--%-- +From: rodarima +Date: Mon, 28 Oct 2024 14:01:16 +0000 + +> I don't see any scrolling glitches as you mentioned above, so hopefully thats fixed now. + +These problems are likely in Dillo not FLTK. The FLTK new commits don't change any DPI code that I can see. They are still present for me on 1.4.0rc2. + +What is your screen DPI? Are you on Xorg or Wayland? If on Xorg: + +``` +$ xdpyinfo | grep -B2 resolution +``` + +Also, how did you built dillo with FLTK 1.4? Can you attach the config.log and: + +``` +$ ldd src/dillo +``` + +--%-- +From: ghost +Date: Mon, 28 Oct 2024 14:40:39 +0000 + +It's Xorg @ 96dpi. + +I set configure.ac to: + +AC_PATH_PROG(FLTK_CONFIG,fltk-config) +AC_MSG_CHECKING([FLTK 1.4]) +fltk_version="`$FLTK_CONFIG --version 2>/dev/null`" +case $fltk_version in + 1.4.*) AC_MSG_RESULT(yes) + LIBFLTK_CXXFLAGS=`$FLTK_CONFIG --cxxflags` + LIBFLTK_CFLAGS=`$FLTK_CONFIG --cflags` + LIBFLTK_LIBS=`$FLTK_CONFIG --ldflags`;; + +Then removed the original FLTK package, built the new 1.4.0rc2 from source, and installed: + +$ fltk-config --version +1.4.0 + +Then built dillo with the new version. + +I sent you the config.log and the ldd output. + +--%-- +From: rodarima +Date: Mon, 28 Oct 2024 14:56:21 +0000 + +> It's Xorg @ 96dpi. + +I don't think you will see it on 96dpi. You need a DPI value larger than 96 (but not a multiple), so it triggers the rounding problem. My screen is 101dpi which seems to be very problematic. + +You may be able to fake a 101dpi and reproduce it with: + +``` +$ FLTK_SCALING_FACTOR=1.0539418854166667 src/dillo +``` + +I can also try with another 96dpi screen and see if it goes away on my end (probably). + +--%-- +From: ghost +Date: Mon, 28 Oct 2024 15:50:25 +0000 + +Ok, I start to see some glitching when doing that, and when changing the dpi higher than 96 with xrandr. + +--%-- +From: juanitotc +Date: Mon, 11 Nov 2024 13:56:26 +0000 + +For info - I just built dillo-3.1.0 against fltk-1.4.0rc3 wayland only and things seem to work + +--%-- +From: ghost +Date: Thu, 26 Dec 2024 15:07:15 +0000 + +FLTK 1.4.1 was released a while ago, and the changelog indicates that this issue might be fixed, but unfortunately there is still some of this glitching happening in Dillo with it. + + + +--%-- +From: rodarima +Date: Thu, 26 Dec 2024 17:04:07 +0000 + +> FLTK 1.4.1 was released a while ago, and the changelog indicates that this +> issue might be fixed, but unfortunately there is still some of this glitching +> happening in Dillo with it. + +This issue is here to act as a meta-issue, so I can cross-link all other +fixes required for FLTK 1.4. There are several issues with FLTK 1.4 which you +can find in the issue tracker searching for "FLTK" (I should add a new label). + +Until all of them are solved and I have checked that there is no big penalty in +performance, I will not consider supporting FLTK 1.4 officially. Some issues may +require large changes on Dillo, so I would not expect this to happen any time +soon. + +If you are refering to this: + +> Fix graphical glitches on 101 DPI screen + +This doesn't solve the issue on Dillo rendering, but it "fixes" a issue on a +FLTK test program. + +>  + +I have multiple patches to mitigate this issue, none good enough. There is +something wrong on the FLTK side, and until I don't find the proper solution, it +will remain broken. + +There are other issues that are not so evident which would need to be solved +too. So it is safer to keep Dillo clearly broken, so we don't end up with +distributions shipping with FLTK 1.4 and a crappy patch to make it apparently +work. + +One way in which you can help is by testing future patches on your hardware, so +we can determine it is fixed on a broad variety of screen resolutions. In the +meanwhile, we will have to wait. + + +--%-- +From: ghost +Date: Thu, 26 Dec 2024 20:31:07 +0000 + + +> Until all of them are solved and I have checked that there is no big +> penalty in performance, I will not consider supporting FLTK 1.4 +> officially. Some issues may require large changes on Dillo, so I +> would not expect this to happen any time soon. + +Makes sense. Hopefully distros won't be too quick to phase-out FLTK +1.3.X versions for now. + +> If you are refering to this: +> +> > Fix graphical glitches on 101 DPI screen +> +> This doesn't solve the issue on Dillo rendering, but it "fixes" a +> issue on a FLTK test program. + +Right, that's the one that got my attention... + + + + +--%-- +From: rodarima +Date: Sun, 29 Jun 2025 12:43:14 +0000 + +> So it is safer to keep Dillo clearly broken, so we don't end up with distributions shipping with FLTK 1.4 and a crappy patch to make it apparently work. + +Given that it is taking me a while to fix this, I think it would be more useful to output the current patch under a `--enable-experimental-fltk-1.4` configure flag (or similar), so users have to manually activate it. Hopefully this will stop distributions from enabling it by default, and give users the chance to test it and potentially contribute towards a fix.
\ No newline at end of file diff --git a/247/index.md b/247/index.md new file mode 100644 index 0000000..4869ea0 --- /dev/null +++ b/247/index.md @@ -0,0 +1,23 @@ +Title: Dark mode switching +Author: rodarima +Created: Fri, 16 Aug 2024 19:11:32 +0000 +State: open + +Browsing the web at night or in a dark environment is generally more appealing +with dark backgrounds. However, during the day or in well illuminated rooms, +using a light background is generally preferred, as the eyes can shut the pupil +due to the large amount of light, causing the borders of letters to be sharper, +making reading easier. + +It should be doable to quickly switch from a light mode to a dark mode. Ideally, +we may want to add a way to control the transition so it is not just binary, but +more gradual. However, the minimum requirement for this issue is to provide a +dark mode only. + +The dark mode should change the browser UI (menus, tool bars...) but also the +content itself of the web. For the latter, we would need to define a dark mode +CSS theme, which can override the web defined colors. Similarly, we can do a +similar job to try to adjust images so that the background is dark. + +Some websites can already work with a dark mode and can provide images with +adequate colors for a dark theme, without the need to adjust them. diff --git a/248/index.md b/248/index.md new file mode 100644 index 0000000..83b33ab --- /dev/null +++ b/248/index.md @@ -0,0 +1,20 @@ +Title: Is gif supported? +Author: serfcity +Created: Sat, 17 Aug 2024 06:00:44 +0000 +State: closed + +Hello, guys! + +Is **animated** gif supported? I see only first frame of an animated gif image. + +--%-- +From: rodarima +Date: Sat, 17 Aug 2024 10:31:53 +0000 + +Nope, only static GIF. + +--%-- +From: serfcity +Date: Sat, 17 Aug 2024 11:18:36 +0000 + +Thank you for information. It's sad.
\ No newline at end of file diff --git a/249/index.md b/249/index.md new file mode 100644 index 0000000..c0bd32d --- /dev/null +++ b/249/index.md @@ -0,0 +1,67 @@ +Title: Allow users to empty the cache +Author: rodarima +Created: Sat, 17 Aug 2024 14:36:42 +0000 +State: open + +As a half-way implementation of #231, we could initially add a manual mechanism +to empty the cache. Adding an automatic mechanism would require storing some +score in the cache entries, while doing it manually is an easy patch. + + +--%-- +From: rodarima +Date: Sat, 17 Aug 2024 17:18:46 +0000 + +There are several caches in Dillo. The one that seems to occupy the most is the +so called Dicache, which stores uncompressed image buffers. For reference, +loading Brutaldon takes around 100 MiB of uncompressed image size. + +The Dicache has several reference counters to avoid removing buffers that are +still in use. Even after they are not used, they will survive three cleanup +attempts. + +On the other hand, after closing the page with the images, and calling +`a_Dicache_cleanup()` doesn't seem to be enough to get rid of the cache entries. +Not sure if there are more references somewhere. + +This should be easy to test, as we can make a page with large images, load it, +then open a new page without images, clear the cache and ensure the resident +memory usage goes to the initial level. + +It doesn't look we are leaking those buffers when closing Dillo. + +I have also tested clearing the "normal" cache, which just stores the compressed +images and other resources fetched by HTTP, but it doesn't seem to free that +much memory. + + +--%-- +From: rodarima +Date: Sun, 18 Aug 2024 00:24:29 +0000 + +From [Livio comment in 2003](https://dillo-dev.auriga.wearlab.narkive.com/TYZWEMgE/how-to-use-dicache): + +> Let me clarify a little bit about what the dicache is. +> +> This is how Dillo works. When you ask for a URL (be it a root URL, +> like a HTML, or an image embedded in a page), it looks it up in a +> _memory_ cache. If it's already there it returns the content of the +> cache, and if not it makes a connection to retrieve that URL. +> +> But there is a complication with respect to images. The images which +> are downloaded need to be decompressed to be displayed (that is, +> transformed from their original format, jpeg, gif, etc, to a bitmap +> format). So for images, first the dicache (_d_ecompressed _i_mage +> cache) is checked, then the cache, then finally it is retrieved from +> the site. The problem with dicache is that it eats up a *LOT* of +> memory, and the only benefit is the processing time of transforming +> from the original format to the bitmap. That's why the default is NO. + +Good to know that dicache comes from "decompressed image cache". + +I assume it is only worth it when we have multiple clones of the same pages +loaded with big images into multiple tabs, so we only need to decompress the +images once. + +Other than that, it shouldn't retain any memory after the decompressed images +are evicted. diff --git a/25/index.md b/25/index.md new file mode 100644 index 0000000..e1d4b8a --- /dev/null +++ b/25/index.md @@ -0,0 +1,12 @@ +Title: Check patches in "mobilized dillo" for Pinephone +Author: rodarima +Created: Thu, 21 Dec 2023 01:06:11 +0000 +State: open + +A patched version of Dillo for usage on the Pinephone: https://www.toomanyatoms.com/software/mobilized_dillo.html + +Here is how it looks like: + + + +Re-compressed in gzip (due GitHub limitations with xz) here: [mobilized-dillo-25.tar.gz](https://github.com/dillo-browser/dillo/files/13733957/mobilized-dillo-25.tar.gz)
\ No newline at end of file diff --git a/250/index.md b/250/index.md new file mode 100644 index 0000000..3eb5467 --- /dev/null +++ b/250/index.md @@ -0,0 +1,64 @@ +Title: Add support to use an external password manager +Author: rodarima +Created: Sat, 17 Aug 2024 23:46:49 +0000 +State: open + +Dillo should be able to store user/password information (and potentially others) +in a safe way, so that it is remembered in the future. + +A potential solution is to add support for external password managers so we +don't need to implement it ourselves. + +See: https://xn--4pv.arzinfo.eu.org/Otyugh/p/1723455843.925137 +See: https://brutaldon.org/thread/112948402411922456 + + +--%-- +From: rodarima +Date: Sun, 25 Aug 2024 19:18:11 +0000 + +Firefox Sync can store passwords too with the ffsclient: https://github.com/Mikescher/firefox-sync-client + +--%-- +From: jn64 +Date: Sun, 02 Mar 2025 03:39:49 +0000 + +I think these are separate concerns: + +1. "Dillo should be able to store user/password information." +2. "Dillo should support external password manager(s)." + +### "Dillo should be able to store user/password information." + +1 is much more useful for a browser. It means anyone can start using Dillo, +login to a website, maybe get a prompt "Do you want Dillo to save passwords?" +and click yes, regardless if they use any password manager or even +understand the concept. + +On mainstream Linux this might be done with [freedesktop Secret Service API](https://specifications.freedesktop.org/secret-service-spec/latest/) +(see also [libsecret](https://gnome.pages.gitlab.gnome.org/libsecret/)). Users often have one of [gnome-keyring](https://wiki.archlinux.org/title/GNOME/Keyring) or [kwallet](https://wiki.archlinux.org/title/Kwallet) (KDE Wallet), +even if they don't use GNOME or KDE and don't explicitly use these as +password managers, because they are used by other apps to store secrets +(e.g. NetworkManager, Evolution mail client). + +(Just examples. I don't know if this is a good fit for Dillo. +libsecret seems to be available in FreeBSD as well.) + +### "Dillo should support external password manager(s)." + +2 is much less useful. Users who already use a password manager +probably wouldn't want to use a different one just for Dillo. + +Also, password manager users may not need or want this support. +I use [KeepassXC](https://keepassxc.org), and I intentionally do not install its browser extension(s). + +I only save passwords into KeepassXC directly, and use passwords in other +apps by invoking a global hotkey for KeepassXC to type a chosen password. +This way all apps have the same workflow; browser, terminal, any window +that can be focused and accepts keyboard input. + +I don't need to worry if any app has integration with my specific password +manager, or if that integration is correct or maintained. + +So, I can already use my password manager with Dillo. I suspect most other +intentional password manager users can also do this. diff --git a/251/index.md b/251/index.md new file mode 100644 index 0000000..4560a67 --- /dev/null +++ b/251/index.md @@ -0,0 +1,15 @@ +Title: Fix Google search +Author: rodarima +Created: Sun, 18 Aug 2024 12:46:16 +0000 +State: closed + +- Switch to HTTPS for Google search +- Fix Google search by adding gbv=1 param +- Avoid Google consent dialog by denying it + + +--%-- +From: rodarima +Date: Wed, 11 Sep 2024 18:18:53 +0000 + +Not sure if leaving `ucbcb=1` is safe, so let's address it in another PR.
\ No newline at end of file diff --git a/252/index.md b/252/index.md new file mode 100644 index 0000000..4ef99d0 --- /dev/null +++ b/252/index.md @@ -0,0 +1,62 @@ +Title: Move test suite to another repository +Author: rodarima +Created: Tue, 20 Aug 2024 12:18:30 +0000 +State: open + +Our current test suite involves a very limited number of simple HTML rendering +tests. These tests are currently distributed in the tarball release. + +However, there are other tests we should be doing which would involve many other +pieces that we don't use for Dillo: + +- HTTP, HTTPS, FTP, Gopher, Gemini, and other servers +- Multiple TLS ciphers (including broken ciphers or bad behaved replies) +- Multiple compression algorithms for transfer encoding +- Multiple content type mismatch (Content-Type says PNG, image bytes say JPG) +- Very slow networks and missing packets (TLS timeout?) +- Performance tests: measuring how long it takes to render some pages +- Memory tests: tracking memory usage over time and potential leaks + +All those tests will likely require extra software dependencies that would cause +Dillo to have a unnecessary long list of dependencies for testing. + +Having tests in a separate repository allows us to test multiple releases of +Dillo with the latest test suite. We could even try to run WPT or port some of +the tests to our test suite. + +Moving them outside the repository also makes the Dillo repository smaller, as +we don't have to bring unnecessary images or other potentially big files with +the browser. + +The drawbacks of this approach is that we won't be able to simply run `make +check` to pass all tests in any platform. + +We can develop Dillo from an old machine too, as the current requirements to +build it are not too high. Ideally we should keep the requirements for both +using Dillo and developing it about the same. + +This would also lift the strict requirements to stick to old C and C++ standards +for Dillo code, but allowing them for testing. + +This can be tested without disrupting the current test suite distributed with +Dillo, and then decided once we have more information on how that would work +out. + + +--%-- +From: sjehuda +Date: Wed, 06 Nov 2024 10:00:05 +0000 + +Gopher and Gemini would absolutely be great to have! + +--%-- +From: rodarima +Date: Wed, 06 Nov 2024 12:07:20 +0000 + +Read the issue again. + +> Gopher and Gemini would absolutely be great to have! + +https://dillo-browser.github.io/#plugins + +Locking.
\ No newline at end of file diff --git a/253/index.md b/253/index.md new file mode 100644 index 0000000..02f9646 --- /dev/null +++ b/253/index.md @@ -0,0 +1,73 @@ +Title: Consider allowing cookies after a 302 redirection +Author: rodarima +Created: Tue, 20 Aug 2024 13:08:11 +0000 +State: open + +Currently Dillo only accepts cookies for the same organization that caused the +initial request. + +For example, if loading a page from server foo.org causes loading another +resource from bar.org, bar.org is not allowed to set any cookie. + +This is a good protection against tracking [using third party +cookies](https://en.wikipedia.org/wiki/Third-party_cookies). + +The problem with this approach is that the OAuth mechanism used by Mastodon, and +in particular used by Brutaldon causes a single request that begins from a POST +to the brutaldon.org server to continue in a fosstodon.org server. + +Therefore, the fosstodon.org server cannot store cookies and the OAuth login +doesn't work. + +We could allow cookies when the whole page location is changed to another page, +not a resource. This would continue to block third party resources while +allowing OAuth to work. + +It would of course only work if the fosstodon.org domain is allowed to set +cookies in cookiesrc. + +The side effect of not being able to use OAuth is that users may attempt to use +other methods, like logging in directly into Brutaldon by sending the user and +pass to the brutaldon.org server. This requires trusting the Brutaldon instance, +as the OAuth mechanism never discloses the credentials with it, and has a finer +grained access control to the protected resource. + +The OAuth 2.0 mechanism is described in +[RFC-6749](https://datatracker.ietf.org/doc/html/rfc6749), but the specification +leaves out the usage of cookies to the implementation: + +> 3.1. Authorization Endpoint +> +> The authorization endpoint is used to interact with the resource +> owner and obtain an authorization grant. The authorization server +> MUST first verify the identity of the resource owner. The way in +> which the authorization server authenticates the resource owner +> (e.g., username and password login, session cookies) is beyond the +> scope of this specification. + +Similarly for CSRF protection: + +> 10.12. Cross-Site Request Forgery +> +> Cross-site request forgery (CSRF) is an exploit in which an attacker +> causes the user-agent of a victim end-user to follow a malicious URI +> (e.g., provided to the user-agent as a misleading link, image, or +> redirection) to a trusting server (usually established via the +> presence of a valid session cookie). +> +> A CSRF attack against the client's redirection URI allows an attacker +> to inject its own authorization code or access token, which can +> result in the client using an access token associated with the +> attacker's protected resources rather than the victim's (e.g., save +> the victim's bank account information to a protected resource +> controlled by the attacker). +> +> The client MUST implement CSRF protection for its redirection URI. +> This is typically accomplished by requiring any request sent to the +> redirection URI endpoint to include a value that binds the request to +> the user-agent's authenticated state (e.g., a hash of the session +> cookie used to authenticate the user-agent). The client SHOULD +> utilize the "state" request parameter to deliver this value to the +> authorization server when making an authorization request. + +See: https://github.com/mastodon/mastodon/issues/31466 diff --git a/254/index.md b/254/index.md new file mode 100644 index 0000000..13ab55c --- /dev/null +++ b/254/index.md @@ -0,0 +1,9 @@ +Title: Fix heap use after free in TLS conn on errors +Author: rodarima +Created: Wed, 28 Aug 2024 22:43:21 +0000 +State: closed + +When a error causes the TLS connection to fail and stop, the conn struct is free on Tls_close_by_key(), so writing to conn->in_connect is not correct after that point. The solution is to only set the flag when the it is still valid. + +Reported-by: Alex <a1ex@dismail.de> +Link: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/TY2JYCIPC7IQ32U6VC7ZOV3FVFFOE5K3/
\ No newline at end of file diff --git a/255/index.md b/255/index.md new file mode 100644 index 0000000..fba6609 --- /dev/null +++ b/255/index.md @@ -0,0 +1,6 @@ +Title: Reload current page on SIGUSR1 +Author: rodarima +Created: Sat, 31 Aug 2024 15:29:31 +0000 +State: closed + +It would be nice to live view a local page and reload on changes.
\ No newline at end of file diff --git a/256/index.md b/256/index.md new file mode 100644 index 0000000..8bba496 --- /dev/null +++ b/256/index.md @@ -0,0 +1,44 @@ +Title: Avoid expensive boundary search inside file +Author: rodarima +Created: Sun, 01 Sep 2024 22:23:26 +0000 +State: closed + +Prevents Dillo from checking if the boundary collides with the file by making the boundary have 70 random characters which have an extremely low probability of collision. + +--%-- +From: XaviDCR92 +Date: Tue, 03 Sep 2024 20:39:45 +0000 + +Since the two later commits are modifying things implemented by the first commit on the PR, feel free to squash all of them into a single commit. + +--%-- +From: rodarima +Date: Mon, 09 Sep 2024 18:53:12 +0000 + +> Since the two later commits are modifying things implemented by the first commit on the PR, feel free to squash all of them into a single commit. + +I think for this time I'm going to leave it in different commits, as they show the history of how we came with the current implementation and they also build fine. + +Could you test it with slcl? + +--%-- +From: XaviDCR92 +Date: Mon, 09 Sep 2024 21:00:16 +0000 + +Please take into account that the boundary string [would still be quoted](https://github.com/dillo-browser/dillo/blob/8a360e32ac3136494a494379a6dbbacef6f95da2/src/IO/http.c#L362) if no further changes are made. It might be a sensible idea to add an extra commit that removes the quoting from the `boundary`. + +> Could you test it with slcl? + +I have just tested this branch with `slcl` and it worked as expected, receiving `boundary=u6ngno8jWSmEjUQbfDwOpL8Wb4CWoPkJLyNWKK3usgYzYDA44UIjvE3wyvgLaqiJMVwktn` from Dillo. + +--%-- +From: rodarima +Date: Tue, 10 Sep 2024 05:02:14 +0000 + +> Please take into account that the boundary string [would still be quoted](https://github.com/dillo-browser/dillo/blob/8a360e32ac3136494a494379a6dbbacef6f95da2/src/IO/http.c#L362) if no further changes are made. It might be a sensible idea to add an extra commit that removes the quoting from the `boundary`. + +Yes, I'm aware. It looks all major browsers as well as curl do it without quotes, so it should be fairly safe to change it, but let's address it in another PR. There is also another potential problem, as Dillo doesn't finish the last boundary delimiter with CRLF, although the RFC doesn't seem to state that it must be placed there. + +> I have just tested this branch with `slcl` and it worked as expected, receiving `boundary=u6ngno8jWSmEjUQbfDwOpL8Wb4CWoPkJLyNWKK3usgYzYDA44UIjvE3wyvgLaqiJMVwktn` from Dillo. + +Thanks!, I'll add it to the ChangeLog and merge it.
\ No newline at end of file diff --git a/257/index.md b/257/index.md new file mode 100644 index 0000000..56ee4c3 --- /dev/null +++ b/257/index.md @@ -0,0 +1,12 @@ +Title: Missing doc/install.md from release +Author: rodarima +Created: Mon, 09 Sep 2024 19:29:02 +0000 +State: closed + +Reported-by: https://tuxjam.otherside.network/tuxjam-112-dillo-dally/ + +--%-- +From: rodarima +Date: Sat, 05 Oct 2024 07:41:10 +0000 + +Fixed in #266
\ No newline at end of file diff --git a/258/index.md b/258/index.md new file mode 100644 index 0000000..d49acd0 --- /dev/null +++ b/258/index.md @@ -0,0 +1,152 @@ +Title: Problems with png-config and fltk-config +Author: rodarima +Created: Wed, 11 Sep 2024 07:56:42 +0000 +State: open + +When installing FLTK in a different directory than /usr while keeping another installation there, I cannot link Dillo as it tries to find the libraries from /usr/lib due to a flag inserted by png-config: + +``` +g++ \ + -I/usr/include/libpng16 \ + -I/home/ram/dev/dillo/fltk/git/install/include \ + -D_LARGEFILE_SOURCE \ + -D_LARGEFILE64_SOURCE \ + -D_FILE_OFFSET_BITS=64 \ + -D_THREAD_SAFE \ + -D_REENTRANT \ + -g \ + -O2 \ + -Wall \ + -W \ + -Wno-unused-parameter \ + -fno-rtti \ + -fno-exceptions \ + -pedantic \ + -std=c++11 \ + -D_POSIX_C_SOURCE=200112L \ + \ + \ + -o \ + dillo \ + dillo.o \ + paths.o \ + tipwin.o \ + ui.o \ + uicmd.o \ + bw.o \ + cookies.o \ + hsts.o \ + auth.o \ + md5.o \ + digest.o \ + colors.o \ + misc.o \ + history.o \ + prefs.o \ + prefsparser.o \ + keys.o \ + url.o \ + bitvec.o \ + klist.o \ + chain.o \ + utf8.o \ + timeout.o \ + dialog.o \ + web.o \ + nav.o \ + cache.o \ + decode.o \ + dicache.o \ + capi.o \ + domain.o \ + css.o \ + cssparser.o \ + styleengine.o \ + plain.o \ + html.o \ + form.o \ + table.o \ + bookmark.o \ + dns.o \ + gif.o \ + jpeg.o \ + png.o \ + svg.o \ + imgbuf.o \ + image.o \ + menu.o \ + dpiapi.o \ + findbar.o \ + xembed.o \ + ../dlib/libDlib.a \ + ../dpip/libDpip.a \ + IO/libDiof.a \ + ../dw/libDw-widgets.a \ + ../dw/libDw-fltk.a \ + ../dw/libDw-core.a \ + ../lout/liblout.a \ + -ljpeg \ + -L/usr/lib \ <-------- here + -lpng16 \ + -L/home/ram/dev/dillo/fltk/git/install/lib \ + -lfltk \ + -lm \ + -lpthread \ + -lXinerama \ + -lXfixes \ + -lXcursor \ + -L/usr/lib \ + -lpangoxft-1.0 \ + -lpangoft2-1.0 \ + -lpango-1.0 \ + -lgobject-2.0 \ + -lglib-2.0 \ + -lharfbuzz \ + -lfontconfig \ + -lfreetype \ + -lXft \ + -lpangocairo-1.0 \ + -lcairo \ + -lX11 \ + -lXrender \ + -lwayland-cursor \ + -lwayland-client \ + -lxkbcommon \ + -ldbus-1 \ + -ldecor-0 \ + -ldl \ + -lz \ + -liconv \ + -lpthread \ + -lX11 \ + -lcrypto \ + -lssl +``` + +Ideally we should either point to the whole path with -l or discover how to make -L only affect the corresponding -l library. + +--%-- +From: rodarima +Date: Wed, 11 Sep 2024 08:36:38 +0000 + +Tried `-Wl,--push-state` but it doesn't seem to affect `-L`. + +--%-- +From: rodarima +Date: Wed, 11 Sep 2024 09:02:07 +0000 + +We should let the users pass the FLTK and other flags manually, so we avoid the problem in which a injected `-L` from fltk-config or png-config affects the rest of the libraries. + +--%-- +From: rodarima +Date: Mon, 14 Apr 2025 17:55:18 +0000 + +Also, fltk-config is injecting its own -O2 flags, which will race with the optimization level for debugging. + +--%-- +From: rodarima +Date: Sun, 31 Aug 2025 22:44:30 +0000 + +There is another issue, if there is already an FLTK library installed in /usr/lib (or potentially /usr/local/lib) it can be loaded *instead* of the one dillo was linked against. We would need to add the corresponding `-Wl,-rpath,...` flags for the linker as well. + +I think leaving the control of the variable to the use for non-standard installation is the best choice, so it can also inject platform or compiler specific flags.
\ No newline at end of file diff --git a/26/index.md b/26/index.md new file mode 100644 index 0000000..4f7c072 --- /dev/null +++ b/26/index.md @@ -0,0 +1,170 @@ +Title: HTML5 "autofocus" tag for input element in dillo +Author: rodarima +Created: Thu, 21 Dec 2023 11:43:16 +0000 +State: open + +We may want to integrate a patch to support autofocus from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033320 : + +> The attached patch adds support for HTML5's autofocus tag to Dillo: this allows to automatically focus certain input fields as soon as the page with the form loads. We're using this to implement a barcode scanner on a raspberry pi 3, so that the browser is immediately ready to scan, without a need to touch into the input field first. + +Here is the diff: + +```diff +diff -ur dillo-3.0.5.orig/dw/fltkplatform.cc dillo-3.0.5/dw/fltkplatform.cc +--- dillo-3.0.5.orig/dw/fltkplatform.cc 2015-06-10 23:48:53.000000000 +0200 ++++ dillo-3.0.5/dw/fltkplatform.cc 2023-03-18 12:41:21.910464773 +0100 +@@ -370,6 +370,10 @@ + { + } + ++void FltkView::focusFltkWidget (Fl_Widget *widget) ++{ ++} ++ + void FltkView::allocateFltkWidget (Fl_Widget *widget, + core::Allocation *allocation) + { +diff -ur dillo-3.0.5.orig/dw/fltkplatform.hh dillo-3.0.5/dw/fltkplatform.hh +--- dillo-3.0.5.orig/dw/fltkplatform.hh 2015-06-30 16:06:08.000000000 +0200 ++++ dillo-3.0.5/dw/fltkplatform.hh 2023-03-18 12:46:12.542094720 +0100 +@@ -86,6 +86,7 @@ + virtual void allocateFltkWidget (Fl_Widget *widget, + core::Allocation *allocation); + virtual void drawFltkWidget (Fl_Widget *widget, core::Rectangle *area); ++ virtual void focusFltkWidget (Fl_Widget *widget); + }; + + +diff -ur dillo-3.0.5.orig/dw/fltkui.cc dillo-3.0.5/dw/fltkui.cc +--- dillo-3.0.5.orig/dw/fltkui.cc 2015-06-30 16:06:08.000000000 +0200 ++++ dillo-3.0.5/dw/fltkui.cc 2023-03-18 12:33:36.914259944 +0100 +@@ -460,6 +460,11 @@ + this->view = NULL; + } + ++void FltkResource::focus () ++{ ++ view->focusFltkWidget (widget); ++} ++ + void FltkResource::sizeAllocate (core::Allocation *allocation) + { + this->allocation = *allocation; +@@ -574,6 +579,11 @@ + FltkResource::setEnabled (enabled); + } + ++template <class I> void FltkSpecificResource<I>::focus () ++{ ++ FltkResource::focus (); ++} ++ + // ---------------------------------------------------------------------- + + class EnterButton : public Fl_Button { +diff -ur dillo-3.0.5.orig/dw/fltkui.hh dillo-3.0.5/dw/fltkui.hh +--- dillo-3.0.5.orig/dw/fltkui.hh 2015-06-30 16:06:09.000000000 +0200 ++++ dillo-3.0.5/dw/fltkui.hh 2023-03-18 12:38:41.898264236 +0100 +@@ -217,6 +217,8 @@ + + bool isEnabled (); + void setEnabled (bool enabled); ++ ++ void focus (); + }; + + +@@ -232,6 +234,8 @@ + + bool isEnabled (); + void setEnabled (bool enabled); ++ ++ void focus (); + }; + + +diff -ur dillo-3.0.5.orig/dw/fltkviewbase.cc dillo-3.0.5/dw/fltkviewbase.cc +--- dillo-3.0.5.orig/dw/fltkviewbase.cc 2015-06-30 16:06:09.000000000 +0200 ++++ dillo-3.0.5/dw/fltkviewbase.cc 2023-03-18 12:18:12.234001790 +0100 +@@ -711,6 +711,12 @@ + add (widget); + } + ++void FltkWidgetView::focusFltkWidget (Fl_Widget *widget) ++{ ++ focused_child=widget; ++ widget->take_focus(); ++} ++ + void FltkWidgetView::removeFltkWidget (Fl_Widget *widget) + { + remove (widget); +diff -ur dillo-3.0.5.orig/dw/fltkviewbase.hh dillo-3.0.5/dw/fltkviewbase.hh +--- dillo-3.0.5.orig/dw/fltkviewbase.hh 2015-06-30 16:06:09.000000000 +0200 ++++ dillo-3.0.5/dw/fltkviewbase.hh 2023-03-18 12:39:07.514936690 +0100 +@@ -132,6 +132,7 @@ + void allocateFltkWidget (Fl_Widget *widget, + core::Allocation *allocation); + void drawFltkWidget (Fl_Widget *widget, core::Rectangle *area); ++ void focusFltkWidget (Fl_Widget *widget); + }; + + } // namespace fltk +diff -ur dillo-3.0.5.orig/dw/ui.cc dillo-3.0.5/dw/ui.cc +--- dillo-3.0.5.orig/dw/ui.cc 2015-06-30 16:06:09.000000000 +0200 ++++ dillo-3.0.5/dw/ui.cc 2023-03-18 12:41:55.403344022 +0100 +@@ -223,6 +223,10 @@ + { + } + ++void Resource::focus () ++{ ++} ++ + void Resource::emitEnter () + { + activateEmitter.emitEnter(this); +diff -ur dillo-3.0.5.orig/dw/ui.hh dillo-3.0.5/dw/ui.hh +--- dillo-3.0.5.orig/dw/ui.hh 2015-06-30 16:06:09.000000000 +0200 ++++ dillo-3.0.5/dw/ui.hh 2023-03-18 12:33:20.465828321 +0100 +@@ -347,6 +347,8 @@ + virtual bool isEnabled () = 0; + virtual void setEnabled (bool enabled) = 0; + ++ virtual void focus () = 0; ++ + inline void connectActivate (ActivateReceiver *receiver) { + activateEmitter.connectActivate (receiver); } + inline void connectClicked (ClickedReceiver *receiver) { +diff -ur dillo-3.0.5.orig/src/form.cc dillo-3.0.5/src/form.cc +--- dillo-3.0.5.orig/src/form.cc 2015-06-30 16:06:09.000000000 +0200 ++++ dillo-3.0.5/src/form.cc 2023-03-18 12:40:04.192424547 +0100 +@@ -431,7 +431,7 @@ + DilloHtmlInputType inp_type; + Resource *resource = NULL; + Embed *embed = NULL; +- char *value, *name, *type, *init_str, *placeholder = NULL; ++ char *value, *name, *type, *init_str, *placeholder = NULL, *autofocus; + const char *attrbuf, *label; + bool init_val = false; + ResourceFactory *factory; +@@ -451,6 +451,7 @@ + value = a_Html_get_attr_wdef(html, tag, tagsize, "value", NULL); + name = a_Html_get_attr_wdef(html, tag, tagsize, "name", NULL); + type = a_Html_get_attr_wdef(html, tag, tagsize, "type", ""); ++ autofocus = a_Html_get_attr_wdef(html, tag, tagsize, "autofocus", NULL); + + init_str = NULL; + inp_type = DILLO_HTML_INPUT_UNKNOWN; +@@ -541,6 +542,9 @@ + if (resource) + embed = new Embed (resource); + ++ if (resource && autofocus) ++ resource->focus(); ++ + if (inp_type != DILLO_HTML_INPUT_UNKNOWN) { + Html_add_input(html, inp_type, embed, name, + (init_str) ? init_str : "", init_val); + +```
\ No newline at end of file diff --git a/262/index.md b/262/index.md new file mode 100644 index 0000000..fa9f3fe --- /dev/null +++ b/262/index.md @@ -0,0 +1,104 @@ +Title: Configure uses `which` which is not POSIX compliant +Author: Kangie +Created: Tue, 01 Oct 2024 01:16:01 +0000 +State: closed + +## Issue + +``` +checking FLTK 1.3... yes +checking whether to link to X11... yes +checking for jpeglib.h... yes +checking for jpeg_destroy_decompress in -ljpeg... yes +checking for zlib.h... yes +checking for zlibVersion in -lz... yes +checking for libpng-config... ./configure: line 7202: which: command not found +./configure: line 7204: which: command not found +./configure: line 7207: which: command not found +``` + +`which` is not listed as a required command by POSIX and should be replaced by `command -v`. + +See also: https://bugs.gentoo.org/940568 + +## Reproducing + +Attempt to configure dillo on a machine without `which`. + +## Resolution + +Exorcise `which` from the codebase. + +Examples: + +https://github.com/dillo-browser/dillo/blob/4f303337cdf3d86b69918a137db19351cdbae581/autogen.sh#L18 + +https://github.com/dillo-browser/dillo/blob/4f303337cdf3d86b69918a137db19351cdbae581/configure.ac#L298-L313 + + +--%-- +From: Kangie +Date: Tue, 01 Oct 2024 01:19:19 +0000 + +Would you accept a PR that switched to the `meson` build system rather than patching autotools? + +It will prove to be more maintainable, will eliminate this issue entirely, and in terms of 'needs to run anywhere' there are [muon](https://github.com/muon-build/muon) and [samurai](https://github.com/michaelforney/samurai) which are C99 implementations of Meson and Ninja respectively. + +--%-- +From: Kangie +Date: Tue, 01 Oct 2024 01:21:29 +0000 + +Re: + +https://github.com/dillo-browser/dillo/blob/4f303337cdf3d86b69918a137db19351cdbae581/configure.ac#L298-L313 + +If autotools is to be retained this whole section (and the checks afterwards) could be trivially simplified to 'query pkg-config'. + +--%-- +From: rodarima +Date: Tue, 01 Oct 2024 17:08:23 +0000 + +I commented on the meson build in the PR. Let's keep this issue to solve *only* the problem of removing `which` to `command -v`, which should be fairly easy to do. + +We don't have a build dependency over `pkg-config`, so I don't think this particular problem needs to pull it. + +--%-- +From: eli-schwartz +Date: Tue, 01 Oct 2024 23:19:23 +0000 + +Instead of using `command -v`, there is preexisting code earlier in this file: +```m4 +AC_PATH_PROG(FLTK_CONFIG,fltk-config) +``` + +indicating the correct way to check for a program while respecting pre-set environment variables, is already known. + +> We don't have a build dependency over `pkg-config`, so I don't think this particular problem needs to pull it. + +"which" isn't the problem that is solved by using pkg-config. You still have to check for and find `pkg-config` as well. + +The problem that is solved by using pkg-config is the cross-compilation problem. :) There are plenty of other dependencies that can use the same treatment... openssl, zlib, jpeg... + +--%-- +From: eli-schwartz +Date: Tue, 01 Oct 2024 23:20:47 +0000 + +It's possible to check pkg-config first and fall back to foobar-config programs only when that fails. + +--%-- +From: rodarima +Date: Wed, 02 Oct 2024 05:15:08 +0000 + +> ...indicating the correct way to check for a program... + +The `which` command is not needed, so I prefer to switch to `command -v` which should be available in a POSIX shell. + +> The problem that is solved by using pkg-config is the cross-compilation problem + +Then I recommend you address it in another issue. I think this may also help #258 and #34. It would be nice to have a cross-compilation build in the CI, but I'm not sure if I know how to set it up. + +--%-- +From: rodarima +Date: Thu, 03 Oct 2024 19:43:02 +0000 + +Fixed in https://github.com/dillo-browser/dillo/commit/9880c1ba603a6080b2493c7c399ae36d656a9834
\ No newline at end of file diff --git a/263/index.md b/263/index.md new file mode 100644 index 0000000..04cb148 --- /dev/null +++ b/263/index.md @@ -0,0 +1,618 @@ +Title: Meson Build +Author: Kangie +Created: Tue, 01 Oct 2024 10:12:14 +0000 +State: open + +Hi Team, + +While logging #262 I had the thought that it ought to be relatively straightforward to port Dillo to Meson. + +I took a bit of time this afternoon and the result is an initial port. + +It builds and links without complaint, but it's currently not producing a "working" dillo - I've missed something with DNS that I'll come back to shortly. + +I know this wasn't specifically requested however I still think it's worthwhile: + +- It's possible to run a 'meson' build using [`muon`](https://github.com/muon-build/muon) and [`samurai`](https://github.com/michaelforney/samurai) which are C99 implementations of Meson and Ninja respectively. +- It's a lot smaller than automake + autoconf (coming in at just over half the lines of "code" to maintain, which could be reduced by adjusting the blind formatting rules I used) +- It's faster / more efficient + + `sh -c 'meson setup --wipe build ; ninja -C build' 18.87s user 7.74s system 958% cpu 2.777 total` + + `sh -c './configure && make -j' 33.55s user 4.55s system 550% cpu 6.917 total` +- It doesn't rely on `which` ;) + + + + + +I'll keep plugging away at this unless you're not interested until we can get it ready for release. + +Closes: #262 + +Cheers, + +Matt + +--%-- +From: rodarima +Date: Tue, 01 Oct 2024 17:03:28 +0000 + +Thanks for the PR and sorry for the late reply. + +Even if I hate autotools with all my heart, they are capable of producing a unreadable but dependency-free configure script that can run in (almost?) any POSIX-compliant machine, including very old ones. + +There are other issues with autotools too, which are mostly the reason I'll probably change the build system in the future, but I don't like the idea of adding python as a build dependency because of meson (or using the WIP muon). + +As FLTK has switched recently to cmake, and it is very likely that it has to be supported in every platform that we want to build Dillo on, we can asume that cmake is already available due to indirect build dependencies. So I will be inclined to choose it over meson, which should yield similar speeds when using ninja instead of make. + +In any case, I won't take this decision without making a study beforehand of the options, and see which one is more appropriate. Also consider the fact that I have already some knowledge on cmake, and almost none on meson. Regardless, this change will cause a major version bump, so it will not likely happen soon. + +Regarding the `which` problem, it should be a ~5 line patch, so I don't think it is a reason to change the build system (yet). The IWYU patch is also welcome. + +--%-- +From: Kangie +Date: Tue, 01 Oct 2024 22:01:02 +0000 + +> or using the WIP muon. + +Having recently done the fvwm3 meson port where Muon was a desired feature, I can say that the recent `0.3.0` release is effectively on-par with mainline Meson (so no hard Python req) + +> As FLTK has switched recently to cmake, and it is very likely that it has to be supported in every platform that we want to build Dillo on, we can asume that cmake is already available due to indirect build dependencies. So I will be inclined to choose it over meson, which should yield similar speeds when using ninja instead of make. + +CMake is "fine" however IMO Meson results in far more maintainable and readable build system code, and typically one obvious way to accomplish any given task rather than the ~5 ways that there are to do it in CMake (with no indication which is more appropriate for a given situation). + +Which platforms that we're building C++11 code on don't support C99 and/or Python anyway ;) + +With 99% of the porting done you shouldn't need to dig into the guts for quite a while. + +I may submit a patch for the `which` issue at some point; got to do actual work today. I will, however, get the Meson build to the point that the browser is actually functional at some point so that you can compare. + + + + + +--%-- +From: rodarima +Date: Wed, 02 Oct 2024 05:31:40 +0000 + +> With 99% of the porting done you shouldn't need to dig into the guts for quite a while. + +I need to understand very deeply the build system as to debug weird problems in all kinds of platforms I don't have access to, other than a mail/IRC channel with the person. So, totally the opposite. + +> I may submit a patch for the `which` issue at some point; got to do actual work today. + +Thanks, that would be nice. + +--%-- +From: Kangie +Date: Tue, 15 Oct 2024 00:08:35 +0000 + +Following up on this, it looks like it's (almost) all working: + + + +``` +build/src/dillo +paths: Cannot open file '/home/kangie/.dillo/dillorc': No such file or directory +paths: Cannot open file '/usr/local/etc/dillodillorc': No such file or directory +paths: Using internal defaults... +paths: Cannot open file '/home/kangie/.dillo/keysrc': No such file or directory +paths: Cannot open file '/usr/local/etc/dillokeysrc': No such file or directory +paths: Using internal defaults... +paths: Cannot open file '/home/kangie/.dillo/domainrc': No such file or directory +paths: Cannot open file '/usr/local/etc/dillodomainrc': No such file or directory +paths: Using internal defaults... +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.2 3 Sep 2024 +Disabling cookies. +paths: Cannot open file '/home/kangie/.dillo/hsts_preload': No such file or directory +paths: Cannot open file '/usr/local/etc/dillohsts_preload': No such file or directory +paths: Using internal defaults... +Nav_open_url: new url='about:splash' +Nav_open_url: new url='https://www.google.com' +Dns_server [0]: www.google.com is 142.250.67.4 2404:6800:4006:811::2004 +Connecting to 142.250.67.4:443 +www.google.com: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 256-bit EC: /CN=www.google.com +sha256 2048-bit RSA: /C=US/O=Google Trust Services/CN=WR2 +sha256 4096-bit RSA: /C=US/O=Google Trust Services LLC/CN=GTS Root R1 +root: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA +>>>> a_Nav_repush <<<< +Nav_open_url: new url='https://www.google.com' +a_Nav_expect_done: repush! +``` + +Not sure why the PNG isn't visible but that should be straightforward to fix, and the `etcdir` just needs a trailing slash. + + +--%-- +From: Kangie +Date: Tue, 15 Oct 2024 00:21:50 +0000 + +OK, making progress... I had HAVE_PNG not ENABLE_PNG. + +This is looking good: + + + +``` +aths: Cannot open file '/home/kangie/.dillo/dillorc': No such file or directory +paths: Cannot open file '/usr/local/etc/dillo/dillorc': No such file or directory +paths: Using internal defaults... +paths: Cannot open file '/home/kangie/.dillo/keysrc': No such file or directory +paths: Cannot open file '/usr/local/etc/dillo/keysrc': No such file or directory +paths: Using internal defaults... +paths: Cannot open file '/home/kangie/.dillo/domainrc': No such file or directory +paths: Cannot open file '/usr/local/etc/dillo/domainrc': No such file or directory +paths: Using internal defaults... +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.2 3 Sep 2024 +Disabling cookies. +paths: Cannot open file '/home/kangie/.dillo/hsts_preload': No such file or directory +paths: Cannot open file '/usr/local/etc/dillo/hsts_preload': No such file or directory +paths: Using internal defaults... +Nav_open_url: new url='about:splash' +Nav_open_url: new url='http://www.google.com' +Dns_server [0]: www.google.com is 142.251.221.68 2404:6800:4006:809::2004 +Connecting to 142.251.221.68:80 +>>>> a_Nav_repush <<<< +Nav_open_url: new url='http://www.google.com' +a_Nav_expect_done: repush! +``` + +--%-- +From: Kangie +Date: Tue, 15 Oct 2024 00:26:05 +0000 + +Sorry about the spam, but best to keep this commentary separate: + +> Regardless, this change will cause a major version bump, so it will not likely happen soon. + +There's little reason (aside from keeping autotools in the repo...) not to include the meson build files alongside autotools for a transitional period, then you are able to deprecate autotools and remove it at a time of your choosing with the confidence that it's not going to suddenly cause downstream issues. + +--%-- +From: Kangie +Date: Tue, 15 Oct 2024 22:52:14 +0000 + +@rodarima + +Thoughts? I'm having a bit of trouble with the HTML tests in CI (frankly I can barely get them to run on Gentoo at the best of times) but otherwise we have a working browser and test suite. + +~Cygwin is unfortunate, but it was building and passing tests before I set the required meson version to _just_ above what is currenly packaged. Theoretically pip will work, just pushed that change; can follow up and request a slightly newer meson be packaged.~ + +--%-- +From: rodarima +Date: Wed, 16 Oct 2024 17:16:00 +0000 + +I'm not sure what problem you are trying to solve here, but I see you are putting a lot of effort into something we have not requested or encouraged. There are plenty of issues here that I would like someone to help with: https://github.com/dillo-browser/dillo/issues + +Autoconf/autotools is doing an acceptable job as build system. It is slow but that shouldn't be a big problem when Dillo is mainly targeted towards slow machines where the bottleneck is the build (not the scheduling of the build). Saving some seconds in the build process is not very relevant when we can produce a portable tarball release. + +I have a limited time to spend on the project, so I will prioritize not changing the build system or choosing one that I'm familiar with, rather than learning a new one. I will not maintain two build systems, when we switch (if we do) we will remove autotools. + +Keep in mind that we can only test a very limited amount of (modern) platforms right now, and I will not try to switch the build system until I have determined which platforms we decide to break and which ones to continue to support. Before that point, I would like to have improved the CI so we also test Dillo on older hardware. Until that happens, I will not change the build system. + +I think this PR may be useful to compare with cmake or others in the future (I have saved the patch), but from the knowledge I have right now it is very unlikely that we end up switching to meson/muon. + +Fixes for includes would be nice to merge on their own. + +I know there are current problems with the current build system. For example, we don't support cross-compilation, mainly by the way we query FLTK and other flags, but that can also be fixed independetly without changing the build system. + +> I'm having a bit of trouble with the HTML tests in CI (frankly I can barely get them to run on Gentoo at the best of times) + +The HTML test suite is not designed to run by non-developers, the same way I don't expect you to pass the WPT tests when packaging Firefox or Chromium. But essentially, we open the test page on dillo in a virtual X server and take a snapshot, then we do the same with a reference page and we compare the pixels one by one. The two images are saved, so you may be able to see what went wrong. Also, those tests require a vanilla dillorc and style.css, otherwise you will likely break them. If they continue to break, please address it in a new issue, as they shouldn't break. + +--%-- +From: Kangie +Date: Wed, 16 Oct 2024 23:06:57 +0000 + +> but I see you are putting a lot of effort into something we have not requested or encouraged + +Making the world a better place is its own reward. + +Additionally, as a downstream packager/maintainer it ended up being more effective to _rewrite the whole build system_ than deal with the mess that is the existing autotools impl. I also really don't want to deal with more downstream tickets or additional porting work due to the (at best, charitably described as) legacy way in which the current Autotools implementation does things. + +> There are plenty of issues here that I would like someone to help with: https://github.com/dillo-browser/dillo/issues + +I would be more inclined to help if I didn't have to deal with a poor autotools impl, and I'm not inclined to fix autotools when the work on meson is _already done_. + +> so I will prioritize not changing the build system or choosing one that I'm familiar with, rather than learning a new one. I will not maintain two build systems, when we switch (if we do) we will remove autotools. + +As the current maintainer of Dillo, that's your prerogative. I can point at other examples where projects aimed at low spec / older machines and which value portability have gone with precisely this approach, and picked Meson. + +> I will not try to switch the build system until I have determined which platforms we decide to break and which ones to continue to support + +As a C++ project you can assume that C99 compilers will be available to provide `muon` and `samurai` to substitute for `meson` and `ninja` respectively on platforms that don't have (or want) a Python dependency. + +If your platforms need C++11 and don't support C99 that is, honestly, their problem. Users can always continue to use an older tarball - who actually updates these legacy systems you're concerned about frequently, and isn't likely to just grab an older tarball? + +> I know there are current problems with the current build system. For example, we don't support cross-compilation, mainly by the way we query FLTK and other flags, but that can also be fixed independetly without changing the build system. + +The TL;DR is that I've already done _all of the work for you_ on each of the issues that you've just listed. + +If you want to throw that away because you already have "some knowledge" of cmake that is, of course, your choice. + +Having already admitted that you already have limited time to work on this project, and with volunteers submitting fixes for deficiencies in the existing build system that you are aware of, it really seems like you're shooting yourself in the foot by not considering this. + +> Saving some seconds in the build process is not very relevant when we can produce a portable tarball release. + +Saving time in CI/downstream delivers on measurable benefits to both energy consumption and to the people that have to actually verify their own bulids. + +Additionally the reduced complexity of Meson (and the use of a matrix to provide better CI/CD coverage in a concise manner) lends itself to a more maintainable build system going forward. How many autotools issues have not been fixed because it's terrible spaghetti that's too hard to parse? + +> Fixes for includes would be nice to merge on their own. + +`git cherry-pick ...` + +> The HTML test suite is not designed to run by non-developers + +Conveniently I, as a downstream packager, _do_ want to know that my package behaves as expected before pushing it out to my users. + +> If they continue to break, please address it in a new issue, as they shouldn't break. + +I'm really not inclined to touch anything to do with autotools in _my_ limited time for this project. + +--%-- +From: rodarima +Date: Thu, 17 Oct 2024 17:57:09 +0000 + +> The TL;DR is that I've already done all of the work for you on each of the issues that you've just listed. + +This is far from the reality. + +You have done a fair amount of work to help yourself avoid dealing with autotools (which is understandable) but you have not really considered the implications of this change for the project and other users. + +The expensive part of the work is not porting this to a new build system, but maintaining it over the years and identifying issues reported by users from other platforms I don't have access to. + +You have continued to work on this on your own, even if I have already explained to you that I will evaluate this in the future not now. I cannot stop you from spending your own time into whatever it is you what to spend it. + +Your current solution continues to rely on the `fltk-config` binary, which won't work for cross compilation, which is one of the main issues I want to solve when switching the build system. I prioritized cmake because they can read the information from the .cmake module of FLTK directly: + +https://cmake.org/cmake/help/latest/module/FindFLTK.html +https://github.com/Kitware/CMake/blob/fa61269d8e6e75448437cf9071cde97ecb35e054/Modules/FindFLTK.cmake#L163-L207 + +> If you want to throw that away because you already have "some knowledge" of cmake that is, of course, your choice. + +> As the current maintainer of Dillo, that's your prerogative + +> git cherry-pick ... + +The hostile behavior is not helping. I suggest you consider how you what to approach the FOSS comunity. + +> Conveniently I, as a downstream packager, do want to know that my package behaves as expected before pushing it out to my users. + +And I, as the person who wrote the test infrastructure as well as those tests, I'm telling you that they are not designed for you to run as packager. They are designed to avoid introducing regressions in the layout engine. Same with RTFL, which I have no idea why you enabled it under the "debug" flag. + +If you still insist into running them, I recommend you read the output logs to see what is wrong rather than blaming autotools: + +https://933451.bugs.gentoo.org/attachment.cgi?id=894972 + +``` ++ xwd -id 0x200009 -silent ++ convert xwd:- png:white-space.html_x8y/html.png +client(400000): Reserved pid(931). +client(400000): Reserved cmdname(xwd) and cmdargs(-id 0x200009 -silent). +AllocNewConnection: client index = 2, socket fd = 8, local = 1 +convert: unable to open image 'xwd:-': No such file or directory @ error/blob.c/OpenBlob/3571. +``` + +Your convert(1) program doesn't understand `xwd:-` for some reason. We may be able to place it in a temporary directory instead of using a pipe, not sure what is causing this problem on your end (maybe a config switch on convert). + +I really don't have any interest in pursuing this discussion futher, as I want to focus on the next 3.2.0 release. I understand your position, and I will come back to reevaluate this in the future, hopefully when we have some more exotic machines to test a build system on. + +--%-- +From: Kangie +Date: Fri, 18 Oct 2024 01:34:56 +0000 + +> You have continued to work on this on your own, even if I have already explained to you that I will evaluate this in the future not now + +You need a working (or mostly-working) PR to evaluate; the initial state was 'it builds'. The current PR is mostly feature-complete, however obviously the HTML tests aren't running properly in CI (likely down to how the script is invoked via meson), and some of the more debug-y options are not yet implemented (`efence`, `gprof`, `insure`) - That should be enough for you to decide whether or not you want to proceed further down this path. + +**edit**: HTML tests actually appear to be working locally, but never returning properly - the test output appears to show expected tests and failures but Meson's test harness isn't happy and if the timeout is disabled the tests "run" indefinitely - I'll look into the test script at some point, maybe. + +**Edit 2**: First HTML test terminated successfully without intervention in just over an hour so they will eventually complete. + +**Edit 3**: After remembering to install Dillo into a prefix I'm able to successfully run the HTML rendering tests via meson (using the binary in `builddir/src`) locally. Oops. I suspect that the missing files may have been the cause of the hanging tests. There are a number that now actually fail based on the image comparison; I'll look into the html - I didn't have everything enabled in terms of image formats and that's a likely culprit. + +> Your current solution continues to rely on the `fltk-config` binary, which won't work for cross compilation, which is one of the main issues I want to solve when switching the build system. I prioritized cmake because they can read the information from the .cmake module of FLTK directly: +> +> https://cmake.org/cmake/help/latest/module/FindFLTK.html https://github.com/Kitware/CMake/blob/fa61269d8e6e75448437cf9071cde97ecb35e054/Modules/FindFLTK.cmake#L163-L207 + +Thanks for the pointer, I'd assumed that was coming with upstream's port to CMake that you mentioned; I've pushed a commit that will use this to detect FLTK (which I'll rebase and squash at some point soon); turns out it needed `FLTK` not `fltk`. I suspect that it's going to fall back to `fltk-config` a lot of the time anyway; upstream probably still need to ship a pkgconfig file. This will likely be true regardless of build system. + +> > If you want to throw that away because you already have "some knowledge" of cmake that is, of course, your choice. +> +> > As the current maintainer of Dillo, that's your prerogative +> +> > git cherry-pick ... +> +> The hostile behavior is not helping. I suggest you consider how you what to approach the FOSS comunity. + +I'm sorry that you feel that this is hostile, there has been some miscommunication; It's your project, it's your choice whether or not you accept offered help - I'm not going to be bitter if you go with CMake (though if you hit the '5 ways to do something with no obvious best option' I may drop-in for an 'I told you so'). + +On my part I'm a bit of a build system buff who has worked on / ported multiple projects, and I have seen many poor CMake implementations in-the-wild: I regularly work on Autotools, CMake, GN, Meson, and hand-rolled scientific computing Makefiles. + +I'm also involved in upstream fixes to many packages that I maintain; I'd consider your examples to be 'direct' or 'blunt' communication but I'll take it under consideration. + +I'm not likely to submit additional PRs for the trivial fixes, please feel free to cherry pick them; I'll sort out any conflicts when I rebase. + +As a real carrot for a proper build system, tools like [`include-what-you-use`](https://github.com/include-what-you-use/include-what-you-use) will make identifying future instances of this trivial and comes "free" with CMake or Meson. + +> Same with RTFL, which I have no idea why you enabled it under the "debug" flag. + +This: + +https://github.com/dillo-browser/dillo/blob/572b9346d5d844822b1a0cc1f22e15fb898135b4/configure.ac#L74-L75 + +`debug` seems more appropriate than `rtfl` based on the comment, and enabling `-Ddebug` seems like something no reasonable person would use in anger in the real-world. When it comes time to evaluate, and if you decide to proceed, please ping me with any desired changes, this is a first-pass 'port autotools effectively as-is', not a final state. + +> Your convert(1) program doesn't understand `xwd:-` for some reason. We may be able to place it in a temporary directory instead of using a pipe, not sure what is causing this problem on your end (maybe a config switch on convert). + +Appreciate the pointer; I've pushed a commit to include the missing X11 dependencies on ImageMagick. + +> I want to focus on the next 3.2.0 release. I understand your position, and I will come back to reevaluate this in the future, hopefully when we have some more exotic machines to test a build system on. + +Evaluate at your leisure, please don't think I was implying that this should replace the build system for your upcoming release. As downstream packager I would _love_ to see any replacement for Autotools considered at some point after that. + +As a final note I would like you to consider running Autotools and Meson (or CMake) side-by-side for a transition period - we can add a `-Dexperimental` flag a la `freeciv` to indicate to users that it's not the 'default' build path (and make them explicitly opt-in) and we can roadmap the deprecation - this should enable users with those exotic systems to provide feedback well before the legacy build is in any danger of being removed. The updated matrix CI should make maintaining them side-by-side far easier :) + +--%-- +From: Kangie +Date: Thu, 30 Jan 2025 02:30:25 +0000 + +Rebased on current master, tidied up commit history and squashed meson commits down for comparison with #333 + +Builds fine, runs fine. Tests are running successfully but timing out - I can dig into that if further development is welcome. CI updated to use matrices to test as many options as possible, but not tested post merge; I expect failures here. + +I suspect the remaining issues to be tidied up are to do meson not successfully interpreting the test driver exiting, as my test logs show the diff coming back as `0 = 0`. + +``` +==================================== 9/44 ==================================== +test: b-div +start time: 02:13:40 +duration: 30.00s +result: exit status 0 +command: MESON_TEST_ITERATION=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=126 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 DILLOBIN=/data/development/temp/dillo/build/src/dillo /data/development/temp/dillo/test/html/driver.sh /data/development/temp/dillo/test/html/render/b-div.html +----------------------------------- stdout ----------------------------------- +paths: Cannot open file '/home/kangie/.dillo/dillorc': No such file or directory +paths: Cannot open file '/tmp/dillo/etc/dillo/dillorc': No such file or directory +paths: Using internal defaults... +paths: Cannot open file '/home/kangie/.dillo/keysrc': No such file or directory +paths: Cannot open file '/tmp/dillo/etc/dillo/keysrc': No such file or directory +paths: Using internal defaults... +paths: Cannot open file '/home/kangie/.dillo/domainrc': No such file or directory +paths: Cannot open file '/tmp/dillo/etc/dillo/domainrc': No such file or directory +paths: Using internal defaults... +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.2 3 Sep 2024 +Disabling cookies. +paths: Cannot open file '/home/kangie/.dillo/hsts_preload': No such file or directory +paths: Cannot open file '/tmp/dillo/etc/dillo/hsts_preload': No such file or directory +paths: Using internal defaults... +Nav_open_url: new url='file:/data/development/temp/dillo/test/html/render/b-div.html' +** ERROR **: [Dpi_read_comm_keys] No such file or directory +Dpi_blocking_start_dpid: try 1 +paths: Cannot open file '/home/kangie/.dillo/dillorc': No such file or directory +paths: Cannot open file '/tmp/dillo/etc/dillo/dillorc': No such file or directory +paths: Using internal defaults... +paths: Cannot open file '/home/kangie/.dillo/keysrc': No such file or directory +paths: Cannot open file '/tmp/dillo/etc/dillo/keysrc': No such file or directory +paths: Using internal defaults... +paths: Cannot open file '/home/kangie/.dillo/domainrc': No such file or directory +paths: Cannot open file '/tmp/dillo/etc/dillo/domainrc': No such file or directory +paths: Using internal defaults... +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.2 3 Sep 2024 +Disabling cookies. +paths: Cannot open file '/home/kangie/.dillo/hsts_preload': No such file or directory +paths: Cannot open file '/tmp/dillo/etc/dillo/hsts_preload': No such file or directory +paths: Using internal defaults... +Nav_open_url: new url='file:/data/development/temp/dillo/test/html/render/b-div.ref.html' +OK +----------------------------------- stderr ----------------------------------- ++ DILLOBIN=/data/development/temp/dillo/build/src/dillo ++ '[' '!' -e /data/development/temp/dillo/build/src/dillo ']' ++ magick_bin=convert ++ command -v magick ++ magick_bin=magick ++ test_file /data/development/temp/dillo/test/html/render/b-div.html ++ html_file=/data/development/temp/dillo/test/html/render/b-div.html ++ '[' '!' -e /data/development/temp/dillo/test/html/render/b-div.html ']' ++ ref_file=/data/development/temp/dillo/test/html/render/b-div.ref.html ++ '[' '!' -e /data/development/temp/dillo/test/html/render/b-div.ref.html ']' +++ basename /data/development/temp/dillo/test/html/render/b-div.html ++ test_name=b-div.html ++ wdir=b-div.html_wdir ++ rm -rf b-div.html_wdir ++ mkdir -p b-div.html_wdir ++ mkfifo b-div.html_wdir/display.fifo ++ exec ++ xorgpid=999693 ++ trap 'kill 999693' EXIT ++ read dispnum ++ Xvfb -screen 5 1024x768x24 -displayfd 6 +_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed +_XSERVTransMakeAllCOTSServerListeners: server already running +_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed +_XSERVTransMakeAllCOTSServerListeners: server already running ++ export DISPLAY=:2 ++ DISPLAY=:2 ++ render_page /data/development/temp/dillo/test/html/render/b-div.html b-div.html_wdir/html.png ++ htmlfile=/data/development/temp/dillo/test/html/render/b-div.html ++ outpic=b-div.html_wdir/html.png ++ dillopid=999706 ++ sleep 1 ++ /data/development/temp/dillo/build/src/dillo -f /data/development/temp/dillo/test/html/render/b-div.html +++ xwininfo -all -root +++ awk '/Dillo:/ {print $1}' ++ winid=0x200009 ++ '[' -z 0x200009 ']' ++ xwd -id 0x200009 -silent ++ magick xwd:- png:b-div.html_wdir/html.png ++ kill 999706 ++ render_page /data/development/temp/dillo/test/html/render/b-div.ref.html b-div.html_wdir/ref.png ++ htmlfile=/data/development/temp/dillo/test/html/render/b-div.ref.html ++ outpic=b-div.html_wdir/ref.png ++ dillopid=999771 ++ sleep 1 ++ /data/development/temp/dillo/build/src/dillo -f /data/development/temp/dillo/test/html/render/b-div.ref.html +++ xwininfo -all -root +++ awk '/Dillo:/ {print $1}' ++ winid=0x200009 ++ '[' -z 0x200009 ']' ++ xwd -id 0x200009 -silent ++ magick xwd:- png:b-div.html_wdir/ref.png ++ kill 999771 +++ compare -metric AE b-div.html_wdir/html.png b-div.html_wdir/ref.png b-div.html_wdir/diff.png ++ diffcount=0 ++ '[' 0 = 0 ']' ++ echo OK ++ ret=0 ++ exec ++ rm b-div.html_wdir/display.fifo ++ '[' -z '' ']' ++ rm -rf b-div.html_wdir ++ return 0 ++ exit 0 ++ kill 999693 +============================================================================== +``` + +--%-- +From: Kangie +Date: Thu, 30 Jan 2025 02:31:04 +0000 + +It's probably worth, at the very least, cherry-picking the IWYU fixes. + +--%-- +From: Kangie +Date: Thu, 30 Jan 2025 04:27:03 +0000 + +Tracked down hanging tests to the exit trap. + +If there's willingness to consider merging this I'm happy to tidy up the CI and look into test failures, but otherwise the port is "done", and is up-to-date with current master. + +--%-- +From: Sunny-Maxis +Date: Sat, 01 Mar 2025 21:23:06 +0000 + +Comment for Rodrigo: + +Do not adopt meson if you plan to support old UNIXes. Muon, the C99 Meson, is unfortunately poorly coded with poor support for aligned access on RISC systems and numerous problems (My main critique being, who peppers a setup with hundreds of asserts in a DEFAULT BUILD?), and boson, the C11 version, is poorly maintained. + +Out of all options, autotools is preferable, but CMake is workable. I understand as you are moving to C++11 that GCC moreorless will become the sole compiler, but dillo never properly built on anything else. + +I do not want to hurt Kengie's feelings or upset their effort, it's just, Meson is not an acceptable system for this project. CMake has additionally decent Windows support, if MS windows support is a priority. + +--%-- +From: eli-schwartz +Date: Sun, 02 Mar 2025 02:25:34 +0000 + +I hope you don't plan on compiling CMake on systems without a C++ (11) compiler. + +--%-- +From: Sunny-Maxis +Date: Sun, 02 Mar 2025 05:24:37 +0000 + +> I hope you don't plan on compiling CMake on systems without a C++ (11) compiler. + +Building a build tool with GCC is different than building a program with a native compiler. + +There's hassles and problems with building GCC for everything on niche platforms. On IRIX, for instance, GCC cannot be effectively debugged even with restored GCC support from Kazuo K. or the SGUG GCC, the gdb system on IRIX can't debug threads, stack traces are funky. dbx expects dwarf of a certain kind. On Itanium and PA-RISC, GCC's C++ performance compared to HPE's is baaad. It's a bit better there, you got several compilers to choose from depending on OS (ICC, aCC, Pro64) but yeah, I think ya get my point. + +Regardless, I was offering my input. Dillo is a useful browser and you gotta get with the times, Cmake being a necessity is what it is. Meson and Muon are not acceptable IMHO for projects that target older systems. + +--%-- +From: rodarima +Date: Sun, 02 Mar 2025 13:55:29 +0000 + +> Meson and Muon are not acceptable IMHO for projects that target older systems. + +I also suspect the same, but I will need to do more research to be sure. This is not a priority now, so I will take some time to address other issues first. I recommend not investing more time in this PR until that is clarified on my side, otherwise you risk wasting your time. + +> I hope you don't plan on compiling CMake on systems without a C++ (11) compiler. + +We try to target 20+ year old stacks, including older gcc with no support for C++11 as we only need variadic macros from C++11 which are available in much older compilers. There is no public announcement about what we support and what not because is not an easy task to even measure (I don't have access to many of the old systems that claim to run Dillo). + +I won't change the build system until I have researched all platforms in which Dillo works currently and how it will be affected. And I would rather not maintain two build systems. + +If you @Sunny-Maxis want to help improving the support on IRIX that would be nice to have. Feel free to open another issue to track the current status and what we can do to improve it. + +--%-- +From: eli-schwartz +Date: Sun, 02 Mar 2025 16:28:32 +0000 + +> We try to target 20+ year old stacks, including older gcc with no support for C++11 as we only need variadic macros from C++11 which are available in much older compilers. There is no public announcement about what we support and what not because is not an easy task to even measure (I don't have access to many of the old systems that claim to run Dillo). + +CMake, when compiling itself, searches for a C++17 compiler, or a C++14 compiler, or a C++11 compiler, and if it cannot at least find a C++11 compiler it errors out with this code: + +```cmake + if(NOT CMake_HAVE_CXX_UNIQUE_PTR) + message(FATAL_ERROR "The C++ compiler does not support C++11 (e.g. std::unique_ptr).") + endif() +``` + +So I don't think you can use cmake if you target 20+ year old stacks. + +Meson can in theory run on any system with a c99 compiler, though it may require either: +- python (the entire programming language -- python 3.10 is written in c99, python 3.11 moved to c11, meson supports python 3.7) +- or muon (a relatively lean codebase implementing a standalone version of meson in c99) + +to be ported to that system, possibly a much easier task than porting a C++ compiler. + +According to https://github.com/muon-build/muon/issues/115 + +> Muon would benefit IRIX because Python is terrible on our platform for speed and performance. + +which indicates that python does *work*? + +Muon is definitely willing to accept patches, but it was made clear that IRIX in particular cannot be emulated, and uses a different MIPS ABI than other OSes running on MIPS, and @Sunny-Maxis decided it was too painful to debug (interesting assessment) so idk what to tell you. I am not convinced that experience is generally applicable to older systems. + +I suppose you could argue that the only option is to continue with autotools... + +--%-- +From: rodarima +Date: Sun, 02 Mar 2025 19:08:38 +0000 + +> I suppose you could argue that the only option is to continue with autotools... + +For very old platforms it probably is the best tradeoff for now, but it slows down development on relatively modern ones. However the current issues I have with autotools are probably fixable with enough perseverance. + +--%-- +From: Sunny-Maxis +Date: Mon, 03 Mar 2025 07:08:06 +0000 + +> If you @Sunny-Maxis want to help improving the support on IRIX that would be nice to have. Feel free to open another issue to track the current status and what we can do to improve it. + +I will definitely give it a shot when I'm at that point. It's going to be a hot minute more than likely because we are trying to get other stuff out of the way. + + +> So I don't think you can use cmake if you target 20+ year old stacks. + +This is a fair assessment. However I can get a version of Cmake running on IRIX (3.8 or so) using a somewhat recent version of GCC without dealing with libuv, and people have gotten a later version of it running using their own tool chains. + +That is to say he could simply stick with an older version of Cmake as a minimum required version. + +> which indicates that python does _work_? +Python does work but Meson presumably will continue to roll forward with more and more stringent system requirements that spells bad news for such a project where you're trying to maintain support for obsolete platforms. + +It's extremely painful to use meson on a system like IRIX. Unless you're cross compiling which I am not able to do with our setup because we are trying to use the native compiler whenever possible, and because my boss is of the opinion that cross compiling is not necessary on this particular system. +> Muon is definitely willing to accept patches, but it was made clear that IRIX in particular cannot be emulated, and uses a different MIPS ABI than other OSes running on MIPS, and @Sunny-Maxis decided it was too painful to debug (interesting assessment) so idk what to tell you. I am not convinced that experience is generally applicable to older systems. + +This is somewhat out of the scope for this discussion but I will briefly elaborate: + +1. It was crashing no matter which compiler are used even before initialization. Manually disabling the asserts that were used in the code in the range of almost 200 was possible to get it further but it ended up failing well before it actually did anything useful. Asserts are a great tool for debugging but I was repeatedly informed throughout the thread that removing them was not supported / they kept on telling me I was doing it wrong which I didn't appreciate. That was severely condescending. + + +2. They couldn't answer basic aligned access questions which I suspected was the ultimate issue because you would once you got past the assert bull end up with bus errors which usually means stack alignment issues. + +3. They kept on insisting it was a problem with the compiler which was complete bull crap. We have compiled dozens of programs without problems using both compilers and it was just not productive use of our time anymore. + +4. For the most part when something requires meson/ninja we just use an older release or in some cases my boss has ported applications to new build systems and given the finger to the person who thought it was an educated idea to lock out older systems on a relatively portable application otherwise. + +> I suppose you could argue that the only option is to continue with autotools... + +This is what I would recommend based on what's being said here. If you're going to Target windows as a platform at all honestly you should just tell people that they should have to fork and track the project separately with Ms build or something. The windows and UNIX universes are just not compatible on several levels. + +Regardless it's much easier to port GCC to a platform or reinstate support even, then to sometimes deal with poor upstream support or crap code. Sometimes dealing with projects like Muon, which I'm not saying was intentional on their part, feels like pulling teeth and I don't appreciate the way I was lectured on several occasions and told to just throw printf's everywhere. + +Rodrigo you'll be hearing from me when I do have something to show on dillo for IRIX. That'll probably be sometime in the next 3 to 4 months or so. That may not be that far off though that's just a rough estimate.
\ No newline at end of file diff --git a/264/index.md b/264/index.md new file mode 100644 index 0000000..e5d1886 --- /dev/null +++ b/264/index.md @@ -0,0 +1,8 @@ +Title: Add support for more CSS units +Author: rodarima +Created: Wed, 02 Oct 2024 17:43:58 +0000 +State: closed + +Add support for more CSS units and changes the parser representation to a struct, so we don't need to eat more bits from the unit values. + +Closes #48 and #174
\ No newline at end of file diff --git a/265/index.md b/265/index.md new file mode 100644 index 0000000..8b12dbe --- /dev/null +++ b/265/index.md @@ -0,0 +1,45 @@ +Title: use command -v instead of which +Author: ghost +Created: Thu, 03 Oct 2024 11:03:08 +0000 +State: closed + +Makes the build POSIX compliant by not using 'which' + +--%-- +From: ghost +Date: Thu, 03 Oct 2024 11:10:12 +0000 + +@Kangie @eli-schwartz +This should fix the issue with 'which' + +--%-- +From: rodarima +Date: Thu, 03 Oct 2024 19:38:49 +0000 + +Thanks Alex. Merging with capitalized "Use" in the commit message. + +--%-- +From: rodarima +Date: Thu, 03 Oct 2024 19:41:42 +0000 + +Merged here: https://github.com/dillo-browser/dillo/commit/9880c1ba603a6080b2493c7c399ae36d656a9834 + +--%-- +From: eli-schwartz +Date: Sun, 06 Oct 2024 00:35:34 +0000 + +> @Kangie @eli-schwartz This should fix the issue with 'which' + +I had pointed out in the associated issue that this isn't really the correct fix, but oh well. :) + +--%-- +From: rodarima +Date: Sun, 06 Oct 2024 08:24:39 +0000 + +> I had pointed out in the associated issue that this isn't really the correct fix, but oh well. :) + +The issue #262 states that the problem is that the configure uses which(1), which is not posix compliant and there is no dependency documented anywhere. Using `command -v` makes the configure process posix compliant, so it is one correct solution to the problem. + +Additionally, it makes Dillo remove the dependency over which(1), so that is a bonus. + +I'm aware of AC_PATH_PROG to search for programs, just it is not needed for this particular case.
\ No newline at end of file diff --git a/266/index.md b/266/index.md new file mode 100644 index 0000000..a968ab7 --- /dev/null +++ b/266/index.md @@ -0,0 +1,12 @@ +Title: Add doc/install.md to release +Author: ghost +Created: Fri, 04 Oct 2024 13:42:31 +0000 +State: closed + +This should fix [https://github.com/dillo-browser/dillo/issues/257](url) + +--%-- +From: rodarima +Date: Sat, 05 Oct 2024 07:40:18 +0000 + +Thanks!
\ No newline at end of file diff --git a/267/index.md b/267/index.md new file mode 100644 index 0000000..6db5629 --- /dev/null +++ b/267/index.md @@ -0,0 +1,10 @@ +Title: Test the C++ compiler works +Author: rodarima +Created: Sat, 05 Oct 2024 17:25:16 +0000 +State: closed + +Stops the configure process if the C++ compiler doesn't work, otherwise it will fail at build time. + +Fixes: https://github.com/dillo-browser/dillo/issues/187 + +CC @xlex8
\ No newline at end of file diff --git a/268/index.md b/268/index.md new file mode 100644 index 0000000..dc6a78a --- /dev/null +++ b/268/index.md @@ -0,0 +1,22 @@ +Title: Navigation by pages +Author: rodarima +Created: Sun, 06 Oct 2024 09:23:04 +0000 +State: open + +The mouse wheel has become the main input method to read documents on the Web, which causes pages to scroll by small increments, often causing a spike of compute resources to keep the framerate high. + +We still have "next page" and "previous page" shortcuts, but they cut the text at arbitrary positions. Dillo leaves a scroll step margin to avoid missing content, but this is not a very good solution. + +On the other hand, ebook readers have a mechanism to paginate books and present them so that they fill a page, leaving margins all around. + +I think it may be possible to use the same technique to render websites, so that we select a number of whole lines of text that fits in the page, including margins at the top and bottom, and then we cut the page there. This is essentially what "modern" browsers do nowadays when you try to print a page. They never cut a line in half. + +If we are able to support such mechanism, maybe we can revert the spread of the mouse wheel and let the eyes rest from tracking the page moving around, as well as the CPU/GPU. It may also appear faster, as the next page will load immediately, rather than you having to wait until you slowly scroll to the next "page". + +--%-- +From: rodarima +Date: Sat, 12 Oct 2024 16:21:32 +0000 + +We may want to add another scroll mode in which we use the right and left mouse button to move to the next and previous page, respectively, regardless of at which side of the thumb the pointer has clicked. This is useful to focus on the text itself while leaving the mouse resting, and only click (ignoring the thumb location) to advance. The current problem now is that once the thumb reaches the mouse position, it won't continue to advance pages. It also makes moving to the previous page much easier. + +The fast scrolling can still be implemented by detecting dragging. In fact we can potentially detect dragging at any position of the scrollbar, not only from the thumb, which would help if you are in a very long page and the thumb is very small.
\ No newline at end of file diff --git a/269/index.md b/269/index.md new file mode 100644 index 0000000..60b86fd --- /dev/null +++ b/269/index.md @@ -0,0 +1,34 @@ +Title: Improve default style readability +Author: rodarima +Created: Sun, 06 Oct 2024 10:42:32 +0000 +State: open + +Until `margin:auto` is supported, we have a lot of pages showing text glued to the Dillo window. Disabling CSS styles cause the default body margin of 5px to take effect. This margin is too small for computer screens, which is the default target. + +It can be overrided by user styles `~/.dillo/style.css`, but we should select a reasonable default. + +Here is an example where this happens: https://washbear.neocities.org/browsers + +And this is how it looks with CSS disabled and the margin increased to 2.5em: + + + +Similarly, we may want to increase the default font size and the line height. + +Here is the recommended style for HTML4 CSS2: https://drafts.csswg.org/css2/#html-stylesheet + +Also: https://html.spec.whatwg.org/multipage/rendering.html + +--%-- +From: rodarima +Date: Sun, 06 Oct 2024 10:56:21 +0000 + +Hmm, I see that increasing the default margin breaks too many websites. Probably it is only okay to make it 8 or 10 px. + +--%-- +From: rodarima +Date: Sun, 06 Oct 2024 11:06:03 +0000 + +The default background color #dcd1ba is also too dark by default. The idea that we should not use too bright colors is good, but I don't think it should be addressed at the browser level by default, as there are tools that dimm bright colors on the whole system. + +The spec recommend the canvas to be white by default, so I think it would be expected to switch it. Of course users can choose any other value in the config.
\ No newline at end of file diff --git a/27/index.md b/27/index.md new file mode 100644 index 0000000..c12c444 --- /dev/null +++ b/27/index.md @@ -0,0 +1,10 @@ +Title: Add support for OpenSSL, mbedTLS 2 and mbedTLS 3 +Author: rodarima +Created: Fri, 22 Dec 2023 19:57:16 +0000 +State: closed + +Fixes #20 + +The `--enable-ssl` flag is renamed to `--enable-tls`. + +Support for TLS (https) is now enabled by default unless explicitly disabled with `--disable-tls`.
\ No newline at end of file diff --git a/270/index.md b/270/index.md new file mode 100644 index 0000000..3823ea9 --- /dev/null +++ b/270/index.md @@ -0,0 +1,8 @@ +Title: Remove border from images with href +Author: rodarima +Created: Mon, 07 Oct 2024 20:03:29 +0000 +State: closed + +Rationale: + + diff --git a/271/index.md b/271/index.md new file mode 100644 index 0000000..e48b96b --- /dev/null +++ b/271/index.md @@ -0,0 +1,8 @@ +Title: Protect the user against massive image loading +Author: rodarima +Created: Mon, 07 Oct 2024 20:31:15 +0000 +State: open + +Some news websites have a massive number of images, which are usually designed to be rendered at a reasonable size. However, a failure in parsing some of the constraints in the CSS rules may cause all images to render at a much higher size than intended. This situation causes a spike in CPU and memory usage which may fill all available memory. As a concrete example, in my computer it reaches 1 GiB of memory usage opening a single news page. + +We should by default protect the user against this problem (but let them remove the restriction if desired). One option may be to cap the maximum image cache per page, so we stop loading more images if we already reached the limit.
\ No newline at end of file diff --git a/272/index.md b/272/index.md new file mode 100644 index 0000000..c68fded --- /dev/null +++ b/272/index.md @@ -0,0 +1,12 @@ +Title: About dillo’s .zip archive ... +Author: ioc2e3 +Created: Fri, 11 Oct 2024 19:46:43 +0000 +State: closed + +Here ( https://github.com/dillo-browser/dillo/releases ) … + +Why after decompressing dillo's .zip file ... + +There is no thing as dillo.exe ? + +.
\ No newline at end of file diff --git a/273/index.md b/273/index.md new file mode 100644 index 0000000..31d2dc0 --- /dev/null +++ b/273/index.md @@ -0,0 +1,12 @@ +Title: Add support for left scrollbar +Author: rodarima +Created: Sat, 12 Oct 2024 16:14:36 +0000 +State: closed + +Implements support for placing the vertical scrollbar on the left side by setting `scrollbar_on_left=YES` on dillorc. By default, continues to be on the right side. + + + + +See: https://www.toomanyatoms.com/software/mobilized_dillo.html +Authored-By: dogma
\ No newline at end of file diff --git a/274/index.md b/274/index.md new file mode 100644 index 0000000..2d031ec --- /dev/null +++ b/274/index.md @@ -0,0 +1,6 @@ +Title: Scroll page mode +Author: rodarima +Created: Sat, 12 Oct 2024 20:14:50 +0000 +State: closed + +Adds support for scrolling full pages with the mouse wheel and clicking on the scrollbar.
\ No newline at end of file diff --git a/275/index.md b/275/index.md new file mode 100644 index 0000000..5539a2a --- /dev/null +++ b/275/index.md @@ -0,0 +1,31 @@ +Title: dillo2 fails to load anything if started in xinit+tmux +Author: cschuber +Created: Sun, 13 Oct 2024 08:26:25 +0000 +State: open + +Copied from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282042: + +Using xinit/startx to launch dillo leads to dillo only loading a couple of local files (Not tested with external websites). as in { dillo htmlfiles*.html } + +After much testing I could reduce the number of hanging tabs but you still get some. + +launching dpid first, dpidc register; and then launching dillo after sleeping for a while does lead to less hanging (I think) + +So I ran + +truss -fda -o /dev/stdout dpid | awk '1;/ERR#9/ {exit}' > dpid.truss.txt + +which leads to an infinite close(n+1) ERR#9 bad file descriptor +with n=3 + +Making dillo unusable, so trying to debug it is worse. + +Mind you, I can still use dillo fine, just not via xinitrc, even with sleeping. + +--%-- +From: rodarima +Date: Sun, 13 Oct 2024 11:17:37 +0000 + +Thanks for the report. I talked a bit with OP on IRC, but I cannot reproduce those hangs on Linux. Ideally I'll need a script that I can run that reproduces the hangs with some probability and/or a backtrace of dpid on that infinite loop. + +On another topic, dillo 2 was based on FLTK 2.0, which [was discontinued](https://dillo-browser.github.io/old/news_old.html). You may want to rename www/dillo2 to www/dillo3 (or just www/dillo) and update to [3.1.1](https://dillo-browser.github.io/release/3.1.1/), althought it is unlikely this problem will be fixed on 3.1.1.
\ No newline at end of file diff --git a/276/index.md b/276/index.md new file mode 100644 index 0000000..03a8fc3 --- /dev/null +++ b/276/index.md @@ -0,0 +1,6 @@ +Title: Control page overlap independently from scroll step +Author: rodarima +Created: Sun, 13 Oct 2024 11:55:49 +0000 +State: closed + +When scrolling a page using full pages, the page overlap doesn't need to match the scroll step. Specially on small screens, the page overlap will be much smaller than the scroll step. A new option can be used to control this.
\ No newline at end of file diff --git a/277/index.md b/277/index.md new file mode 100644 index 0000000..6bdcc55 --- /dev/null +++ b/277/index.md @@ -0,0 +1,8 @@ +Title: Control the page overlap independently +Author: rodarima +Created: Sun, 13 Oct 2024 12:29:06 +0000 +State: closed + +Introduces the new option scroll_page_overlap to control the amount of pixels of overlap when scrolling to the next or previous page. Previously this value was taken from scroll_step, but now they are controlled independently. + +Fixes: https://github.com/dillo-browser/dillo/issues/276
\ No newline at end of file diff --git a/278/index.md b/278/index.md new file mode 100644 index 0000000..a3da2a2 --- /dev/null +++ b/278/index.md @@ -0,0 +1,6 @@ +Title: Page mode improvements +Author: rodarima +Created: Sun, 13 Oct 2024 18:06:31 +0000 +State: closed + +Repeat when holding the button over the scrollbar and jump to top and bottom when clicking on the scrollbar arrow buttons.
\ No newline at end of file diff --git a/279/index.md b/279/index.md new file mode 100644 index 0000000..225f96f --- /dev/null +++ b/279/index.md @@ -0,0 +1,107 @@ +Title: Bad request when using proxy for some hosts +Author: rodarima +Created: Tue, 15 Oct 2024 18:14:29 +0000 +State: closed + +The following pages: + +- https://lite.duckduckgo.com/lite/ +- https://www.openbsd.org/ +- https://undeadly.org/ +- https://why-openbsd.rocks/ + +Fail with 400 Bad Request when fetched using a HTTP proxy via Tor. The setup is done with privoxy listening as a HTTP proxy at 8118 and tor as socks5 at 9050. + +``` +privoxy's config (main info is listen-address and the forward-socks5t with a dot at then end of line) + +# grep -v '^#' /etc/privoxy/config +confdir /etc/privoxy +logdir /log +actionsfile match-all.action # Actions that are applied to all sites and maybe overruled later on. +actionsfile default.action # Main actions file +actionsfile user.action # User customizations +filterfile default.filter +filterfile user.filter # User customizations +logfile logfile +listen-address 127.0.0.1:8118 +toggle 1 +enable-remote-toggle 0 +enable-remote-http-toggle 0 +enable-edit-actions 0 +enforce-blocks 0 +buffer-limit 4096 +enable-proxy-authentication-forwarding 0 + forward-socks5t / 127.0.0.1:9050 . +forwarded-connect-retries 0 +accept-intercepted-requests 0 +allow-cgi-request-crunching 0 +split-large-forms 0 +keep-alive-timeout 5 +tolerate-pipelining 1 +socket-timeout 300 + +tor's config is the default config (listening to 9050 on localhost, cf SOCKSPort) : +# grep -v '^#' /etc/tor/torrc | grep . +Log notice syslog +RunAsDaemon 1 +DataDirectory /var/tor +User _tor + +so here privoxy listen tor on 9050, and is accessible at localhost:8118 +``` + +It seems to be reproduced on master and 3.1.1, and using OpenSSL as well as mbedtls. + +Using curl however can fetch those pages properly: + +``` +% curl -s --proxy http://localhost:8118 https://lite.duckduckgo.com/lite/ | grep '<title' + <title>DuckDuckGo</title> +``` + +Reported-By: mesago + +--%-- +From: rodarima +Date: Tue, 15 Oct 2024 18:25:59 +0000 + +We are requesting `GET https://lite.duckduckgo.com/lite/ HTTP/1.1` via the TLS tunnel instead of `GET /lite/ HTTP/1.1`. + +Tentative patch: + +```diff +diff --git a/src/IO/http.c b/src/IO/http.c +index c7915fc5..f8a1ebb2 100644 +--- a/src/IO/http.c ++++ b/src/IO/http.c +@@ -380,7 +380,7 @@ static Dstr *Http_make_content_type(const DilloUrl *url) + /** + * Make the http query string + */ +-static Dstr *Http_make_query_str(DilloWeb *web, bool_t use_proxy) ++static Dstr *Http_make_query_str(DilloWeb *web, bool_t use_proxy, bool_t use_tls) + { + char *ptr, *cookies, *referer, *auth; + const DilloUrl *url = web->url; +@@ -397,7 +397,7 @@ static Dstr *Http_make_query_str(DilloWeb *web, bool_t use_proxy) + const char *connection_hdr_val = + (prefs.http_persistent_conns == TRUE) ? "keep-alive" : "close"; + +- if (use_proxy) { ++ if (use_proxy && !use_tls) { + dStr_sprintfa(request_uri, "%s%s", + URL_STR(url), + (URL_PATH_(url) || URL_QUERY_(url)) ? "" : "/"); +@@ -485,7 +485,9 @@ static void Http_send_query(SocketData_t *S) + DataBuf *dbuf; + + /* Create the query */ +- query = Http_make_query_str(S->web, S->flags & HTTP_SOCKET_USE_PROXY); ++ query = Http_make_query_str(S->web, ++ S->flags & HTTP_SOCKET_USE_PROXY, ++ S->flags & HTTP_SOCKET_TLS); + dbuf = a_Chain_dbuf_new(query->str, query->len, 0); + + MSG_BW(S->web, 1, "Sending query%s...", +```
\ No newline at end of file diff --git a/28/index.md b/28/index.md new file mode 100644 index 0000000..d36f257 --- /dev/null +++ b/28/index.md @@ -0,0 +1,14 @@ +Title: meta http-equiv makes .xhtml files not be recognized +Author: rodarima +Created: Fri, 22 Dec 2023 22:12:36 +0000 +State: closed + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036382 + +There are two different problems, on is the file dpi and the other one is caused by the content type determination once that it is reported in the HTTP headers. + +--%-- +From: rodarima +Date: Fri, 03 May 2024 23:27:58 +0000 + +Fixed in https://github.com/dillo-browser/dillo/pull/140, closing.
\ No newline at end of file diff --git a/280/index.md b/280/index.md new file mode 100644 index 0000000..bd90885 --- /dev/null +++ b/280/index.md @@ -0,0 +1,8 @@ +Title: Only use full URL for HTTP proxies +Author: rodarima +Created: Wed, 16 Oct 2024 17:30:28 +0000 +State: closed + +When performing a HTTPS request over a HTTP proxy, a direct connection is made to the remote server, so the GET line will be received as is. Therefore we shouldn't send the full URL but just the path. + +Fixes: https://github.com/dillo-browser/dillo/issues/279
\ No newline at end of file diff --git a/281/index.md b/281/index.md new file mode 100644 index 0000000..9f46f6e --- /dev/null +++ b/281/index.md @@ -0,0 +1,18 @@ +Title: misc.hh: error: class lout::misc::NotSoSimpleVector<T> has no member named arrayExtra +Author: rodarima +Created: Thu, 17 Oct 2024 07:56:36 +0000 +State: closed + +From: https://bugs.gentoo.org/939137 + +``` +In file included from object.hh:7, + from container.hh:4, + from container.cc:23: +misc.hh: In copy constructor lout::misc::NotSoSimpleVector<T>::NotSoSimpleVector(const lout::misc::NotSoSimpleVector<T>&): +misc.hh:384:13: error: class lout::misc::NotSoSimpleVector<T> has no member named arrayExtra; did you mean arrayExtra1? [-Wtemplate-body] + 384 | this->arrayExtra = NULL; + | ^~~~~~~~~~ +``` + +It seems we left an outdated constructor. This was caught by gcc 15.
\ No newline at end of file diff --git a/282/index.md b/282/index.md new file mode 100644 index 0000000..ef46f08 --- /dev/null +++ b/282/index.md @@ -0,0 +1,7 @@ +Title: Remove unused NotSoSimpleVector constructor +Author: rodarima +Created: Thu, 17 Oct 2024 16:13:36 +0000 +State: closed + +Fixes: https://github.com/dillo-browser/dillo/issues/281 +See: https://bugs.gentoo.org/939137
\ No newline at end of file diff --git a/283/index.md b/283/index.md new file mode 100644 index 0000000..e2b8458 --- /dev/null +++ b/283/index.md @@ -0,0 +1,6 @@ +Title: Flip focus_new_tab and show_quit_dialog +Author: rodarima +Created: Thu, 17 Oct 2024 16:20:04 +0000 +State: closed + +Set focus_new_tab=NO and show_quit_dialog=NO by default.
\ No newline at end of file diff --git a/284/index.md b/284/index.md new file mode 100644 index 0000000..5c99ff9 --- /dev/null +++ b/284/index.md @@ -0,0 +1,49 @@ +Title: Crazy memory usage on paper with lots of SVG equations +Author: rodarima +Created: Fri, 18 Oct 2024 17:37:48 +0000 +State: open + +https://www.gutenberg.org/cache/epub/36276/pg36276-images.html + +--%-- +From: ghost +Date: Fri, 18 Oct 2024 21:53:04 +0000 + +Confirmed. + +This page makes Dillo eventually exit on OpenBSD, but with no error or core dump. + +Here is a log: + +Nav_open_url: new url='https://www.gutenberg.org/cache/epub/36276/pg36276-images.html' +Dns_server [0]: www.gutenberg.org is 152.19.134.47 +Connecting to 152.19.134.47:443 +www.gutenberg.org: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha384 2048-bit RSA: /C=US/ST=Utah/O=Project Gutenberg Literary Archive Foundation/CN=*.gutenberg.org +** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. +sha1 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +sha384 4096-bit RSA: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority +sha384 3072-bit RSA: /C=US/O=Network Solutions L.L.C./CN=Network Solutions RSA OV SSL CA 3 +root: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority +** WARNING **: Svg_write: suspicious image size request 13860 x 3157 +** WARNING **: Svg_write: suspicious image size request 23126 x 2862 +** WARNING **: Svg_write: suspicious image size request 18688 x 4515 +** WARNING **: Svg_write: suspicious image size request 26130 x 1457 +** WARNING **: Svg_write: suspicious image size request 25814 x 2237 +** WARNING **: Svg_write: suspicious image size request 22996 x 2429 +** WARNING **: Svg_write: suspicious image size request 20241 x 2464 +** WARNING **: Svg_write: suspicious image size request 18318 x 2252 +** WARNING **: Svg_write: suspicious image size request 20462 x 2405 +** WARNING **: Svg_write: suspicious image size request 22800 x 2416 +** WARNING **: Svg_write: suspicious image size request 18689 x 2293 +** WARNING **: Svg_write: suspicious image size request 16809 x 2242 +** WARNING **: Svg_write: suspicious image size request 32013 x 2466 +** WARNING **: Svg_write: suspicious image size request 17586 x 5080 +** WARNING **: Svg_write: suspicious image size request 18218 x 4993 +** WARNING **: Svg_write: suspicious image size request 24356 x 2374 +** WARNING **: Svg_write: suspicious image size request 8570 x 5135 +** WARNING **: Svg_write: suspicious image size request 27708 x 2261 +** WARNING **: Svg_write: suspicious image size request 19614 x 2374 +** WARNING **: Svg_write: suspicious image size request 17799 x 5080 +** WARNING **: Svg_write: suspicious image size request 26582 x 11224 +EXIT: 1
\ No newline at end of file diff --git a/285/index.md b/285/index.md new file mode 100644 index 0000000..630cd25 --- /dev/null +++ b/285/index.md @@ -0,0 +1,73 @@ +Title: SSL routines::unexpected eof while reading +Author: rodarima +Created: Fri, 18 Oct 2024 18:18:31 +0000 +State: open + +EU page doesn't load due TLS errors https://ec.europa.eu/commission/presscorner/detail/en/ip_24_4761: + +``` +% dillo https://ec.europa.eu/commission/presscorner/detail/en/ip_24_4761 +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.2 3 Sep 2024 +Enabling cookies as from cookiesrc... +Nav_open_url: new url='https://ec.europa.eu/commission/presscorner/detail/en/ip_24_4761' +Dns_server [0]: ec.europa.eu is 147.67.34.30 147.67.210.30 +Connecting to 147.67.34.30:443 +ec.europa.eu: TLSv1.3, cipher TLS_AES_128_GCM_SHA256 +sha256 2048-bit RSA: /C=BE/ST=Brussels-Capital Region/L=Brussels/O=European Commission/CN=*.ec.europa.eu +sha256 2048-bit RSA: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018 +root: /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign +TLS ALERT on write: decode error +SSL_read() failed: error:0A000126:SSL routines::unexpected eof while reading +NumPendingStyleSheets=1 +Tls_close_by_key: Avoiding SSL shutdown for: https://ec.europa.eu/commission/presscorner/detail/en/ip_24_4761 +Premature close for https://ec.europa.eu/commission/presscorner/detail/en/ip_24_4761 +TLS ALERT on write: decode error +SSL_read() failed: error:0A000126:SSL routines::unexpected eof while reading +Tls_close_by_key: Avoiding SSL shutdown for: https://ec.europa.eu/commission/presscorner/styles-6R54LL4T.css +Premature close for https://ec.europa.eu/commission/presscorner/styles-6R54LL4T.css +>>>> a_Nav_repush <<<< +Nav_open_url: new url='https://ec.europa.eu/commission/presscorner/detail/en/ip_24_4761' +a_Nav_expect_done: repush! +``` + +--%-- +From: rodarima +Date: Sat, 19 Oct 2024 17:04:31 +0000 + +The page *does* load, just that nothing is displayed unless JS is enabled. + + + + +--%-- +From: rodarima +Date: Sun, 02 Mar 2025 19:47:32 +0000 + +Interestingly, loading the CSS of the page directly causes at least 15 seconds of UI locked at 100% CPU while wrapping the paragraph of the 500_000 characters long single line: + +``` +% dillo https://ec.europa.eu/commission/presscorner/styles-PDEFUULV.css +``` + +What a goldmine of problems in a single website. + +Here is a more stable reproducer: + +``` +% dillo -l https://ec.europa.eu/commission/presscorner/ +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.4.1 11 Feb 2025 +Enabling cookies as from cookiesrc... +Nav_open_url: new url='https://ec.europa.eu/commission/presscorner/' +Dns_server [0]: ec.europa.eu is 147.67.210.30 147.67.34.30 +Connecting to 147.67.210.30:443 +ec.europa.eu: TLSv1.3, cipher TLS_AES_128_GCM_SHA256 +sha256 2048-bit RSA: /C=BE/ST=Brussels-Capital Region/L=Brussels/O=European Commission/CN=*.ec.europa.eu +sha256 2048-bit RSA: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018 +root: /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign +TLS ALERT on write: decode error +SSL_read() failed: error:0A000126:SSL routines::unexpected eof while reading +Tls_close_by_key: Avoiding SSL shutdown for: https://ec.europa.eu/commission/presscorner/ +Premature close for https://ec.europa.eu/commission/presscorner/ +```
\ No newline at end of file diff --git a/286/index.md b/286/index.md new file mode 100644 index 0000000..a84f60e --- /dev/null +++ b/286/index.md @@ -0,0 +1,32 @@ +Title: Cannot load www.washingtonpost.com +Author: rodarima +Created: Sat, 19 Oct 2024 09:41:02 +0000 +State: closed + +Aparently https://www.washingtonpost.com/ doesn't load on Dillo, Curl or W3M. It does on Firefox. They seem to be banning us, but let's double check it is not on our end. + +--%-- +From: rodarima +Date: Sat, 19 Oct 2024 15:59:12 +0000 + +We can only access it if all the following hold: + +- We use HTTP/2 (not supported in Dillo) +- Compressed with accept-encoding (already being done) +- They like the user agent (no curl, Dillo/ver is ok) + + + +--%-- +From: rodarima +Date: Sat, 19 Oct 2024 16:21:25 +0000 + +Reported to The Washington Post. Other than that, not much we can do until we implement support for HTTP/2, so closing for now. + +--%-- +From: rodarima +Date: Mon, 28 Oct 2024 07:49:32 +0000 + +No reply, but... instead of allowing HTTP/1.1 for Dillo, they just banned the User-Agent. Now both HTTP/1.1 or HTTP/2 won't work unless we mimick Mozilla et al. + +Ticket #3948239.
\ No newline at end of file diff --git a/287/index.md b/287/index.md new file mode 100644 index 0000000..46cedb5 --- /dev/null +++ b/287/index.md @@ -0,0 +1,8 @@ +Title: Don't add border on images with a link +Author: rodarima +Created: Mon, 21 Oct 2024 17:23:36 +0000 +State: closed + +Some images have the same background color as the page so they don't have a visible border. Always adding a border on images with a link breaks this property. Links continue to be discoverable by hovering with the mouse. + +Fixes: https://github.com/dillo-browser/dillo/issues/270
\ No newline at end of file diff --git a/288/index.md b/288/index.md new file mode 100644 index 0000000..4656e75 --- /dev/null +++ b/288/index.md @@ -0,0 +1,11 @@ +Title: Print the commit with dillo -v +Author: rodarima +Created: Tue, 22 Oct 2024 16:05:40 +0000 +State: closed + +When testing version of Dillo that are not released yet, it is convenient to see the exact commit they belong to. We can report this information by collecting it at the configure stage. Something like this: + +``` +% dillo -v +Dillo version 3.1.1 (commit 3480a9bb) +```
\ No newline at end of file diff --git a/289/index.md b/289/index.md new file mode 100644 index 0000000..7da3e9f --- /dev/null +++ b/289/index.md @@ -0,0 +1,32 @@ +Title: Use git commit in version if built from git +Author: rodarima +Created: Tue, 22 Oct 2024 18:23:30 +0000 +State: closed + +Attempts to fix #288 + +I see at least one **big** problem: + +``` +$ git clone ... && cd dillo +$ ./autogen.sh # this will populate the version +$ mkdir build && cd build +$ ../configure && make # Okay, not we build dillo with the correct version +$ cd .. +$ $EDITOR src/... +$ git checkout -b foobar +$ git add ... +$ git commit -m foo +$ cd build +$ ../configure # <--- now we are placing the wrong version in dillo, as it was not updated in configure +``` + +So if I forget to run `./autogen.sh` again I get a fully working dillo binary with the wrong version. + +This should run at configure time, not when running autoconf. + +--%-- +From: rodarima +Date: Mon, 09 Dec 2024 19:05:29 +0000 + +Closing in favor of #318
\ No newline at end of file diff --git a/29/index.md b/29/index.md new file mode 100644 index 0000000..2707adc --- /dev/null +++ b/29/index.md @@ -0,0 +1,30 @@ +Title: Open file dialog pops up in /tmp and forgets opened file's dir when changing page +Author: rodarima +Created: Fri, 22 Dec 2023 22:20:00 +0000 +State: open + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036384 + +>When I pop up the Open file dialog it always opens in /tmp, forcing you +>to change to home, which is where it should open. The only exception is +>when you have already opened a file and are still displaying it, then it +>rightly opens in the same dir, but if you go back to another page and +>return it forgets. +> +>Besides, if I click on FLTK's shortcut for /, right up the Filename +>text entry, it only displays kernel fs dirs: sys, proc, dev, run, and +>subdirs of these. +> +>The whole issue is a very serious usability issue. + +Agreed, I would expect it to either be in the last directory you used (this is specially painful if you are downloading 10 or more files, one by one) or let the user change the behavior and always start from a directory of users choice. + +--%-- +From: rodarima +Date: Fri, 22 Dec 2023 22:38:26 +0000 + +We can easily switch to the native file chooser, which would open something familiar to users. In my case is using the GTK file chooser (although I didn't care much to setup a proper theme): + + + +These choosers typically hold the last directories on their own.
\ No newline at end of file diff --git a/290/index.md b/290/index.md new file mode 100644 index 0000000..1403fd2 --- /dev/null +++ b/290/index.md @@ -0,0 +1,18 @@ +Title: Reload the current page on SIGUSR1 signal +Author: rodarima +Created: Fri, 25 Oct 2024 16:50:24 +0000 +State: closed + +Fixes: https://github.com/dillo-browser/dillo/issues/255 + +Known limitations: External CSS and images are not fetched again, refetching them again causes issues. + +--%-- +From: rodarima +Date: Fri, 25 Oct 2024 17:41:16 +0000 + +This only operates on the first tab, even if it is out of focus. Once the first tab is closed, reloading via the signal causes a crash. + +We will need to operate only on the "current" tab. If we have multiple windows, I assume we either reload the current tab on all windows, or just one of them. + +Let's reload all of them for now.
\ No newline at end of file diff --git a/291/index.md b/291/index.md new file mode 100644 index 0000000..811c03f --- /dev/null +++ b/291/index.md @@ -0,0 +1,10 @@ +Title: Remove the 1 pixel line on the top when hiding the tabs +Author: rodarima +Created: Fri, 25 Oct 2024 17:39:29 +0000 +State: open + +It seems to be caused by resizing the tab bar to 1 pixel of height: + +https://github.com/dillo-browser/dillo/blob/6d5b3ee329b61adfa144c4f7f9d60bbe10e04071/src/uicmd.cc#L363-L366 + +Setting it to 0 doesn't work well.
\ No newline at end of file diff --git a/292/index.md b/292/index.md new file mode 100644 index 0000000..9eccd84 --- /dev/null +++ b/292/index.md @@ -0,0 +1,12 @@ +Title: Rename BrowserWindow to something else +Author: rodarima +Created: Fri, 25 Oct 2024 17:57:51 +0000 +State: open + +The current BrowserWindow structure is actually holding the information for the tab, not the FLTK window. In fact, there is no way to iterate among windows from Dillo itself. + +--%-- +From: DiegoSpirit +Date: Mon, 17 Mar 2025 10:57:49 +0000 + +BrowserWidget ?
\ No newline at end of file diff --git a/293/index.md b/293/index.md new file mode 100644 index 0000000..07d6442 --- /dev/null +++ b/293/index.md @@ -0,0 +1,13 @@ +Title: Cache issue when login into codeberg +Author: rodarima +Created: Sun, 27 Oct 2024 16:04:29 +0000 +State: open + +At first I thought login into Codeberg was not working, as I was being redirected to the main page again. However, the issue is that is not being fetched again, and is serving it from the cache, even if I am now logged in. Steps to reproduce: + +- Enable cookies for codeberg.org +- Go to codeberg.org +- Login +- Same main page is redirected. + +On reload, the proper page is shown. The logout functionality seems to be broken without JS, so I need to remove the cookie by hand.
\ No newline at end of file diff --git a/294/index.md b/294/index.md new file mode 100644 index 0000000..16f779a --- /dev/null +++ b/294/index.md @@ -0,0 +1,5 @@ +Title: Update readme and add funding link +Author: rodarima +Created: Mon, 28 Oct 2024 19:46:00 +0000 +State: closed + diff --git a/295/index.md b/295/index.md new file mode 100644 index 0000000..b9eec1f --- /dev/null +++ b/295/index.md @@ -0,0 +1,25 @@ +Title: Missing entities lsquo and rsquo +Author: rodarima +Created: Sat, 02 Nov 2024 09:21:51 +0000 +State: closed + +Source: https://www.w3.org/2000/04/26-csrules.html + +``` +1. The hierarchy (<body> / <div1> / <div2> / <p>) is unaffected by whether +forms are present or not; <form> is ‘transparent’ to the hierarchy. +``` + +--%-- +From: rodarima +Date: Sat, 02 Nov 2024 09:27:26 +0000 + +Nevermind, it is wrong HTML: + +```html +<li> The hierarchy (<tt><body></tt> / <tt><div1></tt> / <tt><div2></tt> / +<tt><p></tt>) is unaffected by whether forms are present or not; +<tt><form></tt> is &lsquo;transparent&rsquo; to the +hierarchy.</li> +``` +We do support lsquo and rsquo.
\ No newline at end of file diff --git a/296/index.md b/296/index.md new file mode 100644 index 0000000..25794ff --- /dev/null +++ b/296/index.md @@ -0,0 +1,30 @@ +Title: Handset mode +Author: sjehuda +Created: Wed, 06 Nov 2024 09:57:36 +0000 +State: closed + +Good day! + +I am using [postmarketOS](https://wiki.postmarketos.org/wiki/Dillo), and I have tried [Mobilized-Dillo](https://www.toomanyatoms.com/software/mobilized_dillo.html), yesterday. + +Mobilized-Dillo is useful for handset devices, including displays with touch interface. + +I think, that it would be beneficial to integrate features from Mobilized-Dillo into Dillo. + +For larger touch screen devices, I use Falkon, because it offers touch interface, yet I would definitely prefer Dillo for handset devices that fit to a pocket. + +Schimon + +--%-- +From: rodarima +Date: Wed, 06 Nov 2024 12:05:39 +0000 + +> it would be beneficial to integrate features from Mobilized-Dillo into Dillo. + +Yes, I'm aware. For now, I'm focusing on desktop. We may be able to join forces and have both implementations merged, but not likely happening soon. + +--%-- +From: sjehuda +Date: Wed, 06 Nov 2024 17:29:28 +0000 + +Thank you! This is good to know. diff --git a/297/index.md b/297/index.md new file mode 100644 index 0000000..754de38 --- /dev/null +++ b/297/index.md @@ -0,0 +1,109 @@ +Title: XMPP PubSub +Author: sjehuda +Created: Wed, 06 Nov 2024 11:28:32 +0000 +State: closed + +Please add support for XMPP. + +By adding support for XMPP, I namely mean to [Atom Over XMPP](https://blasta.woodpeckersnest.eu/help/about/xmpp/atomsub) (XEP-0277 and XEP-0472) which is utilizing XEP-0060: Publish-Subscribe (PubSub) which allows to host "rich" content on XMPP. + +This is a visual demonstration to prove that subject matter https://video.xmpp-it.net/w/vNqcMooy3pqRAZ8Yb8grr1 + +[Rivista XJP](https://git.xmpp-it.net/sch/Rivista) is an HTTP gateway to deliver posts from the XMPP network. + +See also: +- https://xmpp.org/extensions/xep-0060.html +- https://xmpp.org/extensions/xep-0277.html +- https://xmpp.org/extensions/xep-0472.html +- https://blasta.woodpeckersnest.eu/help/about/xmpp/pubsub +- https://join.movim.eu/ + +For example, the journal at https://mov.im/blog/edhelas is not hosted at mov.im; rather, it is hosted inside an account at XMPP server movim.eu which is conveyed by the Movim instance at mov.im. + +Please join to JDev group chat if you want more help or information https://search.jabber.network/search?q=jdev + +Related: https://github.com/crossbowerbt/dillo-plus/issues/54 + +--%-- +From: rodarima +Date: Wed, 06 Nov 2024 12:00:25 +0000 + +> [Rivista XJP](https://git.xmpp-it.net/sch/Rivista) is an HTTP gateway to deliver posts from the XMPP network. + +What is wrong with this gateway? + +--%-- +From: sjehuda +Date: Wed, 06 Nov 2024 17:48:24 +0000 + +This gateway works fine. + +Proof of concept +---------------- + +The gateway was intended only for feed readers; and yet, with XSLT, I +have made it usable for HTML browsers too, but this gateway is really a +proof-of-concept, albeit it is competent for content publishing. + + +The subject matter +------------------ + +Dillo is an HTML browser, which parses HTML; so, I would suggest to add +support for XMPP, which would: + +1) Allow to view HTML content which is stored on XMPP. +2) Be extensible to comment on XMPP PubSub posts and also to publish + posts to XMPP PubSub. + + +The benefit of XMPP PubSub structure +------------------------------------ + +The item and node fashion, by which XMPP PubSub is designed, allow for +efficient usage of bandwidth on both ends (client and server). + +Please. Try the gateway, especially the part which allows to view +single posts (i.e. Item ID), to observe this statement. + + +Conclusion +---------- + +I firmly suggest to consider this feature. + + +--%-- +From: sjehuda +Date: Wed, 06 Nov 2024 17:50:18 +0000 + +Is it possible to write a plugin with Python? + +I would be glad to contribute an XMPP plugin. + +https://dillo-browser.github.io/#plugins + + +--%-- +From: rodarima +Date: Wed, 06 Nov 2024 18:43:48 +0000 + +Yes, you can make a plugin in Python as long as you output HTML that Dillo can parse. See the available plugins as examples. + +Maybe you use something like [miniflux](https://miniflux.app/) as a web reader interface, so you can just connect your gateway to miniflux and read the feeds from there via HTTP as HTML. + +--%-- +From: sjehuda +Date: Wed, 06 Nov 2024 18:59:17 +0000 + +I will use Slixmpp to retrieve HTML content from XMPP PubSub nodes. + +I suppose, that I will use my own design. + +I will continue at the mailing list. + +Thank you. + + + + diff --git a/298/index.md b/298/index.md new file mode 100644 index 0000000..08d8741 --- /dev/null +++ b/298/index.md @@ -0,0 +1,35 @@ +Title: XSLT +Author: sjehuda +Created: Fri, 08 Nov 2024 12:17:31 +0000 +State: closed + +XSLT allows to convert XML files to XML, XHTML and Text. + +Supporting XSLT will further allow to Dillo to render Atom/RDF/RSS documents as readable HTML. + +--- + +I have wrote extensively of syndication and the important of XSLT. + +See https://greasyfork.org/en/scripts/465932-newspaper-html-feed-reader + +To read this, you will need to open an ActivitySream/Atom/JSON/RDF/RSS file and then click on the icon "rescue wheel" to see the content, or just read it from source file. + +--%-- +From: rodarima +Date: Wed, 13 Nov 2024 17:49:37 +0000 + +This is out the scope of Dillo. You can use plugins to extend it and perform the XSLT transformation so that the HTML output can be opened in Dillo. + +--%-- +From: sjehuda +Date: Wed, 20 Nov 2024 05:16:15 +0000 + +I have sent this to the mailing-list. May you help me? + +I would want to know of an example or an elaboration as of how would it +be possible to wriite a plugin which would parse XSLT. + +I want to know how to trigger Dillo to engage such type of a plugin. + +https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/KYUF5MBUZV3ZUL5PVAHGGSJIPLX7ICXW/
\ No newline at end of file diff --git a/299/index.md b/299/index.md new file mode 100644 index 0000000..882435d --- /dev/null +++ b/299/index.md @@ -0,0 +1,15 @@ +Title: use `magick` instead of `convert` if available +Author: Kangie +Created: Tue, 12 Nov 2024 06:20:45 +0000 +State: closed + +This suppresses a warning on more modern systems while preserving the ability of older systems and CI/CD to run the test suite. + +> WARNING: The convert command is deprecated in IMv7, \ +> use "magick" instead of "convert" or "magick convert" + +--%-- +From: rodarima +Date: Wed, 13 Nov 2024 17:45:58 +0000 + +Thanks!
\ No newline at end of file diff --git a/3/index.md b/3/index.md new file mode 100644 index 0000000..c65587a --- /dev/null +++ b/3/index.md @@ -0,0 +1,6 @@ +Title: URL opener +Author: rodarima +Created: Sun, 08 Nov 2020 12:33:13 +0000 +State: closed + +Following #2 we would like to open some urls using other tools, such as mpv(1) for videos or GIF animated images.
\ No newline at end of file diff --git a/30/index.md b/30/index.md new file mode 100644 index 0000000..5c61593 --- /dev/null +++ b/30/index.md @@ -0,0 +1,60 @@ +Title: EVP_PKEY_get_id deprecated since openssl 3.0 +Author: th-otto +Created: Sat, 23 Dec 2023 13:19:26 +0000 +State: closed + +That function was deprecated since openssl 3.0.0, and no longer exists in newer versions. Consequently i get a warning during compile, and a link error at runtime. + +(sorry but i have no idea how to properly replace it) + +System: openSUSE; with openssl 3.1.4 installed + +--%-- +From: rodarima +Date: Sat, 23 Dec 2023 13:26:49 +0000 + +Can you paste the full error that you are getting? Following the documentation for OpenSSL 3.1, it seems to be supported: + +https://www.openssl.org/docs/man3.1/man3/EVP_PKEY_get_id.html + +Also, which commit are you using? I changed the OpenSSL implementation recently. + +**Edit:** Based on: + +> The EVP_PKEY_id() and EVP_PKEY_base_id() functions were renamed to include get in their names in OpenSSL 3.0, respectively. The old names are kept as non-deprecated alias macros. + +I suspect that you may be linking with an older OpenSSL, instead of 3.1. + +--%-- +From: th-otto +Date: Sat, 23 Dec 2023 13:42:28 +0000 + +Oops sorry, you are right. I had both an older version installed (openssl 1.1.0) as well as openssl-3, but only development files for the older version, so that was used instead. + + +--%-- +From: rodarima +Date: Sat, 23 Dec 2023 13:45:34 +0000 + +I was planning to add support for OpenSSL 1.1 too, but for now only 3.x is supported. Anyway, this should be detected at configure time in any case. Thanks for the report :-) + +--%-- +From: th-otto +Date: Sat, 23 Dec 2023 13:56:42 +0000 + +Yes, support for openssl 1.1 would be nice, since i have no port of openssl3 for atari (yet) ;) + +BTW, in your readme you mention that you have no control of dillo.org anymore, but the about:splash page still has links to it (and is rendered quite strangely) + + +--%-- +From: rodarima +Date: Sat, 23 Dec 2023 14:10:13 +0000 + +> Yes, support for openssl 1.1 would be nice, since i have no port of openssl3 for atari (yet) ;) + +In the meanwhile, you can try with [mbedTLS](https://en.wikipedia.org/wiki/Mbed_TLS) in case it is already ported (use `--disable-openssl` to search only for mbedTLS). + +> BTW, in your readme you mention that you have no control of dillo.org anymore, but the about:splash page still has links to it (and is rendered quite strangely) + +Thanks, I opened #32 to address it.
\ No newline at end of file diff --git a/300/index.md b/300/index.md new file mode 100644 index 0000000..88ead55 --- /dev/null +++ b/300/index.md @@ -0,0 +1,14 @@ +Title: Resizing the window several times triggers the layout emergency brake +Author: rodarima +Created: Wed, 13 Nov 2024 18:28:54 +0000 +State: closed + +We should reset the counter of the layout loop if the window is being resized, otherwise it will lock and no more layout updates will happen. + +See #236 + +--%-- +From: rodarima +Date: Wed, 13 Nov 2024 19:41:38 +0000 + +There are multiple Layout instances in a single tab and each is currently using its own resizeCounter. This is used for ComplexButtonResource. We may want to use it only in the top level one, otherwise each sub-layout may break at different times.
\ No newline at end of file diff --git a/301/index.md b/301/index.md new file mode 100644 index 0000000..10a8684 --- /dev/null +++ b/301/index.md @@ -0,0 +1,6 @@ +Title: Reset resize counter when viewport changes size +Author: rodarima +Created: Thu, 14 Nov 2024 19:02:03 +0000 +State: closed + +Fixes #300
\ No newline at end of file diff --git a/302/index.md b/302/index.md new file mode 100644 index 0000000..fc4f236 --- /dev/null +++ b/302/index.md @@ -0,0 +1,37 @@ +Title: Wiby.me search broken +Author: rodarima +Created: Sun, 17 Nov 2024 22:00:19 +0000 +State: closed + +We are missing the / in the GET query: + +``` + GET ?q=dillo HTTP/1.1\r\n + Host: wiby.me\r\n + User-Agent: Dillo/3.1.1\r\n + Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n + Accept-Encoding: gzip, deflate\r\n + DNT: 1\r\n + Referer: http://wiby.me/\r\n + Connection: keep-alive\r\n + \r\n +``` + + + +--%-- +From: rodarima +Date: Sun, 17 Nov 2024 22:34:49 +0000 + +This was fixed on dilloNG https://github.com/w00fpack/dilloNG/commit/bd50718a507872038ac8b4c40bf93e4f8c0a2a75 + +They set the url->path component to `/` when empty, but this is not a URI requirement, see https://datatracker.ietf.org/doc/html/rfc3986#section-3.3: + +> If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character. [...] A path is always defined for a URI, though the defined path may be empty (zero length). + + +This is only required for HTTP, see https://datatracker.ietf.org/doc/html/rfc7230#section-5.3.1: + +> If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. + +So I prefer to fix it on the http side.
\ No newline at end of file diff --git a/303/index.md b/303/index.md new file mode 100644 index 0000000..b2b6bfd --- /dev/null +++ b/303/index.md @@ -0,0 +1,13 @@ +Title: Always include the path "/" in HTTP requests +Author: rodarima +Created: Mon, 18 Nov 2024 18:19:19 +0000 +State: closed + +Following https://datatracker.ietf.org/doc/html/rfc7230#section-5.3.1, the path must not be empty, even if we have a query: + +> If the target URI's path component is empty, the client MUST send "/" +> as the path within the origin-form of request-target. + +Notice URIs can have empty paths, this is a restriction of HTTP only. + +Fixes: https://github.com/dillo-browser/dillo/issues/302
\ No newline at end of file diff --git a/304/index.md b/304/index.md new file mode 100644 index 0000000..072a87c --- /dev/null +++ b/304/index.md @@ -0,0 +1,70 @@ +Title: Images not loading for http://retro.hackaday.com +Author: rodarima +Created: Tue, 19 Nov 2024 08:37:24 +0000 +State: open + +Loading the website causes the images not to display. But following a link and then going back causes the images to properly load. + +Reported-by: Flea86 + +--%-- +From: rodarima +Date: Tue, 19 Nov 2024 20:07:05 +0000 + +Reproducer: + +```html +<img src="http://hackaday.com/wp-content/uploads/2011/11/pic.jpg"> +``` + +The image returns a 301 redirect: + +``` +GET /wp-content/uploads/2011/11/pic.jpg HTTP/1.1 +Host: hackaday.com +User-Agent: Dillo/3.1.1 +Accept: image/png,image/*;q=0.8,*/*;q=0.5 +Accept-Encoding: gzip, deflate +DNT: 1 +Referer: http://hackaday.com/ +Connection: keep-alive + + +HTTP/1.1 301 Moved Permanently +Server: nginx +Date: Tue, 19 Nov 2024 19:42:16 GMT +Content-Type: text/html +Content-Length: 162 +Connection: keep-alive +Location: https://hackaday.com/wp-content/uploads/2011/11/pic.jpg +cache-control: max-age=31536000 +x-rq: mad1 + +<html> +<head><title>301 Moved Permanently</title></head> +<body> +<center><h1>301 Moved Permanently</h1></center> +<hr><center>nginx</center> +</body> +</html> +``` + +Dillo seems to ignore redirects on non-root requests like images: + +https://github.com/dillo-browser/dillo/blob/f3103cc4b6c369da96c7de487214a9e56eca755d/src/cache.c#L1240-L1242 + +Also: + +https://github.com/dillo-browser/dillo/blob/f3103cc4b6c369da96c7de487214a9e56eca755d/src/cache.c#L1102-L1107 + +This predates the git history (2007), so I don't know the context at which this was done. It looks simply unfinished. + +--%-- +From: kaimac1 +Date: Tue, 03 Dec 2024 16:11:17 +0000 + +I was just looking at the old site and saw that this behaviour is described as intentional: + +> If Dillo requests an image and receives a response containing a redirection (i.e., pointing to a different URL), the redirection is not followed. These have a strong tendency to be advertisements. + +https://dillo-browser.github.io/old/FAQ.html#q28
\ No newline at end of file diff --git a/305/index.md b/305/index.md new file mode 100644 index 0000000..8a2871e --- /dev/null +++ b/305/index.md @@ -0,0 +1,420 @@ +Title: Tracking problems of Dillo 3.0.5 on Debian +Author: rodarima +Created: Fri, 22 Nov 2024 22:44:39 +0000 +State: open + +Debian continues to ship with [Dillo 3.0.5](https://packages.debian.org/search?keywords=dillo), even if we have made already two [releases](https://github.com/dillo-browser/dillo/releases) since we took over the maintenace (see this [HN post](https://news.ycombinator.com/item?id=38847613)). For reference, **Dillo 3.0.5 was released in 2015**. + +Several people are affected by issues that were fixed either by the original developers of Dillo (but never made it to a release) or fixed by us, both of which are solved in the last release (as of now, 3.1.1). + +Until now, I believed that it was somewhat better to at least have 3.0.5 on the Debian repos, but as I read more and more users complaining that it doesn't work at all, I'm starting to change my mind about it. Specially, because **those issues were already fixed**. Users are simply assuming that Dillo is broken, and they just go to find another browser. + +Other distributions like Ubuntu, Raspbian or Linux Mint use the Debian packages, so they also include the outdated Dillo. This is particularly painful, as the users are typically newcomers, and there is not much chance they will even consider they are using an almost 10 year old release. + +I'll try to keep here a list of those issues I find on the web, sorted by time. + +--- + +## 2024-11-06 - https://youtu.be/RjzQNngysh4?t=371 + +> Sometimes I have trouble visiting this website (api.invidious.io), like I think it may be block in some DNS... + +On Dillo 3.0.5-7+b1 it doesn't work: + +``` +Nav_open_url: new url='https://api.invidious.io/' +** ERROR **: [Dpi_read_comm_keys] No such file or directory +Dpi_blocking_start_dpid: try 1 +[dpid]: a_Misc_mksecret: 95fcad05 +dpid started +40776AE697730000:error:0A000438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1590:SSL alert number 80 +``` + +This is probably related to the missing handling of TLS alerts on OpenSSL. On Dillo 3.1.1 it works fine: + + + + +--- + +## 2024-11-22 - https://forums.raspberrypi.com/viewtopic.php?p=2270962 + +> I launched Dillo, it locked up, or at least failed to connect with connect.raspberrypi.com. Wifi is up as sudo apt update worked fine. +> [...] +> Do any of the images include midori or a browser that a 2 Zero can actually launch and use? + +Similar SSL problem on Dillo 3.0.5-7+b1: + +``` +Nav_open_url: new url='https://connect.raspberrypi.com/' +Nav_open_url: new url='https://connect.raspberrypi.com/devices' +Nav_open_url: new url='https://connect.raspberrypi.com/sign-in' +NumPendingStyleSheets=1 +NumPendingStyleSheets=2 +NumPendingStyleSheets=3 +40D74863E4710000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1590:SSL alert number 40 +40E7A918607B0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1590:SSL alert number 40 +``` + +But works fine on Dillo 3.1.1, although it probably require [enabling cookies](https://dillo-browser.github.io/user_help.html#cookiesrc) to login. + + + +--- + +## 2025-09-11 - debian.org + +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1114901 + +``` +Package: dillo +Version: 3.0.5 + +Hi, +trying to open debian.org with dillo browser. +got this error message from dillo : + +"error 421 +Misdirected Request +The client needs a new connection for this request as the requested host +name does not match the Server Name Indication (SNI) in use for this +connection. + +Apache/2.4.65 (Debian) Server at debian-facile.org Port 443 +" + +trying to open debian.org with dillo git release 3.2.0 works. +``` + +At least the user did test 3.2.0 this time. + +--%-- +From: travis-jeans +Date: Wed, 05 Mar 2025 09:32:19 +0000 + +I found this page because I downloaded the "latest" version of Dillo from the Debian repository today, which is 3.0.5... but I was having a lot of difficulty getting certain pages to load. I could load a few https websites. An example is [ABC News](https://www.abc.net.au/news), though it looks like there isn't support for CSS3. Is it possible to update the debian repository with the latest version of dillo? + +Some errors: +``` +a_Dicache_cleanup: length = 142 +Nav_open_url: new url='https://www.abc.net.au/news' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'border-width' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'border-color' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'margin' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'border-width' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'border-width' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'margin' +no values for shorthand property 'border-color' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'margin' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +** WARNING **: Ignoring unsafe author style that might reveal browsing history +no values for shorthand property 'padding' +no values for shorthand property 'border-color' +no values for shorthand property 'border-color' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'margin' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +no values for shorthand property 'padding' +a_Dicache_cleanup: length = 142 +``` diff --git a/306/index.md b/306/index.md new file mode 100644 index 0000000..4d3566d --- /dev/null +++ b/306/index.md @@ -0,0 +1,27 @@ +Title: Adhere to XDG base directory specification +Author: joshas +Created: Sat, 23 Nov 2024 20:06:38 +0000 +State: closed + +A minor nitpick, but it would be great if Dillo stored configuration files adhering to [XDG base directory specification](https://specifications.freedesktop.org/basedir-spec/latest/). Instead of creating directory `.dillo` directly in $HOME directory, application should keep it in `$HOME/.config/dillo`. +This is useful, as all configs end up in single directory and it is easier to backup everything, not picking by single directory. Also, cleaner $HOME :) + +[FLTK fixed this issue in 1.4 release](https://www.fltk.org/str.php?L3370), so I'd expect this fix happening only after Dillo upgrades to latest version of FLTK. + +--%-- +From: rodarima +Date: Sat, 23 Nov 2024 21:10:27 +0000 + +Not a huge fan of typing `.config/dillo/dillorc` every time I need to change the config. + +Maybe `ln -s .config/dillo .dillo` ? + +This is independent of FLTK, but I don't see that many benefits as to compensate the pain it would take to implement an maintain. + +--%-- +From: philocalyst +Date: Sat, 21 Dec 2024 19:05:30 +0000 + +Would say there is a great deal more nuance to this issue than just convenience to reach, Very much valued and a boon for user choice -- I would view this as a general step towards a greater compatibility with various user expectations. If you are comfortable letting it be in your home directory, you can set that! Approached the right way, this would make the codebase more robust if anything. + +Making it default is another discussion, but adding this variable is not something to be dismissed.
\ No newline at end of file diff --git a/307/index.md b/307/index.md new file mode 100644 index 0000000..16e9701 --- /dev/null +++ b/307/index.md @@ -0,0 +1,12 @@ +Title: Settings not persisted after closing application +Author: joshas +Created: Sat, 23 Nov 2024 20:11:26 +0000 +State: closed + +None of settings from "Tools" menu do not persist after application is closed and started again. Not a huge issue, as defaults are suitable, but it would be useful to store them. + +--%-- +From: rodarima +Date: Sat, 23 Nov 2024 20:54:27 +0000 + +This is intended, as they are designed to be changed over time on a single session. If you want to change the defaults, just edit the `~/.dillo/dillorc` file.
\ No newline at end of file diff --git a/308/index.md b/308/index.md new file mode 100644 index 0000000..da59673 --- /dev/null +++ b/308/index.md @@ -0,0 +1,20 @@ +Title: Consider publishing Dillo to Flathub +Author: joshas +Created: Sat, 23 Nov 2024 20:21:51 +0000 +State: closed + +Please consider providing official Dillo package (flatpak) for [Flathub](https://flathub.org/). Main benefit is that single package can be used in many different Linux distributions. This could solve the problem with recent Dillo version not being available on Debian and other distributions, with exception of Ubuntu, as they prefer "snaps". +You can read about more benefits on [official website](https://docs.flathub.org/docs/for-app-authors/why-flathub). I understand, that there will be a lot of work to get package build and accepted to Flathub, but it is very important that flatpak package is provided by application author, not some random packager. +To help get you started, I have built a working [flatpak for current version of Dillo](https://github.com/joshas/dillo-flatpak/). It has strict permissions (no access to local files), and no way it should be considered of high quality. Would be great that someone with more knowledge about flatpaks would review the packaging configuration. + +--%-- +From: rodarima +Date: Sat, 23 Nov 2024 20:52:41 +0000 + +Sorry, but I will not maintain any binary package of Dillo, I'm already maintaining the software itself and that is plenty of work. + +If you need to install it on any OS that doesn't have a package, I recommend you build it from source, which we have done a lot of work to be sure it works well. Building Dillo takes less than 10 minutes in the slowest machine I have, but typically 1 min. + +I don't recommend you package something like a web browser that links with a TLS library with a mechanism that can prevent security updates from the repositories to reach Dillo. See https://flatkill.org/ + +The proper way is to unblock the Debian situation by having the current maintainer (or a trusted party) review our changes, which are not that many. This will also help the project itself, so is a win-win. The rest of distributions are up to date.
\ No newline at end of file diff --git a/309/index.md b/309/index.md new file mode 100644 index 0000000..24d1a0a --- /dev/null +++ b/309/index.md @@ -0,0 +1,34 @@ +Title: FLTK 1.4.0 problems with pixel units +Author: rodarima +Created: Sat, 23 Nov 2024 21:46:37 +0000 +State: open + +FLTK has now changed the positions and sizes from screen pixels to "units", which are scaled to have a consistent size across multiple DPI screens. This is causing several problems in Dillo. The most visible one is the horizontal glitches when scrolling. But there are several more. + +Let's focus on the scrolling problem. After the page is rendered, there is a buffer on FLTK that holds the current pixels (screen pixels) in memory. When you scroll up or down, Dillo tries to be clever, and computes how much it needs to "shift" the current canvas so that it can reuse that portion and doesn't need to re-render it again. This is good for performance. + +The way in which we do that is by calling the fl_scroll() FLTK function. BUT, we use FLTK units to instruct how much we need to shift the screen. This is internally translated into pixels, and then calls XCopyArea on X11 or simply a memcpy/memmove on Wayland. + +So far so good. The problem is that now we have a chunk of the screen that needs to be rendered with the actual page content. This is what is done by the draw_area function, which is a function pointer that FLTK will invoke on its own with the position and size that needs to be rebuild. + +The problem is that this position doesn't match the hole that has been left by shifting the screen. I suspect this has something to do with the scale factor while translating from FLTK units to pixels. In my particular case, this leaves a 3 pixel line of missing content (which will simply show what it was there before). + +This is the *main* problem. We can "solve" it by causing each scroll event to redraw the screen, but that would hurt the performance. It is better to find a way to solve this while we keep the nice "shift" trick. + +The other problem is that fl_scroll will accumulate errors over time due to the transformation to integer positions after applying the scale value. This causes that after several scroll events (in the same direction) the content of the screen is no longer placed in the same position as it should be. And any attempt to interact with the elements, will cause a redraw of that particular element, making it visible out of place. We should avoid fl_scroll (or at least the way we use it now). + +Another problem that we have is that we need to know the final size in screen pixels of some elements, like images. As we will render an image to the final dimensions, often from a much larger buffer. So it doesn't make a lot of sense that after we render the image at, say 96 DPI, FLTK scales it to, say 120 DPI, causing artifacts in the image, when we can just render it at 120 DPI from the start. + +Similarly, lines are no longer trusted to have exactly an integer number of pixels wide. This causes links with underlines to have a random 1 or 2 pixel wide, leaving inconsistent line widths on the same page. + +As an intemediate solution, we can force FLTK to always work at 96 DPI, which I presume it would keep the 1.3.* behavior, and then slowly start fixing those problems. So we can at least link Dillo with 1.4.0 without causing a mess, as I start to suspect that distributions will begin to adopt 1.4.0, replacing 1.3.10 "soon". + +--%-- +From: rodarima +Date: Sun, 24 Nov 2024 10:59:16 +0000 + +Running with 96 DPI doesn't seem to be enough. The text rendering is also different, and in my quick tests it seems to be worse than before. I'm not sure what is responsible. Here are two cases from lobste.rs at 8x: + + + +(Not an endorsement of Kubernetes)
\ No newline at end of file diff --git a/31/index.md b/31/index.md new file mode 100644 index 0000000..5c837ac --- /dev/null +++ b/31/index.md @@ -0,0 +1,14 @@ +Title: Support for OpenSSL 1.1 +Author: rodarima +Created: Sat, 23 Dec 2023 13:51:14 +0000 +State: closed + +We may want to add support for OpenSSL 1.1, as there are not that many changes and we can use some ifdefs to skip the differences. + +In any case, the detection of OpenSSL should include new functions that are only in 3.x while we don't support OpenSSL 1.1, so we can detect an invalid version early. See #30. + +--%-- +From: rodarima +Date: Sun, 24 Dec 2023 16:05:46 +0000 + +Closed in #33
\ No newline at end of file diff --git a/310/index.md b/310/index.md new file mode 100644 index 0000000..9bf3349 --- /dev/null +++ b/310/index.md @@ -0,0 +1,8 @@ +Title: Prevent using FLTK 1.4 for now +Author: rodarima +Created: Sun, 24 Nov 2024 12:06:15 +0000 +State: closed + +There are several problems that need to be resolved before we can switch to FLTK 1.4. The support is intentionally disabled until it is ready. + +See: https://github.com/dillo-browser/dillo/issues/246
\ No newline at end of file diff --git a/311/index.md b/311/index.md new file mode 100644 index 0000000..6dda99b --- /dev/null +++ b/311/index.md @@ -0,0 +1,14 @@ +Title: Print version of libraries and features +Author: rodarima +Created: Sun, 24 Nov 2024 16:13:10 +0000 +State: closed + + When reporting the version of Dillo with -v, print also the version of + the libraries it is currently using, as well as the features that were + enabled at build time. Notice the versions are reported by reading them + at runtime, so we can detect the version loaded at run time, regardless + of which version was used at link time. + + All features are always printed, but prefixes with + if enabled or - if + disabled. This allows checking if the feature was disabled at configure + time or if it is missing in that version of Dillo.
\ No newline at end of file diff --git a/312/index.md b/312/index.md new file mode 100644 index 0000000..27d16fb --- /dev/null +++ b/312/index.md @@ -0,0 +1,118 @@ +Title: Add WebP image support +Author: rodarima +Created: Sun, 24 Nov 2024 18:19:13 +0000 +State: closed + +Adds WebP image support, enabled by default if libwebp is present at configure time. + +Fixes: https://github.com/dillo-browser/dillo/issues/71 +See: https://www.toomanyatoms.com/software/mobilized_dillo.html + +--%-- +From: ghost +Date: Mon, 25 Nov 2024 10:45:43 +0000 + +I'm not a fan of having this in Dillo and agree with many of the points linked in this comment: +https://github.com/dillo-browser/dillo/issues/71#issuecomment-2180178620 + +If you are intent on commiting this, can we at least have an option to disable this at runtime for the people who don't build Dillo from source? + +--%-- +From: rodarima +Date: Tue, 26 Nov 2024 20:05:25 +0000 + +> I'm not a fan of having this in Dillo and agree with many of the points linked in this comment: [#71 (comment)](https://github.com/dillo-browser/dillo/issues/71#issuecomment-2180178620) + +Out of curiosity, can you elaborate on what is your worry on using libwebp for decoding WebP images (with respect to the other decoders)? + +I think whether WebP leads to a better compression ratio and thus should be used widely is out of the scope of this PR, as we are only focusing on "given a page with WebP images what do we do?". + +> If you are intent on commiting this, can we at least have an option to disable this at runtime for the people who don't build Dillo from source? + +We have the `load_images` switch, but we could add another option that allows you to select a subset of formats to never load. + +However, I would expect any user that worries about which decoders are being used, to be able to build Dillo from source, selecting whichever subset of image support at build time. + +--%-- +From: ghost +Date: Tue, 26 Nov 2024 22:14:07 +0000 + +> Out of curiosity, can you elaborate on what is your worry on using libwebp for decoding WebP images (with respect to the other decoders)? + +I don't believe that Dillo should rush to endorse a new Google image format which doesn't provide a clear benefit over the existing well-tested formats, and which also faces security questions following a recent exploit. Unfortunately a few sites still insist on using WebP, but I think it's something to be rejected, not embraced. + +> We have the `load_images` switch, but we could add another option that allows you to select a subset of formats to never load. + +Firefox and Chrome both have the ability to disable WebP at runtime, so I think Dillo should too. + + + +--%-- +From: rodarima +Date: Tue, 26 Nov 2024 23:58:08 +0000 + +> I don't believe that Dillo should rush to endorse a new Google image format which doesn't provide a clear benefit over the existing well-tested formats, and which also faces security questions following a recent exploit. Unfortunately a few sites still insist on using WebP, but I think it's something to be rejected, not embraced. + +I don't have any interest in endorsing a Google format, I think the current JPEG and PNG are mostly okay. But that doesn't change the fact that websites are increasingly using WebP. + +Here is an example of usage from https://w3techs.com/technologies/history_overview/image_format/all/y: + + + +Here is the methodology: https://w3techs.com/technologies + +Another study from 2023: https://arxiv.org/pdf/2310.00788 + +If you want to change this trend, I don't think avoiding WebP support on Dillo will have any measurable impact. I would probably be better to convince web developers that it is not a good idea to use it. + +> also faces security questions following a recent exploit + +I have not studied that exploit or the quality of the code it affects to be able to make predictions for future RCEs. But keep in mind that the other image libraries are not free from CVEs: + +https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libpng +https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libjpeg +https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libwebp + +Same for the custom GIF and nanosvg decoders. These are not widely used, so it is likely that there is no interest in finding exploits for them. It doesn't mean they don't have RCE bugs. I would be a good idea to fuzz them. + +> Firefox and Chrome both have the ability to disable WebP at runtime, so I think Dillo should too. + +I don't think it is a bad idea to be able to disable them at runtime, it is probably an easy patch. + +--%-- +From: ghost +Date: Wed, 27 Nov 2024 10:30:08 +0000 + +> I don't have any interest in endorsing a Google format, I think the current JPEG and PNG are mostly okay. But that doesn't change the fact that websites are increasingly using WebP. +> +> Here is an example of usage from https://w3techs.com/technologies/history_overview/image_format/all/y: + +According to your links, WebP still has under 15% usage on the web. Out of that, I wonder how many of those sites even work on Dillo to begin with. + +There is also some concern about the future of the format, since the US is considering forcing the sale of Chrome (and WebP) to a potentially even more hostile corporation. + +> If you want to change this trend, I don't think avoiding WebP support on Dillo will have any measurable impact. I would probably be better to convince web developers that it is not a good idea to use it. + +It's perfectly reasonable to take a principled stand, while knowing full well you're not going to change the world. I don't think we are in a position to convince web developers of anything. + +> I don't think it is a bad idea to be able to disable them at runtime, it is probably an easy patch. + +Great, this would be the best compromise. + +--%-- +From: rodarima +Date: Wed, 27 Nov 2024 19:32:22 +0000 + +> It's perfectly reasonable to take a principled stand, while knowing full well you're not going to change the world. + +Dillo is a tool to render the Web (or at least a useful subset) in older/smaller computers. If you want to avoid using WebP, nobody is forcing you to use it, you can build Dillo with `--disable-webp` (or in the future via the config file). + +Refusing to implement support for WebP means that users that cannot use Firefox/Chrome due to computing constraints (like me sometimes) are left with not many choices (if at all) to load pages with WebP images. + +This may be a reasonable option to you, but may not be for everyone. That's why I prefer to give the users the choice to decide what they want. + +> Great, this would be the best compromise. + +Let's address this in another PR. + +I'll merge this if there are no more concerns.
\ No newline at end of file diff --git a/313/index.md b/313/index.md new file mode 100644 index 0000000..2225e11 --- /dev/null +++ b/313/index.md @@ -0,0 +1,9 @@ +Title: Pin FLTK to 1.3 in homebrew +Author: rodarima +Created: Wed, 27 Nov 2024 20:56:49 +0000 +State: closed + +Homebrew has updated the default version of FLTK to 1.4, which is causing rendering issues in Dillo. So for now, we build with FLTK 1.3 by pinning it. + +See: https://github.com/Homebrew/homebrew-core/pull/198029 +See: https://github.com/dillo-browser/dillo/issues/246
\ No newline at end of file diff --git a/314/index.md b/314/index.md new file mode 100644 index 0000000..80e1700 --- /dev/null +++ b/314/index.md @@ -0,0 +1,26 @@ +Title: Consider switching the CSS parser to flex + bison +Author: rodarima +Created: Sun, 01 Dec 2024 15:56:11 +0000 +State: closed + +Given that CSS is a context-free grammar, we may be able to switch to flex + bison and create a parser that can easily handle the latest CSS spec. Extending the current parser to add support for variables and functions can be done, but will likely require more effort. + +The CSS standard provides some reference grammar that we can use as a starting point, and it would make it much easier to read and be sure we are following the spec correctly. + +Notice that a page may cause a DoS by abusing the `calc()` functions. We may want to also consider a CPU budget per page, so we can stop hungry sites from hanging the browser. + +We would also need to consider how much the generated parser weights, not to exceed out release tarball size budget, as we are already at 90% of the floppy size. Considering only the `.l` and `.y` sources is not acceptable, as that would add flex and bison as a mandatory build dependency. Preliminary results show at least 50KiB (15KiB compressed) for the scanner and 60KiB+ (17KiB compressed) for the parser. + +--%-- +From: rodarima +Date: Wed, 04 Dec 2024 18:34:29 +0000 + +While CSS might be a context-free grammar, it has moved away from being easily described by a flex scanner and bison parser. All major rendering engines have moved to a recursive descend, and the whole specification has also moved to a recursive descend approach. + +The current CSS parser in dillo is also a recursive descend parser with "only" 1800 lines (56 KiB). LALR parsers have some benefits over RD, but I don't think they are particularly useful for Dillo. + +I think it would be better to wait until we see clear drawbacks with the current parser before we implement a new LALR parser. We can improve the current one first, specially the error reporting which is currently missing. + +A very different topic is why the CSS WG had decided to implement a painfully complicated language that cannot be easily scanned by ignoring whitespace. + +Closing for now.
\ No newline at end of file diff --git a/315/index.md b/315/index.md new file mode 100644 index 0000000..5196ac0 --- /dev/null +++ b/315/index.md @@ -0,0 +1,168 @@ +Title: Text sized with "pt" appears to be too big +Author: kaimac1 +Created: Tue, 03 Dec 2024 17:40:34 +0000 +State: closed + +I was looking at why some of the text on search.marginalia.nu is really big. + + <!doctype html> + <style>body {font-family: serif;}</style> + <span style="font-size:20px">20px text</span><br> + <span style="font-size:15pt">15pt text</span><br> + +In dillo vs firefox: + + + + + +--%-- +From: rodarima +Date: Tue, 03 Dec 2024 18:08:44 +0000 + +Thanks for the report, this may be related to your screen resolution. + +Which commit of Dillo are you using and what is your screen DPI? On Xorg I get: + +``` +% xdpyinfo | grep -B 2 resolution +screen #0: + dimensions: 1920x1080 pixels (483x272 millimeters) + resolution: 101x101 dots per inch +``` + +And renders "okay": + + + + +I have a patch to make marginalia render better, but is not public yet: + + + + + +--%-- +From: kaimac1 +Date: Tue, 03 Dec 2024 18:28:58 +0000 + +I'm running the latest commit, https://github.com/dillo-browser/dillo/commit/d4f56d0d8d07dd45600eca76551c011e290e4520 + + $ xdpyinfo | grep -B 2 resolution + screen #0: + dimensions: 3840x2160 pixels (621x341 millimeters) + resolution: 157x161 dots per inch + + +--%-- +From: rodarima +Date: Tue, 03 Dec 2024 19:06:50 +0000 + +I think that is correct for the pt units. + +A pt is defined as 1pt = 1/72 of an inch. So 15 pt is 0.2083 inches (or 5.29 mm). + +As your screen has ~160 pixels per inch, 15 pt = 15/72 in * 160 pixels/in = 33.3 pixels. + +I have marked in your image boundary lines at 20 px and 33 px: + + + +Now, the problem is that Dillo will render "20 px" as 20 screen pixels, while this is not the case for [the "px" unit used in CSS/HTML](https://www.w3.org/TR/css-values-4/#reference-pixel). A web px unit is the angle a pixel has in a 96 DPI at an arm length. So in your screen, 20 CSS pixels should be also around 20 * 160 / 96 = 33.3 screen pixels. + +This is something that will be addressed by FLTK 1.4.0, when we manage to solve the rest of the issues. + +Now, I don't know why on Firefox is being rendered that small, but that doesn't seem to be the size it should have. You can check this by making a div of, say, 5 inches (or 15 cm) and measuring it with a rule. + +```html +<!doctype html> +<html><head><title>Rule</title></head><style> +div { + background: lightgreen; + border: 1px solid black; + height:100px; + margin: 1em; +} +</style><body> +<div style="width:5in">5 inches wide</div> +<div style="width:15cm">15 cm wide</div> +</body></html> +``` + +--%-- +From: kaimac1 +Date: Tue, 03 Dec 2024 20:53:57 +0000 + +Ok, thanks for the info! + +What you are saying makes sense, which is that on my screen 15pt should be 33 pixels and 20px should also be around 33 pixels. + +Does this make sense as a possible explanation? + +According to [this](https://www.w3.org/Style/Examples/007/units.en.html#units), images should ("by default") be displayed such that one image pixel maps to 1px. And in firefox (and dillo), images are displayed with 1 image pixel = 1 display pixel. Therefore 1px = 1 pixel, which might explain why firefox's 20px text is 20 pixels high. And if 15pt should be about the same size as 20px, it will also be around 20 pixels. So rather than scaling images up by ~50%, the absolute pt/in/cm units are being scaled down ~33%. That's what I see with your ruler example - the 15cm div is only about 10cm long on my screen. That link also says that the absolute units are only required to be accurate on high resolution output devices, meaning printers. + +--%-- +From: rodarima +Date: Tue, 03 Dec 2024 21:42:30 +0000 + +> Does this make sense as a possible explanation? +> +> According to [this](https://www.w3.org/Style/Examples/007/units.en.html#units), images should ("by default") be displayed such that one image pixel maps to 1px. + + +I don't interpret this from the document: + +> A photo with a 600 by 400 resolution will be 600px wide and 400px high. The pixels in the photo thus do not map to pixels of the display device (which may be very small), but map to px units. + +One image pixel should be mapped to one CSS px unit (0.0213 degrees). So if you have a super high density screen, it will continue to have the same physical size (eye angle) as in a low density display, which is good. + +The CSS px units should be the same among images, divs or font sizes. + +You can see this by opening the above image in Firefox and Sxiv. In my case with 101 DPI is just slightly bigger, which is expected: + + + +> And in firefox (and dillo), images are displayed with 1 image pixel = 1 display pixel. + +In Dillo yes (our limitation), but in Firefox it shouldn't be the case. See: + + + +> Therefore 1px = 1 pixel, which might explain why firefox's 20px text is 20 pixels high. And if 15pt should be about the same size as 20px, it will also be around 20 pixels. + +I suspect that Firefox is assuming your screen has 96 DPI. Check: + +https://wiki.archlinux.org/title/HiDPI#X_Resources + +You can query what value you have in your system with `xrdb -query | grep dpi`, which should be around 160 not 96. + +After setting it to your DPI, you should see the 15 cm sized div measure 15 physical cm in Firefox (unless you have other scale settings). + +> So rather than scaling images up by ~50%, the absolute pt/in/cm units are being scaled down ~33%. That's what I see with your ruler example - the 15cm div is only about 10cm long on my screen. That link also says that the absolute units are only required to be accurate on high resolution output devices, meaning printers. + +I would say that not having the 15cm div measure 15cm means something is not well configured on your system if you were planning to have a scale factor of 1. + +--%-- +From: kaimac1 +Date: Tue, 03 Dec 2024 22:25:56 +0000 + +>> And in firefox (and dillo), images are displayed with 1 image pixel = 1 display pixel. +> In Dillo yes (our limitation), but in Firefox it shouldn't be the case. + +I think we disagree that this is a bad thing. It's not that Firefox has the "wrong" DPI, it's that it is essentially set to have a device pixel ratio of 1 pixel per "px", which I like. I don't want images to be upscaled and therefore slightly blurry. If I had a very high DPI display, maybe I would use a DPR of 2. + +A DPR of 1 necessarily means absolute units aren't the right size, unless you have a 96 DPI display, but that's ok. I think what you are saying is that the DPR should be set to a fractional value such that absolute units like inches are displayed correctly. I don't think that's right and I wouldn't want dillo to do that because it would mean blurry images - but I guess there'll be a setting for this when it's on the new FLTK version :) + +--%-- +From: rodarima +Date: Tue, 03 Dec 2024 22:50:30 +0000 + +> I think we disagree that this is a bad thing. It's not that Firefox has the "wrong" DPI, it's that it is essentially set to have a device pixel ratio of 1 pixel per "px", which I like. I don't want images to be upscaled and therefore slightly blurry. If I had a very high DPI display, maybe I would use a DPR of 2. + +I understand. I also don't think is a bad thing if you are explicitly configuring it that way. Nowadays, retina display are causing websites to use images with a size of at least double the CSS px size specified in their size, so they are still rendered okay in 2*96 DPIs displays. But not all websites do this, and it also incurrs in larger transfer sizes. + +> A DPR of 1 necessarily means absolute units aren't the right size, unless you have a 96 DPI display, but that's ok. I think what you are saying is that the DPR should be set to a fractional value such that absolute units like inches are displayed correctly. I don't think that's right and I wouldn't want dillo to do that because it would mean blurry images - but I guess there'll be a setting for this when it's on the new FLTK version :) + +Yeah, I think setting the DPI to 96 and knowing an inch won't match is fine. It also bothers me a bit when I see blurry images in Firefox, so I have an extra reason to go and use Dillo instead :) + +Feel free to close this if the pt concern is addressed.
\ No newline at end of file diff --git a/316/index.md b/316/index.md new file mode 100644 index 0000000..cea7b9c --- /dev/null +++ b/316/index.md @@ -0,0 +1,67 @@ +Title: Allow image formats to be disabled from dillorc +Author: rodarima +Created: Sun, 08 Dec 2024 15:40:31 +0000 +State: closed + +Makes disabling certain formats posible without the need to rebuild Dillo from source. + +See: https://github.com/dillo-browser/dillo/pull/312 + +--%-- +From: rodarima +Date: Sun, 08 Dec 2024 15:42:37 +0000 + +@xlex8 could you take a look at this PR? + +--%-- +From: ghost +Date: Sun, 08 Dec 2024 18:26:14 +0000 + +This branch is not compiling here: +... +c++ -DHAVE_CONFIG_H -I. -I.. -I.. -DDILLO_SYSCONF='"/usr/local/etc/dillo/"' -DDILLO_DOCDIR='"/usr/local/share/doc/dillo/"' -I/usr/local/include -I/usr/X11R6/include -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/X11R6/include/freetype2 -O2 -pipe -I/usr/local/include -fvisibility-inlines-hidden -I/usr/X11R6/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/usr/X11R6/lib -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -pedantic -std=c++11 -D_POSIX_C_SOURCE=200112L -MT tipwin.o -MD -MP -MF .deps/tipwin.Tpo -c -o tipwin.o tipwin.cc +version.cc:40:25: error: no member named 'api_version' in 'Fl' + int fltkver = Fl::api_version(); + ~~~~^ +1 error generated. + + +--%-- +From: rodarima +Date: Sun, 08 Dec 2024 18:36:18 +0000 + +> version.cc:40:25: error: no member named 'api_version' in 'Fl' + +Which FLTK version are you using? The method should be available on 1.3.X: + +https://www.fltk.org/doc-1.3/classFl.html#a7600b0ef3dcd4311850ab4b2988d5d6d + +--%-- +From: ghost +Date: Sun, 08 Dec 2024 18:53:15 +0000 + +Stock FLTK 1.3.3 here. Just did a new build of master with no errors, and also some older checkouts, so it seems to be a recent change. + +--%-- +From: rodarima +Date: Sun, 08 Dec 2024 19:05:37 +0000 + +> Stock FLTK 1.3.3 here. Just did a new build of master with no errors, and also some older checkouts, so it seems to be a recent change. + +Right, on 1.3.3 it was not available yet, I need to use Fl::version() instead. + +https://github.com/fltk/fltk/blob/release-1.3.3/src/Fl.cxx#L135C1-L135C12 + +Let me do a quick patch so it builds for you too. + +--%-- +From: rodarima +Date: Sun, 08 Dec 2024 19:16:01 +0000 + +Should be fixed in https://github.com/dillo-browser/dillo/pull/316/commits/486cdad55097d5ffd8128c28c9952bac0854ac95 + +--%-- +From: ghost +Date: Sun, 08 Dec 2024 19:45:17 +0000 + +Thanks, this PR appears to be working fine now!
\ No newline at end of file diff --git a/317/index.md b/317/index.md new file mode 100644 index 0000000..3398cd7 --- /dev/null +++ b/317/index.md @@ -0,0 +1,14 @@ +Title: Consider distrusting Entrust certificates after 2024-11-11 +Author: rodarima +Created: Sun, 08 Dec 2024 21:01:21 +0000 +State: open + +Following Chrome and Firefox, we may want to distrust Entrust certificated issued after November 11, 2024, following the concern on Entrust: + +https://security.googleblog.com/2024/06/sustaining-digital-certificate-security.html + +There is also more details in the Mozilla bugzilla: + +https://bugzilla.mozilla.org/buglist.cgi?o2=greaterthaneq&short_desc_type=casesubstring&o1=notequals&v1=Graveyard&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&classification=Graveyard&v2=2015-11-01&f1=classification&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&short_desc=Entrust&f2=creation_ts&component=CA%20Certificate%20Compliance&query_format=advanced&list_id=17064895 + +Reported-by: dogma
\ No newline at end of file diff --git a/318/index.md b/318/index.md new file mode 100644 index 0000000..d81f443 --- /dev/null +++ b/318/index.md @@ -0,0 +1,39 @@ +Title: Add git commit to the reported version with -v +Author: rodarima +Created: Mon, 09 Dec 2024 19:05:06 +0000 +State: closed + +When git is available, records the git commit in the dillo binary, so dillo -v reports the version and the commit. Otherwise only the release version is reported (as we do now). + +The commit is *always* recomputed when "make" is called. This allows switching branches, doing a dirty rebuild and still get the correct commit with "dillo -v". + +Using AC_INIT() doesn't update the commit when the source is already configured. + +Fixes: https://github.com/dillo-browser/dillo/issues/288 + +--%-- +From: rodarima +Date: Tue, 10 Dec 2024 17:35:48 +0000 + +Hi @xlex8, could you test this on OpenBSD? It should detect the git commit and report it with "dillo -v". It should say exactly "Dillo v3.1.1-114-g458776d7" in the first line. + +--%-- +From: ghost +Date: Tue, 10 Dec 2024 19:28:20 +0000 + +This works: +git clone --single-branch --branch report-git-commit https://github.com/dillo-browser/ +... +dillo$ src/dillo -v +Dillo v3.1.1-114-g458776d7 + + +--%-- +From: rodarima +Date: Tue, 10 Dec 2024 19:34:34 +0000 + +> This works: git clone --single-branch --branch report-git-commit https://github.com/dillo-browser/ ... dillo$ src/dillo -v Dillo v3.1.1-114-g458776d7 + +Nice!, thanks for the check. + +(Before it was failing because of the -b flag, which creates a new branch from master rather than switching to the one on the repo.)
\ No newline at end of file diff --git a/319/index.md b/319/index.md new file mode 100644 index 0000000..94f2a4f --- /dev/null +++ b/319/index.md @@ -0,0 +1,14 @@ +Title: Use Dillo user agent for downloads too +Author: rodarima +Created: Tue, 10 Dec 2024 18:56:43 +0000 +State: closed + +Send the user agent to the downloads DPI so we can use the same as Dillo uses from the http_user_agent option. + +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/A6IHJ4TBGHJ3CT2UOMEAROSG2WRTRO6U/ + +--%-- +From: ghost +Date: Wed, 11 Dec 2024 20:23:25 +0000 + +Thanks for this, seems to be working fine here!
\ No newline at end of file diff --git a/32/index.md b/32/index.md new file mode 100644 index 0000000..4f7dfb3 --- /dev/null +++ b/32/index.md @@ -0,0 +1,6 @@ +Title: Remove references to dillo.org from about:splash +Author: rodarima +Created: Sat, 23 Dec 2023 14:09:25 +0000 +State: closed + +The splash page still has references to `dillo.org`. We should make it self-contained so we don't rely on additional servers.
\ No newline at end of file diff --git a/320/index.md b/320/index.md new file mode 100644 index 0000000..fcdacdb --- /dev/null +++ b/320/index.md @@ -0,0 +1,6 @@ +Title: Fix FLTK version for old releases +Author: rodarima +Created: Tue, 10 Dec 2024 20:44:27 +0000 +State: closed + +The returned value from Fl::version() is a floating point number like 1.0303, not 10303, so we correct it to follow Fl::api_version().
\ No newline at end of file diff --git a/321/index.md b/321/index.md new file mode 100644 index 0000000..e4f8a5a --- /dev/null +++ b/321/index.md @@ -0,0 +1,6 @@ +Title: Avoid rebuild when the git commit is the same +Author: rodarima +Created: Wed, 11 Dec 2024 21:58:29 +0000 +State: closed + +Compare the commit used in the last rebuild to determine if it has changed, rather than using a phony target which always causes a rebuild.
\ No newline at end of file diff --git a/322/index.md b/322/index.md new file mode 100644 index 0000000..0cf4d7e --- /dev/null +++ b/322/index.md @@ -0,0 +1,136 @@ +Title: [GCC15] error: passing argument 2 of a_Timeout_add from incompatible pointer type [-Wincompatible-pointer-types] +Author: Kangie +Created: Thu, 12 Dec 2024 07:02:53 +0000 +State: closed + +``` +x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDILLO_SYSCONF='"/etc/dillo/"' -DDILLO_DOCDIR='"/usr/share/doc/dillo-3.1.1/"' -DCUR_WORKING_DIR='"/var/tmp/portage/www-client/dillo-3.1.1/work/dillo-3.1.1/src"' -I/usr/include/libpng16 -O2 -pipe -march=native -fno-diagnostics-color -DENABLE_I +cache.c: In function Cache_delayed_process_queue: +cache.c:1388:26: error: passing argument 2 of a_Timeout_add from incompatible pointer type [-Wincompatible-pointer-types] + 1388 | a_Timeout_add(0.0, Cache_delayed_process_queue_callback, NULL); + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +``` + +See: https://bugs.gentoo.org/944457 + +--%-- +From: rodarima +Date: Thu, 12 Dec 2024 19:21:44 +0000 + +Not sure what the problem is here: + +```c +/* timeout.hh */ +typedef void (*TimeoutCb_t)(void *data); +void a_Timeout_add(float t, TimeoutCb_t cb, void *cbdata); + +/* cache.c */ +static void Cache_delayed_process_queue_callback(void *ptr) +{ + /* ... */ +} + +static void Cache_delayed_process_queue(CacheEntry_t *entry) +{ + /* ... */ + a_Timeout_add(0.0, Cache_delayed_process_queue_callback, NULL); + /* ... */ +} +``` + +It is compiling ok on gcc trunk: https://godbolt.org/z/adPcq8G5d + +(GCC 15 is not released yet) + +Edit: Looking at the [logs](https://944457.bugs.gentoo.org/attachment.cgi?id=911544), it looks like a gcc bug: + +``` +cache.c: In function ‘Cache_delayed_process_queue’: +cache.c:1388:26: error: passing argument 2 of ‘a_Timeout_add’ from incompatible pointer type [-Wincompatible-pointer-types] + 1388 | a_Timeout_add(0.0, Cache_delayed_process_queue_callback, NULL); + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | | + | void (*)(void) +In file included from cache.c:37: +timeout.hh:10:41: note: expected ‘TimeoutCb_t’ {aka ‘void (*)(void *)’} but argument is of type ‘void (*)(void)’ + 10 | void a_Timeout_add(float t, TimeoutCb_t cb, void *cbdata); + | ~~~~~~~~~~~~^~ +make[3]: *** [Makefile:691: cache.o] Error 1 +``` + +The argument `Cache_delayed_process_queue_callback` seems to me to have type `void (*)(void *)`. + +--%-- +From: rodarima +Date: Wed, 22 Jan 2025 17:11:32 +0000 + +Closing, cannot reproduce. Reopen with steps to reproduce if this is still an issue. + +--%-- +From: NHOrus +Date: Mon, 24 Feb 2025 13:48:25 +0000 + +Install GCC-15 or pass `-std=gnu23` to GCC-14 as a cflag + +--%-- +From: NHOrus +Date: Mon, 24 Feb 2025 13:58:37 +0000 + +C23 forbids K&R style incomplete function declarations like `int f()`, it recognizes such declaration as `int f(void)` +see https://en.cppreference.com/w/c/language/function_declaration + +--%-- +From: NHOrus +Date: Mon, 24 Feb 2025 14:05:13 +0000 + +Patch looks like somewhat like this: +``` +--- a/src/cache.c ++++ b/src/cache.c +@@ -1359,7 +1359,7 @@ + /** + * Callback function for Cache_delayed_process_queue. + */ +-static void Cache_delayed_process_queue_callback() ++static void Cache_delayed_process_queue_callback(void *data) + { + CacheEntry_t *entry; + +--- a/src/jpeg.c ++++ b/src/jpeg.c +@@ -124,7 +124,7 @@ + * static void init_source(j_decompress_ptr cinfo) + * (declaring it with no parameter avoids a compiler warning) + */ +-static void init_source() ++static void init_source(struct jpeg_decompress_struct *cinfo) + { + } + +@@ -181,7 +181,7 @@ + * static void term_source(j_decompress_ptr cinfo) + * (declaring it with no parameter avoids a compiler warning) + */ +-static void term_source() ++static void term_source(struct jpeg_decompress_struct *cinfo) + { + } +``` + +--%-- +From: NHOrus +Date: Mon, 24 Feb 2025 14:40:20 +0000 + +This patch is for 3.1.1 and not 3.2.0, 3.2.0 builds without problem. + +Sorry about this. + +--%-- +From: rodarima +Date: Mon, 24 Feb 2025 17:24:16 +0000 + +Thanks, that explains why I couldn't reproduce the issue as I was using the tip of master while they were using the 3.1.1 release: + +> Unpacking dillo-3.1.1.tar.bz2 to /var/tmp/portage/www-client/dillo-3.1.1/work + +This should be fixed on 3.2.0 by 4d51150ca0aae979718ac10030df85421b763cd1.
\ No newline at end of file diff --git a/323/index.md b/323/index.md new file mode 100644 index 0000000..e16aceb --- /dev/null +++ b/323/index.md @@ -0,0 +1,37 @@ +Title: Don't complain (on the console) about missing files which aren't necessary +Author: eyalroz +Created: Mon, 16 Dec 2024 21:04:46 +0000 +State: closed + +What running dillo (3.1.1), I get: +``` +paths: Cannot open file '/home/eyalroz/.dillo/dillorc': No such file or directory +paths: Using /opt/dillo/etc/dillo/dillorc +paths: Cannot open file '/home/eyalroz/.dillo/keysrc': No such file or directory +paths: Using /opt/dillo/etc/dillo/keysrc +paths: Cannot open file '/home/eyalroz/.dillo/domainrc': No such file or directory +paths: Using /opt/dillo/etc/dillo/domainrc +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.3.2 3 Sep 2024 +Disabling cookies. +paths: Cannot open file '/home/eyalroz/.dillo/hsts_preload': No such file or directory +``` +Indeed, I don't have a `dillorc`, `keysrc`, or `domainrc`, and in fact no `.dillo`. But: + +1. That's not an error, it's perfectly legitimate not to have them. +2. Dillo doesn't create them to force them into existence. + +So - why report the files not being there as an error? And, in fact, why even try opening files in `~/.dillo` when it doesn't exist? Plus, you're already saying +``` +paths: Using /opt/dillo/etc/dillo/dillorc +paths: Using /opt/dillo/etc/dillo/keysrc +paths: Using /opt/dillo/etc/dillo/domainrc +``` +is that not sufficient? + +--%-- +From: rodarima +Date: Tue, 17 Dec 2024 04:55:59 +0000 + +There is no error, knowing the reason we cannot use dillorc is useful.
\ No newline at end of file diff --git a/324/index.md b/324/index.md new file mode 100644 index 0000000..0d4c1f2 --- /dev/null +++ b/324/index.md @@ -0,0 +1,18 @@ +Title: Text in right-to-left languages is rendered left-to-right +Author: eyalroz +Created: Mon, 16 Dec 2024 21:17:02 +0000 +State: open + +About 8% of the world uses a right-to-left script for their native language. A much larger fraction (probably over 15%) use an RTL script for a secondary language. And yet - dillo does not seem to support right-to-left scripts. Taking the most common one, Arabic: When we visit a website in Arabic, e.g.: + +https://ar.wikipedia.org/ + +both the text on the tab, and in the rendered page, is rendered left-to-right (also, with the letters disconnected, but that will probably work better when you use a proper Unicode rendering engine). Diacritics also seem to be messed up (they're done through character which result in modifier glyphs). + +--%-- +From: rodarima +Date: Tue, 17 Dec 2024 04:58:43 +0000 + +RTL support would be nice, but I would need some help as I don't know any RTL language. Feel free to work on a patch. + +Diacritics and other modifiers are a completely different issue, possibly fixed on the new FLTK, so lets focus on RTL first.
\ No newline at end of file diff --git a/325/index.md b/325/index.md new file mode 100644 index 0000000..bb1e25a --- /dev/null +++ b/325/index.md @@ -0,0 +1,8 @@ +Title: Fix build error for missing commit.h +Author: rodarima +Created: Tue, 17 Dec 2024 09:27:29 +0000 +State: closed + +Add the target commit.h as a dependency of version.o, so it gets +generated before being included in version.cc, otherwise when doing a +parallel build it can fail. diff --git a/326/index.md b/326/index.md new file mode 100644 index 0000000..ce6a890 --- /dev/null +++ b/326/index.md @@ -0,0 +1,20 @@ +Title: Add support for user actions in the link menu +Author: rodarima +Created: Tue, 17 Dec 2024 21:48:21 +0000 +State: closed + +Allows the user to define additional entries in the link menu which will +execute the given program/script. Each actions is defined using the +"link_action" option. The link URL is stored in the $url enviroment +variable and the current page in $origin, so the user can customize how +do the handling. + +Here is a simple example to add three new entries: + + link_action="Debug variables:echo url=$url origin=$origin" + link_action="Open in MPV:mpv $url" + link_action="Open in Firefox:firefox $url" + +The command is spawned in a forked process using the system() call, +which uses the shell to expand any variable. In particular, the $url +variable is set to the current URL being opened. diff --git a/327/index.md b/327/index.md new file mode 100644 index 0000000..e3675ba --- /dev/null +++ b/327/index.md @@ -0,0 +1,45 @@ +Title: ebay.com not loading +Author: rodarima +Created: Thu, 19 Dec 2024 12:48:03 +0000 +State: closed + +When loading https://www.ebay.com, an error appears on Dillo: + +``` +Service Unavailable - Zero size object +The server is temporarily unable to service your request. Please try again later. +Reference #15.3dc21302.1734611720.1dedf3d2 +https://errors.edgesuite.net/15.3dc21302.1734611720.1dedf3d2 +``` + +The site loads well on w3m and links. + +Setting `http_user_agent="w3m/0.5.3+git20230129"` makes Dillo load the site +properly. + + +--%-- +From: rodarima +Date: Sat, 21 Dec 2024 20:43:19 +0000 + +Same with https://www.blick.ch/. This is likely Akamai. + + +--%-- +From: rodarima +Date: Sun, 22 Dec 2024 17:36:00 +0000 + +Reported to Akamai. + + +--%-- +From: JessFairbairn +Date: Thu, 09 Jan 2025 16:41:39 +0000 + +Off topic, but wow having a whitelist of useragents is so against how the web is meant to work. + +--%-- +From: rodarima +Date: Sat, 11 Jan 2025 17:20:39 +0000 + +3 weeks with no reply, giving up. Ticket: F-CS-9320406
\ No newline at end of file diff --git a/328/index.md b/328/index.md new file mode 100644 index 0000000..8df809c --- /dev/null +++ b/328/index.md @@ -0,0 +1,16 @@ +Title: High speed wheel causes erratic scroll +Author: rodarima +Created: Thu, 19 Dec 2024 13:13:29 +0000 +State: closed + +When scrolling a page using a mouse wheel, the scroll seems to work well until +the speed at which the mouse wheel is too fast. At that point the page scrolls +erratically, as if we loose events or they arrive with the opposite direction. + + +--%-- +From: rodarima +Date: Sun, 22 Dec 2024 15:25:24 +0000 + +This is caused by my mouse, the same behavior is shown in xev. It looks like +after some speed it starts to send events in the opposite direction. Closing. diff --git a/329/index.md b/329/index.md new file mode 100644 index 0000000..faecdf5 --- /dev/null +++ b/329/index.md @@ -0,0 +1,27 @@ +Title: Windows build with MSCV of Dillo +Author: andreasrosdal +Created: Fri, 20 Dec 2024 12:16:57 +0000 +State: closed + +Please make Windows build with MSCV of Dillo, so Dillo can run natively on Windows. + +--%-- +From: andreasrosdal +Date: Fri, 20 Dec 2024 12:17:26 +0000 + +I started with a branch here: https://github.com/andreasrosdal/dillo/ + +--%-- +From: rodarima +Date: Fri, 20 Dec 2024 14:11:23 +0000 + +> I started with a branch here: https://github.com/andreasrosdal/dillo/ + +Nice! + +Dillo can be executed on Windows by using Cygwin and WSL. I won't oppose +to add native MSVC or MinGW support as long as you are willing to +implement it *and maintain it*, as I don't have enough expertise on that +area and I'm not a Windows user. + +Check out also: https://sourceforge.net/projects/dillo-win32/ diff --git a/33/index.md b/33/index.md new file mode 100644 index 0000000..455a86e --- /dev/null +++ b/33/index.md @@ -0,0 +1,199 @@ +Title: Add support for OpenSSL 1.1 +Author: rodarima +Created: Sat, 23 Dec 2023 14:25:39 +0000 +State: closed + +The function is not available in OpenSSL 1.1 with the `_get` suffix. + +--%-- +From: rodarima +Date: Sat, 23 Dec 2023 14:26:53 +0000 + +Can you test it works with OpenSSL 1.1, @th-otto ? + +--%-- +From: th-otto +Date: Sat, 23 Dec 2023 16:24:02 +0000 + +I cannot test it on linux anymore, because i cannot simultaneously install development packages for both openssl 1.1.0 and openssl-3, because they conflict with each other. + +Your patch is not yet merged, so i had to apply it manually. But i get other error, when trying to cross-compile for mint (with openssl 1.1.1 libraries installed) +(have to specifiy LIBS=-lz when running the configure script, because of all libraries being static only): +``` +$ PKG_CONFIG_PATH=/usr/m68k-atari-mint/lib/pkgconfig ./configure LIBS="-lz" --disable-threads --prefix=/usr --host=m68k-atari-mint +... +Configuration summary: + + CXX : m68k-atari-mint-g++ + CXXFLAGS: -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions + + TLS enabled: yes + TLS library: OpenSSL + TLS flags : -lcrypto -lssl + + Cookies enabled: yes + XEmbed enabled : yes + RTFL enabled : no + JPEG enabled : yes + PNG enabled : yes + GIF enabled : yes + +$ make + +m68k-atari-mint-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -DDILLO_BINDIR='"/usr/bin/"' -DCA_CERTS_FILE='""' m68k-atari-mint-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -DDILLO_BINDIR='"/usr/bin/"' -DCA_CERTS_FILE='""' -DCA_CERTS_DIR='""' -I/usr/local/include -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter -Waggregate-return -MT tls_openssl.o -MD -MP -MF .deps/tls_openssl.Tpo -c -o tls_openssl.o tls_openssl.c +tls_openssl.c: In function 'Tls_examine_certificate': +tls_openssl.c:839:10: error: a label can only be part of a statement and a declaration is not a statement + X509_NAME *subject_name = X509_get_subject_name(remote_cert); + ^~~~~~~~~ +tls_openssl.c:840:10: error: expected expression before 'char' + char *subj = X509_NAME_oneline(subject_name, NULL, 0); + ^~~~ +tls_openssl.c:841:27: error: 'subj' undeclared (first use in this function) + if ((cn = strstr(subj, "/CN=")) == NULL) { + ^~~~ +tls_openssl.c:841:27: note: each undeclared identifier is reported only once for each function it appears in +tls_openssl.c:839:21: warning: unused variable 'subject_name' [-Wunused-variable] + X509_NAME *subject_name = X509_get_subject_name(remote_cert); + ^~~~~~~~~~~~ +``` + +Although it does not seem to cause problems for this particular case, the ``-I/usr/local/include`` does not belong there when cross-compiling (maybe that slipped in from checking for the X11-libraries? did not check yet) + +Compiler is gcc-7.5.0 + + +--%-- +From: rodarima +Date: Sat, 23 Dec 2023 17:01:05 +0000 + +> Your patch is not yet merged, so i had to apply it manually. + +I'll wait until I can setup some automatic tests for OpenSSL 1.1 before merging this. + +> ``` +> m68k-atari-mint-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -DDILLO_BINDIR='"/usr/bin/"' -DCA_CERTS_FILE='""' m68k-atari-mint-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -DDILLO_BINDIR='"/usr/bin/"' -DCA_CERTS_FILE='""' -DCA_CERTS_DIR='""' -I/usr/local/include -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter -Waggregate-return -MT tls_openssl.o -MD -MP -MF .deps/tls_openssl.Tpo -c -o tls_openssl.o tls_openssl.c +> tls_openssl.c: In function 'Tls_examine_certificate': +> tls_openssl.c:839:10: error: a label can only be part of a statement and a declaration is not a statement +> X509_NAME *subject_name = X509_get_subject_name(remote_cert); +> ^~~~~~~~~ +> ``` + +I cannot reproduce this in any of my setups, but it is indeed an error. I pushed a tentative fix. + +> Although it does not seem to cause problems for this particular case, the `-I/usr/local/include` does not belong there when cross-compiling (maybe that slipped in from checking for the X11-libraries? did not check yet) + +This is likely caused by either `$CPP -v` reporting the directory to be used (see [configure.ac](https://github.com/dillo-browser/dillo/blob/80732c652e923981c43a730c2704e1c6876bd3e6/configure.ac#L151-L154)), or by `fltk-config --cxxflags` if installed in /usr/local. + +As a workaround if your cross-compiler doesn't outputs "/usr/local/include" you can add `CPP=m68k-atari-mint-g++` to the configure line. Otherwise, just remove or comment the configure.ac part in which the include is added. + +For `fltk-config` I don't have a solution yet, maybe adding something like this after the detection of the [FLTK flags in configure.ac](https://github.com/dillo-browser/dillo/blob/80732c652e923981c43a730c2704e1c6876bd3e6/configure.ac#L203-L213): + +``` +LIBFLTK_CFLAGS=`echo $LIBFLTK_CFLAGS | tr '-I/usr/local/include' ' '` +LIBFLTK_CXXFLAGS=`echo $LIBFLTK_CXXFLAGS | tr '-I/usr/local/include' ' '` +``` + +--%-- +From: th-otto +Date: Sat, 23 Dec 2023 17:36:27 +0000 + +> I cannot reproduce this in any of my setups, but it is indeed an error. I pushed a tentative fix. + +Yes, strangely gcc-13 seems to accept this, although it is clearly an error, atleast in non-C++ code. Your workaround fixed this. + +> This is likely caused by either `$CPP -v` reporting the directory to be used (see [configure.ac](https://github.com/dillo-browser/dillo/blob/80732c652e923981c43a730c2704e1c6876bd3e6/configure.ac#L151-L154)), or by `fltk-config --cxxflags` if installed in /usr/local. + +Maybe, i have to check that. If configure.ac invokes fltk-config, that may indeed be a problem when cross-compiling. +Unfortunately FLTK does not seem to install a pkg-config script. In the meantime, i think it would be best to force the user to specify the FLTK_CFLAGS & LIBS when cross-compiling. + +However, the -I/usr/local/include does not seem to come from the fltk-config script, they are part of $CPPFLAGS (although i specified --prefix=/usr). Same for LDFLAGS: they are set to -L/usr/lib. That will even be wrong when compiling natively (eg. on openSUSE, fedora and others, 64-bit libraries are installed in /usr/lib64, and linking with -L/usr/lib wil give a warning atleast from the linker about incompatible libraries). + +For further tests, i need cross-compiled FLTK libraries first. + + +--%-- +From: th-otto +Date: Sat, 23 Dec 2023 19:33:26 +0000 + +After fiddling with configure.ac (for X11 libs, and also for libpng), i can confirm that building with openssl 1.1.1 works: + + + +Only dns lookups do not seem to work yet (maybe same problem that medmed had). But it does not completely freeze, it times out after about a 1-2 min. + + +--%-- +From: rodarima +Date: Sat, 23 Dec 2023 19:50:31 +0000 + + +> After fiddling with configure.ac (for X11 libs, and also for libpng), i can confirm that building with openssl 1.1.1 works: + +Amazing :-) + +> +> Only dns lookups do not seem to work yet (maybe same problem that medmed had). But it does not completely freeze, it times out after about a 1-2 min. + +Do you see any messages in the terminal? As a quick test, you could try to disable the threaded DNS resolver by using `--disable-threaded-dns` in case that could be affecting you as it was [causing problems in BSD](https://github.com/dillo-browser/dillo/blob/master/doc/install.md#bsd). + +Can you resolve other hosts from the machine?, does `curl -v google.com`? If you don't have Curl, here is a test you can try with the OpenSSL CLI (which you may already have available): +``` +$ echo | openssl s_client -showcerts -connect google.com:443 +``` + +--%-- +From: rodarima +Date: Sat, 23 Dec 2023 20:07:55 +0000 + +> After fiddling with configure.ac (for X11 libs, and also for libpng) + +Also, can you share your patch/changes?, so I can also understand which parts are not working properly. + +> Maybe, i have to check that. If configure.ac invokes fltk-config, that may indeed be a problem when cross-compiling. +> Unfortunately FLTK does not seem to install a pkg-config script. In the meantime, i think it would be best to force the user to specify the FLTK_CFLAGS & LIBS when cross-compiling. + +That solution sounds good to me, in case you want to make a MR :-) + +> However, the -I/usr/local/include does not seem to come from the fltk-config script, they are part of $CPPFLAGS (although i specified --prefix=/usr). + +Then, it is likely to be coming from the `CPP` variable, (notice `CC != CXX != CPP`). You can comment or remove those lines from the `configure.ac` if they cause you any trouble. + +Adding `/usr/local/include` is required in some BSD systems, as they install some headers/libs there (from ports). This also breaks BSD builds in other obscure ways (like using a header from `/usr/include/local` but linking with the library in `/usr/lib`), so we would need to find a better solution anyway. + +--%-- +From: th-otto +Date: Sun, 24 Dec 2023 10:09:35 +0000 + +> Do you see any messages in the terminal? + +There are no error messages, it just times out after some time with the message +``Dns_server [0]: <hostname> is (nil)`` + +But seems to be a bit random. Sometimes it works. Maybe just a problem with my setup (using aranym with a bridge to the host), since sometimes other network connections also fail. I've always used --disable-threaded-dns, since the only thread implementation currently available is pth, and that is non-preemptive and just causes problems because of this. + +>Adding /usr/local/include is required in some BSD systems + +I have disabled that currently when using gcc, since gcc should always look in that directories by default. Should that cause problems on BSD system, the test could also be changed to ``if test "$cross_compiling" = no`` + +Other things that i changed: looking for png library uses png-config. I've tested it also on linux, but may need some testing for other systems. + +For FLTK i currently just use -lfltk when cross-compiling, since it does not seem to require any special cflags. Maybe that test could also be changed to some ``AC_CHECK_LIB``. + +The dpi programs have to be linked explicitly to the x11 libraries. This is again only needed because of static libraries, but should not hurt on other systems. + +Searching for openssl also uses pkg-config now. I have no mbedtls yet, so i don't know what files are installed there. + +All in all the patches aren't that large, so if you don't want to apply them, i can just keep them as mint-specific patches. + +But note that this is all quite experimental. There are other quirks currently, some drawing problems (which i suspect to be fVDI problems in combination with aranym), the tooltips sometimes immediately disappearing again etc. And of course that X.App that is needed is also quite experimental. + +However the rendering always is quite strange, also in the linux version of dillo. Maybe some features of CSS that are not implemented yet? + +[dillo.patch.txt](https://github.com/dillo-browser/dillo/files/13761123/dillo.patch.txt) + + +--%-- +From: rodarima +Date: Sun, 24 Dec 2023 14:20:57 +0000 + +I would like to continue the discussion for Atari support here https://github.com/dillo-browser/dillo/issues/34, as I want this PR to be focused on the support for OpenSSL 1.1 only. The other issues we can deal in other PR, so we break them into small changes.
\ No newline at end of file diff --git a/330/index.md b/330/index.md new file mode 100644 index 0000000..693b0a3 --- /dev/null +++ b/330/index.md @@ -0,0 +1,15 @@ +Title: Allow line fragments in plain text documents +Author: rodarima +Created: Fri, 27 Dec 2024 23:03:12 +0000 +State: closed + +There are some cases in which I need to share a link to an specific line +in a text file and it would be nice to be able to do it in a URL: + +- Sharing a link to a GitHub source file by going to the raw file (not the JS + CPU toaster) +- Link to a given line in a CSS file +- Plain text pastes + +Using `http://foo.bar/file.txt#L128` or simply `http://foo.bar/file.txt#128` +seems sane. diff --git a/331/index.md b/331/index.md new file mode 100644 index 0000000..6791123 --- /dev/null +++ b/331/index.md @@ -0,0 +1,9 @@ +Title: Support line fragments in plain text files +Author: rodarima +Created: Fri, 27 Dec 2024 23:55:58 +0000 +State: closed + +Line numbers can be referenced using the fragment L + line number. For +example, file://foo/bar.txt#L42 will cause Dillo to scroll to line 42. + +Fixes: https://github.com/dillo-browser/dillo/issues/330 diff --git a/332/index.md b/332/index.md new file mode 100644 index 0000000..f2ff178 --- /dev/null +++ b/332/index.md @@ -0,0 +1,57 @@ +Title: Doubled border/phantom box for images with block display style +Author: bblhd +Created: Sun, 29 Dec 2024 03:03:22 +0000 +State: open + +Hello! When styling an image in dillo, if you give it the property `display: block;` and also a border, such as `border: 1px solid black;`, it will draw two borders around the image, one around the image itself, and one where the image's margin should be, also doubling the margin. + +It seems to be creating a box around the image with the same style properties as the image? + +### Minimal demonstration: +``` +<!DOCTYPE html> +<html> +<head> +<title>Demonstation</title> +<style>*{margin: 10px; padding 10px; border: 5px solid black; display: block;}</style> +</head> +<body> +<div style='border-color: blue;'> +<img style='border-color: red;' src='https://upload.wikimedia.org/wikipedia/commons/thumb/f/f3/Youngkitten.JPG/320px-Youngkitten.JPG'/> +</div> +</body> +</html> +``` + +### How dillo renders it (for me): + + + +--%-- +From: rodarima +Date: Sun, 29 Dec 2024 15:57:04 +0000 + +Thanks for the report, it is hard to find a proper issue nowadays, even less +with a working reproducer. + +This seems to be coming from the current implementation for block and +display-block, which is internally done by wrapping the image in another +container which seems to be also getting the same style. + +I'll try to find a quick workaround. Otherwise I'll probably address this after +3.2.0, as this may require changing the way the block elements are implemented. + + +--%-- +From: joshas +Date: Thu, 02 Jan 2025 18:54:19 +0000 + +Are you aware, that by using CSS universal selector *, you are styling all HTML elements on the page, including `<html>` and `<body>` ? Interesting to note, that Dillo does not render `<head>`, `<title>` and `<style>` elements, when they get `display: block` style applied. + +--%-- +From: bblhd +Date: Fri, 03 Jan 2025 01:55:36 +0000 + +> Are you aware, that by using CSS universal selector *, you are styling all HTML elements on the page, including `<html>` and `<body>` ? + +Yes, hence the differently coloured borders, though I didn't know that some browsers could interpret head/title/style tags as block elements until today
\ No newline at end of file diff --git a/333/index.md b/333/index.md new file mode 100644 index 0000000..0ae9280 --- /dev/null +++ b/333/index.md @@ -0,0 +1,132 @@ +Title: Add CMake build +Author: MoAlyousef +Created: Fri, 03 Jan 2025 08:46:37 +0000 +State: open + +Hello @rodarima + +This PR adds a CMake build to dillo. +It by default uses FLTK 1.4. I tried getting FLTK 1.3 to work with CMake but unfortunately the distro-packaged FindFLTK.cmake or FLTKConfig.cmake are broken in some form for 1.3 on several systems like alpine, cygwin, freebsd and macos! + +The CMakeLists.txt tries `find_package(FLTK 1.4 CONFIG)` and if it can't, it fetches the sources and builds FLTK. The CI actions do that, however when FLTK 1.4 is already installed, it finds it without issues. The PR also contains a `.github/workfows/cmake.yml`. +Once FLTK 1.4 is packaged for debian/ubuntu, I plan to modify the script and remove the FetchContent part. + +There are many small commits which attempt to fix the CI, these can be squashed if you choose to merge the PR. + + +--%-- +From: rodarima +Date: Mon, 06 Jan 2025 13:50:25 +0000 + +Thanks!, it looks good overall. I'll take a closer look when I find some +time. I think we can squash all commits into a single commit. + +About FLTK 1.4, it is not working well just yet, so we will need to find a way +to make it find FLTK 1.3 in the meanwhile. + +Have you had a chance to test cross-compilation? Is one of the reasons I wanted +to change the build system. + + +--%-- +From: MoAlyousef +Date: Mon, 06 Jan 2025 16:41:08 +0000 + +Cross-compilation works, this jobs compiles from linxu x86-64 to aarch64: +https://github.com/MoAlyousef/dillo/actions/runs/12636324124/job/35208135068 + +Regarding FLTK 1.3, I think I can add a cmake script which manually tries to find the libraries since the FindFLTK.cmake that's distributed with CMake seems broken on some systems. Making cross-compilation work with that might be more difficult. + +--%-- +From: rodarima +Date: Mon, 06 Jan 2025 18:03:34 +0000 + +> Cross-compilation works, this jobs compiles from linxu x86-64 to aarch64: +> https://github.com/MoAlyousef/dillo/actions/runs/12636324124/job/35208135068 + +Thanks!, that's nice. + +> Regarding FLTK 1.3, I think I can add a cmake script which manually tries to +> find the libraries since the FindFLTK.cmake that's distributed with CMake +> seems broken on some systems. + +Here is the FindFLTK module: + +<https://gitlab.kitware.com/cmake/cmake/-/raw/master/Modules/FindFLTK.cmake> + +In my current system (Arch Linux with FLTK 1.3.9) using: + + set(CMAKE_FIND_DEBUG_MODE TRUE) + find_package(FLTK 1.3 REQUIRED) + set(CMAKE_FIND_DEBUG_MODE FALSE) + +It is also failing if I set the `FLTK_DIR` to the directory that contains the +FLTKConfig.cmake file with: + + CMake Error at /usr/share/cmake/Modules/FindFLTK.cmake:189 (load_cache): + load_cache Cannot load cache file from /usr/share/fltk/CMakeCache.txt + Call Stack (most recent call first): + CMakeLists.txt:81 (find_package) + +As it is trying to load the CMakeCache, but it is not distributed in the fltk +package. Not sure if this is Arch Linux fault or FLTK 1.3.9 forgot to install +it. + +Not setting `FLTK_DIR` causes cmake to fail (also weird) when locating the +FindConfig.cmake file, which then fallbacks to using fltk-config and it works: + + -- Found FLTK: /usr/lib/libfltk_images.so;/usr/lib/libfltk_forms.so;/usr/lib/libfltk_gl.so;/usr/lib/libfltk.so (Required is at least version "1.3") + +But there is no targets defined for FLTK 1.3 so using fltk::fltk fails. This +method will still fail when using cross compilation as fltk-config won't run. + +Trying to locate the libraries by hand and making our own fltk::fltk target is +probably the best choice as it will also work well with cross-compilation, but +I'm not sure how to detect which other dependant libraries are also needed. + + +--%-- +From: MoAlyousef +Date: Mon, 06 Jan 2025 19:18:30 +0000 + +I've replaced fltk::fltk with ${DILLO_FLTK_LIBS} and used that across the modules. The build is green currently on all platforms. It still remains quite fragile. FLTK itself directs devs to use `find_package(FLTK CONFIG)`, however the packaged FLTK in distros is sometimes built using autoconf (like on macos, freebsd and cygwin for example), this makes the CONFIG value useless. +This PR currently uses `find_package(FLTK REQUIRED)`, since even setting the version to 1.3 might not work! + +The only job that uses FLTK 1.4 is the cross-compilation one. To use FLTK 1.4, devs would have to pass `-DENABLE_FLTK_1_4=ON` to cmake. + + +--%-- +From: rodarima +Date: Sun, 12 Jan 2025 17:06:00 +0000 + +Thanks, I don't think we can rely on CONFIG as you comment. However, it would be nice to complain if FLTK is 1.4 (unless explicitly told so) as it will cause rendering issues even if it builds fine. + +As long as we have a way to pass the installation path (libs and headers) of FLTK (avoiding fltk-config) I think that would be enough for cross-compilation. + +Rebasing over a882875c324f9404351b1b9d3a095d7da4984ba9 will likely fix the CI. + +--%-- +From: MoAlyousef +Date: Sun, 12 Jan 2025 18:33:11 +0000 + +I've added a warning in the CMake script when targeting FLTK 1.4 (targeting of which already requires a feature flag ENABLE_FLTK_1_4). I've also squashed and rebased. + +--%-- +From: Kangie +Date: Thu, 30 Jan 2025 00:30:50 +0000 + +I still _highly_ recommend meson as the alternative bulid system when compared to CMake for maintainability, readability, (etc). #263 is effectively complete, pending only a rebase. @rodarima will you consider that as an alternative? + +I'm also happy to maintain it side-by-side with CMake if that is desirable, but either is better than Autotools. + +--%-- +From: Kangie +Date: Thu, 30 Jan 2025 05:20:59 +0000 + +As an aside, this CMake port seems to be done pretty well, my biggest gripe being that it's, well, CMake. My only feedback is that you need EOF newlines on most of the new files. + +--%-- +From: MoAlyousef +Date: Thu, 30 Jan 2025 09:03:53 +0000 + +I’m fine with either build generators. Both are cross-platform, can generate compile_commands.json (for extra tooling), and support cross-compilation.
\ No newline at end of file diff --git a/334/index.md b/334/index.md new file mode 100644 index 0000000..d23fd88 --- /dev/null +++ b/334/index.md @@ -0,0 +1,116 @@ +Title: Reader Mode using rdrview +Author: dflock +Created: Fri, 03 Jan 2025 16:59:53 +0000 +State: closed + +The https://github.com/eafer/rdrview project is an implementation of Firefox's Reader View as a command line tool. It's written in C, and seems to work well. + +I think an option to use rdrview, in combination with the exiting user mode CSS would be a really useful feature. It does a great job of distilling the page's HTML into a much simpler version (`rdrview --html` for html output) - which would be much more predictable and vastly simpler to style using user/reader mode CSS. + +--%-- +From: rodarima +Date: Mon, 06 Jan 2025 00:13:36 +0000 + +> The https://github.com/eafer/rdrview project is an implementation of Firefox's +> Reader View as a command line tool. It's written in C, and seems to work well. +> +> I think an option to use rdrview, in combination with the exiting user mode +> CSS would be a really useful feature. It does a great job of distilling the +> page's HTML into a much simpler version (`rdrview --html` for html output) - +> which would be much more predictable and vastly simpler to style using +> user/reader mode CSS. + +You can extend Dillo with plugins to implement any automatic transformation that +you want. Here is a simple plugin in bash that runs rdrview and shows the page +in Dillo: + +```sh +#!/bin/bash +# Copyright (c) 2025 Rodrigo Arias Mallo +# SPDX-License-Identifier: GPL-3.0-or-later + +IFS= read -d '>' auth # Ignore auth +IFS= read -d '>' cmd +dir="$(dirname $(readlink -f $0))" + +case "$cmd" in + "<cmd='open_url' url='"*);; + *) echo $cmd; exit;; +esac + +url=${cmd#"<cmd='open_url' url='"} +url=${url%"' '"} + +serve_error() { + printf "<cmd='start_send_page' url='' '>\n" + printf "Content-type: text/plain\r\n\r\n" + echo "Error: $@" + exit 0 +} + +serve_page() { + set -x + url="$1" + url=${url#"rdrview:"} + + printf "<cmd='start_send_page' url='' '>\n" + printf "Content-type: text/html\r\n\r\n" + echo "<!DOCTYPE html>" + echo "<html>" + echo "<head>" + # Optional: + #echo "<style>" + #cat "$dir/style.css" + #echo "</style>" + echo "</head>" + echo "<body>" + rdrview -E utf-8 --html "$url" + echo "</body>" + echo "</html>" +} + +case "$url" in + rdrview:*) serve_page "$url";; + *) serve_error "unknown URL: ${url}";; +esac +``` + +I did a quick test but I find that sites don't really work that well as you seem +to suggest. I'll be happy to see a reasonably sized sample of sites that improve +substantially when using rdrview to consider adding it in a new git repo as a +new plugin. + +We should add a mechanism to open the current page in a external tool, so that +the resulting outcome can be loaded in the same page or in a new tab. I'll need +to think about how to do it, probably with a CLI tool that can just open a new +tab like the new `link_action` option: + + page_action="Open in reader mode:dillocli new-tab rdrview:$url" + +For now just prepend rdrview: in front of the URL you want to transform. Refer +to the user manual and the other plugins to see how to install and use it. + + +--%-- +From: rodarima +Date: Tue, 07 Jan 2025 18:16:45 +0000 + +Some pages seem to improve with rdrview, so I assume it can still be useful. + +I uploaded the plugin here: <https://github.com/dillo-browser/dillo-plugin-rdrview> + +For now you will need to manually type the `rdrview:` prefix to enable the +reader mode, but I plan to make this type of transformations easier in the +future so you can do it from the menu or maybe with a keyboard shortcut. + +I think we can close this issue now, as the basic support for rdrview is +available and address the rest of the improvements in other issues. + + +--%-- +From: dflock +Date: Tue, 07 Jan 2025 23:00:05 +0000 + +Thank you for you help, this is awesome! I'll try out the plugin :) + +As you say, readability doesn't work well/at all on every page, depends on the HTML, but when it works, it's pretty great.
\ No newline at end of file diff --git a/335/index.md b/335/index.md new file mode 100644 index 0000000..1d25e34 --- /dev/null +++ b/335/index.md @@ -0,0 +1,31 @@ +Title: AVIF/AV1 image support +Author: dflock +Created: Fri, 03 Jan 2025 17:32:49 +0000 +State: closed + +It would be great if dillo supported avif images. Here are some resources that might be useful when implementing: + +- https://en.wikipedia.org/wiki/AVIF +- avif spec: https://aomediacodec.github.io/av1-avif/ +- avif decode library: https://github.com/AOMediaCodec/libavif + - other options for decoding: + - https://github.com/strukturag/libheif + - https://sail.software/ +- Recent pr for adding webp support: https://github.com/dillo-browser/dillo/commit/b9e801cb940b45cfd9a4cf95bf5af68b084156b4 + +--%-- +From: rodarima +Date: Mon, 06 Jan 2025 00:34:03 +0000 + +> It would be great if dillo supported avif images. + +I don't think so, at least not yet. Every time we add support for a new image +decoder, we increase the surface for new attacks. [Here][1] you can see that +only 0.4% of set of sites use AVIF. + +[1]:https://w3techs.com/technologies/overview/image_format + +I'll wait until it is more widely adopted. + +Notice that this has nothing to do of how good or bad is AVIF as an image +format. diff --git a/336/index.md b/336/index.md new file mode 100644 index 0000000..90a1df5 --- /dev/null +++ b/336/index.md @@ -0,0 +1,5 @@ +Title: Release version 3.2.0-rc1 +Author: rodarima +Created: Sun, 12 Jan 2025 15:56:16 +0000 +State: closed + diff --git a/337/index.md b/337/index.md new file mode 100644 index 0000000..57bc28e --- /dev/null +++ b/337/index.md @@ -0,0 +1,266 @@ +Title: [Dpi_read_comm_keys] No such file or directory on Cygwin +Author: niutech +Created: Tue, 14 Jan 2025 13:15:02 +0000 +State: closed + +When I run `dillo data:text/html,Hello%2C%20World` version 3.2.0-rc1 in Cygwin I get the following output: +``` +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +TLS library: mbed TLS 2.23.0 +Trusting 148 TLS certificates. +Disabling cookies. +Nav_open_url: new url='data:text/html,Hello%2C%20World' +** ERROR **: [Dpi_read_comm_keys] No such file or directory +Dpi_check_dpid: check_st=-1 +Dpi_check_dpid: EAGAIN +Dpi_blocking_start_dpid: try 1 +[dpid]: a_Misc_mksecret: e4d94003 +dpid started +Dpi_check_dpid: check_st=1 +Dpi_check_dpid: OK +Dpi_get_server_port: server_name = [proto.data] +[<cmd='check_server' msg='proto.data' '>] +Dpi_get_server_port: can't read server port from dpid. +Dpi_connect_socket: can't get port number for proto.data +``` +Now there is a file `~/.dillo/dpid_comm_keys` with the following contents: `5020 e4d94003` but Dillo doesn't load anything. +After Dillo restart, the window is still blank and this is the console output: +``` +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +TLS library: mbed TLS 2.23.0 +Trusting 148 TLS certificates. +Disabling cookies. +Nav_open_url: new url='data:text/html,Hello%2C%20World' +Dpi_check_dpid: check_st=1 +Dpi_check_dpid: OK +Dpi_get_server_port: server_name = [proto.data] +[<cmd='check_server' msg='proto.data' '>] +Dpi_get_server_port: can't read server port from dpid. +Dpi_connect_socket: can't get port number for proto.data +``` +The port 5020 is opened, which is seen by `netstat`: +``` +Active Connections + + Proto Local Address Foreign Address State + TCP 127.0.0.1:5020 PC:65373 TIME_WAIT +``` + +--%-- +From: rodarima +Date: Wed, 15 Jan 2025 19:31:35 +0000 + +> Dpi_connect_socket: can't get port number for proto.data + +It looks dpid cannot find the data: builtin plugin. What is the value of dpi_dir in ~/.dillo/dpidrc? https://dillo-browser.github.io/user_help.html#dpidrc + +--%-- +From: niutech +Date: Thu, 16 Jan 2025 09:50:07 +0000 + +Here is `~/.dillo/dpidrc`: +``` +dpi_dir=/usr/local/lib/dillo/dpi + +proto.file=file/file.dpi.exe +proto.ftp=ftp/ftp.filter.dpi.exe +proto.data=datauri/datauri.filter.dpi.exe +``` +And here is `ls /usr/local/lib/dillo/dpi/`: +``` +bookmarks cookies datauri downloads file ftp hello vsource +``` + + +--%-- +From: rodarima +Date: Thu, 16 Jan 2025 21:55:58 +0000 + +I cannot reproduce this with 3.2.0-rc1 (from git or the tarball) following the [install instructions for cygwin](https://github.com/dillo-browser/dillo/blob/master/doc/install.md#windows-via-cygwin): + + + +Not sure how you are getting these lines, they don't appear on my Dillo 3.2.0-rc1: + +``` +Dpi_check_dpid: check_st=1 +Dpi_check_dpid: OK +Dpi_get_server_port: server_name = [proto.data] +[<cmd='check_server' msg='proto.data' '>] +``` + +Do you have more than one Dillo installed? Can you open the bookmarks? + +Does the issue persist after `dpidc stop`? + +If so, please add the instructions to reproduce from source step by step. Send also the output of `dillo -v` and your config.log file (from the build directory). + +--%-- +From: niutech +Date: Thu, 16 Jan 2025 22:20:01 +0000 + +Yes, the issue persists after `dpidc stop`. I see just the blank page and `Dpi_get_server_port: can't read server port from dpid.` + +I've built dillo from the HEAD of git repo. These extra lines are from replacing `_MSG` macro with `MSG` in `src/IO/dpi.c` for debugging. + +The build instructions were pretty standard: `./autogen.sh && ./configure --prefix=/usr/local && make && make install` + +I cannot open bookmarks neither. The output is: +``` +Nav_open_url: new url='dpi:/bm/' +Dpi_check_dpid: check_st=1 +Dpi_check_dpid: OK +Dpi_get_server_port: server_name = [bookmarks] +[<cmd='check_server' msg='bookmarks' '>] +Dpi_get_server_port: can't read server port from dpid. +Dpi_connect_socket: can't get port number for bookmarks +``` + +`ps aux` shows running `/usr/local/bin/dpid`. File `~/.dillo/dpid_comm_keys` contains `5020 6faa6c1e`. + + +`dillo -v` is: +``` +Dillo v3.2.0-rc1-dirty +Libraries: fltk/1.3.8 zlib/1.3.1 jpeg/3.1.0 png/1.6.42 mbedTLS/2.23.0 +Features: +GIF +JPEG +PNG +SVG -WEBP +XEMBED +TLS +``` + +Maybe I should remove dillo altogether and rebuild it from scratch? + +--%-- +From: rodarima +Date: Thu, 16 Jan 2025 22:30:17 +0000 + +Hmm, can you run `dpidc stop` to stop dpid and then from another window run `strace -f dpid` manually? Then try again to open dillo. The trace should tell us what is happening with dpid. + +> Maybe I should remove dillo altogether and rebuild it from scratch? + +That may get rid of the issue, but I don't know what is happening yet. + +--%-- +From: niutech +Date: Thu, 16 Jan 2025 22:39:35 +0000 + +[Here](https://privatebin.net/?63762a407b69b9c4#HsNP5k7mk7trZ1HM6cqcrto9jpA8fbdkGKWEhP9XFRWU) is the strace log when opening `dillo data:text/html,Hello%2C%20World`. + +I can see there `__set_winsock_errno: recv_internal:1232 - winsock error 10035 -> errno 11` which is described as: + +> WSAEWOULDBLOCK: Resource temporarily unavailable. +> This error is returned from operations on nonblocking sockets that cannot be completed immediately, for example [recv](https://learn.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-recv) when no data is queued to be read from the socket. It is a nonfatal error, and the operation should be retried later. It is normal for WSAEWOULDBLOCK to be reported as the result from calling [connect](https://learn.microsoft.com/en-us/windows/desktop/api/Winsock2/nf-winsock2-connect) on a nonblocking SOCK_STREAM socket, since some time must elapse for the connection to be established. + +--%-- +From: rodarima +Date: Thu, 16 Jan 2025 23:11:46 +0000 + +Before that, dpid will try to scan all dpis available. Is it possible it is failing to opendir /usr/local/lib/dillo/dpi/ ? + +> 180 1923424 [main] dpid 2028 __set_errno: DIR* opendir(const char*):67 setting errno 2 + +You may want to put some extra MSG lines in the dpid code: https://github.com/dillo-browser/dillo/blob/master/dpid/dpid.c#L233 + +It should first scan the dpi directory to register all plugins, and then use that table to find which dpi needs to spawn. Let's check first that it is properly finding the datauri dpi. + +```diff +diff --git a/dpid/dpid.c b/dpid/dpid.c +index 9bf28f46..9639432f 100644 +--- a/dpid/dpid.c ++++ b/dpid/dpid.c +@@ -239,6 +239,8 @@ int get_dpi_attr(char *dpi_dir, char *service, struct dp *dpi_attr) + DIR *dir_stream; + struct dirent *dir_entry = NULL; + ++ MSG("get_dpi_attr(dpi_dir=%s, service=%s, ...)\n", dpi_dir, service); ++ + service_dir = dStrconcat(dpi_dir, "/", service, NULL); + if (stat(service_dir, &statinfo) == -1) { + ERRMSG("get_dpi_attr", "stat", errno); +@@ -276,6 +278,8 @@ int get_dpi_attr(char *dpi_dir, char *service, struct dp *dpi_attr) + if (ret != 0) + MSG_ERR("get_dpi_attr: No dpi plug-in in %s/%s\n", + dpi_dir, service); ++ else ++ MSG("get_dpi_attr: %s OK\n", service); + } + dFree(service_dir); + return ret; + +``` + +Check that you see the lines: + +``` +[dpid]: get_dpi_attr(dpi_dir=/usr/local/lib/dillo/dpi, service=datauri, ...) +[dpid]: get_dpi_attr: datauri OK +``` + +When running the new `dpid`. + +--%-- +From: niutech +Date: Thu, 16 Jan 2025 23:49:21 +0000 + +I've added these MSG and rebuilt, but when I run `dpid`, I get only: +``` +[dpid]: a_Misc_mksecret: c44d0303 +dpid started +``` +like `get_dpi_attr` wasn't invoked at all on start. Moreover, `register_service` and `get_command` neither. + +Only when I open `dillo data:text/html,Hello%2C%20World`, I get: +``` +[dpid]: get_command(dpi_tag=null) +[dpid]: get_command(dpi_tag=<cmd='check_server' msg='proto.data' '>) +``` +but no `register_service` nor `register_all` commands are invoked. + +Also, `numdpis` is 0 in `main`. + +--%-- +From: niutech +Date: Fri, 17 Jan 2025 00:44:12 +0000 + +Bingo! I've added a symlink `ln -s /usr/local/lib/dillo/dpi/ ~/.dillo/` and now it works! + + + +It is searching for services in ~`~/.dillo/dpi` directory (`get_dpi_attr(dpi_dir=~/.dillo/dpi)`) even though in my `~/.dillo/dpidrc` there is: +``` +dpi_dir=/usr/local/lib/dillo/dpi +``` +The problem is in `register_all` function, it should register services from my `dpi_dir`, not `~/.dillo/dpi` directory. + +--%-- +From: rodarima +Date: Fri, 17 Jan 2025 09:56:43 +0000 + +I suspect there is something wrong with your /usr/local/lib/dillo/dpi path. You could try installing dillo in some other prefix like ~/usr and see if the issue persist. On the other hand I think we should emit some message when we cannot open the system path of dpis, see the opendir here: + +https://github.com/dillo-browser/dillo/blob/f10a7800efa7c3a8017878e6e998ecf7b32d8e86/dpid/dpid.c#L399-L410 + +> It is searching for services in ~~/.dillo/dpi directory (get_dpi_attr(dpi_dir=~/.dillo/dpi)) even though in my ~/.dillo/dpidrc there is: + +Dillo searches in your home AND in the system dpi_dir directory set in dpidrc for plugins. The latter is the one that includes the datauri plugin. It should search in both places. + +--%-- +From: rodarima +Date: Fri, 17 Jan 2025 20:19:13 +0000 + +I have added another error message to determine if there was a problem opening the dpi directory in PR https://github.com/dillo-browser/dillo/pull/339. I reproduced your sympthoms by removing the read access to the system dpi directory, which now complains and also reports how many plugins it has loaded: + +``` +% dpid/dpid +[dpid]: cannot open system dpi directory '/usr/local/lib/dillo/dpi': Permission denied +[dpid]: a_Misc_mksecret: xxxx +dpid started (found 0 dpis) +``` + +If you can reproduce this on your end, chances are that dpid is not able to read the `/usr/local/lib/dillo/dpi` directory. + +--%-- +From: rodarima +Date: Sat, 25 Jan 2025 14:07:47 +0000 + +Closing for now, reopen if the issue persist and you want to further track it down.
\ No newline at end of file diff --git a/338/index.md b/338/index.md new file mode 100644 index 0000000..f299224 --- /dev/null +++ b/338/index.md @@ -0,0 +1,107 @@ +Title: Google Search broken +Author: rodarima +Created: Thu, 16 Jan 2025 13:14:56 +0000 +State: closed + +Google is now banning the default Dillo user agent with a JS wall. + +Reported: case ID is 3-0213000037750. + +--%-- +From: rodarima +Date: Thu, 16 Jan 2025 21:09:33 +0000 + +Got reply, sent details. + +--%-- +From: rodarima +Date: Fri, 17 Jan 2025 19:40:09 +0000 + +New reply, smells like AI: + +``` +[image: Google] + +Hi Rodrigo, + +Thank you for writing back to us. + +I see that you are not able to access Google Search while using Dillo +Browser. + +I would like to inform you that since, Dillo is a lightweight browser that +doesn't support JavaScript, frames, or embedded media playback and Chrome +is a web browser developed by Google I would like to recommend you to +submit feedback to the Google developers so that they will be notified +about the concern and make changes in the application which helps you in +accessing Google Search in Dillo browser. + +Here are the steps to submit feedback on Google: + + 1. On your Android phone or tablet, open the Chrome app [image: Chrome]. + 2. To the right of the address bar, tap More [image: More] [image: and + then] *Help & feedback*. + 3. At the bottom, tap *Send feedback*. + 4. Add details, including steps to help us recreate the issue you're + experiencing. + 5. Choose if you want to include more information in your report, like a + web address, your email address, or a screenshot. + 6. At the top right, tap Send [image: Send]. + +I hope this information helps you. If you have any questions related to +Google Products, feel free to reply to this email. I’ll be happy to help +you. + +Within 48 hours of our last interaction, you will receive a short survey +through email. We'd love to hear your feedback about our interaction today +and your overall experience with Google support. + +Best Regards, +Suzi +The Google Support Team +[image: Google] + +Google Help Center <https://support.google.com/> +Google Ireland Ltd, Gordon House, Barrow Street, Dublin 4, Ireland + + +*Google uses information you provide when contacting support to improve +support quality and training, to help address technical issues, and to +improve our products and services, subject to our Privacy Policy +<https://policies.google.com/privacy>. * + +``` + +Reminds me of this scene from [Westworld](https://nearfuturelaboratory.com/blog/2021/01/when-caleb-gets-a-call/): + +> Sean the Agent: Hi, this is Sean from DCA. +> +> Caleb: Is this about the position? +> +> Sean the Agent: Listen, Caleb. Your application was very strong. Unfortunately, our strategy group hasn’t found anything. +> +> [PAUSE] +> +> Sean the Agent: Caleb, are you still with me? +> +> Caleb: Okay, thank you. Look, is there anything I should be working on to make myself a better candidate? +> +> Sean the Agent: Like I said, your application was strong. We just don’t have anything that would be a great fit for you right now. +> +> Caleb: Sure. But, um, you know, if I’m not a good fit, is there a different shape I can fit myself into? +> +> [LONG PAUSE] +> +> Caleb: Hey, no offense, but are you a human? +> +> Sean the AI: I’m Sean. I can help you with all kinds of resources for DCA. Anything else I can do for you today, Caleb? +> +> Caleb: No, that’s all right. Thanks. + +Rat wheel, giving up. + +--%-- +From: rodarima +Date: Fri, 17 Jan 2025 20:56:19 +0000 + +https://techcrunch.com/2025/01/17/google-begins-requiring-javascript-for-google-search/
\ No newline at end of file diff --git a/339/index.md b/339/index.md new file mode 100644 index 0000000..bcb5d65 --- /dev/null +++ b/339/index.md @@ -0,0 +1,8 @@ +Title: Print error if dpi_dir cannot be opened +Author: rodarima +Created: Fri, 17 Jan 2025 20:02:51 +0000 +State: closed + +On cases where the system directory cannot be opened, dpid will not load the builtin plugins causing Dillo to fail to work properly with file: or data: URLs. Reporting a failure to open the directory allows users to determine the cause of the problem. + +See: https://github.com/dillo-browser/dillo/issues/337
\ No newline at end of file diff --git a/34/index.md b/34/index.md new file mode 100644 index 0000000..dd6f584 --- /dev/null +++ b/34/index.md @@ -0,0 +1,424 @@ +Title: Support for Atari machines +Author: rodarima +Created: Sun, 24 Dec 2023 14:11:15 +0000 +State: open + +Following this thread: + +https://www.atari-forum.com/viewtopic.php?t=43326 + +The folks at Atari Forum managed to get Dillo working on an Atari simulator: + + + +I'm opening this issue to track the current status of the port and to see what changes we may need to add to Dillo and the build system to improve the support for this platform. + +Some of the issues and quirks required are discussed in #33. Most of them are caused by the not great support for cross compilation. + +Here is the that @th-otto provided to build it on this platform. It needs to cross-compile Dillo using the `m68k-atari-mint-g++` compiler: + +```diff +diff --git a/configure.ac b/configure.ac +index 93747056..25ea5f65 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -148,10 +148,12 @@ dnl Check whether to add /usr/local or not + dnl (this is somewhat a religious problem) + dnl -------------------------------------- + dnl ++if test "$GCC" = no; then + if test "`$CPP -v < /dev/null 2>&1 | grep '/usr/local/include' 2>&1`" = ""; then + CPPFLAGS="$CPPFLAGS -I/usr/local/include" + LDFLAGS="$LDFLAGS -L/usr/local/lib" + fi ++fi + + dnl ------------------------------------ + dnl Check for socket libs (AIX, Solaris) +@@ -198,6 +200,7 @@ dnl Test for FLTK 1.3 library + dnl ------------------------- + dnl + dnl For debugging and to be user friendly ++if test "$cross_compiling" = no; then + AC_PATH_PROG(FLTK_CONFIG,fltk-config) + AC_MSG_CHECKING([FLTK 1.3]) + fltk_version="`$FLTK_CONFIG --version 2>/dev/null`" +@@ -211,6 +214,10 @@ case $fltk_version in + *) AC_MSG_RESULT(no) + AC_MSG_ERROR(FLTK 1.3 required; fltk-config not found) + esac ++else ++ AC_MSG_RESULT(assume yes) ++ LIBFLTK_LIBS="-lfltk" ++fi + + dnl ----------------------------------- + dnl Test for X11 (only on some systems) +@@ -221,20 +228,18 @@ old_libs=$LIBS + old_cxxflags=$CXXFLAGS + LIBS=$LIBFLTK_LIBS + CXXFLAGS=$LIBFLTK_CXXFLAGS +-AC_RUN_IFELSE([AC_LANG_PROGRAM([[ ++AC_LINK_IFELSE([AC_LANG_PROGRAM([[ + #define FL_INTERNALS + #include <FL/x.H> + ]],[[ + #ifdef X_PROTOCOL + return 0; + #else +- return 1; ++ nope + #endif + ]])], [AC_MSG_RESULT(yes) +- LIBX11_LIBS="-lX11"], +- [AC_MSG_RESULT(no)], +- [AC_MSG_RESULT(no) +- AC_MSG_WARN([*** Test for X11 not possible when cross-compiling. ***])]) ++ LIBX11_LIBS="-lXext -lX11"], ++ [AC_MSG_RESULT(no)]) + CXXFLAGS=$old_cxxflags + LIBS=$old_libs + AC_LANG_POP([C++]) +@@ -292,68 +297,33 @@ dnl --------------- + dnl Test for libpng + dnl --------------- + dnl ++PKG_PROG_PKG_CONFIG + png_ok="no" + if test "x$enable_png" = "xyes"; then +- AC_MSG_CHECKING([for libpng-config]) +- +-dnl Check if the user hasn't set the variable $PNG_CONFIG +- if test -z "$PNG_CONFIG"; then +- PNG_CONFIG=`which libpng16-config` +- if test -z "$PNG_CONFIG"; then +- PNG_CONFIG=`which libpng14-config` +- fi +- if test -z "$PNG_CONFIG"; then +- PNG_CONFIG=`which libpng12-config` +- fi +- if test -z "$PNG_CONFIG"; then +- PNG_CONFIG=`which libpng-config` ++ AC_MSG_CHECKING([for libpng]) ++ for libpng in libpng libpng16 libpng14 libpng12 libpng10; do ++ if test "$png_ok" = "no"; then ++ PKG_CHECK_MODULES([LIBPNG], $libpng, [png_ok="yes"; png_version=`$PKG_CONFIG --modversion $libpng`]) + fi +- if test -z "$PNG_CONFIG"; then +- PNG_CONFIG=`which libpng10-config` +- fi +- fi +- +-dnl Check if the libpng-config script was found and is executable +- if test -n "$PNG_CONFIG" && test -x "$PNG_CONFIG"; then +- AC_MSG_RESULT([$PNG_CONFIG]) +- png_ok="yes" +- else +- AC_MSG_RESULT([missing]) +- png_ok="no" +- fi ++ done + + if test "x$png_ok" = "xyes"; then + dnl For debugging and to be user friendly + AC_MSG_CHECKING([for libpng version]) +- png_version=`$PNG_CONFIG --version` + case $png_version in + 1.[[0246]].*) AC_MSG_RESULT([$png_version]) ;; + *) AC_MSG_RESULT([$png_version (unrecognised version)]) ;; + esac + +-dnl Try to use options that are supported by all libpng-config versions... +- LIBPNG_CFLAGS=`$PNG_CONFIG --cflags` +- LIBPNG_LIBS=`$PNG_CONFIG --ldflags` +- case $png_version in +- 1.2.4*) LIBPNG_LIBS="$LIBPNG_LIBS `$PNG_CONFIG --libs`" ;; +- esac +- else +-dnl Try to find libpng even though libpng-config wasn't found +- AC_CHECK_HEADERS(png.h libpng/png.h, png_ok=yes && break, png_ok=no) +- + if test "x$png_ok" = "xyes"; then + old_libs="$LIBS" +- AC_CHECK_LIB(png, png_sig_cmp, png_ok=yes, png_ok=no, $LIBZ_LIBS -lm) ++ AC_CHECK_LIB(png, png_sig_cmp, :, png_ok=no, $LIBPNG_LIBS $LIBZ_LIBS -lm) + LIBS="$old_libs" +- +- if test "x$png_ok" = "xyes"; then +- LIBPNG_LIBS="-lpng -lm" +- fi + fi + +- if test "x$png_ok" = "xno"; then +- AC_MSG_WARN([*** No libpng found. Disabling PNG images ***]) +- fi ++ fi ++ if test "x$png_ok" = "xno"; then ++ AC_MSG_WARN([*** No libpng found. Disabling PNG images ***]) + fi + fi + +@@ -375,13 +345,13 @@ tls_ok="no" + tls_impl="none" + if test "x$enable_tls" = "xyes"; then + if test "x$enable_openssl" = "xyes"; then +- dnl Search for OpenSSL headers first +- AC_CHECK_HEADER(openssl/ssl.h, openssl_ok=yes, openssl_ok=no) ++ dnl Search for OpenSSL ++ PKG_CHECK_MODULES([LIBSSL], [openssl], openssl_ok=yes, openssl_ok=no) + + dnl If the headers are found, try to link with -lssl and -lcrypto + if test "x$openssl_ok" = "xyes"; then + old_libs="$LIBS" +- AC_CHECK_LIB(ssl, SSL_write, openssl_ok=yes, openssl_ok=no, -lcrypto) ++ AC_CHECK_LIB(ssl, SSL_write, openssl_ok=yes, openssl_ok=no, $LIBSSL_LIBS) + LIBS="$old_libs" + fi + +@@ -390,7 +360,6 @@ if test "x$enable_tls" = "xyes"; then + AC_MSG_NOTICE([Using OpenSSL as TLS library.]) + tls_impl="OpenSSL" + AC_DEFINE([HAVE_OPENSSL], [1], [OpenSSL works]) +- LIBSSL_LIBS="-lcrypto -lssl" + else + AC_MSG_NOTICE([Cannot find OpenSSL, trying mbedTLS...]) + fi +@@ -519,6 +488,10 @@ case $target in + AC_MSG_NOTICE([Minix detected, skipping pthread detection]) + ;; + ++ *-*-mint*) ++ AC_MSG_NOTICE([MiNT detected, skipping pthread detection]) ++ ;; ++ + *) + AC_MSG_CHECKING(whether threads work with -pthread) + LDSAVEFLAGS=$LDFLAGS +diff --git a/dpi/Makefile.am b/dpi/Makefile.am +index 62b82e1b..4781c75f 100644 +--- a/dpi/Makefile.am ++++ b/dpi/Makefile.am +@@ -1,6 +1,8 @@ + AM_CPPFLAGS = \ + -I$(top_srcdir) + ++LIBS = $(LIBX11_LIBS) ++ + bookmarksdir = $(libdir)/dillo/dpi/bookmarks + downloadsdir = $(libdir)/dillo/dpi/downloads + ftpdir = $(libdir)/dillo/dpi/ftp +diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c +index d2a454e7..9d153a8f 100644 +--- a/src/IO/tls_openssl.c ++++ b/src/IO/tls_openssl.c +@@ -491,7 +491,11 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) + if (print_chain) + MSG("%s ", buf); + ++#if OPENSSL_VERSION_NUMBER >= 0x30000000L + key_type = EVP_PKEY_type(EVP_PKEY_get_id(public_key)); ++#else ++ key_type = EVP_PKEY_type(EVP_PKEY_id(public_key)); ++#endif + type_str = key_type == EVP_PKEY_RSA ? "RSA" : + key_type == EVP_PKEY_DSA ? "DSA" : + key_type == EVP_PKEY_DH ? "DH" : +@@ -830,6 +834,7 @@ static int Tls_examine_certificate(SSL *ssl, Server_t *srv) + ret = 0; + break; + case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: ++ { /* Case follows declaration */ + /* Either self signed and untrusted */ + /* Extract CN from certificate name information */ + X509_NAME *subject_name = X509_get_subject_name(remote_cert); +@@ -868,6 +873,7 @@ static int Tls_examine_certificate(SSL *ssl, Server_t *srv) + default: + break; + } ++ } + break; + case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: + case X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY: +``` + +--%-- +From: rodarima +Date: Sun, 24 Dec 2023 14:18:53 +0000 + +I will continue the discussion here, as the other PR was for OpenSSL 1.1 support only. + +> > Do you see any messages in the terminal? +> +> There are no error messages, it just times out after some time with the message `Dns_server [0]: <hostname> is (nil)` +> +> But seems to be a bit random. Sometimes it works. Maybe just a problem with my setup (using aranym with a bridge to the host), since sometimes other network connections also fail. I've always used --disable-threaded-dns, since the only thread implementation currently available is pth, and that is non-preemptive and just causes problems because of this. + +That's strange, but if you report that other network connections fail maybe is not related with Dillo. + +> > Adding /usr/local/include is required in some BSD systems +> +> I have disabled that currently when using gcc, since gcc should always look in that directories by default. Should that cause problems on BSD system, the test could also be changed to `if test "$cross_compiling" = no` +> +> Other things that i changed: looking for png library uses png-config. I've tested it also on linux, but may need some testing for other systems. +> +> For FLTK i currently just use -lfltk when cross-compiling, since it does not seem to require any special cflags. Maybe that test could also be changed to some `AC_CHECK_LIB`. +> +> The dpi programs have to be linked explicitly to the x11 libraries. This is again only needed because of static libraries, but should not hurt on other systems. +> +> Searching for openssl also uses pkg-config now. I have no mbedtls yet, so i don't know what files are installed there. +> +> All in all the patches aren't that large, so if you don't want to apply them, i can just keep them as mint-specific patches. +> +> But note that this is all quite experimental. There are other quirks currently, some drawing problems (which i suspect to be fVDI problems in combination with aranym), the tooltips sometimes immediately disappearing again etc. And of course that X.App that is needed is also quite experimental. + +I think most of those patches can be included in Dillo. But I'll have to think a way to test it under CI, so I can avoid breaking it in the future. Maybe I can find a way to cross compile to ARM, which would exercise most of the cross compilation logic. Or I don't know how complicated is to setup the simulator for Atari. + +> However the rendering always is quite strange, also in the linux version of dillo. Maybe some features of CSS that are not implemented yet? + +Yeah, the support for CSS is not complete (yet). + +> [dillo.patch.txt](https://github.com/dillo-browser/dillo/files/13761123/dillo.patch.txt) + +Thanks for the patch! + +--%-- +From: th-otto +Date: Sun, 24 Dec 2023 18:27:49 +0000 + +> Or I don't know how complicated is to setup the simulator for Atari. + +Well first thing you would need is aranym ;) Unforunately, currently snapshots are still not available since bintray closed, so you have to compile it yourself. But it is autotools based, so shouldn't be that hard. + +For a working freemint environment, you should be able to use the snapshot builds of freemint: https://tho-otto.de/snapshots/freemint/bootable/ + +Getting network working is another thing though. + +Precompiled libraries for fltk, openssl and everything else you might need are available at https://tho-otto.de/crossmint.php + +--%-- +From: rodarima +Date: Mon, 25 Dec 2023 14:05:57 +0000 + +> > Or I don't know how complicated is to setup the simulator for Atari. +> +> Well first thing you would need is aranym ;) Unforunately, currently snapshots are still not available since bintray closed, so you have to compile it yourself. But it is autotools based, so shouldn't be that hard. + +It seems to be available in the [AUR](https://aur.archlinux.org/packages/aranym) which builds it from: + +http://downloads.sourceforge.net/sourceforge/aranym/aranym_1.1.0.orig.tar.gz + +I'm guessing that may work (?). It asks for a ROM: + + + + + +> For a working freemint environment, you should be able to use the snapshot builds of freemint: https://tho-otto.de/snapshots/freemint/bootable/ + +Which file(s) do I need exactly? And can you specify how to invoke ARAnyM to load the ROM/images? + +> Getting network working is another thing though. +> +> Precompiled libraries for fltk, openssl and everything else you might need are available at https://tho-otto.de/crossmint.php + +Okay, I'll try that eventually. + +First, I'll try to setup a CI runner that does a cross compilation from x64 to something else (probably ARM) as that seems like an easier first step. Once that works, I see if I can try to boot ARAnyM myself and built it there. + +--%-- +From: rodarima +Date: Mon, 25 Dec 2023 14:20:45 +0000 + +Managed to get EmuTOS loading: + + + +But no idea how to load FreeMiNT. + +--%-- +From: rodarima +Date: Mon, 25 Dec 2023 14:32:25 +0000 + +Managed to boot FreeMiNT and open a bash shell: + + + + +--%-- +From: th-otto +Date: Mon, 25 Dec 2023 14:37:43 +0000 + +> It seems to be available in the [AUR](https://aur.archlinux.org/packages/aranym) which builds it from: +> I'm guessing that may work (?). It asks for a ROM: + +That might work, but there haven't been any releases for a while. You can use it as a start, but eventually you should replace that later by a freshly compiled version from the source repo (https://github.com/aranym/aranym) + +>Which file(s) do I need exactly? And can you specify how to invoke ARAnyM to load the ROM/images? + +Seems you have figured that out already. You should specify EmuTOS as ROM in ``~/.aranym/config`` +``` +[GLOBAL] +EmuTOS = emutos-aranym.img +``` + +>Managed to boot FreeMiNT and open a bash shell: + +Nice. Thats almost all you need. Easiest way to access other files is to map a host filesystem: +``` +[HOSTFS] +H = ~/ +``` + +(or some other dir) + +Edit: You should make sure that important directories like /usr point to a filesystem that supports long filenames, otherwise you run into trouble with lots of unix programs. /usr is typically setup as a symlink in u:\usr (U:\ is the root filesystem for MiNT) + + +--%-- +From: rodarima +Date: Mon, 25 Dec 2023 14:48:00 +0000 + +> > It seems to be available in the [AUR](https://aur.archlinux.org/packages/aranym) which builds it from: +> > I'm guessing that may work (?). It asks for a ROM: +> +> That might work, but there haven't been any releases for a while. You can use it as a start, but eventually you should replace that later by a freshly compiled version from the source repo (https://github.com/aranym/aranym) + +Okey, I'll adjust the PKGBUILD. + +> > Which file(s) do I need exactly? And can you specify how to invoke ARAnyM to load the ROM/images? +> +> Seems you have figured that out already. You should specify EmuTOS as ROM in `~/.aranym/config` +> +> ``` +> [GLOBAL] +> EmuTOS = emutos-aranym.img +> ``` + +I'm using the `runme.sh` insize `freemint-1-19-bc6492f7-040-aranym.zip`, `EmuTOS` is already set to that value. + +> > Managed to boot FreeMiNT and open a bash shell: +> +> Nice. Thats almost all you need. Easiest way to access other files is to map a host filesystem: +> +> ``` +> [HOSTFS] +> H = ~/ +> ``` +> +> (or some other dir) +> +> Edit: You should make sure that important directories like /usr point to a filesystem that supports long filenames, otherwise you run into trouble with lots of unix programs. /usr is typically setup as a symlink in u:\usr (U:\ is the root filesystem for MiNT) + +So you cross-compile Dillo with dynamic libs and then you share the binary and dependencies inside the VM with the HOSTFS mounts? + + + +--%-- +From: th-otto +Date: Mon, 25 Dec 2023 16:42:06 +0000 + +There aren't any dynamic libs ;) But basically yes, i cross-compile dillo on linux, then switch to aranym, cd to the directory where i just compiled it on the host, and run it from there. + +For the dip-programs, you can copy them inside aranym to the /usr/lib/dillo directory. But i think for a first test they are not needed. + +But it seems it is not that easy to setup the X.app for atari correctly. See also the thread https://www.atari-forum.com/viewtopic.php?p=455548#p455548
\ No newline at end of file diff --git a/340/index.md b/340/index.md new file mode 100644 index 0000000..fcd33f6 --- /dev/null +++ b/340/index.md @@ -0,0 +1,6 @@ +Title: Release version 3.2.0 +Author: rodarima +Created: Sat, 18 Jan 2025 13:43:07 +0000 +State: closed + +Closes milestone https://github.com/dillo-browser/dillo/milestone/3
\ No newline at end of file diff --git a/341/index.md b/341/index.md new file mode 100644 index 0000000..3e01139 --- /dev/null +++ b/341/index.md @@ -0,0 +1,12 @@ +Title: Right-click menu: copy link location does not work +Author: danrobi11 +Created: Mon, 20 Jan 2025 04:21:15 +0000 +State: closed + +Hi. copying from url bar with `C-c` does work as intended. However, the `copy link location` from right-click menu does not work. + +Compiled the 3.2.0.tar.gz + +Debian 12 + +New edit: Also, cant copy selected text with `C-c` . There's no copy option when right-clicking after selecting text. So no way for copying selected text in web pages.
\ No newline at end of file diff --git a/342/index.md b/342/index.md new file mode 100644 index 0000000..0a57283 --- /dev/null +++ b/342/index.md @@ -0,0 +1,18 @@ +Title: User guide needs updating for focus_new_tab=NO default +Author: nortti0 +Created: Mon, 20 Jan 2025 18:03:27 +0000 +State: closed + +The user guide [still describes focus_new_tab=YES as the default behaviour](https://github.com/dillo-browser/dillo/blob/dc3c3bc087ee5ae5a25e936eab62124685564d4b/doc/user_help.in.html#L351), even though [that's no longer the case](https://github.com/dillo-browser/dillo/commit/71e680bd5f19bfd6b29e221e2f0b6e4d03cf3294) in 3.2.0. + +--%-- +From: rodarima +Date: Mon, 20 Jan 2025 21:35:09 +0000 + +Thanks for reporting, would you like to open a MR? + +--%-- +From: nortti0 +Date: Mon, 20 Jan 2025 21:46:59 +0000 + +Aye, can do that.
\ No newline at end of file diff --git a/343/index.md b/343/index.md new file mode 100644 index 0000000..1fba237 --- /dev/null +++ b/343/index.md @@ -0,0 +1,15 @@ +Title: Is possible move FLTK to SDL2 or wx-widgets? +Author: mix127 +Created: Mon, 20 Jan 2025 19:56:22 +0000 +State: closed + +Is possible make a version without FLTK. No problem if without gui. Many project no need gui. + +For example printing html /svg no needed gui. +Many projects no need more than simple function() for some element gui : back, forward, open url, increase , decrease etc. + +--%-- +From: rodarima +Date: Mon, 20 Jan 2025 21:38:48 +0000 + +Not easy, but could be theoretically posible to do. You'll need to rewrite most of the dw/ code. Unlikely to happen any time soon.
\ No newline at end of file diff --git a/344/index.md b/344/index.md new file mode 100644 index 0000000..94fb467 --- /dev/null +++ b/344/index.md @@ -0,0 +1,16 @@ +Title: Add http handler to mime type +Author: rodarima +Created: Wed, 22 Jan 2025 23:07:58 +0000 +State: closed + +https://gitlab.archlinux.org/archlinux/packaging/packages/dillo/-/merge_requests/1 + +--%-- +From: rodarima +Date: Thu, 23 Jan 2025 21:49:38 +0000 + +Already done: + +https://github.com/dillo-browser/dillo/blob/dc3c3bc087ee5ae5a25e936eab62124685564d4b/dillo.desktop#L5 + +They are distributing their own dillo.desktop.
\ No newline at end of file diff --git a/345/index.md b/345/index.md new file mode 100644 index 0000000..ff1b10f --- /dev/null +++ b/345/index.md @@ -0,0 +1,5 @@ +Title: Fix oob nanosvg +Author: rodarima +Created: Sat, 25 Jan 2025 13:26:37 +0000 +State: closed + diff --git a/346/index.md b/346/index.md new file mode 100644 index 0000000..e162426 --- /dev/null +++ b/346/index.md @@ -0,0 +1,24 @@ +Title: Add plugin for geo: URLs +Author: rodarima +Created: Sat, 25 Jan 2025 14:05:15 +0000 +State: closed + +I'm just opening the issue here so I don't forget, but it should probably be done in a separate plugin. + +The geo: URL scheme was designed to locate places on Earth (other planets seem to be also supported) which I like a lot. It is an agnostic identifier, so you are not tied to a single provider like Google Maps or Open Street Map, so you decide where to open it. + +https://en.wikipedia.org/wiki/Geo_URI_scheme + +Here is the RFC: + +https://datatracker.ietf.org/doc/html/rfc5870 + +This also shows that we should be able to assign custom handlers (applications) to open certain protocols, rather than trying to display them on the browser. In my case, I would love to add support to lightweight map viewers like florb. + +--%-- +From: rodarima +Date: Wed, 05 Feb 2025 20:38:28 +0000 + +This can be done with the link actions: https://github.com/rodarima/florb/tree/open-geo-links + +Closing.
\ No newline at end of file diff --git a/347/index.md b/347/index.md new file mode 100644 index 0000000..e588d91 --- /dev/null +++ b/347/index.md @@ -0,0 +1,12 @@ +Title: Update the documentation for tab focusing behaviour +Author: nortti0 +Created: Sat, 25 Jan 2025 16:57:05 +0000 +State: closed + +Fixes #342. + +--%-- +From: rodarima +Date: Sat, 25 Jan 2025 17:39:23 +0000 + +Thanks!
\ No newline at end of file diff --git a/348/index.md b/348/index.md new file mode 100644 index 0000000..5c20914 --- /dev/null +++ b/348/index.md @@ -0,0 +1,30 @@ +Title: [3.2.0] HTML Tests: FAIL: render/svg-current-color.html +Author: Kangie +Created: Thu, 30 Jan 2025 01:14:06 +0000 +State: closed + +When configured with + +``` + ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/dillo-3.2.0 --htmldir=/usr/share/doc/dillo-3.2.0/html --libdir=/usr/lib64 --disable-rtfl --enable-gif --enable-jpeg --disable-mbedtls --enable-openssl --enable-png --enable-tls --enable-svg --enable-xembed --enable-ipv6 --enable-html-tests=yes +``` + +I am unable to successfully complete the test suite on Gentoo Linux in either the 3.2.0 tarball or a clean checkout of master (0c7e087fbd0278da9a39bd16ab9385073f1f495c) due to + +``` +FAIL: render/svg-current-color.html +``` + +Given that SVG support is vendored I'm not sure that there's much that I can do here. + +Any suggestions? + +[build.log.txt](https://github.com/user-attachments/files/18596098/build.log.txt) from a Gentoo Portage build, but I see the same (without `/dev/dri/card0` warnings) building from git sources manually. + +--%-- +From: rodarima +Date: Tue, 04 Feb 2025 18:28:19 +0000 + +> Any suggestions? + +Disable the HTML rendering tests, they are not designed to be run outside the CI environment.
\ No newline at end of file diff --git a/349/index.md b/349/index.md new file mode 100644 index 0000000..9ffc5d2 --- /dev/null +++ b/349/index.md @@ -0,0 +1,8 @@ +Title: build against fltk 1.4 +Author: HalanoSiblee +Created: Mon, 03 Feb 2025 18:32:01 +0000 +State: closed + +Is there anyway to build dillo on fltk 1.4 I don't want to downgrade + +
\ No newline at end of file diff --git a/35/index.md b/35/index.md new file mode 100644 index 0000000..5299c2c --- /dev/null +++ b/35/index.md @@ -0,0 +1,6 @@ +Title: Add macOS 13 build in CI +Author: rodarima +Created: Sun, 24 Dec 2023 16:31:37 +0000 +State: closed + +Builds Dillo in mac OS 13.
\ No newline at end of file diff --git a/350/index.md b/350/index.md new file mode 100644 index 0000000..cd2f5a9 --- /dev/null +++ b/350/index.md @@ -0,0 +1,25 @@ +Title: Consider support for CSS used by Hugo PaperMod theme +Author: dslgr +Created: Tue, 04 Feb 2025 01:03:01 +0000 +State: closed + +It looks like Hugo PaperMod uses some CSS that isn't supported by Dillo. The blog entry links on the homepage aren't working. It maybe particularly good to support as it is the most popular [hugo theme by github stars](https://github.com/topics/hugo-theme). + +https://adityatelange.github.io/hugo-PaperMod/ + +--%-- +From: rodarima +Date: Tue, 04 Feb 2025 18:15:42 +0000 + +Fix your theme so it works without JS or CSS, this is awful: + +``` +<a class="entry-link" + aria-label="post link to Install / Update PaperMod" + href="https://adityatelange.github.io/hugo-PaperMod/posts/papermod/papermod-installation/"> +</a> +``` + +The `a` tag should contain the whole entry, not be empty. + +Improving Dillo CSS support is already planned.
\ No newline at end of file diff --git a/351/index.md b/351/index.md new file mode 100644 index 0000000..0532622 --- /dev/null +++ b/351/index.md @@ -0,0 +1,6 @@ +Title: Fix several typos +Author: rodarima +Created: Wed, 05 Feb 2025 20:31:17 +0000 +State: closed + +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/L3FFAINJJMIOZQNID5HC2DHKJIIIHEYH/
\ No newline at end of file diff --git a/352/index.md b/352/index.md new file mode 100644 index 0000000..531006e --- /dev/null +++ b/352/index.md @@ -0,0 +1,19 @@ +Title: meson as build system +Author: vtorri +Created: Fri, 07 Feb 2025 17:13:47 +0000 +State: closed + +i've looked at the slides at FOSDEM 25. It is said that slow compilation is a constraint. +I wouls suggest using meson instead of autotools, it's a LOT faster with a nice syntax +There is also a C port of meson (which is in python) called muon, which makes the compilation even faster. + +in case it interests you + +regards + + +--%-- +From: rodarima +Date: Fri, 07 Feb 2025 17:24:53 +0000 + +Thanks, but the bootleneck in old computers is building the objects, not the build system. There are other reasons to move away from autotools though.
\ No newline at end of file diff --git a/353/index.md b/353/index.md new file mode 100644 index 0000000..8406c1b --- /dev/null +++ b/353/index.md @@ -0,0 +1,73 @@ +Title: Compile without -std=c++11, not really needed +Author: pekdon +Created: Fri, 07 Feb 2025 17:49:44 +0000 +State: closed + +Might be a bit unconventional, downgrading the required standard, but without these extra , and the use of isinf this compiles and runs on Solaris 10 still which seems like a good fit for Dillo. + +--%-- +From: rodarima +Date: Fri, 07 Feb 2025 18:07:07 +0000 + +Thanks, the C++11 check is to prevent accidentally adding a dependency with newer standards. + +We can run it only on the CI, as Dillo can be built with a compiler that supports C++03 and GNU macros, but I need to be sure it works first by making it fail. + +> compiles and runs on Solaris 10 still which seems like a good fit for Dillo. + +Screenshot for the gallery? https://dillo-browser.github.io/gallery/ + +--%-- +From: pekdon +Date: Fri, 07 Feb 2025 18:44:51 +0000 + +Sounds reasonable to have such a check, easy to accidentally add! + +Something like that? + + +--%-- +From: sevan +Date: Sat, 08 Feb 2025 23:10:27 +0000 + +This is great, and a huge timesaver. Alongside this patch I also had to make similar changes to +`dw/fltkui.cc`, `src/css.hh`, `src/cssparser.cc`, `src/dillo.cc`, `src/html_common.hh`, `src/xembed.cc` and then I could build Dillo 3.2.0 on OS X 10.4 with GCC 4.0.1 on my PowerBook which takes just over 2 minutes. With a C++11 dependency add another 24 hours :) +[additional patch](https://github.com/user-attachments/files/18722511/dillo-patch-no-cpp11.txt) + +Tested with GCC 4.0.1 & 8.5 on OS X 10.4 PowerPC. + + +--%-- +From: pekdon +Date: Sun, 09 Feb 2025 11:43:57 +0000 + +Updated my branch based on your changes too @sevan (mentioned in the commit) + +--%-- +From: rodarima +Date: Tue, 18 Feb 2025 22:12:55 +0000 + +Thanks, these patches are great. It is nice to see it is still working on Solaris, I will the screenshot to the gallery :) + +Before I merge this, I will add some commits to this PR to stick to C++11 only on the CI as well as some future features to be sure it fails. + +--%-- +From: sevan +Date: Tue, 18 Feb 2025 22:22:34 +0000 + +> Thanks, these patches are great. It is nice to see it is still working on Solaris, I will the screenshot to the gallery :) +> +> Before I merge this, I will add some commits to this PR to stick to C++11 only on the CI as well as some future features to be sure it fails. + +I guess there's a run which needs `-std=gnu++98` to be set since we're dealing with compilers which lack C++11 support? + +--%-- +From: rodarima +Date: Tue, 18 Feb 2025 22:38:39 +0000 + + +> I guess there's a run which needs `-std=gnu++98` to be set since we're dealing with compilers which lack C++11 support? + +It would probably be good add a CI build with an old GCC, as I don't know if gnu++98 is enough if you are building from a new compiler. For this PR I will just focus on not removing the current C++11 check. + +Ideally we should remove the C++ variadic macros, which I believe is the only requeriment from C++11, so we can at least downgrade to C++03, but we can cover that in another issue/PR.
\ No newline at end of file diff --git a/354/index.md b/354/index.md new file mode 100644 index 0000000..b9d2e42 --- /dev/null +++ b/354/index.md @@ -0,0 +1,12 @@ +Title: library associated to the web browser +Author: vtorri +Created: Fri, 07 Feb 2025 19:34:58 +0000 +State: closed + +Is there a library that I can use to embed the rendering in my own toolkit and not FLTK ? + +--%-- +From: rodarima +Date: Mon, 24 Feb 2025 17:25:40 +0000 + +No, the Dillo rendering engine is tighly coupled to FLTK.
\ No newline at end of file diff --git a/355/index.md b/355/index.md new file mode 100644 index 0000000..b4e7886 --- /dev/null +++ b/355/index.md @@ -0,0 +1,28 @@ +Title: configure with IPv6 on by default +Author: sevan +Created: Sat, 08 Feb 2025 23:33:24 +0000 +State: closed + +Provide an argument to disable IPv6, inverting previous behaviour. + +Realised that I had to enable IPv6 specifically when surfing on OS X 10.4. + +--%-- +From: rodarima +Date: Mon, 24 Feb 2025 17:41:35 +0000 + +Thanks, but this will cause a build failure in old machines that don't support IPv6, see https://github.com/dillo-browser/dillo/issues/167. I will eventually implement a detection mechanism, for now I'll keep it disabled. + +We can add the `--enable-ipv6` flag in the [install notes for MacOS](https://github.com/dillo-browser/dillo/blob/master/doc/install.md#building-from-source-1) in the meanwhile. + +--%-- +From: rodarima +Date: Fri, 11 Jul 2025 20:49:13 +0000 + +I added support to detect IPv6 at build time, see https://github.com/dillo-browser/dillo/pull/419. In the CI with Mac OS 13 it detects it and enables as expected. May be a good idea to try it with Mac OS X 10.4 as well. + +--%-- +From: sevan +Date: Fri, 11 Jul 2025 20:50:57 +0000 + +Yep, no worries. Will take a look over the weekend and report back.
\ No newline at end of file diff --git a/356/index.md b/356/index.md new file mode 100644 index 0000000..f861a29 --- /dev/null +++ b/356/index.md @@ -0,0 +1,180 @@ +Title: Dillo fails to connect to PHP internal http webserver / PHP webserver instantly resets TCP connection +Author: ghost +Created: Sat, 15 Feb 2025 14:11:55 +0000 +State: closed + +**1. Start PHP internal webserver by running:** + +`php -S localhost:80 -t /path/to/html-directory/` + +(you can choos to use an port above 1024 if you do not have enough privileges) + +**2. Try to connect to the URL (http://localhost:80, for example)** + + - Dillo displays error message: "Could not establish connection" + + +**4. Looking at Wireshark log the following TCP package sequence can be seen** + +Dillo Requests connection +PHP resets connection +Dillo Requests connection +PHP resets conntection + + +**Packet capture details of the first 2 packets** + +Dillo request: + +``` +Transmission Control Protocol, Src Port: 43556, Dst Port: 80, Seq: 0, Len: 0 + Source Port: 43556 + Destination Port: 80 + [Stream index: 0] + [Conversation completeness: Incomplete (37)] + [TCP Segment Len: 0] + Sequence Number: 0 (relative sequence number) + Sequence Number (raw): 211095531 + [Next Sequence Number: 1 (relative sequence number)] + Acknowledgment Number: 0 + Acknowledgment number (raw): 0 + 1010 .... = Header Length: 40 bytes (10) + Flags: 0x002 (SYN) + 000. .... .... = Reserved: Not set + ...0 .... .... = Accurate ECN: Not set + .... 0... .... = Congestion Window Reduced: Not set + .... .0.. .... = ECN-Echo: Not set + .... ..0. .... = Urgent: Not set + .... ...0 .... = Acknowledgment: Not set + .... .... 0... = Push: Not set + .... .... .0.. = Reset: Not set + .... .... ..1. = Syn: Set + [Expert Info (Chat/Sequence): Connection establish request (SYN): server port 80] + [Connection establish request (SYN): server port 80] + [Severity level: Chat] + [Group: Sequence] + .... .... ...0 = Fin: Not set + [TCP Flags: ··········S·] + Window: 65495 + [Calculated window size: 65495] + Checksum: 0xf5ad [unverified] + [Checksum Status: Unverified] + Urgent Pointer: 0 + Options: (20 bytes), Maximum segment size, SACK permitted, Timestamps, No-Operation (NOP), Window scale + TCP Option - Maximum segment size: 65495 bytes + Kind: Maximum Segment Size (2) + Length: 4 + MSS Value: 65495 + TCP Option - SACK permitted + Kind: SACK Permitted (4) + Length: 2 + TCP Option - Timestamps: TSval 423197222, TSecr 0 + Kind: Time Stamp Option (8) + Length: 10 + Timestamp value: 423197222 + Timestamp echo reply: 0 + TCP Option - No-Operation (NOP) + Kind: No-Operation (1) + TCP Option - Window scale: 7 (multiply by 128) + Kind: Window Scale (3) + Length: 3 + Shift count: 7 + [Multiplier: 128] + [Timestamps] + [Time since first frame in this TCP stream: 0.000000000 seconds] + [Time since previous frame in this TCP stream: 0.000000000 seconds] +``` + + +PHP response: +``` + +Transmission Control Protocol, Src Port: 80, Dst Port: 43556, Seq: 1, Ack: 1, Len: 0 + Source Port: 80 + Destination Port: 43556 + [Stream index: 0] + [Conversation completeness: Incomplete (37)] + [TCP Segment Len: 0] + Sequence Number: 1 (relative sequence number) + Sequence Number (raw): 0 + [Next Sequence Number: 1 (relative sequence number)] + Acknowledgment Number: 1 (relative ack number) + Acknowledgment number (raw): 211095532 + 0101 .... = Header Length: 20 bytes (5) + Flags: 0x014 (RST, ACK) + 000. .... .... = Reserved: Not set + ...0 .... .... = Accurate ECN: Not set + .... 0... .... = Congestion Window Reduced: Not set + .... .0.. .... = ECN-Echo: Not set + .... ..0. .... = Urgent: Not set + .... ...1 .... = Acknowledgment: Set + .... .... 0... = Push: Not set + .... .... .1.. = Reset: Set + [Expert Info (Warning/Sequence): Connection reset (RST)] + [Connection reset (RST)] + [Severity level: Warning] + [Group: Sequence] + .... .... ..0. = Syn: Not set + .... .... ...0 = Fin: Not set + [TCP Flags: ·······A·R··] + Window: 0 + [Calculated window size: 0] + [Window size scaling factor: -1 (unknown)] + Checksum: 0xead8 [unverified] + [Checksum Status: Unverified] + Urgent Pointer: 0 + [Timestamps] + [Time since first frame in this TCP stream: 0.000044930 seconds] + [Time since previous frame in this TCP stream: 0.000044930 seconds] + [SEQ/ACK analysis] + [This is an ACK to the segment in frame: 438] + [The RTT to ACK the segment was: 0.000044930 seconds] + [iRTT: 0.000044930 seconds] +``` + + + + +--%-- +From: rodarima +Date: Sat, 15 Feb 2025 14:37:45 +0000 + +What does “curl -v http://localhost” says? + + +--%-- +From: ghost +Date: Sat, 15 Feb 2025 15:00:09 +0000 + +Interesting, seems to be IP version related, haven't thought about that. + +curl -v http://localhost:12888/index.html +* Trying 127.0.0.1:12888... +* connect to 127.0.0.1 port 12888 failed: Connection rejected +* Trying [::1]:12888... +* Connected to localhost (::1) port 12888 (#0) +> GET /index.html HTTP/1.1 +> Host: localhost:12888 +> User-Agent: curl/7.88.1 +> Accept: */* +> +< HTTP/1.1 200 OK +< Host: localhost:12888 +< Date: Sat, 15 Feb 2025 14:57:44 GMT +< Connection: close +< Content-Type: text/html; charset=UTF-8 +< Content-Length: 49935 + + + +--%-- +From: rodarima +Date: Sat, 15 Feb 2025 15:08:38 +0000 + +Try building dillo with --enable-ipv6, it looks you are listening on IPv6 only. + +--%-- +From: ghost +Date: Sat, 15 Feb 2025 15:15:48 +0000 + +Yeah, that was an example of RTFM and works fine now 🙈👍
\ No newline at end of file diff --git a/357/index.md b/357/index.md new file mode 100644 index 0000000..1b70643 --- /dev/null +++ b/357/index.md @@ -0,0 +1,23 @@ +Title: Now unusable due to UI font size +Author: SvenMichaelKlose +Created: Sun, 16 Feb 2025 00:18:17 +0000 +State: closed + +The labels on the user interface are like microfilm on a modern display. Wouldn't hurt to go quadruple of the size it is now. + +--%-- +From: rodarima +Date: Sun, 16 Feb 2025 13:06:26 +0000 + +Here are some suggestions for microfilm readers: + +https://www.ebay.com/itm/186891525274 +https://www.ebay.com/itm/335427776277 + +Alternatively, use the search bar: https://github.com/dillo-browser/dillo/issues/169 https://github.com/dillo-browser/dillo/issues/246 + +--%-- +From: SvenMichaelKlose +Date: Tue, 18 Feb 2025 15:38:27 +0000 + +Always fun to be contributing, especially in those fast-paced times.
\ No newline at end of file diff --git a/358/index.md b/358/index.md new file mode 100644 index 0000000..24d8aab --- /dev/null +++ b/358/index.md @@ -0,0 +1,20 @@ +Title: Add Network Programming Internals of the Dillo Web Browser paper +Author: niutech +Created: Mon, 17 Feb 2025 09:29:42 +0000 +State: closed + +I'm adding the Network Programming Internals of the Dillo Web Browser paper by Jorge Arellano-Cid and Horst H. von Brand from SCCC 2000 for archival reasons. It's hard to find the PDF, there is only a PostScript version, so I have converted it to PDF for convenience. + +--%-- +From: rodarima +Date: Wed, 19 Mar 2025 22:45:41 +0000 + +That paper is too outdated for the current codebase of Dillo. We can keep it as a relic in https://github.com/dillo-browser/dillo-browser.github.io/tree/master/old along the original postcript version, open a PR there if you are interested. + +It is available [here](https://dillo-browser.github.io/old/Links.html) under the Papers section as well. + +--%-- +From: niutech +Date: Thu, 20 Mar 2025 10:17:17 +0000 + +I've made a PR https://github.com/dillo-browser/dillo-browser.github.io/pull/17. There is only a gzipped PS version, which is not easy to open, PDF is more universal and indexable.
\ No newline at end of file diff --git a/359/index.md b/359/index.md new file mode 100644 index 0000000..35d9ba5 --- /dev/null +++ b/359/index.md @@ -0,0 +1,74 @@ +Title: Text under scrollbar when placed on the left side +Author: rodarima +Created: Thu, 27 Feb 2025 21:28:01 +0000 +State: closed + +Reproducer: https://emreed.net/LowTech_Directory + + + +--%-- +From: rodarima +Date: Thu, 27 Feb 2025 21:37:19 +0000 + +Simplified reproducer: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test text under left scrollbar</title> + <style> + body { width: 700px; height: 1000px; } + </style> + </head> + <body> + <p> + Can you read me? + <em>You must set the scrollbar_on_left=YES config option</em> + </p> + </body> +</html> +``` + +--%-- +From: rodarima +Date: Thu, 27 Feb 2025 22:25:58 +0000 + +Ah, I see. We first perform the layouting in one go, assuming the scrollbar is not needed and placing the content closer to the window border. Then the canvas ascent and descent is updated, triggering Layout::containerSizeChanged: + +https://github.com/dillo-browser/dillo/blob/fbd719f93ab659fec6c42952e76f5e5b971728be/dw/layout.cc#L966-L972 + +https://github.com/dillo-browser/dillo/blob/fbd719f93ab659fec6c42952e76f5e5b971728be/dw/layout.cc#L1344-L1354 + +But this in turn never enters again inside the conditional: + +https://github.com/dillo-browser/dillo/blob/fbd719f93ab659fec6c42952e76f5e5b971728be/dw/layout.cc#L928-L929 + +So the allocation.x is never updated: + +https://github.com/dillo-browser/dillo/blob/fbd719f93ab659fec6c42952e76f5e5b971728be/dw/layout.cc#L947-L948 + +We cannot apply this optimization: + +https://github.com/dillo-browser/dillo/blob/fbd719f93ab659fec6c42952e76f5e5b971728be/dw/layout.cc#L925-L929 + +As otherwise we will miss the case in which the canvas it too large when the toplevel widget has finished rendering. We need to trigger a toplevel resize as if the viewport has changed its size. + +--%-- +From: rodarima +Date: Thu, 27 Feb 2025 23:02:51 +0000 + +The toplevel widget will refuse to queue a resize if its own size is specified in absolute units: + +https://github.com/dillo-browser/dillo/blob/fbd719f93ab659fec6c42952e76f5e5b971728be/dw/widget.cc#L456-L460 + +This is actually correct, as the size of the widget won't change. We only need to force the top level widget to re-allocate (compute the position of the tree in a different offset). We can just enable the NEEDS_ALLOCATE flag when we detect that the scrollbar was just enabled. + +--%-- +From: rodarima +Date: Thu, 27 Feb 2025 23:04:41 +0000 + +That seems to fix it. I will need to check we don't accidentally enter a loop of allocations, but it doesn't seem posible. It will trigger the emergency brake anyway. + +
\ No newline at end of file diff --git a/36/index.md b/36/index.md new file mode 100644 index 0000000..d79f56a --- /dev/null +++ b/36/index.md @@ -0,0 +1,45 @@ +Title: CSS max-width not working properly +Author: rodarima +Created: Sun, 24 Dec 2023 18:15:51 +0000 +State: closed + +Example page: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test max-width CSS property</title> + <style> + body {max-width: 200px} + </style> + </head> + <body> + <p> + This is a rather long text to increase the maximal paragraph + width. Sed ut perspiciatis, unde omnis iste natus error sit voluptatem + accusantium doloremque laudantium, totam rem aperiam eaque ipsa, quae + ab illo inventore veritatis et quasi architecto beatae vitae dicta + sunt, explicabo. nemo enim ipsam voluptatem, quia voluptas sit, + aspernatur aut odit aut fugit, sed quia consequuntur magni dolores + eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, + qui dolorem ipsum, quia dolor sit, amet, consectetur, adipisci velit, + sed quia non numquam eius modi tempora incidunt, ut labore et dolore + magnam aliquam quaerat voluptatem. ut enim ad minima veniam, quis + nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut + aliquid ex ea commodi consequatur? quis autem vel eum iure + reprehenderit, qui in ea voluptate velit esse, quam nihil molestiae + consequatur, vel illum, qui dolorem eum fugiat, quo voluptas nulla + pariatur? + </p> + </body> +</html> +``` + +Renders like this: + + + +While the width should be constrained to 200 px, like this in Firefox: + + diff --git a/360/index.md b/360/index.md new file mode 100644 index 0000000..a86a5a8 --- /dev/null +++ b/360/index.md @@ -0,0 +1,8 @@ +Title: Fix text under scrollbar on the left +Author: rodarima +Created: Thu, 27 Feb 2025 23:12:19 +0000 +State: closed + +When the page is first layouted, we can then determine if the vertical scrollbar needs to be present. When the vertical scrollbar is on the left side, the whole content needs to be shifted to the right, so we need to allocate the top level widget again. The current fix simply marks the top level widget for allocation. + +Fixes: https://github.com/dillo-browser/dillo/issues/359
\ No newline at end of file diff --git a/361/index.md b/361/index.md new file mode 100644 index 0000000..0afae67 --- /dev/null +++ b/361/index.md @@ -0,0 +1,10 @@ +Title: DNS blocks in non-threaded mode +Author: rodarima +Created: Sun, 02 Mar 2025 19:36:17 +0000 +State: open + +We may want to consider bringing a truly non-blocking DNS implementation instead of relying on getaddrinfo() which will block the thread and lock the UI when the threading mode is disabled. This also makes Dillo require support for threads when we could drop it completely. + +Newer alternatives like getaddrinfo_a() just do what we already do but requiring a much modern glibc. + +See: https://c-ares.org/
\ No newline at end of file diff --git a/362/index.md b/362/index.md new file mode 100644 index 0000000..1a5bb53 --- /dev/null +++ b/362/index.md @@ -0,0 +1,6 @@ +Title: X11 is a required dependecy when using XEmbed +Author: rodarima +Created: Sun, 02 Mar 2025 22:33:48 +0000 +State: open + +We should link with -lX11 regardless of what FLTK includes.
\ No newline at end of file diff --git a/363/index.md b/363/index.md new file mode 100644 index 0000000..4c5794e --- /dev/null +++ b/363/index.md @@ -0,0 +1,673 @@ +Title: dillo 3.2 release on irix 6.5.21+ +Author: Sunny-Maxis +Created: Tue, 04 Mar 2025 05:47:44 +0000 +State: open + +Hello everyone, + +I am under the employ of Kazuo Kuroi (owner of IRIXNet) and trying to test if dillo can be built on IRIX. + +Here is my analysis and work thus far: + +Firstly, all C++ dependencies must be built with GCC. This is due to incompatible C++ ABI (and because Mipspro does not support variadic macros) + +As far as building it goes, we had a couple of hiccups from bad headers. Kazuo observed that the stat64 struct pissed off our GCC 6.5.0 requiring us to patch the header temporarily although we will probably be able to fix include in GCC if necessary. + +As far as building, we got to the final link stage: + +/opt/gcc/bin/g++ -I/usr/nekoware/include/libpng16 -I/usr/nekoware/include -I/usr/nekoware/include/freetype2 -I/usr/nekoware/include/libpng16 -I/usr/nekoware/include -O2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -pedantic -std=c++11 -D_POSIX_C_SOURCE=200112L -L/usr/nekoware/gcc/lib32 -Wl,-rpath -L/usr/nekoware/lib32 -L/usr/lib32 -Wl,/usr/nekoware/gcc/lib32 -lxg -lgen -o dillo dillo.o version.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o actions.o hsts.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o webp.o svg.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/nekoware/lib32 -lpng16 -lwebp -L/usr/nekoware/lib32 -Wl,-rpath,/usr/nekoware/lib32 -L/usr/lib32 -Wl,-rpath -Wl,/usr/nekoware/lib32 -lfltk -lXrender -lXext -lfontconfig -lpthread -lm -lX11 -lz -liconv -lcrypto -lssl +/usr/nekoware/lib32/libxg.so: undefined reference to `dirfd' +/usr/nekoware/lib32/libXrender.so: undefined reference to `_XEatDataWords' + +We are not 100% sure what is causing the error with libxrender. That's something that will need to be diagnosed further. It might be a C++ name mangling issue or something + +Ignoring the error with libxg (a library built by Kazuo to offer setenv on IRIX, here's the summary of work to maintain IRIX support in tree: + +In dpi.c you should not include netinet/tcp.h with the __sgi macro guarding it out. Instead, manually define TCP_NODELAY with 0x01 + +Make sure configure checks if on irix you're using GCC. Mipspro probably will never build unless you got rid of all variadic macros and ditched a move to C++11, so as that's infeasible/impractical, just make sure that GCC is the actual compiler being used. + +menu.cc should have a compat for setenv(). That is why we pulled in libxg (libxenograft) but it should not be relied on as not everybody is using this compatibility library. We are hardly the only platform with out this set of functionality. + +That's all there is to it. Everything else about our issues linking and building it at this point should be fixable on our end soon. We are using a messy tool chain and a messy set of dependencies that might be causing some of our problems. Fix these issues, and I wouldn't be surprised if it builds on most ancient SVR4 systems with little pain. + +I will be happy to submit a pull request to fix some of these problems when I have more information in front of me but I need to figure out how to add setenv() to this if that duty falls to me (honestly I would prefer you guys to just incorporate it in a way that's not going to hurt you) + +Best regards, + +Patrick "Sunny" Maxis + +--%-- +From: rodarima +Date: Tue, 04 Mar 2025 20:13:57 +0000 + +> Hello everyone, +> +> I am under the employ of Kazuo Kuroi (owner of IRIXNet) and trying to test if dillo can be built on IRIX. +> +> Here is my analysis and work thus far: +> +> Firstly, all C++ dependencies must be built with GCC. This is due to incompatible C++ ABI (and because Mipspro does not support variadic macros) + +I think we could drop the variadic macros, but not sure if it is worth the hassle. Maybe I can leave this for later as it seems GCC is a way to avoid this for now. + +> As far as building it goes, we had a couple of hiccups from bad headers. Kazuo observed that the stat64 struct pissed off our GCC 6.5.0 requiring us to patch the header temporarily although we will probably be able to fix include in GCC if necessary. +> +> As far as building, we got to the final link stage: +> +> /opt/gcc/bin/g++ -I/usr/nekoware/include/libpng16 -I/usr/nekoware/include -I/usr/nekoware/include/freetype2 -I/usr/nekoware/include/libpng16 -I/usr/nekoware/include -O2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -pedantic -std=c++11 -D_POSIX_C_SOURCE=200112L -L/usr/nekoware/gcc/lib32 -Wl,-rpath -L/usr/nekoware/lib32 -L/usr/lib32 -Wl,/usr/nekoware/gcc/lib32 -lxg -lgen -o dillo dillo.o version.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o actions.o hsts.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o webp.o svg.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/nekoware/lib32 -lpng16 -lwebp -L/usr/nekoware/lib32 -Wl,-rpath,/usr/nekoware/lib32 -L/usr/lib32 -Wl,-rpath -Wl,/usr/nekoware/lib32 -lfltk -lXrender -lXext -lfontconfig -lpthread -lm -lX11 -lz -liconv -lcrypto -lssl +/usr/nekoware/lib32/libxg.so: undefined reference to 'dirfd' +/usr/nekoware/lib32/libXrender.so: undefined reference to '_XEatDataWords' +> +> We are not 100% sure what is causing the error with libxrender. That's something that will need to be diagnosed further. It might be a C++ name mangling issue or something + +Regarding: + +> /usr/nekoware/lib32/libXrender.so: undefined reference to '_XEatDataWords' + +In my system (Arch Linux) libXrender.so requires the symbol _XEatDataWords which is provided by needed shared library libX11.so.6 in the ELF header of libXrender.so: + +``` +% readelf -Ws /usr/lib/libXrender.so | grep _XEatDataWords + 40: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _XEatDataWords + +% readelf -d /usr/lib/libXrender.so + +Dynamic section at offset 0x9c80 contains 26 entries: + Tag Type Name/Value + 0x0000000000000001 (NEEDED) Shared library: [libX11.so.6] + 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] + 0x000000000000000e (SONAME) Library soname: [libXrender.so.1] + 0x000000000000000c (INIT) 0x2000 + 0x000000000000000d (FINI) 0x8564 + 0x0000000000000019 (INIT_ARRAY) 0xac70 + 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) + 0x000000000000001a (FINI_ARRAY) 0xac78 + 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) + 0x000000006ffffef5 (GNU_HASH) 0x310 + 0x0000000000000005 (STRTAB) 0xd60 + 0x0000000000000006 (SYMTAB) 0x508 + 0x000000000000000a (STRSZ) 1663 (bytes) + 0x000000000000000b (SYMENT) 24 (bytes) + 0x0000000000000007 (RELA) 0x14e8 + 0x0000000000000008 (RELASZ) 1128 (bytes) + 0x0000000000000009 (RELAENT) 24 (bytes) + 0x000000000000001e (FLAGS) BIND_NOW + 0x000000006ffffffb (FLAGS_1) Flags: NOW + 0x000000006ffffffe (VERNEED) 0x1498 + 0x000000006fffffff (VERNEEDNUM) 1 + 0x000000006ffffff0 (VERSYM) 0x13e0 + 0x0000000000000024 (RELR) 0x1950 + 0x0000000000000023 (RELRSZ) 24 (bytes) + 0x0000000000000025 (RELRENT) 8 (bytes) + 0x0000000000000000 (NULL) 0x0 + +% readelf -Ws /usr/lib/libX11.so | grep _XEatDataWords + 829: 0000000000017584 93 FUNC GLOBAL DEFAULT 9 _XEatDataWords +``` + +Does your libX11.so provide it? This simple test isolates any potential problem from mangling: + +``` +% cat a.c +void _XEatDataWords(void); + +int main() +{ + _XEatDataWords(); + return 0; +} +% gcc a.c -o a -lXrender +/usr/bin/ld: /tmp/cc0TaBie.o: undefined reference to symbol '_XEatDataWords' +/usr/bin/ld: /usr/lib/libX11.so.6: error adding symbols: DSO missing from command line +collect2: error: ld returned 1 exit status +% gcc a.c -o a -lXrender -lX11 +% gcc a.c -o a -lX11 -lXrender +``` + +> Ignoring the error with libxg (a library built by Kazuo to offer setenv on IRIX, here's the summary of work to maintain IRIX support in tree: +> +> In dpi.c you should not include netinet/tcp.h with the __sgi macro guarding it out. Instead, manually define TCP_NODELAY with 0x01 + +I think this could be tested at configure time and set a HAVE_TCP_NODELAY or similar, so we don't need to rely on __sgi directly. + +> Make sure configure checks if on irix you're using GCC. Mipspro probably will never build unless you got rid of all variadic macros and ditched a move to C++11, so as that's infeasible/impractical, just make sure that GCC is the actual compiler being used. + +Maybe we can just add a check for variadic macros at configure time as well? This may fail on other compilers as well. + +> menu.cc should have a compat for setenv(). That is why we pulled in libxg (libxenograft) but it should not be relied on as not everybody is using this compatibility library. We are hardly the only platform with out this set of functionality. + +Do you have putenv()? We can make a compatibility implementation if not found at configure time. + +> That's all there is to it. Everything else about our issues linking and building it at this point should be fixable on our end soon. We are using a messy tool chain and a messy set of dependencies that might be causing some of our problems. Fix these issues, and I wouldn't be surprised if it builds on most ancient SVR4 systems with little pain. + +That's actually not that bad :-) + +> I will be happy to submit a pull request to fix some of these problems when I have more information in front of me but I need to figure out how to add setenv() to this if that duty falls to me (honestly I would prefer you guys to just incorporate it in a way that's not going to hurt you) + +I can prepare some patches, but it would be nice if you can test them on IRIX. Also, if you manage to run it, I would like to add a screenshot and/or picture to the gallery: https://dillo-browser.github.io/gallery/index.html + +--%-- +From: rodarima +Date: Tue, 04 Mar 2025 23:11:26 +0000 + +Regarding + +> > In dpi.c you should not include netinet/tcp.h with the __sgi macro guarding it out. Instead, manually define TCP_NODELAY with 0x01 +> +> I think this could be tested at configure time and set a HAVE_TCP_NODELAY or similar, so we don't need to rely on __sgi directly. + +Is `netinet/tcp.h` missing in your specific version of IRIX?, or is just not defining TCP_NODELAY?. + +This IRIX manual I could find online seems to suggest that it must be defined in `netinet/tcp.h`: + +https://nixdoc.net/man-pages/IRIX/man7/tcp.7.html + +``` + TCP supports two socket options which can be tested with getsockopt(2), + and manipulated with setsockopt(2). These options are defined in + <netinet/tcp.h>. + + TCP_NODELAY + Under most circumstances, TCP sends data when it is presented; when + outstanding data has not yet been acknowledged, it gathers small + amounts of output to be sent in a single packet once an + acknowledgement is received. For a small number of clients, such as + window systems that send a stream of mouse events which receive no + replies, this packetization may cause significant delays. + Therefore, TCP provides a boolean option, TCP_NODELAY, to defeat + this algorithm. +``` + +If it is missing, is `TCP_NODELAY` defined elsewhere, so we can include that header instead? It would be nice if I can get a copy of the headers so I can see how things are defined in IRIX. + +Otherwise, how can we know it has value 0x01 and it is supported? + +Another way is to avoid the `setsockopt()` when TCP_NODELAY is not defined, as it is only used to improve the performance while communicating with the plugins via localhost, so we assume that it is not supported. + +Here is a curl patch that does that when not defined: + +https://curl.se/mail/lib-2004-03/0340.html + +--%-- +From: Sunny-Maxis +Date: Wed, 05 Mar 2025 03:55:22 +0000 + +> I think we could drop the variadic macros, but not sure if it is worth the hassle. Maybe I can leave this for later as it seems GCC is a way to avoid this for now. + +It's definitely a portability problem if you want portability with ancient compilers. + +> Does your libX11.so provide it? + +We failed that test because we don't have Xrender in base. We also cannot recompile our X stuff, as we use XSGI. I will have to see if an older version of libXrender gets around this issue. Or else rewrite our implementation. I figured it was something to do with GNU ld which is a giant issue on our platform for various reasons. It tends to break in very unpredictable ways. + +Either way I thank you for pointing that out regardless because I would not have picked up on that. + +We managed to correct that issue by updating our libXrender code to not define it. + +> I think this could be tested at configure time and set a HAVE_TCP_NODELAY or similar, so we don't need to rely on __sgi directly. + +The issue more so is that our base header is a problem. Some headers on IRIX are not GCC-safe and I can't necessarily test your program with mipspro unless you really want to strip away anything super problematic to it's c99 compiler. Genuinely don't think that that's worth our time either way unless you really want to commit to it. +Trust me when I say this is an SGI specific problem. You need to guard the header and manually define it. I'm not going to start patching headers against it it's not something that's worth doing for a variety of reasons. + +> Is netinet/tcp.h missing in your specific version of IRIX?, or is just not defining TCP_NODELAY?. + +The header literally chokes GCC out. Here's the actual error and there's only really very little I can do except for probably try to build a fixinclude for it (we are using an unofficial GCC 6 build) + +https://pastebin.com/MLA5dyuV + +The problem primarily is that some of these headers are system headers and they're not intended for use by GCC, which is a guest compiler, on our system. So the easiest way to fix this is to just manually define it for our platform specifically. There are no other versions of IRIX that are probably going to be running this. + +> Do you have putenv()? We can make a compatibility implementation if not found at configure time. + +That would be acceptable yes. + +> I can prepare some patches, but it would be nice if you can test them on IRIX + +Me and the boss are willing to do our best about tracking you guys and reporting issues as they come up as well as offering patches. But we can't make exact time guarantees + +--%-- +From: rodarima +Date: Wed, 05 Mar 2025 20:05:43 +0000 + +> Either way I thank you for pointing that out regardless because I would not have picked up on that. +> +> We managed to correct that issue by updating our libXrender code to not define it. + +Nice! + +> > I think this could be tested at configure time and set a HAVE_TCP_NODELAY or similar, so we don't need to rely on __sgi directly. +> +> The issue more so is that our base header is a problem. Some headers on IRIX are not GCC-safe and I can't necessarily test your program with mipspro unless you really want to strip away anything super problematic to it's c99 compiler. Genuinely don't think that that's worth our time either way unless you really want to commit to it. Trust me when I say this is an SGI specific problem. You need to guard the header and manually define it. I'm not going to start patching headers against it it's not something that's worth doing for a variety of reasons. +> +> > Is netinet/tcp.h missing in your specific version of IRIX?, or is just not defining TCP_NODELAY?. +> +> The header literally chokes GCC out. Here's the actual error and there's only really very little I can do except for probably try to build a fixinclude for it (we are using an unofficial GCC 6 build) +> +> https://pastebin.com/MLA5dyuV +> +> The problem primarily is that some of these headers are system headers and they're not intended for use by GCC, which is a guest compiler, on our system. So the easiest way to fix this is to just manually define it for our platform specifically. There are no other versions of IRIX that are probably going to be running this. + +I see. I have added the fix you suggest, but I would like to explore a better solution as it looks like a very brittle workaround (for example if we use another define it would break if we don't define it manually as well). + +From those logs it looks like the only problem is that u_short and u_char are not defined. This may be just a case in which netinet/tcp.h needs those types being defined before it is included. + +Could you provide the output of this? (on /usr/include or where the headers are located in IRIX): + +``` +$ grep -R 'typedef.* u_char' /usr/include +``` + +In my system, they seem to be defined at sys/types.h, so I imagine something like this would work: + +``` +% cat nodelay.c +#include <sys/types.h> /* u_char, u_short */ +#include <netinet/tcp.h> /* TCP_NODELAY */ +#include <stdio.h> /* printf */ + +int main() +{ + printf("TCP_NODELAY = %d\n", TCP_NODELAY); + return 0; +} +% gcc nodelay.c -o nodelay +% ./nodelay +TCP_NODELAY = 1 +``` + +If that is the case, we just need to include that file before netinet/tcp.h. + +> > Do you have putenv()? We can make a compatibility implementation if not found at configure time. +> +> That would be acceptable yes. + +I have added an implementation, but it would be nice if you can test it as I won't be able to test if it actually works: https://github.com/dillo-browser/dillo/pull/364 + +--%-- +From: Sunny-Maxis +Date: Wed, 05 Mar 2025 22:15:41 +0000 + +Ignore my past comment that I had which I just deleted. + +The setenv() fix still requires unsetenv() which we don't have either. + +I just checked. I don't have recursive grep (IRIX is SVR4, we don't use coreutils) so I ran it with find and yes the inclusion is in sys/types.h + +I don't think you're understanding what the problem is exactly but it's okay, I'll illustrate: + +https://pastebin.com/raw/iA2Ndtmy + +This is the header in question. It's designed for mipspro. On IRIX, by default, several of the headers are separated between ANSI, C99 and C++. For instance stdint.h. this breaks a lot of stuff so when GCC comes in it just ignores all of the include guards and in some cases has fixincludes to fix the most egregious, but this is not the case for all of them. + +The problem is it's choking on the struct tcphdr. And if I were to correct it, it potentially breaks mipspro. This makes the header unusable for GCC. This is not the only place in the system this occurs, it happens with several XOPEN headers forcing you to manually pull various definitions. It's not something I can correct for because this is a proprietary operating system. We aren't like open Solaris and we can't make assumptions that people will have patched headers. + +Unfortunately this is the case with supporting older operating systems: you often have to use nasty hacks and brittle fixes. There's not a way I can understand to compromise this. A potential fix of building a fixincludes for GCC is possible but honestly it's not worth it in this case. This is the only time I've ever had this particular issue and I've built half a dozen programs with it. + +If you want to avoid having such brittle fixes directly in the line of fire, add a compat_irix header full ;f.manual definitions and hacks. This is what my boss does for libjpegturbo and a few others we fork. + +Also the proper manual definition is 0x01. It might not make a difference but I always like to copy what the actual header actually says. + +I don't know a lot of ways I can easily compromise and fix this on an our end; we are stuck in a similar situation to ArcaOS. We are applying patches and fixes to the system but we have to do so in a relatively conservative manner to avoid breaking things. There's not really a way I can just radically change stuff up. + +--%-- +From: rodarima +Date: Wed, 05 Mar 2025 23:53:11 +0000 + +> Ignore my past comment that I had which I just deleted. +> +> The setenv() fix still requires unsetenv() which we don't have either. + +Hmm, I think we can ignore that as it will be unlikely that it is already set on the environment. Otherwise we will need to get the env pointer and do it manually. I updated the PR, let me know if that works now. + +> I just checked. I don't have recursive grep (IRIX is SVR4, we don't use coreutils) so I ran it with find and yes the inclusion is in sys/types.h +> +> I don't think you're understanding what the problem is exactly but it's okay, I'll illustrate: +> +> https://pastebin.com/raw/iA2Ndtmy +> +> This is the header in question. It's designed for mipspro. On IRIX, by default, several of the headers are separated between ANSI, C99 and C++. For instance stdint.h. this breaks a lot of stuff so when GCC comes in it just ignores all of the include guards and in some cases has fixincludes to fix the most egregious, but this is not the case for all of them. +> +> The problem is it's choking on the struct tcphdr. And if I were to correct it, it potentially breaks mipspro. This makes the header unusable for GCC. This is not the only place in the system this occurs, it happens with several XOPEN headers forcing you to manually pull various definitions. It's not something I can correct for because this is a proprietary operating system. We aren't like open Solaris and we can't make assumptions that people will have patched headers. +> +> Unfortunately this is the case with supporting older operating systems: you often have to use nasty hacks and brittle fixes. There's not a way I can understand to compromise this. A potential fix of building a fixincludes for GCC is possible but honestly it's not worth it in this case. This is the only time I've ever had this particular issue and I've built half a dozen programs with it. +> +> If you want to avoid having such brittle fixes directly in the line of fire, add a compat_irix header full ;f.manual definitions and hacks. This is what my boss does for libjpegturbo and a few others we fork. +> +> Also the proper manual definition is 0x01. It might not make a difference but I always like to copy what the actual header actually says. + + +Thanks for the extra details, it makes it more clear. + +I understand it is not viable to modify the headers. My suggestion is to pre-define some types from Dillo source *before* we include the netinet/tcp.h file so it works on GCC as-is. + +If the only two types missing are u_char and u_short (and based on your build errors it looks like it is so), we could do this: + +``` +typedef unsigned char u_char; +typedef unsigned short u_short; +#include <netinet/tcp.h> /* TCP_NODELAY */ +#include <stdio.h> /* printf */ + +int main() +{ + printf("TCP_NODELAY = %d\n", TCP_NODELAY); + return 0; +} +``` + +And it will compile fine. If you can test this, I can update the PR with these typedefs for IRIX. + +Based on your log, there doesn't seem to be any other error. + +I did a test on my system to check if that may work and it seems that it does. + +--- + +First I copied your netinet/tcp.h header as-is in ./netinet/tcp.h and added some dummy headers to fill the missing definitions that your IRIX system seems to provide in sgidefs.h and sys/endian.h (or other included files by those): + +``` +% find +. +./netinet +./netinet/tcp.h +./sgidefs.h +./sys +./sys/endian.h +./nodelay.c + +% cat sys/endian.h +#define _LITTLE_ENDIAN 'L' +#define _BIG_ENDIAN 'B' +#define _BYTE_ORDER _BIG_ENDIAN + +% cat sgidefs.h +typedef unsigned int __uint32_t; +``` + +Then I added those typedefs with a guard I can enable or disable from the command line: + +``` +% cat nodelay.c +#ifdef FIX_IRIX +typedef unsigned char u_char; +typedef unsigned short u_short; +#endif + +#include <netinet/tcp.h> /* TCP_NODELAY */ +#include <stdio.h> /* printf */ + +int main() +{ + printf("TCP_NODELAY = %d\n", TCP_NODELAY); + return 0; +} +``` + +To build it, I add the -isystem flag so it picks my hacky headers to mimic your system, but you won't need any of that. + +Without the fix, I get the same 7 errors as you get: + +``` +% gcc -isystem . nodelay.c -o nodelay +In file included from nodelay.c:6: +./netinet/tcp.h:38:9: error: unknown type name ‘u_short’; did you mean ‘short’? + 38 | u_short th_sport; /* source port */ + | ^~~~~~~ + | short +./netinet/tcp.h:39:9: error: unknown type name ‘u_short’; did you mean ‘short’? + 39 | u_short th_dport; /* destination port */ + | ^~~~~~~ + | short +./netinet/tcp.h:52:9: error: unknown type name ‘u_char’; did you mean ‘char’? + 52 | u_char th_off:4, /* data offset */ + | ^~~~~~ + | char +./netinet/tcp.h:55:9: error: unknown type name ‘u_char’; did you mean ‘char’? + 55 | u_char th_flags; + | ^~~~~~ + | char +./netinet/tcp.h:62:9: error: unknown type name ‘u_short’; did you mean ‘short’? + 62 | u_short th_win; /* window */ + | ^~~~~~~ + | short +./netinet/tcp.h:63:9: error: unknown type name ‘u_short’; did you mean ‘short’? + 63 | u_short th_sum; /* checksum */ + | ^~~~~~~ + | short +./netinet/tcp.h:64:9: error: unknown type name ‘u_short’; did you mean ‘short’? + 64 | u_short th_urp; /* urgent pointer */ + | ^~~~~~~ + | short +``` + +But adding those typedefs at the beginning it seems to work fine: + +``` +% gcc -DFIX_IRIX -isystem . nodelay.c -o nodelay +hop% ./nodelay +TCP_NODELAY = 1 +``` + + +> I don't know a lot of ways I can easily compromise and fix this on an our end; we are stuck in a similar situation to ArcaOS. We are applying patches and fixes to the system but we have to do so in a relatively conservative manner to avoid breaking things. There's not really a way I can just radically change stuff up. + +If you are willing to modify the headers, you can add a guard for GCC only that does those definitions for that netinet/tcp.h file: + +``` +#ifdef __GNUC__ +#warning "HACK: Adding extra definitions to fix GCC" +typedef unsigned char u_char; +typedef unsigned short u_short; +#endif +/* rest of netinet/tcp.h file */ +``` + +You can test with mipspro that it doesn't emit the warning, but only gcc does. Maybe a more universal solution is to find out why they are not being picked by GCC and maybe add the `__GNUC__` as part of the guards so the definitions are also included for gcc. If you send me a tarball with all system headers I can suggest some changes to try to fix them (mail them to me if you don't want to upload them here). + +Regardless of that, I would like to make Dillo work on IRIX without modifying the system headers. + +--%-- +From: Sunny-Maxis +Date: Thu, 06 Mar 2025 01:16:52 +0000 + +Your fix did work with the caveat that stdint.h must be placed before tcp.h + +Your unsetenv() fix worked as well. + +I can definitely poke around and copy a set of headers in the future. This machine is not representative of most SGI machines as we have been using it for experimental purposes so I can't guarantee that the headers are accurate, so let me pull them from one of his other machines either this weekend or sometime soon in general. + +I did not think to bring this up beforehand but we did have another issue: + +For dpid (e.g. not the browser, but the plugin stuff) we have an error in GCC that says: + + +```main.c:232:19: error: storage size of 'select_timeout' isn't known + struct timeval select_timeout; + ^~~~~~~~~~~~~~ +main.c:312:14: warning: implicit declaration of function 'select' [-Wimplicit-function-declaration] + n = select(FD_SETSIZE, &selected_set, NULL, NULL, &select_timeout); + ^~~~~~ +main.c:232:19: warning: unused variable 'select_timeout' [-Wunused-variable] + struct timeval select_timeout; + +``` + +This is not an error that I am familiar with myself as I am less than familiar with the style of programming that is being used here. If you have any insight on where I can guide the fix of this issue. + +--%-- +From: rodarima +Date: Thu, 06 Mar 2025 18:23:18 +0000 + +> Your fix did work with the caveat that stdint.h must be placed before tcp.h +> +> Your unsetenv() fix worked as well. + +Great! + +> I did not think to bring this up beforehand but we did have another issue: +> +> For dpid (e.g. not the browser, but the plugin stuff) we have an error in GCC that says: +> +> ``` +> struct timeval select_timeout; +> ^~~~~~~~~~~~~~ +> main.c:312:14: warning: implicit declaration of function 'select' [-Wimplicit-function-declaration] +> n = select(FD_SETSIZE, &selected_set, NULL, NULL, &select_timeout); +> ^~~~~~ +> main.c:232:19: warning: unused variable 'select_timeout' [-Wunused-variable] +> struct timeval select_timeout; +> +> ``` +> +> This is not an error that I am familiar with myself as I am less than familiar with the style of programming that is being used here. If you have any insight on where I can guide the fix of this issue. + +This seems to be a similar case, we are not including the `struct timeval` or `select` definition. It looks like in IRIX we need extra headers: + +https://nixdoc.net/man-pages/IRIX/man2/standard/select.2.html + +So I added them to the PR. It should build fine now if that is the problem. + +--%-- +From: Sunny-Maxis +Date: Thu, 06 Mar 2025 22:06:24 +0000 + +I had to explicitly declare the struct in dpid/main.c and dpi/file.c + +I think the best way to handle this would be to make a header sgi_timeval.h or something and explicitly declare the struct there. + +I can also give you the exact sys/time.h and let you give it a shot on coming up with a creative solution but on my end it's not reading the timeval struct. + +Let me know how you want to handle this. That is however the last particular error that I'm dealing with on the current release tarball. + +If in the future you want to do away with variadic macros I can probably work with you to get running on mipspro C++ in the current form although I will leave that decision up to you and your team. That is a somewhat monumental task to strip those out and that might reduce functionality in some cases or require a big rewrite so I would rather not put more work on you guys when you've been so accommodating. + +--%-- +From: rodarima +Date: Wed, 19 Mar 2025 23:09:11 +0000 + +> I had to explicitly declare the struct in dpid/main.c and dpi/file.c +> +> I think the best way to handle this would be to make a header sgi_timeval.h or something and explicitly declare the struct there. + +We can make an explicit definition if you know the types that timeval is using in SGI. Which definition are you using? On my system they are longs: + +```c +typedef long int time_t; +typedef long int suseconds_t; + +struct timeval { + time_t tv_sec; + suseconds_t tv_usec; +}; +``` + +> I can also give you the exact sys/time.h and let you give it a shot on coming up with a creative solution but on my end it's not reading the timeval struct. + +Can you make a tarball of all headers in /usr/include (or the relevant places) and send it? If you want to keep it private, my email is my username at gmail.com. This would allow me to decide what is the best solution to support SGI in the long run. + +> Let me know how you want to handle this. That is however the last particular error that I'm dealing with on the current release tarball. +> +> If in the future you want to do away with variadic macros I can probably work with you to get running on mipspro C++ in the current form although I will leave that decision up to you and your team. That is a somewhat monumental task to strip those out and that might reduce functionality in some cases or require a big rewrite so I would rather not put more work on you guys when you've been so accommodating. + +For me it would be nice to support GCC as a first step. Maybe we can evaluate later if mipspro is a suitable solution, because removing the variadic macros may not be the only problem. + +--%-- +From: Sunny-Maxis +Date: Thu, 20 Mar 2025 01:28:30 +0000 + +Sending you a tarball with the stuff within an hour, as for this issue: +```c +#if defined(__sgi) && defined(__GNUC__) +struct timeval { +time_t tv_sec; +long tv_usec; +} select_timeout; + +``` +This is the code that I used to fix the issue. I defined it for GNUC because testing with your example, mipspro doesn't care. If we ever do manage to provide support, then it should be good. + +I will reply to the Variadic macro issue in that issue with an explanation and reasoning. + +--%-- +From: rodarima +Date: Sun, 30 Mar 2025 20:07:20 +0000 + +Thanks, I got your mail. I did some experimentation last week, and I now I understand the situation a bit better. It seems that we have 3 groups of problems: + +- GCC must mimic all SGI defines of MIPSpro to be able to use the headers properly. We can add some `#ifdef` logic to detect it is doing the right thing. +- There are missing definitions in the IRIX headers for u_char, u_short, u_int and u_long. Not sure if mipspro defines this on their own, but GCC doesn't. We will need to provide our own. +- IRIX doesn't implement POSIX 2001, which is the lowest standard Dillo supports (at least that I have tested). Enabling that POSIX version doesn't cause the headers to enable enough declarations for it to work. But we can try with _XOPEN_SOURCE 520, which may be enough. + +I did an experiment with a simple program that tries to detect if my intuitions are correct. Here it is. It should build fine as-is with `gcc test.c -o test` if I'm right: + +```c +/* This test checks if we can provide some definitions in IRIX */ + +/* 1. This is only to simulate what gcc should do on MIPS but I'm using x86. + * Ignore this block on IRIX, as the ifdef guard won't include it. */ +#ifdef __x86_64__ +/* These must be provided by gcc when building for mips */ +# define _MIPS_SZLONG 32 +# define _MIPS_SZPTR 32 +# define _MIPS_SZINT 32 +# define _ABIN32 1 +# define __mips__ +# define _MIPSEB 1 +# define _MIPS_SIM _ABIN32 /* Using the new ABI for 32 bits */ +# define _LANGUAGE_C +# define _LONGLONG +/* Define __sgi to simulate a SGI compiler */ +# define __sgi +#endif + +/* 2. Missing definitions on SGI for BSD types. They should be in sys/types.h + * but they are not. Only types like ushort_t are defined, but not u_short. */ +#ifdef __sgi +typedef unsigned char u_char; +typedef unsigned short u_short; +typedef unsigned int u_int; +typedef unsigned long u_long; +#endif + +/* 3. Define the proper XOPEN specification here otherwise many definitions + * won't work. */ +#define _XOPEN_SOURCE 520 +//#define _POSIX_C_SOURCE 200112L + +/* 4. The headers as per the manual */ +#include <unistd.h> +#include <sys/types.h> +#include <bstring.h> +#include <sys/time.h> +#include <netinet/tcp.h> /* TCP_NODELAY */ + +/* 5. Finally a dummy test */ +int main(void) +{ + fd_set set; + + FD_ZERO(&set); + FD_SET(1, &set); + FD_CLR(2, &set); + + struct timeval tv = { .tv_sec = TCP_NODELAY, .tv_usec = 0 }; + + return select(0, &set, &set, &set, &tv); +} + +``` + +--%-- +From: Sunny-Maxis +Date: Mon, 31 Mar 2025 01:07:30 +0000 + +Builds fine, doesn't do anything on the commandline. Not a single complaint from GCC about it. + +ABI on irix is always n32, there's no o32 MIPS. + +IRiX 6.5.0 was released in 1998. While updates were provided for C99 support, POSIX98 is the last official supported version. + +I have not personally tested it myself but we have plenty of people who have built it in the past without problems. The reason why I haven't tested my build is simply down to GCC being hard to package for. Out of the machines my boss has running 24/7, all of them are headless, so we can't do a test easily, especially since X forwarding is broken on modern X from IRIX. + +With the manual definition of the struct in place for GCC in the files mentioned, it builds fine, so my work is done with that.
\ No newline at end of file diff --git a/364/index.md b/364/index.md new file mode 100644 index 0000000..208da9e --- /dev/null +++ b/364/index.md @@ -0,0 +1,6 @@ +Title: Add IRIX 6.5.21+ support +Author: rodarima +Created: Wed, 05 Mar 2025 20:04:34 +0000 +State: open + +Fixes #363
\ No newline at end of file diff --git a/365/index.md b/365/index.md new file mode 100644 index 0000000..51d751b --- /dev/null +++ b/365/index.md @@ -0,0 +1,12 @@ +Title: Update install.md +Author: dflock +Created: Thu, 06 Mar 2025 00:33:45 +0000 +State: closed + +Fix folder name. + +--%-- +From: rodarima +Date: Thu, 06 Mar 2025 18:28:13 +0000 + +What is this fixing? The instructions seem okay as they are, as we want to copy the dillo and dpid binaries, then use the script to install the dpis. Although it is better to use --prefix to specify a different install path.
\ No newline at end of file diff --git a/366/index.md b/366/index.md new file mode 100644 index 0000000..c1af7e5 --- /dev/null +++ b/366/index.md @@ -0,0 +1,52 @@ +Title: Remove variadic macros +Author: Sunny-Maxis +Created: Fri, 14 Mar 2025 04:42:56 +0000 +State: open + +I understand this is a massive undertaking. However, there is a demand for such browsers on systems that do not run GCC. + +My boss, Kazuo Kuroi, got around this on libao (much smaller program) by converting the macros to static inlines: + +https://codeberg.org/IRIXNet-Development/Nekoware-Package-Collections/src/branch/main/patches/neko_libao.patch + +If it would be helpful I could probably attempt to stage something within the next month once we are finished with release testing our major projects + +--%-- +From: rodarima +Date: Wed, 19 Mar 2025 23:22:01 +0000 + +We could probably replace all of them, but it would be a major pain. Removing C++ macros is useful because then we could then lower the standard to C++04, but for C macros I don't think it would be very helpful apart for mipspro. + +I would consider exploring this for C only if we find a big blocker that prevents using GCC. + +--%-- +From: Sunny-Maxis +Date: Thu, 20 Mar 2025 01:39:09 +0000 + +Hello Rodrigo, + +GCC works fine with IRIX to an extent, but it has some annoyances: + +1. fltk has to be recompiled from mipspro to GCC because GCC does not respect the sgi c++ ABI. We have tried and failed to fix this. +2. GDB is fundamentally broken on the platform. Some people have managed to push back partial support but it isn't possible to do a lot of useful debugging. +3. For IRIX 6.5.21+, Kaz Kuroi and myself prefer to use mipspro because it: + +- provides a functional and useful debugger +- doesn't require reduplication of libraries using the C++ abi. +- more things are written with the intent of them being built by Mipspro +- packaging for a mixed compiler setup is more complicated. We have to give GCC stuff its own root. +- is there something that a Variadic macro will provide that an inline variadic function will not? Functionally from my testing with libao Kazuo's fix didn't change anything about the library on a substantial level, errors and such still work as intended. +- provides excellent and flexible optimization beyond what GCC offers. We can flag the compiler to not optimize certain functions, determine what types of optimizations should be applied with less verbosity needed (no need for -f/-m flags, these are literally colon separated lists we use for the compiler) shut off warnings easily etc. +- for a lot of programs that might want to use system libraries such as libfam, libviewkit etc. there might not be alternatives to using Mipspro. + +--%-- +From: rodarima +Date: Sun, 30 Mar 2025 20:13:12 +0000 + +I see. I won't oppose switching the variadic macros to functions, as long as we can make the compiler not emit any instruction when the debugging code is disabled (so we don't introduce any slowdown). However, I don't think I will prioritize this on my list of tasks, so you are welcome to provide a PR in this direction. + +--%-- +From: Sunny-Maxis +Date: Mon, 31 Mar 2025 01:08:25 +0000 + +I will talk to him about it and see if we can fork the repo at some point and make it happen. Thanks for being open to it.
\ No newline at end of file diff --git a/367/index.md b/367/index.md new file mode 100644 index 0000000..b05f82a --- /dev/null +++ b/367/index.md @@ -0,0 +1,39 @@ +Title: Custom page menu actions via dillorc +Author: acmiyaguchi +Created: Sun, 16 Mar 2025 21:55:11 +0000 +State: open + +The `link_action` option enables interesting expansions to dillo. For example: + +- `link_action="Open in Reader View:dillo rdrview:$url"` opens a new dillo instance using the rdrview dpi plugin. +- `link_action="Copy link to clipboard:wl-copy $url"` copies a link into the wayland clipboard + +It would be useful to have the same options for the current page via the page menu. + +I propose a similar interface using `page_action` and `$url`. It would enable actions like "open current page in reader view". + +These actions could be expanded even further with https://github.com/dillo-browser/dillo/issues/47 if actions could call a dillo scripting service. For example, you could open the current page using rdrview in a new tab instead of a new dillo instance. It would also be handy if actions were usable in keybindings. + + +--%-- +From: rodarima +Date: Mon, 17 Mar 2025 19:49:14 +0000 + +> The `link_action` option enables interesting expansions to dillo. For example: +> +> * `link_action="Open in Reader View:dillo rdrview:$url"` opens a new dillo instance using the rdrview dpi plugin. +> * `link_action="Copy link to clipboard:wl-copy $url"` copies a link into the wayland clipboard + +Selecting the location URL copies it into the primary selection (XA_PRIMARY) of X11. We may want to also copy it in the XA_CLIPBOARD and maybe the XA_SECONDARY as well. Not sure how wayland deals with that. + +> It would be useful to have the same options for the current page via the page menu. +> +>  +> +> I propose a similar interface using `page_action` and `$url`. It would enable actions like "open current page in reader view". +> +> These actions could be expanded even further with [#47](https://github.com/dillo-browser/dillo/issues/47) if actions could call a dillo scripting service. For example, you could open the current page using rdrview in a new tab instead of a new dillo instance. It would also be handy if actions were usable in keybindings. + +Yes, this is planned. + +We can also replace the current tab with with the reader mode URL (or any other), by using something like `dillocli open --tab $tab rdrview:$url`, where $tab is provided as an envvar that uniquely identifies the current tab.
\ No newline at end of file diff --git a/368/index.md b/368/index.md new file mode 100644 index 0000000..9dc811d --- /dev/null +++ b/368/index.md @@ -0,0 +1,12 @@ +Title: Add .deps/ to .gitignore +Author: acmiyaguchi +Created: Tue, 18 Mar 2025 03:58:19 +0000 +State: closed + +The .deps folders are part of the build process and dirty git status. This ignores them in the project. + +--%-- +From: rodarima +Date: Wed, 19 Mar 2025 22:35:19 +0000 + +Please, do the build in a separate directory as mentioned [in the documentation](https://github.com/dillo-browser/dillo/blob/master/doc/install.md#from-git). I'll merge this regardless.
\ No newline at end of file diff --git a/369/index.md b/369/index.md new file mode 100644 index 0000000..74423ea --- /dev/null +++ b/369/index.md @@ -0,0 +1,50 @@ +Title: Add logging of DPI commands from server +Author: acmiyaguchi +Created: Tue, 18 Mar 2025 04:08:05 +0000 +State: closed + +I'm looking at dpid to get a sense of what it's doing. There's not a whole ton of documentation about the protocol. I've added a few logging macros and put them into the right places to better see the messages flowing in and out of the service: + +``` +$ ./dpid +[dpid]: get_file_type: Unknown file type for style.css +[dpid]: get_file_type: Unknown file type for style.css +[dpid]: a_Misc_mksecret: e38f370d +[dpid]: SEND - 5020 e38f370d + +dpid started (found 10 dpis) +[dpid]: RECV - <cmd='auth' msg='e38f370d' '> +[dpid]: RECV - <cmd='register_all' '> +[dpid]: get_file_type: Unknown file type for style.css +[dpid]: get_file_type: Unknown file type for style.css +[dpid]: RECV - <cmd='auth' msg='e38f370d' '> +[dpid]: RECV - <cmd='DpiBye' '> +``` + +These are the logs generated by startup, followed by `./dpidc register` and `dpidc stop`. There's a stray newline in there because most of the dpi messages are sent without newlines, while the generated port/secret are written using the same write macro with a new line. + +Here's a few more from browsing: + +``` +[dpid]: RECV - <cmd='check_server' msg='bookmarks' '> +[dpid]: SEND - <cmd='send_data' msg='5030' '> +[dpid]: RECV - <cmd='check_server' msg='proto.rdrview' '> +[dpid]: SEND - <cmd='send_data' msg='5021' '> +``` + + +--%-- +From: rodarima +Date: Wed, 19 Mar 2025 22:40:05 +0000 + +> There's not a whole ton of documentation about the protocol. + +This should be solved by extending the docs, not pulluting the stderr with protocol messages. + +--%-- +From: acmiyaguchi +Date: Wed, 19 Mar 2025 23:50:53 +0000 + +That's fair, I'll just keep this patch around for myself as I poke around. + +I'm curious about the protocol, but maybe it's better that I go build an extension to see how it works from the outside.
\ No newline at end of file diff --git a/37/index.md b/37/index.md new file mode 100644 index 0000000..8512c9d --- /dev/null +++ b/37/index.md @@ -0,0 +1,125 @@ +Title: Fix min-width and max-width CSS attributes +Author: rodarima +Created: Mon, 25 Dec 2023 00:42:44 +0000 +State: closed + +The calculation for the width was not taking into account the `min-width` and `max-width` attributes. Fixes #36. + + +https://github.com/dillo-browser/dillo/assets/3866127/5d5613f5-7023-4b92-b9a7-3e23d1a5ed00 + + + +I need to check that there is nothing else breaking, as there are no layout tests. + +--%-- +From: rodarima +Date: Mon, 25 Dec 2023 13:29:28 +0000 + +Still failing for `html {max-width: 600px}`: + + + + +--%-- +From: rodarima +Date: Mon, 25 Dec 2023 21:10:23 +0000 + +It is also failing for the body element, which is missing content: + + + + +--%-- +From: rodarima +Date: Tue, 26 Dec 2023 15:41:24 +0000 + +The problem seems to be caused by the body widget reporting a lineBreakWidth larger than the maximum constrained by the CSS style. I added a small debug window to compare both trees. On the left is the bad test with the body, and on the right the good one with the div. + + + +Which later causes the line break width of the div to be larger than it should be (600 px): + + + + +--%-- +From: rodarima +Date: Sun, 31 Dec 2023 14:50:06 +0000 + +Added automatic tests: + +``` +make check-TESTS +make[3]: Entering directory '/home/ram/dev/dillo/git/build/test/html' +make[4]: Entering directory '/home/ram/dev/dillo/git/build/test/html' +PASS: render/b-div.html +XFAIL: render/float-img-justify.html +XFAIL: render/img-aspect-ratio.html +FAIL: render/max-width-body.html +PASS: render/max-width-div.html +FAIL: render/max-width-html.html +PASS: render/max-width-nested-div.html +FAIL: render/min-width-body.html +PASS: render/min-width-div.html +FAIL: render/min-width-html.html +PASS: render/min-width-nested-div.html +PASS: render/table-thead-tfoot.html +PASS: render/white-space.html +============================================================================ +Testsuite summary for dillo 3.1-dev +============================================================================ +# TOTAL: 13 +# PASS: 7 +# SKIP: 0 +# XFAIL: 2 +# FAIL: 4 +# XPASS: 0 +# ERROR: 0 +============================================================================ +See test/html/test-suite.log +============================================================================ +``` + +--%-- +From: rodarima +Date: Sun, 31 Dec 2023 19:41:08 +0000 + +The problem with the min-width/max-width attributes in the html selector is that there is no Widget associated with the html tag that can hold the CSS style, it is only present for the body. It is also problematic as the styles are parsed *after* the html tag is opened, although there should be doable to update the HTML style and then finish the element when we open a body. + +So far, the body is now fixed: + +``` +PASS: render/b-div.html +XFAIL: render/float-img-justify.html +XFAIL: render/img-aspect-ratio.html +PASS: render/max-width-body.html +PASS: render/max-width-div.html +FAIL: render/max-width-html.html +PASS: render/max-width-nested-div.html +PASS: render/min-width-body.html +PASS: render/min-width-div.html +FAIL: render/min-width-html.html +PASS: render/min-width-nested-div.html +PASS: render/table-thead-tfoot.html +PASS: render/white-space.html +============================================================================ +Testsuite summary for dillo 3.1-dev +============================================================================ +# TOTAL: 13 +# PASS: 9 +# SKIP: 0 +# XFAIL: 2 +# FAIL: 2 +# XPASS: 0 +# ERROR: 0 +============================================================================ +See test/html/test-suite.log +============================================================================ +``` + +--%-- +From: rodarima +Date: Sun, 31 Dec 2023 20:26:36 +0000 + +Let's leave the fix for the HTML element for another PR, as it would require more analysis.
\ No newline at end of file diff --git a/370/index.md b/370/index.md new file mode 100644 index 0000000..c99baf2 --- /dev/null +++ b/370/index.md @@ -0,0 +1,18 @@ +Title: How can I build this with FLTK 1.4 +Author: Tre-brock +Created: Tue, 18 Mar 2025 11:49:29 +0000 +State: closed + +How can I build this with FLTK 1.4, I have a high DPI screen and it would be useful. I saw the commit that prevented it but I'm fine with bugs to be able to see it better. + +--%-- +From: rodarima +Date: Wed, 19 Mar 2025 23:10:43 +0000 + +FLTK 1.4 compatibility is broken in several ways, I will release a fix when it is ready. + +--%-- +From: Tre-brock +Date: Thu, 20 Mar 2025 12:32:54 +0000 + +ok
\ No newline at end of file diff --git a/371/index.md b/371/index.md new file mode 100644 index 0000000..0010fa9 --- /dev/null +++ b/371/index.md @@ -0,0 +1,6 @@ +Title: Display RSS feeds as plain text +Author: rodarima +Created: Wed, 19 Mar 2025 22:28:56 +0000 +State: closed + +Allows inspecting their content before adding it to a feed reader by reading it as plain text.
\ No newline at end of file diff --git a/372/index.md b/372/index.md new file mode 100644 index 0000000..bec8bc7 --- /dev/null +++ b/372/index.md @@ -0,0 +1,8 @@ +Title: Save page dialog has broken filename input +Author: acmiyaguchi +Created: Thu, 20 Mar 2025 01:53:55 +0000 +State: open + + + +When the `save_dir` property is set to `~/`, the filename input is broken. You can remove the `/tmp` part of the text in one backspace, where it then shows the correct path. If you put the full expanded path, then it works as intended.
\ No newline at end of file diff --git a/373/index.md b/373/index.md new file mode 100644 index 0000000..ae746c5 --- /dev/null +++ b/373/index.md @@ -0,0 +1,285 @@ +Title: Support for Content-Disposition filename +Author: campaul +Created: Sun, 23 Mar 2025 20:39:56 +0000 +State: closed + +This is a partial implementation for #168. Currently it only supports the ascii encoded `filename` field and not the more general `filename*` field. This also adds support for the `attachment` content disposition triggering a download even if the content type is able to be displayed. + +The `a_Misc_parse_content_disposition` function is modeled after the `a_Misc_parse_content_type` function so a large portion of that function is copy/pasted. + + +--%-- +From: campaul +Date: Thu, 27 Mar 2025 14:54:21 +0000 + +Spaces in quoted string should work correctly now. + +For handling special filesystem characters I added the following behavior which mostly matches what firefox does: +1. Strip all leading periods +2. Replace `/`, `\`, and `|` with `_` +3. Allow `~` because it has no special meaning after 1 and 2 are done + + +I'm going to continue going through all of the test cases from http://test.greenbytes.de/tech/tc2231/#attabspath over the next few days to make sure there aren't any other edge cases I've missed. + +--%-- +From: campaul +Date: Fri, 28 Mar 2025 16:40:32 +0000 + +I've finished checking all the tests from http://test.greenbytes.de/tech/tc2231/#attabspath and the failures are listed below. Most of the failures are consistent with Firefox's behavior so I'm not sure if we should fix them to match the tests or just leave them as is. Please let me know how you'd like me to handle those. + +The tests for `filename*`, `creation-date`, and `modification-date` are omitted since those fields are currently ignored. + +### Failures that I'm working on fixing +- Escaped quotes handled incorrectly +`attachment; filename="\"quoting\" tested.html"` becomes `_"quoting_" tested.html` instead of `"quoting" tested.html` +- Unknown content dispositions are treated as inline, should be treated as attachment +- "=" is allowed in token field +`attachment; filename==?ISO-8859-1?Q?foo-=E4.html?=` should fail to parse but works as though it was quoted + +### Failures that are consistent with Firefox's behavior +**Should be parse errors but still parses filename (picks same name as Firefox)** +- attachment; filename=foo,bar.html +- attachment; filename=foo.html ; +- attachment; filename="foo.html"; filename="bar.html" +- attachment; filename=foo[1]\(2\).html +- attachment; inline; filename=foo.html +- attachment; filename="foo.html".txt +- attachment filename=bar + +**Should be parse errors but still parses filename (picks different name than Firefox)** +- attachment; ;filename=foo +- attachment; filename=foo bar.html +- attachment; filename="bar +- attachment; filename=foo"bar;baz"qux +- attachment; filename=foo.html, attachment; filename=bar.html +- attachment; foo=foo filename=bar +- attachment; filename=bar foo=foo + +**Serves as inline when it should download** +- attachment; filename="foo-ä.html" +- attachment; filename="foo-ä.html" +- attachment; filename="ä-%41.html" + + +--%-- +From: rodarima +Date: Fri, 28 Mar 2025 18:59:20 +0000 + +> Spaces in quoted string should work correctly now. + +Thanks! + +> Allow ~ because it has no special meaning after 1 and 2 are done + +I'll would also replace it either entirely or from the start, as `~user` could still be expanded to the home directory of `user`. + +> I've finished checking all the tests from http://test.greenbytes.de/tech/tc2231/#attabspath and the failures are listed below. Most of the failures are consistent with Firefox's behavior so I'm not sure if we should fix them to match the tests or just leave them as is. Please let me know how you'd like me to handle those. + +I'm okay with being more or less consistent with Firefox, long as there are no cases that cause a crash or an expected attachment document is shown as inline. + +Also, I believe we should leave the (uchar_t) cast as it was, as it can cause values above 127 to be considered negative and extend the sign into a int, causing a value that is out of range for unsigned char. Some of those unusual symbols may be wrongly expanded and fail to pass some of the isascii()-family tests. + +I'll leave you here a patch to add a unit test to check multiple content dispositions (you can add get the commit with `git am < disp.patch`). I added some example cases myself, but we can add the ones from that page which would speed up testing. Check with `make check TESTS=disposition VERBOSE=1`: + +```diff +From 00d2ce3d8935095a4064b84c24225cd20a113aad Mon Sep 17 00:00:00 2001 +From: Rodrigo Arias Mallo <rodarima@gmail.com> +Date: Fri, 28 Mar 2025 19:32:28 +0100 +Subject: [PATCH] Add content disposition unit test + +--- + test/unit/Makefile.am | 6 +++ + test/unit/disposition.c | 88 +++++++++++++++++++++++++++++++++++++++++ + 2 files changed, 94 insertions(+) + create mode 100644 test/unit/disposition.c + +diff --git a/test/unit/Makefile.am b/test/unit/Makefile.am +index bcf3e3cb..b372a1ae 100644 +--- a/test/unit/Makefile.am ++++ b/test/unit/Makefile.am +@@ -11,6 +11,7 @@ LDADD = \ + + TESTS = \ + containers \ ++ disposition \ + identity \ + liang \ + notsosimplevector \ +@@ -30,6 +31,11 @@ containers_SOURCES = containers.cc + containers_LDADD = \ + $(top_builddir)/lout/liblout.a \ + $(top_builddir)/dlib/libDlib.a ++disposition_SOURCES = \ ++ $(top_srcdir)/src/misc.c \ ++ disposition.c ++disposition_LDADD = \ ++ $(top_builddir)/dlib/libDlib.a + notsosimplevector_SOURCES = notsosimplevector.cc + identity_SOURCES = identity.cc + identity_LDADD = \ +diff --git a/test/unit/disposition.c b/test/unit/disposition.c +new file mode 100644 +index 00000000..a2f5fc46 +--- /dev/null ++++ b/test/unit/disposition.c +@@ -0,0 +1,88 @@ ++/* ++ * File: disposition.c ++ * ++ * Copyright 2025 Rodrigo Arias Mallo <rodarima@gmail.com> ++ * ++ * This program is free software; you can redistribute it and/or modify ++ * it under the terms of the GNU General Public License as published by ++ * the Free Software Foundation; either version 3 of the License, or ++ * (at your option) any later version. ++ * ++ * This program is distributed in the hope that it will be useful, ++ * but WITHOUT ANY WARRANTY; without even the implied warranty of ++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ++ * GNU General Public License for more details. ++ * ++ * You should have received a copy of the GNU General Public License ++ * along with this program. If not, see <http://www.gnu.org/licenses/>. ++ */ ++ ++#include "dlib/dlib.h" ++#include "src/misc.h" ++ ++#include <stdlib.h> ++ ++struct testcase { ++ const char *disposition; ++ const char *type; ++ const char *filename; ++}; ++ ++struct testcase cases[] = { ++ /* See http://test.greenbytes.de/tech/tc2231/ */ ++ { "attachment; filename=\"\\\"quoting\\\" tested.html\"", "attachment", "_\"quoting_\" tested.html" }, ++ //{ "attachment; filename=\"\\\"quoting\\\" tested.html\"", "attachment", "quoting" }, /* <-- Should be this */ ++ { "attachment; filename=\"/foo.html\"", "attachment", "_foo.html" }, ++ { "attachment; filename=/foo", "attachment", "_foo" }, ++ { "attachment; filename=./../foo", "attachment", "_.._foo" }, ++ { "attachment; filename=", "attachment", NULL }, ++ { "attachment; filename= ", "attachment", NULL }, ++ { "attachment; filename=\"", "attachment", NULL }, ++ { "attachment; filename=\"foo", "attachment", NULL }, ++ { "attachment; filename=~/foo", "attachment", "~_foo" }, ++}; ++ ++static int equal(const char *a, const char *b) ++{ ++ if (a == NULL && b == NULL) ++ return 1; ++ ++ if (a == NULL || b == NULL) ++ return 0; ++ ++ return strcmp(a, b) == 0; ++} ++ ++int main(void) ++{ ++ char dummy[] = "dummy"; ++ int ncases = sizeof(cases) / sizeof(cases[0]); ++ int rc = 0; ++ ++ for (int i = 0; i < ncases; i++) { ++ struct testcase *t = &cases[i]; ++ char *type = dummy; ++ char *filename = dummy; ++ a_Misc_parse_content_disposition(t->disposition, &type, &filename); ++ if (!equal(type, t->type)) { ++ fprintf(stderr, "test %d failed, type mismatch:\n", i); ++ fprintf(stderr, " Content-Dispsition: %s\n", t->disposition); ++ fprintf(stderr, " Expected type: %s\n", t->type); ++ fprintf(stderr, " Computed type: %s\n", type); ++ rc = 1; ++ } ++ ++ if (!equal(filename, t->filename)) { ++ fprintf(stderr, "test %d failed, filename mismatch:\n", i); ++ fprintf(stderr, " Content-Dispsition: %s\n", t->disposition); ++ fprintf(stderr, " Expected filename: %s\n", t->filename); ++ fprintf(stderr, " Computed filename: %s\n", filename); ++ rc = 1; ++ } ++ ++ dFree(type); ++ dFree(filename); ++ } ++ ++ return rc; ++} +-- +2.48.1 + +``` + + +--%-- +From: campaul +Date: Fri, 28 Mar 2025 20:15:27 +0000 + +Thanks for that patch, that's a really good starting point for me to write more tests. Unfortunately I'm getting a linker error when I try to run the test. It looks like the same error is showing up in CI at https://github.com/dillo-browser/dillo/actions/runs/14137052775/job/39611193831?pr=373, any idea what might be wrong? + +--%-- +From: rodarima +Date: Fri, 28 Mar 2025 20:50:51 +0000 + +> Thanks for that patch, that's a really good starting point for me to write more tests. Unfortunately I'm getting a linker error when I try to run the test. It looks like the same error is showing up in CI at https://github.com/dillo-browser/dillo/actions/runs/14137052775/job/39611193831?pr=373, any idea what might be wrong? + +Hmm, it was working for me with gcc 14.2.1, and it seems to work on macos too. We are building that test without including all the dependencies for all functions in misc.o, but for that particular content disposition function, we include all that is neccessary. I suspect on older gccs it complains if it cannot find all symbol definitions. + +One quick workaround is to move the function as an static inline in the misc.h header and drop the misc.o requirement from the Makefile.am. I can take a look later to try to fix it properly. We need to split a lot of objects from the dillo binary into a single static library to be able to link it with unit tests. I already had a WIP patch, maybe this is a good time to finish it. + +*Edit*: Is the `-flto=auto` flag that makes it work. We shouldn't rely on that. + +--%-- +From: campaul +Date: Sat, 29 Mar 2025 00:23:59 +0000 + +I set `-flto=auto` for the moment so the tests can run. I also decided to replace all `~` with `_` to be on the safe side. + +I have added all the relevant tests from the list to the unit test file and updated the parser until they all passed. + +The only remaining issue I have on my list is treating unknown content dispositions the same as `attachment`. + +Edit: also put back the `uchar_t` casts. + +--%-- +From: rodarima +Date: Fri, 04 Apr 2025 23:19:01 +0000 + +> I set `-flto=auto` for the moment so the tests can run. I also decided to replace all `~` with `_` to be on the safe side. +> +> I have added all the relevant tests from the list to the unit test file and updated the parser until they all passed. +> +> The only remaining issue I have on my list is treating unknown content dispositions the same as `attachment`. +> +> Edit: also put back the `uchar_t` casts. + +Thanks a lot for the effort, it is looking nice. I think we can leave as-is for now, I will do a more through review on the parser when I have a moment. + +I've been trying to split the code into an static libraries so we can link the unit test cases against to, but it would require much more effort than what I had imagined. There is a lot of coupling among modules, so it will be a pain. I will need to split them slowly. + +For this particular case, I would be inclined to move the function into the header and make it a static inline, AFAIK it only depends on dlib. I will try to do this myself to fix the pipeline and prepare this for merging. + +--%-- +From: rodarima +Date: Wed, 30 Apr 2025 22:53:31 +0000 + +Sorry for the long delay, it took me a while to review the algorithms in detail. + +I have flattened the control flow so it doesn't nest conditionals. I have also tried to simplify the two last loops in less clever algorithms. It is a bit slower, but I believe it is less error prone an easier to read. I have also rebased it with the latest commit. + +There were also a couple of potential memory leaks which are fixed now. All tests are passing, and also added a few more cases. + +Let me know what you think. + +--%-- +From: campaul +Date: Thu, 01 May 2025 14:46:28 +0000 + +That all looks great to me. I think this is ready to merge if you don't have any further issues.
\ No newline at end of file diff --git a/374/index.md b/374/index.md new file mode 100644 index 0000000..bf5c95e --- /dev/null +++ b/374/index.md @@ -0,0 +1,14 @@ +Title: Add builtin actions to follow rel=next and rel=previous links +Author: rodarima +Created: Sun, 23 Mar 2025 21:01:12 +0000 +State: open + +When reading a paged document it makes sense to be able to jump to the next page by directly pressing a shortcut. The idea is to read a document, press (say) j, j, j, then you reach the bottom, then you press (for example) n, then the next page link is followed without the need to leave the keyboard (this work with one hand and hjkl is next to n). + +There are some cases in the wild: + +- `<link rel=next href="...">` +- `<a rel=next href="...">` + +See: https://html.spec.whatwg.org/multipage/links.html#linkTypes +See: https://html.spec.whatwg.org/multipage/links.html#link-type-next
\ No newline at end of file diff --git a/375/index.md b/375/index.md new file mode 100644 index 0000000..cc9d705 --- /dev/null +++ b/375/index.md @@ -0,0 +1,6 @@ +Title: Improve unit test capabilities to use code from src/ +Author: rodarima +Created: Tue, 01 Apr 2025 17:58:20 +0000 +State: open + +Currently, unit tests are designed to test only the renderer (dw), but we could test src code as well if we split that part into an static library that is linked into the dillo binary as well as any unit test that needs it. It would help testing cases like #373. This could also be used for fuzzing tests.
\ No newline at end of file diff --git a/376/index.md b/376/index.md new file mode 100644 index 0000000..0950c4a --- /dev/null +++ b/376/index.md @@ -0,0 +1,5 @@ +Title: Ignore build directories and other generated files +Author: rodarima +Created: Fri, 04 Apr 2025 22:54:48 +0000 +State: closed + diff --git a/377/index.md b/377/index.md new file mode 100644 index 0000000..c6c67c8 --- /dev/null +++ b/377/index.md @@ -0,0 +1,8 @@ +Title: Handle brotli encoding +Author: rodarima +Created: Sat, 05 Apr 2025 19:49:47 +0000 +State: closed + +Some pages don't respect the Accept-Encoding header and just return brotli encoding (br) regardless of what the client is asking for. One of such examples is https://www.justwatch.com/ (not that we will be able to load it properly anyway, but is an easy reproducer). + +In the short term, we may want to issue a download instead of showing the raw bytes on the screen. On the other hand, we may be able to implement brotli decoding and get rid of this annoyance.
\ No newline at end of file diff --git a/378/index.md b/378/index.md new file mode 100644 index 0000000..3f2573e --- /dev/null +++ b/378/index.md @@ -0,0 +1,6 @@ +Title: Update package lists in CI +Author: rodarima +Created: Sat, 05 Apr 2025 20:12:20 +0000 +State: closed + +See: https://github.com/dillo-browser/dillo/actions/runs/14285249224/job/40039689315#step:3:136
\ No newline at end of file diff --git a/379/index.md b/379/index.md new file mode 100644 index 0000000..28bd60d --- /dev/null +++ b/379/index.md @@ -0,0 +1,8 @@ +Title: Add brotli support +Author: rodarima +Created: Sat, 05 Apr 2025 22:19:59 +0000 +State: closed + +Implements support for brotli (br) content encoding. + +Fixes: https://github.com/dillo-browser/dillo/issues/377
\ No newline at end of file diff --git a/38/index.md b/38/index.md new file mode 100644 index 0000000..a93d350 --- /dev/null +++ b/38/index.md @@ -0,0 +1,32 @@ +Title: Bad layouting of justified text with float image +Author: rodarima +Created: Mon, 25 Dec 2023 22:44:07 +0000 +State: open + +Reproducer: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test floating image in paragraph with br</title> + <style> + body {width: 400px} + img {width: 40%; float:right} + p {text-align: justify;} + </style> + </head> + <body> + <i>The text below should be readable:</i> + <p> + <img src="https://upload.wikimedia.org/wikipedia/commons/8/8e/Dillo-icon.png" /> + This is a rather long text to increase the width. + <br> + </p> + </body> +</html> +``` + +Renders: + +
\ No newline at end of file diff --git a/380/index.md b/380/index.md new file mode 100644 index 0000000..7966cea --- /dev/null +++ b/380/index.md @@ -0,0 +1,130 @@ +Title: Performance improvements +Author: rodarima +Created: Sun, 13 Apr 2025 16:52:07 +0000 +State: open + +Rendering https://html.spec.whatwg.org/ several times (via refresh) leads to the following perf trace on armv7: + +``` +# To display the perf.data header info, please use --header/--header-only options. +# +# +# Total Lost Samples: 0 +# +# Samples: 169K of event 'cycles:Pu' +# Event count (approx.): 33718562150 +# +# Overhead Command Shared Object Symbol +# ........ ....... ....................... ................................................................................................................................................ +# + 7.03% dillo dillo [.] lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const + 6.34% dillo ld-musl-armhf.so.1 [.] __strchrnul + 2.69% dillo dillo [.] Html_write_raw(DilloHtml*, char*, int, int) + 2.22% dillo ld-musl-armhf.so.1 [.] __libc_malloc_impl + 1.91% dillo ld-musl-armhf.so.1 [.] strncmp + 1.86% dillo dillo [.] lout::misc::NotSoSimpleVector<dw::Textblock::Word>::size() const + 1.78% dillo dillo [.] dw::Textblock::accumulateWordData(int) + 1.64% dillo libz.so.1.3.1 [.] crc32_z + 1.51% dillo ld-musl-armhf.so.1 [.] get_meta + 1.45% dillo dillo [.] CssStyleSheet::apply(CssPropertyList*, Doctree*, DoctreeNode const*, MatchCache*) const + 1.37% dillo dillo [.] int lout::misc::max<int>(int, int) + 1.29% dillo dillo [.] dw::Textblock::BadnessAndPenalty::penaltyValue(int, int) + 1.29% dillo ld-musl-armhf.so.1 [.] strcspn + 1.22% dillo ld-musl-armhf.so.1 [.] __libc_free + 1.20% dillo dillo [.] dw::Textblock::BadnessAndPenalty::badnessValue(int) + 1.17% dillo dillo [.] lout::identity::IdentifiableObject::instanceOf(int) + 1.16% dillo dillo [.] dw::Textblock::addText(char const*, unsigned int, dw::core::style::Style*) + 1.16% dillo dillo [.] dw::Textblock::wrapWordInFlow(int, bool) + 1.09% dillo dillo [.] a_Html_get_attr(DilloHtml*, char const*, int, char const*) + 1.03% dillo dillo [.] dw::Textblock::getWidgetRegardingBorderForLine(int, int) + 1.00% dillo dillo [.] CssSelector::match(Doctree*, DoctreeNode const*, int, CssSelector::Combinator, MatchCache*) + 0.92% dillo ld-musl-armhf.so.1 [.] cached_aligned32 + 0.89% dillo dillo [.] dw::Textblock::getLineStretchability(int) + 0.86% dillo ld-musl-armhf.so.1 [.] strlen + 0.85% dillo dillo [.] dw::core::Widget::getStyle() + 0.85% dillo dillo [.] dw::Textblock::calcBorders(int, int) + 0.83% dillo dillo [.] dw::Textblock::handleWordExtremes(int) + 0.80% dillo ld-musl-armhf.so.1 [.] alloc_slot + 0.79% dillo dillo [.] dw::Textblock::BadnessAndPenalty::compareTo(int, dw::Textblock::BadnessAndPenalty*) + 0.78% dillo dillo [.] lout::misc::SimpleVector<dw::Textblock::Line>::size() const + 0.77% dillo dillo [.] lout::container::untyped::Vector::get(int) const + 0.77% dillo dillo [.] lout::object::ConstString::hashValue(char const*) + 0.66% dillo libgcc_s.so.1 [.] __aeabi_idiv + 0.66% dillo dillo [.] CssSimpleSelector::match(DoctreeNode const*) + 0.64% dillo dillo [.] lout::container::untyped::HashSet::findNode(lout::object::Object*) const + 0.63% dillo dillo [.] lout::misc::SimpleVector<dw::Textblock::Line>::getRef(int) const +``` + +There is a bottleneck in getRef of the NotSoSimpleVector. We could probably optimize the hot path as it is doing several checks that are not really needed. Including two asserts. + +``` + │ 0005f7fc <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const>: ▒ + │ /** ▒ + │ * \brief Return the reference of one element. ▒ + │ * ▒ + │ * \sa misc::SimpleVector::get ▒ + │ */ ▒ + │ inline T* getRef (int i) const ▒ + 2.72 │ push {r7, lr} ▒ + 1.83 │ sub sp, #8 ▒ + 2.42 │ add r7, sp, #0 ▒ + 5.87 │ str r0, [r7, #4] ▒ + 1.99 │ str r1, [r7, #0] ▒ + │ { ▒ + │ if (this->startExtra == -1) { ▒ + 2.01 │ ldr r3, [r7, #4] ▒ + 5.73 │ ldr r3, [r3, #28] ▒ + 3.61 │ cmp.w r3, #4294967295 ▒ + │ bne.n 5f84e <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x52> ▒ + │ assert (i >= 0 && i < this->numMain); ▒ + 5.79 │ ldr r3, [r7, #0] ▒ + 3.48 │ cmp r3, #0 ▒ + 0.34 │ blt.n 5f820 <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x24> ▒ + 5.49 │ ldr r3, [r7, #4] ▒ + 5.47 │ ldr r3, [r3, #12] ▒ + 1.67 │ ldr r2, [r7, #0] ▒ + 3.40 │ cmp r2, r3 ▒ + │ blt.n 5f834 <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x38> ▒ + │ ldr r3, [pc, #228] @ (5f908 <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x10c>) ▒ + │ add r3, pc ▒ + │ movw r2, #479 @ 0x1df ▒ + │ ldr r1, [pc, #224] @ (5f90c <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x110>) ▒ + │ add r1, pc ▒ + │ ldr r0, [pc, #224] @ (5f910 <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x114>) ▒ + │ add r0, pc ▒ + │ → blx strrchr@plt ▒ + │ return this->arrayMain + i; ▒ + 5.98 │ ldr r3, [r7, #4] ▒ + 5.65 │ ldr r1, [r3, #0] ▒ + 1.80 │ ldr r2, [r7, #0] ▒ + 3.96 │ mov r3, r2 ▒ + 4.10 │ lsls r3, r3, #1 ▒ + 1.86 │ add r3, r2 ▒ + 3.54 │ lsls r2, r3, #3 ▒ + 1.68 │ subs r2, r2, r3 ▒ + 3.85 │ lsls r3, r2, #2 ▒ + 2.06 │ mov r2, r3 ▒ + 1.84 │ mov r3, r2 ▒ + 2.02 │ add r3, r1 ▒ + │ b.n 5f8fe <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x102> ▒ + │ } else { ▒ + │ if (i < this->startExtra) { ▒ + │ ldr r3, [r7, #4] ▒ + │ ldr r3, [r3, #28] ▒ + │ ldr r2, [r7, #0] ▒ + │ cmp r2, r3 ▒ + │ bge.n 5f88c <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x90> ▒ + │ assert (i >= 0); ▒ + │ ldr r3, [r7, #0] ▒ + │ cmp r3, #0 ▒ + │ bge.n 5f872 <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x76> ▒ + │ ldr r3, [pc, #180] @ (5f914 <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x118>) ▒ + │ add r3, pc ▒ + │ movw r2, #483 @ 0x1e3 ▒ + │ ldr r1, [pc, #176] @ (5f918 <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x11c>) ▒ + │ add r1, pc ▒ + │ ldr r0, [pc, #176] @ (5f91c <lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const+0x120>) ▒ + │ add r0, pc ▒ + │ → blx strrchr@plt +... +```
\ No newline at end of file diff --git a/381/index.md b/381/index.md new file mode 100644 index 0000000..7e3dcdd --- /dev/null +++ b/381/index.md @@ -0,0 +1,20 @@ +Title: Build without asserts by default +Author: rodarima +Created: Sun, 13 Apr 2025 17:00:55 +0000 +State: open + +Asserts are not intended to be used in performance builds. We should first make sure that we can disable them safely and then add `-DNDEBUG` to the flags by default. We probably should add a `--enable-debug` which also controls thhe optimization levels, debug information (-g) and leaving the frame pointer. + +--%-- +From: rodarima +Date: Sun, 13 Apr 2025 17:03:58 +0000 + +My eyes... + +https://github.com/dillo-browser/dillo/blob/b804f4a6a3950fb13342e687acfa51b5c2157625/lout/container.cc#L139-L147 + +--%-- +From: rodarima +Date: Sun, 13 Apr 2025 18:48:33 +0000 + +Introduced here: https://github.com/dillo-browser/dillo/commit/0856f155988da7dfc10eee25157525466ab32f20
\ No newline at end of file diff --git a/382/index.md b/382/index.md new file mode 100644 index 0000000..56f9e45 --- /dev/null +++ b/382/index.md @@ -0,0 +1,49 @@ +Title: Performance regression tests +Author: rodarima +Created: Sun, 13 Apr 2025 19:20:10 +0000 +State: open + +As we do changes in Dillo, we risk introducing performance regressions that won't be detected unless we actually use Dillo on an old computer. + +We could emulate an specific old CPU, but this would be much slower than just using the real hardware. What we probably want to keep in mind is that we need a crappy cache and low RAM. + +I've been doing some experiments with a Raspberry Pi 2 B which has a BCM2836 chip with a ARM v7 CPU with float point unit and 1 GiB of RAM. So far it seems to be *very* good at being slow. I'm not able to find the CPU cache, nor it is available in lscpu, but it can be measured experimentally. + +Ideally, we should be able to run the CI pipeline on the RPi directly, so we can detect regressions before merging. For now lets keep it simple, and I will just run the performance tests manually. + +I could also use it to measure energy consumption in real time, so we can measure the CPU *and* the rest of the components while we benchmark the browser. The benefit of a RPi is that the power usage is minimal (1-4 W) so we won't waste resources. + +To that end, we need some reference pages that exercise several parts of the browser pipeline and a signal that can stop the browser when the page has fully loaded. We need to be able to systematically render a page in about the same time. Having a specific device that doesn't do anything else can reduce the system noise so we can keep the measurements stable after several runs. + + + +--%-- +From: sevan +Date: Sun, 13 Apr 2025 22:56:00 +0000 + +The low end slow things aren't really offered as a hosted service so if it can be a procedure which folks can run & provide feedback that might give a better indication. Since dillo runs on OS X Tiger, I can test on G3 based machines. + +Regarding the Pi, the 1st generation will provide an armv6 with 256 or 512MB RAM if I recall correctly. Let me know if you'd like a donation :) + +--%-- +From: rodarima +Date: Mon, 14 Apr 2025 17:45:39 +0000 + +> Since dillo runs on OS X Tiger, I can test on G3 based machines. + +It would be handy if you report any issues you find while doing regular browsing, as I don't have any MacOS computers around to test (only the CI pipeline on GitHub). I would focus on one device for performance measurements for now, so we can start with a simple goal. + +> Regarding the Pi, the 1st generation will provide an armv6 with 256 or 512MB RAM if I recall correctly. Let me know if you'd like a donation :) + +Thanks for the offer, for now I think the RPi 2 B is in the sweet spot of being slow enough to be sensitive to performance issues and not too slow so we can run the tests reasonably fast. It also helps that I already had one around which I'm not using otherwise :) + +--%-- +From: sevan +Date: Mon, 14 Apr 2025 20:05:31 +0000 + +> > Since dillo runs on OS X Tiger, I can test on G3 based machines. +> +> It would be handy if you report any issues you find while doing regular browsing, as I don't have any MacOS computers around to test (only the CI pipeline on GitHub). I would focus on one device for performance measurements for now, so we can start with a simple goal. + +Sure, no worries, I'll help on the OS X / PowerPC testing side. +If you want to run the Intel build of Tiger and have virtualbox you can follow https://github.com/ranma42/TigerOnVBox/ though you should be able to run it on Qemu as well emulating powerpc or x86. diff --git a/383/index.md b/383/index.md new file mode 100644 index 0000000..7b3c77b --- /dev/null +++ b/383/index.md @@ -0,0 +1,10 @@ +Title: Add a control socket +Author: rodarima +Created: Mon, 21 Apr 2025 11:02:28 +0000 +State: open + +In order to implement #47, we need first a way to talk to the correct browser process. Ideally we should be able to make dpid track all instances of the browser, so we can interact with multiple processes. But this would require implementing the logic in dillo to accept commands from the dpid interface. + +A simpler mechanism (at least in the short term) is to add a UNIX socket per each dillo process, so we can talk directly to that process (say `~/.dillo/control.$PID`). We can hide the implementation details under a CLI tool where we keep the interface stable, allowing us to make changes in the underlying plumbing. + +A single UNIX socket per browser process makes things much easier, as we only need to add a watcher in FLTK and process requests as they come. We can also write events such as "the page finished loaded" which are initiated by the browser itself.
\ No newline at end of file diff --git a/384/index.md b/384/index.md new file mode 100644 index 0000000..4f1ecb6 --- /dev/null +++ b/384/index.md @@ -0,0 +1,8 @@ +Title: Remove Ubuntu 20.04 from the CI pipeline +Author: rodarima +Created: Mon, 21 Apr 2025 19:44:44 +0000 +State: closed + +It is deprecated and got removed. + +See: https://github.com/actions/runner-images/issues/11101
\ No newline at end of file diff --git a/385/index.md b/385/index.md new file mode 100644 index 0000000..c7a8f2b --- /dev/null +++ b/385/index.md @@ -0,0 +1,6 @@ +Title: Add about:keys to show keyboard shortcuts +Author: rodarima +Created: Sat, 26 Apr 2025 21:44:01 +0000 +State: closed + +Fixes: https://github.com/dillo-browser/dillo/issues/66
\ No newline at end of file diff --git a/386/index.md b/386/index.md new file mode 100644 index 0000000..8edc9eb --- /dev/null +++ b/386/index.md @@ -0,0 +1,6 @@ +Title: Control + left click opens link in new tab +Author: rodarima +Created: Mon, 28 Apr 2025 21:07:25 +0000 +State: closed + +Small laptops and netbooks that lack a proper 3 button touchpad make it difficult to open a new tab. Using the control modifier makes is easier to open links in new tabs. It also allows mixing it with the shift modifier to control the focus.
\ No newline at end of file diff --git a/387/index.md b/387/index.md new file mode 100644 index 0000000..3f6abda --- /dev/null +++ b/387/index.md @@ -0,0 +1,7 @@ +Title: Middle-click on back or forward opens in new tab +Author: rodarima +Created: Wed, 30 Apr 2025 18:35:33 +0000 +State: closed + +Reviewed-by: Rodrigo Arias Mallo <rodarima@gmail.com> +See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/XXD2NXCGQLZLJ3V57NCPU3327DAEFKAN/
\ No newline at end of file diff --git a/388/index.md b/388/index.md new file mode 100644 index 0000000..5b54bc5 --- /dev/null +++ b/388/index.md @@ -0,0 +1,235 @@ +Title: Issues with Cocoa API on OS X 10.5 & up +Author: sevan +Created: Thu, 01 May 2025 20:59:47 +0000 +State: open + +Take the title with a pinch of salt as I'v only checked on OS X 10.4, 10.5, 10.11 which are all ancient. +On 10.4, there's no issue. +On 10.5, dillo launches fine and the gui is functional. However in the terminal it was launched in, it is reporting errors regarding the Cocoa API. +``` +<Error>: CGContextSetTextPosition: invalid context +<Error>: CGContextSetShouldAntialias: invalid context +<Error>: CGContextSetShouldAntialias: invalid context +``` +flood the terminal, an then after a short while, dillo crashes. + + +``` +Process: dillo [48397] +Path: /Users/sme/tigerbrew/bin/dillo +Identifier: dillo +Version: ??? (???) +Code Type: X86 (Native) +Parent Process: bash [135] + +Interval Since Last Report: 566426 sec +Crashes Since Last Report: 83 +Per-App Interval Since Last Report: 0 sec +Per-App Crashes Since Last Report: 1 + +Date/Time: 2025-05-01 20:57:20.168 +0100 +OS Version: Mac OS X 10.5.8 (9L31a) +Report Version: 6 +Anonymous UUID: 3E54E8B4-5A3C-46D1-BBCB-860782663158 + +Exception Type: EXC_BAD_ACCESS (SIGSEGV) +Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000b00028 +Crashed Thread: 0 + +Thread 0 Crashed: +0 com.apple.CoreGraphics 0x94f3e770 CGSConvertBGR888toRGBA8888 + 160 +1 com.apple.CoreGraphics 0x94e9758b argb32_image + 5611 +2 libRIP.A.dylib 0x939a4725 ripd_Mark + 326 +3 libRIP.A.dylib 0x9399e9a3 ripl_BltImage + 1307 +4 libRIP.A.dylib 0x93988a18 ripc_RenderImage + 273 +5 libRIP.A.dylib 0x93998e96 ripc_DrawImage + 5102 +6 com.apple.CoreGraphics 0x94e89f4d CGContextDrawImage + 397 +7 libfltk.1.3.dylib 0x0026be30 fl_scroll(int, int, int, int, int, int, void (*)(void*, int, int, int, int), void*) + 420 +8 dillo 0x00077cc8 dw::fltk::FltkViewport::draw() + 432 +9 libfltk.1.3.dylib 0x00218264 Fl_Group::update_child(Fl_Widget&) const + 98 +10 libfltk.1.3.dylib 0x00218397 Fl_Group::draw_children() + 295 +11 libfltk.1.3.dylib 0x00218264 Fl_Group::update_child(Fl_Widget&) const + 98 +12 libfltk.1.3.dylib 0x0025809d Fl_Wizard::draw() + 169 +13 libfltk.1.3.dylib 0x00218264 Fl_Group::update_child(Fl_Widget&) const + 98 +14 libfltk.1.3.dylib 0x00218397 Fl_Group::draw_children() + 295 +15 libfltk.1.3.dylib 0x00257c94 Fl_Window::draw() + 340 +16 libfltk.1.3.dylib 0x001f96c1 -[FLView drawRect:] + 193 +17 com.apple.AppKit 0x92f1abf8 -[NSView _drawRect:clip:] + 3853 +18 com.apple.AppKit 0x92f196ef -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1050 +19 com.apple.AppKit 0x92f18045 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 759 +20 com.apple.AppKit 0x92f144ab -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3090 +21 com.apple.AppKit 0x9303243c -[NSView displayIfNeededIgnoringOpacity] + 443 +22 libfltk.1.3.dylib 0x001f08e6 Fl_X::flush() + 138 +23 libfltk.1.3.dylib 0x00200e89 Fl::flush() + 91 +24 libfltk.1.3.dylib 0x001f7efa fl_mac_flush_and_wait(double) + 428 +25 libfltk.1.3.dylib 0x00200f9d Fl::wait() + 45 +26 dillo 0x000085af main + 2799 +27 dillo 0x00007902 start + 54 + +Thread 1: +0 libSystem.B.dylib 0x9590660a select$DARWIN_EXTSN + 10 +1 libSystem.B.dylib 0x958e8055 _pthread_start + 321 +2 libSystem.B.dylib 0x958e7f12 thread_start + 34 + +Thread 0 crashed with X86 Thread State (32-bit): + eax: 0x000000bf ebx: 0x94e95fbd ecx: 0xffffffff edx: 0x000000be + edi: 0x00b00020 esi: 0x000002fd ebp: 0xbfffdec8 esp: 0xbfffdea8 + ss: 0x0000001f efl: 0x00210202 eip: 0x94f3e770 cs: 0x00000017 + ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 + cr2: 0x00b00028 + +Binary Images: + 0x1000 - 0xa4ff7 +dillo ??? (???) <808f5c7afd57dfb6181cf3d3bc4663e2> /Users/sme/tigerbrew/bin/dillo + 0x102000 - 0x13dff0 +libjpeg.9.dylib ??? (???) <190d123ae13f22b5215a6f34775c48d9> /Users/sme/tigerbrew/lib/libjpeg.9.dylib + 0x145000 - 0x178ffb +libpng16.16.dylib ??? (???) <e711af7180f636a592be4959d5eb4f4f> /Users/sme/tigerbrew/opt/libpng/lib/libpng16.16.dylib + 0x181000 - 0x1deff7 +libwebp.7.dylib ??? (???) <2b1f4e30eea99108791a00a4845b42f4> /Users/sme/tigerbrew/lib/libwebp.7.dylib + 0x1eb000 - 0x282fec +libfltk.1.3.dylib ??? (???) <70af56a3b8eb20a2514c4419991c8496> /Users/sme/tigerbrew/lib/libfltk.1.3.dylib + 0x2ce000 - 0x2e0ffc +libz.1.dylib ??? (???) <b40bc690caf26c5ada0372856fb105aa> /Users/sme/tigerbrew/opt/zlib/lib/libz.1.dylib + 0x2e5000 - 0x3fbff3 +libiconv.2.dylib ??? (???) <8c9225a2ac30dc430cf099ff22439e65> /Users/sme/tigerbrew/opt/libiconv/lib/libiconv.2.dylib + 0x40c000 - 0x6f2bb7 +libcrypto.3.dylib ??? (???) <f7ca3fa9af8c1dfdeb57db2066655481> /Users/sme/tigerbrew/opt/openssl3/lib/libcrypto.3.dylib + 0x815000 - 0x8c3ff5 +libssl.3.dylib ??? (???) <2e72043f262140c7bd78713b54c95a59> /Users/sme/tigerbrew/opt/openssl3/lib/libssl.3.dylib + 0x8f9000 - 0x8fefff +libsharpyuv.0.dylib ??? (???) <d544660507e96239779e9e66ac5d533f> /Users/sme/tigerbrew/Cellar/webp/1.5.0/lib/libsharpyuv.0.dylib +0x14b6d000 - 0x14d75fef com.apple.RawCamera.bundle 2.1.3 (537) <ef9996f5ec0caf58dc832a4153196a1e> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera +0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <458eed38a009e5658a79579e7bc26603> /usr/lib/dyld +0x9025f000 - 0x90266ffe libbsm.dylib ??? (???) <d25c63378a5029648ffd4b4669be31bf> /usr/lib/libbsm.dylib +0x90470000 - 0x9049dfeb libvDSP.dylib ??? (???) <f39d424bd56a0e75d5c7a2280a25cd76> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib +0x9049e000 - 0x9049eff8 com.apple.ApplicationServices 34 (34) <8f910fa65f01d401ad8d04cc933cf887> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices +0x9049f000 - 0x904c8fff libcups.2.dylib ??? (???) <2b0ab6b9fa1957ee940835d0cfd42894> /usr/lib/libcups.2.dylib +0x904c9000 - 0x90546fef libvMisc.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib +0x915fa000 - 0x91602fff com.apple.DiskArbitration 2.2.1 (2.2.1) <ba64dd6ada417b5e7be736957f380bca> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration +0x91603000 - 0x917d4fef com.apple.security 5.0.7 (1) <44e26a9c40630a54d5a9f70c18483411> /System/Library/Frameworks/Security.framework/Versions/A/Security +0x917d5000 - 0x918b6ff7 libxml2.2.dylib ??? (???) <f274ba384fb55203873f9c17569ef131> /usr/lib/libxml2.2.dylib +0x919a6000 - 0x91a61fe3 com.apple.CoreServices.OSServices 228.1 (228.1) <9c640e79ad97f335730d8a49f6cb2032> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices +0x91a76000 - 0x91f47fbe libGLProgrammability.dylib ??? (???) <d5cb4e7997a873cd77523689e6749acd> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib +0x91f7b000 - 0x91fb9fff libGLImage.dylib ??? (???) <2e570958595e0c9c3a289158223b39ee> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib +0x920de000 - 0x9247bfef com.apple.QuartzCore 1.5.8 (1.5.8) <18113e06d296230d63a63b58baf35f55> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore +0x9252c000 - 0x928eafea libLAPACK.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib +0x92930000 - 0x92934fff libGIF.dylib ??? (???) <ade6d93abe118569a7a39d11f81eb9bf> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib +0x92935000 - 0x92953fff libresolv.9.dylib ??? (???) <0e26b308654f33fc94a0c010a50751f9> /usr/lib/libresolv.9.dylib +0x92954000 - 0x92a8dff7 libicucore.A.dylib ??? (???) <f2819243b278259b9a622ea111ea5fd6> /usr/lib/libicucore.A.dylib +0x92a8e000 - 0x92ad7fef com.apple.Metadata 10.5.8 (398.26) <e4d268ea45379200f03cdc7c8bedae6f> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata +0x92b51000 - 0x92bdeff7 com.apple.LaunchServices 292 (292) <a41286c7c1eb20ffd5cc796f791070f0> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices +0x92bdf000 - 0x92c0afe7 libauto.dylib ??? (???) <4f3e58cb81da07a1662c1f647ce30225> /usr/lib/libauto.dylib +0x92c99000 - 0x92d60ff2 com.apple.vImage 3.0 (3.0) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage +0x92d61000 - 0x92debff7 com.apple.DesktopServices 1.4.9 (1.4.9) <f5e51a76d315798371b3dd35a4d46d6c> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv +0x92e12000 - 0x93610fef com.apple.AppKit 6.5.9 (949.54) <4df5d2e2271175452103f789b4f4d8a8> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x93611000 - 0x9361dffe libGL.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib +0x93984000 - 0x939c5fe7 libRIP.A.dylib ??? (???) <cd04df9e8993c51312c8cbcfe2539914> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib +0x939c6000 - 0x939c6ffd com.apple.Accelerate 1.4.2 (Accelerate 1.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate +0x939c7000 - 0x93a21ff7 com.apple.CoreText 2.0.5 (???) <5483518a613464d043455ac661a9dcbe> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText +0x93a22000 - 0x93a73ff7 com.apple.HIServices 1.7.1 (???) <ba7fd0ede540a0da08db027f87efbd60> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices +0x93a74000 - 0x93a84ffc com.apple.LangAnalysis 1.6.5 (1.6.5) <d057feb38163121ffd871c564c692804> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis +0x93a85000 - 0x93a8cff7 libCGATS.A.dylib ??? (???) <8875cf11c0de0579423ac6b6ce80336d> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib +0x93b54000 - 0x93b62ffd libz.1.dylib ??? (???) <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib +0x93b63000 - 0x93bbcff7 libGLU.dylib ??? (???) <64d010e31d7596bd8f9edc6e027d1d0c> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib +0x93bbd000 - 0x93c6fffb libcrypto.0.9.7.dylib ??? (???) <d02f7e5b8a68813bb7a77f5edb34ff9d> /usr/lib/libcrypto.0.9.7.dylib +0x94a29000 - 0x94d03ff3 com.apple.CoreServices.CarbonCore 786.16 (786.16) <d2af3f75c3500c518c39fd00aed7f9b9> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore +0x94d04000 - 0x94d33fe3 com.apple.AE 402.3 (402.3) <dba512e47f68eea1dd0ab35f596edb34> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE +0x94dab000 - 0x94dcffff libxslt.1.dylib ??? (???) <c372568bd2f7169efa0faee6546eead3> /usr/lib/libxslt.1.dylib +0x94e05000 - 0x94e0cfe9 libgcc_s.1.dylib ??? (???) <f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib +0x94e63000 - 0x95503fff com.apple.CoreGraphics 1.409.8 (???) <25020feb388637ee860451c19b613c48> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics +0x95504000 - 0x9553bfff com.apple.SystemConfiguration 1.9.2 (1.9.2) <41d5aeffefc6d19d471f51ae0b15024f> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration +0x9553c000 - 0x9553cffb com.apple.installserver.framework 1.0 (8) /System/Library/PrivateFrameworks/InstallServer.framework/Versions/A/InstallServer +0x9553d000 - 0x957b9fe7 com.apple.Foundation 6.5.9 (677.26) <c68b3cff7864959becfc7fd1a384f925> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation +0x958b6000 - 0x95a1dff3 libSystem.B.dylib ??? (???) <be7a9fa5c8a925578bddcbaa72e5bf6e> /usr/lib/libSystem.B.dylib +0x95a1e000 - 0x95aabff7 com.apple.framework.IOKit 1.5.2 (???) <7a3cc24f78f93931731203854ae0d891> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit +0x95aac000 - 0x95ac2fff com.apple.DictionaryServices 1.0.0 (1.0.0) <ad0aa0252e3323d182e17f50defe56fc> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices +0x95b13000 - 0x95b1dfeb com.apple.audio.SoundManager 3.9.2 (3.9.2) <0f2ba6e891d3761212cf5a5e6134d683> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound +0x95b1e000 - 0x95b29fe7 libCSync.A.dylib ??? (???) <f3228c803584320fde5e1bb9f04b4d44> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib +0x95b48000 - 0x95b63ff3 libPng.dylib ??? (???) <e0c3bdc3144e1ed91f1e4d00d147ff3a> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib +0x95b64000 - 0x95bdeff8 com.apple.print.framework.PrintCore 5.5.4 (245.6) <9ae833544b8249984c07544dbe6a97fa> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore +0x95cdf000 - 0x95dbffff libobjc.A.dylib ??? (???) <3ca288b625a47bbcfe378158e4dc328f> /usr/lib/libobjc.A.dylib +0x95dc0000 - 0x95dc9fff com.apple.speech.recognition.framework 3.7.24 (3.7.24) <17537dd39882e07142db9e5c2db170b8> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition +0x95dca000 - 0x95e71feb com.apple.QD 3.11.57 (???) <35f058678972d42b88ebdf652df79956> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD +0x95e73000 - 0x95f24fff edu.mit.Kerberos 6.0.15 (6.0.15) <28005ea82ba82307f185c255c25bfdd3> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos +0x95f25000 - 0x95f29fff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib +0x95f2a000 - 0x95f2affd com.apple.Accelerate.vecLib 3.4.2 (vecLib 3.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib +0x95f66000 - 0x96376fef libBLAS.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib +0x96389000 - 0x96408ff5 com.apple.SearchKit 1.2.2 (1.2.2) <3b5f3ab6a363a4d8a2bbbf74213ab0e5> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit +0x96409000 - 0x96419fff com.apple.speech.synthesis.framework 3.7.1 (3.7.1) <9a71429c74ed6ca43eb35e1f78471b2e> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis +0x9641a000 - 0x964e5fef com.apple.ColorSync 4.5.4 (4.5.4) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync +0x964e6000 - 0x96520fe7 com.apple.coreui 1.2 (62) /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI +0x96537000 - 0x96556ffa libJPEG.dylib ??? (???) <6d61215d5adfd74f75fed2e4db29a21c> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib +0x96557000 - 0x96564fe7 com.apple.opengl 1.5.10 (1.5.10) <e7d1198d869f45f09251f9697cbdd192> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL +0x96565000 - 0x965c2ffb libstdc++.6.dylib ??? (???) <04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib +0x965c3000 - 0x965c3ffa com.apple.CoreServices 32 (32) <2fcc8f3bd5bbfc000b476cad8e6a3dd2> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices +0x965ca000 - 0x965caffc com.apple.audio.units.AudioUnit 1.5 (1.5) /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit +0x96901000 - 0x96a4aff7 com.apple.ImageIO.framework 2.0.9 (2.0.9) <717938c4837f88bbe8ec613d4d25bc52> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO +0x96a4b000 - 0x96a4dff5 libRadiance.dylib ??? (???) <73169d8c3fc31df4005e8eaa0d16bde5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib +0x96b43000 - 0x96c95ff3 com.apple.audio.toolbox.AudioToolbox 1.5.3 (1.5.3) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox +0x96c96000 - 0x96cd5fef libTIFF.dylib ??? (???) <2afd7f6079224311d67ab427e10bf61c> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib +0x96d74000 - 0x96e07ff3 com.apple.ApplicationServices.ATS 3.8 (???) <e61b0945da6ab368348a927f7428ad67> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS +0x96e08000 - 0x96e8fff7 libsqlite3.0.dylib ??? (???) <aaaf72c093e13f34b96e2688b95bdb4a> /usr/lib/libsqlite3.0.dylib +0x9700a000 - 0x97312fe7 com.apple.HIToolbox 1.5.6 (???) <eece3cb8aa0a4e6843fcc1500aca61c5> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x97367000 - 0x97367ff8 com.apple.Cocoa 6.5 (???) <e064f94d969ce25cb7de3cfb980c3249> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa +0x97368000 - 0x9749bfe7 com.apple.CoreFoundation 6.5.7 (476.19) <a332c8f45529ee26d2e9c36d0c723bad> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x9752b000 - 0x975d2fec com.apple.CFNetwork 438.16 (438.16) <0a2f633dc532b176109547367f209ced> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork +0x975d3000 - 0x975dfff9 com.apple.helpdata 1.0.1 (14.2) /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData +0x97605000 - 0x97682feb com.apple.audio.CoreAudio 3.1.2 (3.1.2) <782a08c44be4698597f4bbd79cac21c6> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio +0x97683000 - 0x97699fe7 com.apple.CoreVideo 1.5.1 (1.5.1) <500f88e655f9566e02e08138f38e898d> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo +0x976a4000 - 0x976a5ffc libffi.dylib ??? (???) <a3b573eb950ca583290f7b2b4c486d09> /usr/lib/libffi.dylib +0x97963000 - 0x9798bff7 com.apple.shortcut 1.0.1 (1.0) <37e4b08cfaf9edb08b8682a06c4ec844> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut +0x9798c000 - 0x97a74ff3 com.apple.CoreData 100.2 (186.2) <44df326fea0236718f5ed64084e82270> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData +0x97aa7000 - 0x97aa7ffd com.apple.vecLib 3.4.2 (vecLib 3.4.2) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib +0xfffe8000 - 0xfffebfff libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib +``` + +On 10.11, the errors are still reported but dillo never crashes or at least it doesn't crash as quickly as it did on 10.5. +Running dillo with `CG_CONTEXT_SHOW_BACKTRACE` set shows +``` +May 1 21:32:53 dillo[48118] <Error>: CGContextSetTextPosition: invalid context 0x0. Backtrace: + <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> + <_ZN2dw4fltk8FltkFontC2EPNS_4core5style9FontAttrsE+236> + <_ZN2dw4fltk8FltkFont6createEPNS_4core5style9FontAttrsE+61> + <_ZN11StyleEngineC2EPN2dw4core6LayoutEPK8DilloUrlS6_f+540> + <a_Web_dispatch_by_type+266> + <Cache_process_queue+803> + <Cache_delayed_process_queue_callback+69> + <_ZL8do_timerP16__CFRunLoopTimerPv+53> + <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> + <__CFRunLoopDoTimer+1075> + <__CFRunLoopDoTimers+298> + <__CFRunLoopRun+1841> + <CFRunLoopRunSpecific+296> + <RunCurrentEventLoopInMode+235> + <ReceiveNextEventCommon+184> + <_BlockUntilNextEventMatchingListInModeWithFilter+71> + <_DPSNextEvent+1067> + <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> + <_Z21fl_mac_flush_and_waitd+549> + <_ZN2Fl4waitEv+29> + <main+2221> +``` + +Issue is on the fltk side? + +--%-- +From: rodarima +Date: Thu, 01 May 2025 21:25:20 +0000 + +Can you provide the output of `dillo -v`? Sound like a FLTK issue, but as we only support 1.3.X for now, tou can consider it to be our fault. You may be lucky to be able to upgrade to a newer 1.3.X version which fixes it. I don't think they support the 1.3 series anymore. + +--%-- +From: sevan +Date: Thu, 01 May 2025 21:30:04 +0000 + +Ancient OS X with up to date components +``` +Dillo v3.2.0 +Libraries: fltk/1.3.11 zlib/1.3.1 jpeg/90 png/1.6.45 webp/1.5.0 OpenSSL/3.5.0 +Features: +GIF +JPEG +PNG +SVG +WEBP -XEMBED +TLS +``` + +--%-- +From: rodarima +Date: Thu, 01 May 2025 21:48:12 +0000 + +Yeah, I don't think there is much you can do with FLTK 1.3 until we fix Dillo for FLTk 1.4, which is queued for the next Dillo release. You could try the FLTK 1.4.2 demos and check they work okay and that problem doesn't happen (specially the `bin/test/pack` program), otherwise you should be able to report those problem upstream in FLTK. + +See: #246 + +--%-- +From: sevan +Date: Thu, 01 May 2025 21:53:03 +0000 + +Ok, I'll do that.
\ No newline at end of file diff --git a/389/index.md b/389/index.md new file mode 100644 index 0000000..65ed6e2 --- /dev/null +++ b/389/index.md @@ -0,0 +1,6 @@ +Title: Print brotli version with -v +Author: rodarima +Created: Thu, 01 May 2025 22:22:40 +0000 +State: closed + +It was missing.
\ No newline at end of file diff --git a/39/index.md b/39/index.md new file mode 100644 index 0000000..f90cb87 --- /dev/null +++ b/39/index.md @@ -0,0 +1,110 @@ +Title: Consider other platforms to host Dillo +Author: rodarima +Created: Tue, 26 Dec 2023 14:52:58 +0000 +State: open + +As discussed with @clehner, we may want to switch to a different platform that can also provide a CI system avoiding Copilot and their closed source nature. + +- Codeberg: https://codeberg.org/ +- GitLab instance: https://wiki.p2pfoundation.net/List_of_Community-Hosted_GitLab_Instances +- Sourcehut: https://sr.ht/ + +Non exaustive list of problems with GitHub: + +- Copilot +- Replying by email doesn't work well: cannot close issues, markdown doesn't render and cannot attach images or files. +- Missing dependencies across issues +- Comments on issues are now JS-walled. +- Open/closed buttons on milestones no longer work in Firefox. + +--%-- +From: rakoo +Date: Wed, 03 Jan 2024 13:03:06 +0000 + +Hey there, thanks for reviving it, dillo is awesome ! + +Sourcehut has been cited in other places as well and will absolutely be a good place. Its focus on small, light web pages aligns with the ideas of Dillo. I'd love to see it there ! + +--%-- +From: rodarima +Date: Thu, 11 Apr 2024 22:39:52 +0000 + +Nice list for GitLab: https://wiki.p2pfoundation.net/List_of_Community-Hosted_GitLab_Instances + +--%-- +From: fgaz +Date: Thu, 30 May 2024 08:30:34 +0000 + +> Its focus on small, light web pages aligns with the ideas of Dillo. + +And it actually works in Dillo, I might add + +--%-- +From: rodarima +Date: Sun, 14 Jul 2024 17:13:52 +0000 + +Very large latency (~30s) observed in the Debian GitLab instance. + +> Sourcehut has been cited in other places as well and will absolutely be a good place. Its focus on small, light web pages aligns with the ideas of Dillo. I'd love to see it there ! + +> And it actually works in Dillo, I might add + +Sourcehut has a nice web interface that works from Dillo, but [Drew has opposed the usage of CI infrastructure for closed-source operative systems](https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC3ZF0IF242P4.3JN5FF60I1J20@keymaker.local%3E), which is fine for other FOSS projects, but not for a browser that tries to be cross-platform. + +The web interface also has other (fixable) problems based on my own experience, regarding attachments and replies to patches, but those are not so much a blocker. + +Another problem with sourcehut is that self-hosting is not particularly easy, specially when multiple services are required. Right now in alpha the prices are okay, but I don't know how much they would increase them when the alpha ends. + +I'm also reviewing other distributed options like [Radicle](https://radicle.xyz/) and [Fossil](https://www.fossil-scm.org/home/doc/trunk/www/index.wiki), but they also come with their own sets of drawbacks and benefits. + +--%-- +From: rodarima +Date: Mon, 30 Dec 2024 22:54:49 +0000 + +Strange situation at Sourcehut, Simon Ser [no longer works there][1]: + +> You may have heard that we also had to part ways with one of our staff members +> recently. This reduces our headcount to two. For the time being we will not be +> hiring a replacement, but our near-future plans are achievable with our +> current headcount. Though we usually aim for transparency to the maximum +> extent possible, we will not be sharing further details about this departure, +> as a matter of reasonable privacy. + +Simon [post][2]: + +> Sadly, I need to start this status update with bad news: SourceHut has decided +> to terminate my contract. At this time, I’m still in the process of figuring +> out what I’ll do next. I’ve marked some SourceHut-specific projects as +> unmaintained, such as sr.ht-container-compose (feel free to fork of course). +> I’ve handed over hut maintenance to xenrox, and I’ve started migrating a few +> projects to other forges (more to follow). I will continue to maintain +> projects that I still use such as soju to the extent that my free time allows. + +Not sure what the details are, but I don't like the lack of transparency. + +[1]: https://sourcehut.org/blog/2024-06-04-status-and-plans/ +[2]: https://emersion.fr/blog/2024/status-update-64/ + + +--%-- +From: rodarima +Date: Mon, 16 Jun 2025 18:07:25 +0000 + +Managed to a setup Woodpecker CI agent (runner) for Codeberg in the RPi 2 for tests. + +--%-- +From: rodarima +Date: Sun, 13 Jul 2025 21:57:29 +0000 + +> I'm also reviewing other distributed options like [Radicle](https://radicle.xyz/) + +Radicle seems to be funded by venture capital, so they will need to find a suitable way to monetize it: + +- https://www.crunchbase.com/organization/radicle-bde6 +- https://tracxn.com/d/companies/radicle/__kTwrUZvI_hwDhvMbO9h4h5TPIEJ5UMCiTyi9B7YXI0Y + +> Radicle has raised a total funding of $12M over 1 round. Its latest funding round was a Series B round on Feb 18, 2021 for $12M. 6 investors participated in its latest round, lead by [NFX](https://tracxn.com/d/venture-capital/nfx/__6V6UcYGwqq_nXCSVDCyXyDyfG46UkAhf0eaaGAdG4MI). +> +> Radicle has 15 institutional investors including [NFX](https://tracxn.com/d/venture-capital/nfx/__6V6UcYGwqq_nXCSVDCyXyDyfG46UkAhf0eaaGAdG4MI), [Cherry Ventures](https://platform.tracxn.com/a/d/company/55e8847ae4b0672c6cbc8808/cherry.vc) and [Coinbase](https://platform.tracxn.com/a/d/company/52bdc180e4b0420b03968e60/coinbase.com). [Naval Ravikant](https://tracxn.com/d/people/naval-ravikant/__zjY_8gmflKDzBLSv520Gkf9qM24BNrfFb_Vo_boSVAQ) and 2 others are Angel Investors in Radicle. + +I don't trust VC software, it tents to get real shitty over time.
\ No newline at end of file diff --git a/390/index.md b/390/index.md new file mode 100644 index 0000000..5775aa1 --- /dev/null +++ b/390/index.md @@ -0,0 +1,6 @@ +Title: Add trace view +Author: rodarima +Created: Fri, 02 May 2025 22:26:17 +0000 +State: open + +It would be interesting to have some statistics on how the current page loaded and the time it took to fetch and parse or decode the rest of the content. Maybe some internal endpoint like `about:trace?id=42` which can be opened in Dillo itself.
\ No newline at end of file diff --git a/391/index.md b/391/index.md new file mode 100644 index 0000000..7f2f99b --- /dev/null +++ b/391/index.md @@ -0,0 +1,6 @@ +Title: Drop Google Search as it now requires JavaScript +Author: rodarima +Created: Sun, 04 May 2025 21:22:36 +0000 +State: closed + +See: https://github.com/dillo-browser/dillo/issues/338
\ No newline at end of file diff --git a/392/index.md b/392/index.md new file mode 100644 index 0000000..770d2d5 --- /dev/null +++ b/392/index.md @@ -0,0 +1,27 @@ +Title: [postmarketos/phosh] usage of SSL websites disables the onscreen keyboard effects +Author: lm2lm2 +Created: Tue, 06 May 2025 10:37:50 +0000 +State: open + +postmarketos v24.12 updated + +dillo 3.2 + +1. open dillo browser +2. go to bookmarks +3. select 68k.news +4. validate cert +5. go to "change" (language) +6. select french +7. anywhere in dillo you will try to enter by keyboard, the keyboard is just disabled, in webpage as well as in address field. + +the On screen keyboard appears well, but it does not "prints" characters at all. + +pmos +https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/3696 + +--%-- +From: rodarima +Date: Mon, 02 Jun 2025 21:42:56 +0000 + +This seems to be a known issue with Phosh and FLTK. You may want to try the [Mobilized fork](https://www.toomanyatoms.com/software/mobilized_dillo.html) in the meanwhile.
\ No newline at end of file diff --git a/393/index.md b/393/index.md new file mode 100644 index 0000000..d4add80 --- /dev/null +++ b/393/index.md @@ -0,0 +1,11 @@ +Title: Use clipboard to copy links and text on Ctrl+C +Author: rodarima +Created: Tue, 06 May 2025 21:48:53 +0000 +State: closed + +Fixes two problems: + +- Copying links places them in the Primary and Clipboard selections. They can be pasted both with middle click or Ctrl+V. +- Copying text from the page with Ctrl+C copies it into the Clipboard selection so Ctrl+V works. + +Fixes: https://github.com/dillo-browser/dillo/issues/228
\ No newline at end of file diff --git a/394/index.md b/394/index.md new file mode 100644 index 0000000..a971dff --- /dev/null +++ b/394/index.md @@ -0,0 +1,27 @@ +Title: Dev +Author: Krowemoh +Created: Fri, 09 May 2025 05:21:49 +0000 +State: closed + +Added support for back and forward buttons on the mouse. + +(Sorry! Accidentally did a PR, I didn't realize which page I was on and I ate some of your actions here.) + +--%-- +From: rodarima +Date: Sat, 10 May 2025 21:57:21 +0000 + +I wouldn't oppose merging something like this. My main concern is how are we supposed to know which mapping from back/next buttons are to the numbers you see in FLTK. It should work for all mice that have those buttons, or at least let the user configure the proper button numbers (and I don't have such a mouse to test). + +Let me know if you want to work on this, I will close it in the meanwhile. + +--%-- +From: Krowemoh +Date: Mon, 12 May 2025 04:53:10 +0000 + +I did some light research and it looks to be the numbers are dependent on OS. On Linux the numbers look to be related to X11 and they look to be consistent however I learned this from forum posts rather than reference material. + +Feel free to leave this closed. + +Thanks for everything you've done to keep dillo alive! + diff --git a/395/index.md b/395/index.md new file mode 100644 index 0000000..0f791a4 --- /dev/null +++ b/395/index.md @@ -0,0 +1,5 @@ +Title: Add Marginalia and Wiby search engines +Author: rodarima +Created: Sat, 10 May 2025 18:44:21 +0000 +State: closed + diff --git a/396/index.md b/396/index.md new file mode 100644 index 0000000..2f9614e --- /dev/null +++ b/396/index.md @@ -0,0 +1,6 @@ +Title: Don't use assert to check if realloc() failed +Author: rodarima +Created: Sat, 10 May 2025 19:05:55 +0000 +State: closed + +Avoid using assert as when building with NDEBUG defined they become a no-operation so the realloc is never done. Always perform the check and exit accordingly.
\ No newline at end of file diff --git a/397/index.md b/397/index.md new file mode 100644 index 0000000..b70f177 --- /dev/null +++ b/397/index.md @@ -0,0 +1,5 @@ +Title: install-dpi-local: dpidc stop only if dpid is running +Author: Nomarian +Created: Mon, 12 May 2025 16:53:59 +0000 +State: closed + diff --git a/398/index.md b/398/index.md new file mode 100644 index 0000000..eadb641 --- /dev/null +++ b/398/index.md @@ -0,0 +1,13 @@ +Title: Content-Disposition causes non-root elements to open save dialogs +Author: rodarima +Created: Sun, 18 May 2025 18:40:18 +0000 +State: closed + +Loading https://xata.io/blog/xata-postgres-with-data-branching-and-pii-anonymization in Dillo causes several "save as" dialogs as the images and other elements contain the Content-Disposition header set: + +``` +$ curl -v 'https://xata.io/_next/image?url=https%3A%2F%2Fxata.io%2Fapi%2Fmedia%2Ffile%2Fcopy-on-write-branching-2.png&w=3840&q=100' |& grep dispo +< content-disposition: attachment; filename="copy-on-write-branching-2.png" +``` + +We should ignore the content disposition on anything that is not the root URL.
\ No newline at end of file diff --git a/399/index.md b/399/index.md new file mode 100644 index 0000000..bcc9619 --- /dev/null +++ b/399/index.md @@ -0,0 +1,10 @@ +Title: Only parse Content-Disposition for root URLs +Author: rodarima +Created: Sun, 18 May 2025 18:59:15 +0000 +State: closed + +A server may return the Content-Disposition in elements of a page like images, which would otherwise trigger several "save as" dialogs. + +Fixes: https://github.com/dillo-browser/dillo/issues/398 + +CC: @campaul
\ No newline at end of file diff --git a/4/index.md b/4/index.md new file mode 100644 index 0000000..e013d2a --- /dev/null +++ b/4/index.md @@ -0,0 +1,61 @@ +Title: build error, multiple definition of `xxxxxx' +Author: linsmod +Created: Mon, 17 Oct 2022 13:37:31 +0000 +State: closed + +``` +gcc -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter -Waggregate-return -L/usr/local/lib -o dpid dpi.o dpi_socket_dir.o dpid.o dpid_common.o main.o misc_new.o ../dpip/libDpip.a ../dlib/libDlib.a +/usr/bin/ld: dpi_socket_dir.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: multiple definition of `dpi_errno'; dpi.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: first defined here +/usr/bin/ld: dpid.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: multiple definition of `dpi_errno'; dpi.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: first defined here +/usr/bin/ld: dpid_common.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: multiple definition of `dpi_errno'; dpi.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: first defined here +/usr/bin/ld: main.o:/home/wulin/rodarima_dillo/dpid/dpid.h:58: multiple definition of `dpi_attr_list'; dpid.o:/home/wulin/rodarima_dillo/dpid/dpid.h:58: first defined here +/usr/bin/ld: main.o:/home/wulin/rodarima_dillo/dpid/dpid.h:61: multiple definition of `services_list'; dpid.o:/home/wulin/rodarima_dillo/dpid/dpid.h:61: first defined here +/usr/bin/ld: main.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: multiple definition of `dpi_errno'; dpi.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: first defined here +/usr/bin/ld: main.o:/home/wulin/rodarima_dillo/dpid/dpid.h:52: multiple definition of `numdpis'; dpid.o:/home/wulin/rodarima_dillo/dpid/dpid.h:52: first defined here +/usr/bin/ld: main.o:/home/wulin/rodarima_dillo/dpid/dpid.h:55: multiple definition of `numsocks'; dpid.o:/home/wulin/rodarima_dillo/dpid/dpid.h:55: first defined here +/usr/bin/ld: main.o:/home/wulin/rodarima_dillo/dpid/dpid.h:64: multiple definition of `sock_set'; dpid.o:/home/wulin/rodarima_dillo/dpid/dpid.h:64: first defined here +/usr/bin/ld: main.o:/home/wulin/rodarima_dillo/dpid/dpid.h:31: multiple definition of `srs_fd'; dpid.o:/home/wulin/rodarima_dillo/dpid/dpid.h:31: first defined here +/usr/bin/ld: main.o:/home/wulin/rodarima_dillo/dpid/dpid.h:28: multiple definition of `srs_name'; dpid.o:/home/wulin/rodarima_dillo/dpid/dpid.h:28: first defined here +/usr/bin/ld: misc_new.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: multiple definition of `dpi_errno'; dpi.o:/home/wulin/rodarima_dillo/dpid/dpid_common.h:43: first defined here +collect2: error: ld returned 1 exit status +make[2]: *** [Makefile:258: dpid] Error 1 +make[2]: Leaving directory '/home/wulin/rodarima_dillo/dpid' +make[1]: *** [Makefile:263: all-recursive] Error 1 +make[1]: Leaving directory '/home/wulin/rodarima_dillo' +make: *** [Makefile:180: all] Error 2 +``` + +--%-- +From: linsmod +Date: Mon, 17 Oct 2022 13:38:29 +0000 + +wulin@R7000:~/rodarima_dillo$ uname -a +Linux R7000 5.15.0-50-generic #56-Ubuntu SMP Tue Sep 20 13:23:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux + +--%-- +From: linsmod +Date: Mon, 17 Oct 2022 13:38:53 +0000 + +gcc --version +gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0 +Copyright (C) 2021 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +--%-- +From: linsmod +Date: Mon, 17 Oct 2022 13:39:42 +0000 + +same error on master and release_3_0_5 + +--%-- +From: rodarima +Date: Mon, 17 Oct 2022 17:31:38 +0000 + +Is probably due to the [changes in GCC 10](https://gcc.gnu.org/gcc-10/porting_to.html), try with `make CFLAGS=-fcommon`. The codebase should be properly patched to use `extern`. + +--%-- +From: linsmod +Date: Sat, 22 Oct 2022 10:41:08 +0000 + +got. fixed by use extern~ thanks ^_^
\ No newline at end of file diff --git a/40/index.md b/40/index.md new file mode 100644 index 0000000..7d0af1d --- /dev/null +++ b/40/index.md @@ -0,0 +1,46 @@ +Title: Add content tree inspector +Author: rodarima +Created: Tue, 26 Dec 2023 15:52:46 +0000 +State: open + +In order to debug some layout problems, we need to be able to see the internal widget tree and probably the related DOM. Currently Dillo discards the HTML as it is being processed (which is good for low memory devices), but we need to be able to run in debug mode in which the DOM is stored in memory and mapped to the widget tree to allow easier debugging. This would probably also open the door to tests which can assert properties of the tree directly. + +I'm thinking in something similar to Firefox/Chrome where I can explore the widget tree and query properties of each Textblock by selecting it interactively. We can also add a box on top to mark the widget in the canvas or blink the background color to locate it. + +I have done a proof of concept, but it should be designed to avoid querying internal members from outside, and instead let each widget report their own internal state in a common way. + + + + +--%-- +From: rodarima +Date: Sun, 03 Mar 2024 17:41:24 +0000 + +We are starting to have too many problems where this tree view is required to fix them. So let's include this in the 3.1 milestone, so we can debug problems in the wild too. + +--%-- +From: rodarima +Date: Thu, 07 Mar 2024 21:51:21 +0000 + +I splitted the tree into two panels, so we can see the document nodes in the left side and the properties on the right. Clicking on any part of the page with <kbd>Ctrl + Right Click</kbd> causes the window to jump to that node (I may need to think a better combination). Resizing the browser window causes the values to be updated in real time, which is useful to identify changes. + +I also added some printing helpers to see the CSS lenghts in human readable values as well as colors. + +Here is an example of fltk.org: + + + + +--%-- +From: rodarima +Date: Fri, 08 Mar 2024 22:42:07 +0000 + +The current solution I quickly put together uses the Fl_Tree widget from the FLTK library directly in the dw::core::Widget and other inherited classes. This breaks the nice separation of concerns of the dw::core and dw::fltk namespaces, where widgets are platform-agnostic and all platform specific implementations are handled in the dw::fltk namespace. + +I need to find a way to keep FLTK away from dw::core first. + +--%-- +From: rodarima +Date: Mon, 01 Apr 2024 21:31:52 +0000 + +I won't add this on 3.1.0, as it requires storing part of the DOM into memory to remember which element belongs to which Widget, and that could cause performance or memory issues with large pages. Additionally, the event window should be merged too, as the widget tree cannot really help debugging on its own. So let's leave this for another release, so we don't block 3.1.0 for longer.
\ No newline at end of file diff --git a/400/index.md b/400/index.md new file mode 100644 index 0000000..cf0f734 --- /dev/null +++ b/400/index.md @@ -0,0 +1,12 @@ +Title: Make Ctrl+A select all text in input +Author: rodarima +Created: Tue, 20 May 2025 21:33:12 +0000 +State: closed + +Users are not necessarily versed in Emacs shortcuts in text inputs. In particular, Ctrl+A should select all text in the input box as FLTK does. The problem is that we are using Emacs Ctrl+A to move to the beginning of the text, causing the select all to not work: + +https://github.com/dillo-browser/dillo/blob/e8be369aa93f535519d6f63db324571286a8996b/src/ui.cc#L130-L132 + +Using Ctrl+Shift+A can make it reach FTLK and select all text, but is not a documented behavior. + +We can add a new option to enable the Emacs handling, but not sure if this is even used.
\ No newline at end of file diff --git a/401/index.md b/401/index.md new file mode 100644 index 0000000..7d39b65 --- /dev/null +++ b/401/index.md @@ -0,0 +1,8 @@ +Title: Make Ctrl+A select input text +Author: rodarima +Created: Tue, 20 May 2025 21:36:44 +0000 +State: closed + +The Emacs shortcut was overriding the FLTK behavior of selecting all input text. + +Fixes: https://github.com/dillo-browser/dillo/issues/400
\ No newline at end of file diff --git a/402/index.md b/402/index.md new file mode 100644 index 0000000..446db74 --- /dev/null +++ b/402/index.md @@ -0,0 +1,62 @@ +Title: Poll for dillo window during HTML tests +Author: campaul +Created: Sat, 24 May 2025 17:51:29 +0000 +State: closed + +This updates the html test driver to poll for the window instead of always waiting for a full second. It also continues to poll for much longer than 1 second. This accomplishes two things: + +1) The tests will run faster on fast computers +2) The tests are now able to run on slower computers for which 1 second wasn't enough of a delay + +--%-- +From: rodarima +Date: Mon, 02 Jun 2025 21:47:05 +0000 + +I have a WIP patch to add a CLI tool to remote control Dillo which solves this problem by waiting until the page loads (or a timeout occurs). But we can merge this in the meanwhile. I'll need to check that all my old devices don't cause false negatives due to the reduction of the sleep time between the window appears and the rendering ends from 1 to 1/4 seconds. + +--%-- +From: rodarima +Date: Sun, 15 Jun 2025 14:06:19 +0000 + +I tested this on my old RPI 2 and it always fails unless the timeout is increased to at least 0.5 seconds (with 0.4 always fails). Here are the false negative rates I observed: + +- 0.5 seconds -> 2% failure rate (15/754 executions) +- 1.0 second -> 0% failure rate (0/563 executions) + +I suggest leaving it at 1 second but allowing developers to lower it by setting a `DILLO_TEST_WAIT_TIME` variable, so you can reduce it if you have faster hardware. This is just a temporary measure until we add support for a proper method that waits until the rendering is completed. + +```diff +From dbcaa28c3dc12f70d6b44344693dc204327baa5a Mon Sep 17 00:00:00 2001 +From: Rodrigo Arias Mallo <rodarima@gmail.com> +Date: Sun, 15 Jun 2025 15:58:47 +0200 +Subject: [PATCH] Set test wait time to 1 second but allow override + +Use the environment variable DILLO_TEST_WAIT_TIME to lower the default +time to wait since dillo window appears and when we take the screenshot +to compare the rendering output. +--- + test/html/driver.sh | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/test/html/driver.sh b/test/html/driver.sh +index 76e3b2ef..07a78b84 100755 +--- a/test/html/driver.sh ++++ b/test/html/driver.sh +@@ -42,7 +42,7 @@ function render_page() { + if [ ! -z "$winid" ]; then + found_window=true + # Wait some after the window appears to ensure rendering is done +- sleep 0.25 ++ sleep ${DILLO_TEST_WAIT_TIME:-1} + break + fi + done +-- +2.49.0 +``` + +--%-- +From: rodarima +Date: Sun, 29 Jun 2025 12:06:15 +0000 + +Thanks, I'll rebase and merge this first. It is also failing with newer Image Magick versions as they now print two values in the compare output. But I will address that in another MR.
\ No newline at end of file diff --git a/403/index.md b/403/index.md new file mode 100644 index 0000000..3602f32 --- /dev/null +++ b/403/index.md @@ -0,0 +1,40 @@ +Title: Implement margin auto +Author: campaul +Created: Thu, 29 May 2025 19:39:00 +0000 +State: open + +Fix for #67 + +This still needs more tests and documentation before it's ready to go but I wanted to post the PR to start getting feedback as early as possible. This is a big change so I expect it will end up needing many revisions. + +## Overview + +Some changes that were made as prerequisites: +- `style.margin` is now a length instead of just a value +- the style class has `marginLeft`, `marginRight`, `marginTop`, and `marginBottom` functions for converting back to a value. Percent and auto are treated as 0 by this function. +- `boxOffsetX`, `boxRestWidth`, and `boxDiffWidth` are moved from style to widget under the names `marginBoxOffsetX`, `marginBoxRestWidth`, and `marginBoxDiffWidth`. +- a `margin` field is added to the `Widget` class. + +The main logic is as follows: +- `calcWidth` computes margin widths and returns a `BoxWidth` struct that contains the computed margin sizes instead of just the total size. +- `calcFinalWidth` sets `widget.margin.left` and `widget.margin.right` based on what it picked as the final size. +- the `marginBoxOffsetX`, `marginBoxRestWidth`, and `marginBoxDiffWidth` functions use the saved `widget.margin` values instead of `style.margin` values. + +This works because `getAvailableWidth` is always called *before* any of `boxOffsetX`, `boxRestWidth` or `boxDiffWidth`. This means `calcFinalWidth` is guaranteed to have already run. + + +## Screenshots +The margin auto test passing +<img width="807" alt="Screenshot 2025-05-29 at 2 22 59 PM" src="https://github.com/user-attachments/assets/b6a50cfa-4b68-434c-aab0-d0b96d0bbc07" /> + +The dillo website correctly centered now +<img width="1169" alt="Screenshot 2025-05-29 at 2 23 33 PM" src="https://github.com/user-attachments/assets/5ef65ba4-9970-4dca-ba35-ec0f59e8fd25" /> + + +--%-- +From: rodarima +Date: Mon, 02 Jun 2025 21:32:28 +0000 + +Thanks a lot for the effort! I will check the implementation when I have a moment, what you describe sounds reasonable. + +So far I see that with fca573fa0b3c2654f2ca178aa6556394f52be2a8 the page https://dillo-browser.github.io/25-years/index.html extends the width ignoring the max-width constraint. Can we add another test case so we prevent future regressions?
\ No newline at end of file diff --git a/404/index.md b/404/index.md new file mode 100644 index 0000000..ead09d1 --- /dev/null +++ b/404/index.md @@ -0,0 +1,26 @@ +Title: blockquote and dd render incorrectly with float +Author: campaul +Created: Thu, 29 May 2025 22:34:10 +0000 +State: open + +The `blockquote` and `dd` tags render incorrectly when float is applied. I suspect this has something to do with the `Html_tag_open_blockquote` and `Html_tag_open_dd` functions but I haven't been able to fully isolate the issue yet. + +The screenshots below are based on the following style: +```css +blockquote { + border-style: solid; + border-color: black; + width: 50px; + height: 50px; + float: left; + background-color: #FC0; + color: black; + margin: 10px; +} +``` + +## Expected Behavior + + +## Current Behavior +
\ No newline at end of file diff --git a/405/index.md b/405/index.md new file mode 100644 index 0000000..a9953b4 --- /dev/null +++ b/405/index.md @@ -0,0 +1,85 @@ +Title: Fix blockquote and dd having textblocks double added +Author: campaul +Created: Thu, 29 May 2025 22:34:59 +0000 +State: open + +Test for #404 + +--%-- +From: campaul +Date: Mon, 02 Jun 2025 18:01:43 +0000 + +The `Html_tag_open_blockquote` and `Html_tag_open_dd` were calling `Html_add_textblock`, essentially turning the elements into block elements despite them being inline. Following that, if a style was applied that would actually make the element be block (`display: block`, `display: inline-block`, or `float: left/right`), then it would end up having the textblock double added. + +To fix this I removed both of those functions and replaced them with calls to `Html_tag_open_default`. I then added `blockquote` and `dd` to the list of elements that have `display: block` applied by default which is recommended by the CSS specification and what other browsers do. + +--%-- +From: rodarima +Date: Mon, 30 Jun 2025 20:41:03 +0000 + +Thanks, I was trying to find out why it was being done that way. I traced it back to the first commit we have recoded from 2007 which already used the textblock (my comments apply to dd too): + +https://github.com/dillo-browser/dillo/blob/93715c46a99c96d6c866968312691ec9ab0f6a03/src/html.cc#L2770-L2774 + +https://github.com/dillo-browser/dillo/blob/93715c46a99c96d6c866968312691ec9ab0f6a03/src/html.cc#L639-L643 + +At that point there was no logic to handle display elements like we have now: + +https://github.com/dillo-browser/dillo/blob/f6abc117030f372261cef98e191113a2078c8c1b/src/html.cc#L4094-L4119 + +I'm guessing this would only potentially cause problems if we have an inline blockquote? As before we would have a new textblock but now we won't. + +Here is a testcase with inline blockquote: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test inline blockquote</title> + <style type="text/css"> + div { + background-color: #ededed; + margin: 10px 3em; + padding: 15px; + border-radius: 5px; + } + blockquote { + display: inline; + border: solid 2px black; + } + </style> + </head> + <body> + <div> + <blockquote cite="https://www.huxley.net/bnw/four.html"> + Words can be like X-rays, if you use them properly—they’ll go through + anything. You read and you’re pierced. + </blockquote> + <p style="text-align:right">—Aldous Huxley, <cite>Brave New World</cite></p> + </div> + </body> +</html> + +``` + +And here it how it changes the rendering from this branch, master and Firefox (top to bottom): + + + +Not sure if there is a good way to avoid breaking the current behavior for inline. We don't follow the "correct" inline behavior either. + +--%-- +From: campaul +Date: Fri, 08 Aug 2025 02:54:46 +0000 + +> Not sure if there is a good way to avoid breaking the current behavior for inline. We don't follow the "correct" inline behavior either. + +It looks like it wont be too hard to implement the correct border behavior for inline elements, so I'm going to focus on implementing that first then return to this PR after that's done. + +--%-- +From: rodarima +Date: Mon, 11 Aug 2025 11:37:07 +0000 + +> I'm going to focus on implementing that first then return to this PR after that's done. + +I'll mark this as WIP in the meanwhile.
\ No newline at end of file diff --git a/406/index.md b/406/index.md new file mode 100644 index 0000000..3350983 --- /dev/null +++ b/406/index.md @@ -0,0 +1,32 @@ +Title: Multiple floated items are clearing when they shouldn't +Author: campaul +Created: Mon, 02 Jun 2025 17:38:09 +0000 +State: open + +Given the following example: + +```html +<html> + <head> + <style type="text/css"> + div { + width: 100px; + height: 100px; + margin: 10px; + border: 5px solid black; + float: left; + } + </style> + </head> + <body> + <div>A</div> + <div>B</div> + </body> +</html> +``` + +## Expected Result (taken from Firefox) + + +## Actual Result +
\ No newline at end of file diff --git a/407/index.md b/407/index.md new file mode 100644 index 0000000..7460f9f --- /dev/null +++ b/407/index.md @@ -0,0 +1,6 @@ +Title: Fractional pixel margin rounding issue +Author: campaul +Created: Mon, 02 Jun 2025 17:44:27 +0000 +State: open + +Margins are rounded to a pixel value *before* being added resulting in margins sometimes being 1 pixel too wide. For example, if two adjacent elements both have margins of `2.5px`, those margins will get rounded to 3 resulting in a total space of 6 pixels between the elements. The correct behavior is to add them before rounding which would result in a total space of 5 pixels.
\ No newline at end of file diff --git a/408/index.md b/408/index.md new file mode 100644 index 0000000..00fe275 --- /dev/null +++ b/408/index.md @@ -0,0 +1,6 @@ +Title: Multiple float and margin rounding tests +Author: campaul +Created: Mon, 02 Jun 2025 19:31:50 +0000 +State: closed + +Tests for #406 and #407
\ No newline at end of file diff --git a/409/index.md b/409/index.md new file mode 100644 index 0000000..bb62f86 --- /dev/null +++ b/409/index.md @@ -0,0 +1,12 @@ +Title: Windows build +Author: andreasrosdal +Created: Mon, 02 Jun 2025 20:42:26 +0000 +State: closed + +Please make a Windows build of the Dillo browser + +--%-- +From: rodarima +Date: Mon, 02 Jun 2025 21:36:11 +0000 + +There is Cygwin support only (WSL seems to work too). Making a native port won't be an easy task, but I wouldn't be oppose to merge such port if you are willing to implement it and maintain it over time.
\ No newline at end of file diff --git a/41/index.md b/41/index.md new file mode 100644 index 0000000..0de6cb0 --- /dev/null +++ b/41/index.md @@ -0,0 +1,199 @@ +Title: FreeBSD linker error due to undefined libiconv_open +Author: rodarima +Created: Wed, 27 Dec 2023 11:45:05 +0000 +State: closed + +``` +c++ -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/include \ + -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -D_THREAD_SAFE -O2 \ + -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing \ + -isystem /usr/local/include -fvisibility-inlines-hidden -I/usr/local/include \ + -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE \ + -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti \ + -fno-exceptions -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o \ + hsts.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o \ + keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o \ + cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o \ + plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o \ + imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a \ + ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a \ + ../dw/libDw-core.a ../lout/liblout.a -L/usr/local/lib -lpng16 -L/usr/local/lib \ + -lm -Wl,-rpath,/usr/local/lib -fstack-protector-strong -lfltk -lXrender -lXcursor \ + -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -lm -lX11 -lz -lX11 \ + -lcrypto -lssl + ld: error: undefined symbol: libiconv_open + >>> referenced by form.cc:1142 (../../../src/form.cc:1142) + >>> form.o:(DilloHtmlForm::buildQueryData(DilloHtmlInput*)) + >>> referenced by form.cc:1146 (../../../src/form.cc:1146) + >>> form.o:(DilloHtmlForm::buildQueryData(DilloHtmlInput*)) + + ld: error: undefined symbol: libiconv_close + >>> referenced by form.cc:1244 (../../../src/form.cc:1244) + >>> form.o:(DilloHtmlForm::buildQueryData(DilloHtmlInput*)) + + ld: error: undefined symbol: libiconv + >>> referenced by form.cc:1339 (../../../src/form.cc:1339) + >>> form.o:(DilloHtmlForm::encodeText(void*, Dstr**)) + c++: error: linker command failed with exit code 1 (use -v to see invocation) + *** Error code 1 + ``` + +This is likely caused by a the configure script first testing if iconv is provided by the libc, which it is: +``` + checking for iconv.h... yes + checking for iconv_open in -lc... yes +``` + +But then, the `-isystem /usr/local/include` gets added from `fltk-config`, causing `/usr/local/include/iconv.h` to be loaded first which is part of libiconv (instead of `/usr/include/iconv.h`). + +This header defines iconv_open() as libiconv_open() instead of the symbol iconv_open() provided by libc. Then, the linker fails as -liconv is not provided as initially it was decided to use the implementation in libc. + +--%-- +From: rodarima +Date: Wed, 27 Dec 2023 14:09:59 +0000 + +This doesn't make a lot of sense, as the form.o is compiled with a `-I/usr/include` first: +``` +2023-12-27T12:38:34.1670839Z c++ -DHAVE_CONFIG_H -I. -I.. -I.. -DDILLO_SYSCONF='"/usr/local/etc/dillo/"' -DDILLO_DOCDIR='"/usr/local/share/doc/dillo/"' -DCUR_WORKING_DIR='"/home/runner/work/dillo/dillo/src"' -I/usr/include -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -D_THREAD_SAFE -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fvisibility-inlines-hidden -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT form.o -MD -MP -MF .deps/form.Tpo -c -o form.o form.cc +``` + +Here is the `tr ' ' '\n'` version: + +``` +tr ' ' '\n' < /tmp/kk +2023-12-27T12:38:34.1670839Z +c++ +-DHAVE_CONFIG_H +-I. +-I.. + + +-I.. + +-DDILLO_SYSCONF='"/usr/local/etc/dillo/"' + +-DDILLO_DOCDIR='"/usr/local/share/doc/dillo/"' + +-DCUR_WORKING_DIR='"/home/runner/work/dillo/dillo/src"' +-I/usr/include +-I/usr/local/include/libpng16 +-I/usr/local/include +-I/usr/local/include +-I/usr/local/include/freetype2 +-I/usr/local/include/libpng16 +-D_THREAD_SAFE +-O2 +-pipe +-fstack-protector-strong +-isystem +/usr/local/include +-fno-strict-aliasing +-isystem +/usr/local/include +-fvisibility-inlines-hidden +-I/usr/local/include +-D_LARGEFILE_SOURCE +-D_LARGEFILE64_SOURCE +-D_THREAD_SAFE +-D_REENTRANT +-g +-O2 +-Wall +-W +-Wno-unused-parameter +-fno-rtti +-fno-exceptions +-MT +form.o +-MD +-MP +-MF +.deps/form.Tpo +-c +-o +form.o +form.cc +``` + +--%-- +From: rodarima +Date: Wed, 27 Dec 2023 14:23:27 +0000 + +Ah, this may be the problem, from gcc(1): + +``` + If a standard system include directory, or a directory specified + with -isystem, is also specified with -I, the -I option is ignored. + The directory is still searched but as a system directory at its + normal position in the system include chain. This is to ensure + that GCC's procedure to fix buggy system headers and the ordering + for the "#include_next" directive are not inadvertently changed. + If you really need to change the search order for system + directories, use the -nostdinc and/or -isystem options. + +``` +So I'm guessing the first `-I/usr/include/` is ignored as it is already in the system list of gcc, then the `-isystem /usr/local/include` adds it to the beginning of the search list, and that ends up with `/usr/include/local/iconv.h`. + +I can verify this by using `CXXFLAGS="-v"`, so it dumps the search path. + +--%-- +From: rodarima +Date: Wed, 27 Dec 2023 14:33:10 +0000 + +Yeah, that seems to be the case: +``` +2023-12-27T14:28:38.9303858Z c++ -DHAVE_CONFIG_H -I. -I.. -I.. -DDILLO_SYSCONF='"/usr/local/etc/dillo/"' -DDILLO_DOCDIR='"/usr/local/share/doc/dillo/"' -DCUR_WORKING_DIR='"/home/runner/work/dillo/dillo/src"' -I/usr/local/include/libpng16 -I/usr/local/include -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -D_THREAD_SAFE -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fvisibility-inlines-hidden -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -I/START -I/usr/include -v -I/END -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT form.o -MD -MP -MF .deps/form.Tpo -c -o form.o form.cc +2023-12-27T14:28:38.9336368Z FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) +2023-12-27T14:28:38.9337563Z Target: x86_64-unknown-freebsd14.0 +2023-12-27T14:28:38.9338145Z Thread model: posix +2023-12-27T14:28:38.9338543Z InstalledDir: /usr/bin +2023-12-27T14:28:38.9340781Z (in-process) +2023-12-27T14:28:38.9354557Z "/usr/bin/c++" -cc1 -triple x86_64-unknown-freebsd14.0 -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name form.cc -mrelocation-model static -mframe-pointer=all -relaxed-aliasing -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/runner/work/dillo/dillo/src -resource-dir /usr/lib/clang/16 -dependency-file .deps/form.Tpo -MT form.o -sys-header-deps -MP -isystem /usr/local/include -isystem /usr/local/include -D HAVE_CONFIG_H -I . -I .. -I .. -D "DILLO_SYSCONF=\"/usr/local/etc/dillo/\"" -D "DILLO_DOCDIR=\"/usr/local/share/doc/dillo/\"" -D "CUR_WORKING_DIR=\"/home/runner/work/dillo/dillo/src\"" -I /usr/local/include/libpng16 -I /usr/local/include -I /usr/local/include -I /usr/local/include/freetype2 -I /usr/local/include/libpng16 -D _THREAD_SAFE -I /usr/local/include -D _LARGEFILE_SOURCE -D _LARGEFILE64_SOURCE -D _THREAD_SAFE -D _REENTRANT -I /START -I /usr/include -I /END -internal-isystem /usr/include/c++/v1 -internal-isystem /usr/lib/clang/16/include -internal-externc-isystem /usr/include -O2 -Wall -W -Wno-unused-parameter -fdeprecated-macro -fdebug-compilation-dir=/home/runner/work/dillo/dillo/src -ferror-limit 19 -fvisibility-inlines-hidden -stack-protector 2 -fno-rtti -fgnuc-version=4.2.1 -vectorize-loops -vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o form.o -x c++ form.cc +2023-12-27T14:28:38.9362257Z clang -cc1 version 16.0.6 based upon LLVM 16.0.6 default target x86_64-unknown-freebsd14.0 +2023-12-27T14:28:38.9362822Z ignoring nonexistent directory "/START" +2023-12-27T14:28:38.9363183Z ignoring nonexistent directory "/END" +2023-12-27T14:28:38.9363521Z ignoring duplicate directory ".." +2023-12-27T14:28:38.9363873Z ignoring duplicate directory "/usr/local/include" +2023-12-27T14:28:38.9364326Z ignoring duplicate directory "/usr/local/include/libpng16" +2023-12-27T14:28:38.9364776Z ignoring duplicate directory "/usr/local/include" +2023-12-27T14:28:38.9365176Z ignoring duplicate directory "/usr/local/include" +2023-12-27T14:28:38.9365733Z as it is a non-system directory that duplicates a system directory +2023-12-27T14:28:38.9366223Z ignoring duplicate directory "/usr/local/include" +2023-12-27T14:28:38.9366846Z ignoring duplicate directory "/usr/include" <--- here +2023-12-27T14:28:38.9367378Z as it is a non-system directory that duplicates a system directory <--- here +2023-12-27T14:28:38.9367828Z #include "..." search starts here: +2023-12-27T14:28:38.9368135Z #include <...> search starts here: +2023-12-27T14:28:38.9368422Z . +2023-12-27T14:28:38.9368601Z .. +2023-12-27T14:28:38.9368803Z /usr/local/include/libpng16 +2023-12-27T14:28:38.9369087Z /usr/local/include/freetype2 +2023-12-27T14:28:38.9369549Z /usr/local/include +2023-12-27T14:28:38.9369787Z /usr/include/c++/v1 +2023-12-27T14:28:38.9370032Z /usr/lib/clang/16/include +2023-12-27T14:28:38.9370287Z /usr/include +2023-12-27T14:28:38.9370498Z End of search list. +``` + +I don't see any easy solution, as including `/usr/local/include` is required for the libraries in ports, so they will always shadow `/usr/include/iconv.h`. Maybe FreeBSD folks can suggest some solution... + +--%-- +From: rodarima +Date: Wed, 27 Dec 2023 17:09:47 +0000 + +Opened ticket in FreeBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275969 + +--%-- +From: idatum +Date: Sun, 05 May 2024 16:04:36 +0000 + +Seeing the same on NetBSD 10 (Aarch64): + +`/work/dillo/build/src/../../src/form.cc:1339: undefined reference to `libiconv' +/work/dillo/build/src/../../src/form.cc:1339:(.text+0x148): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `libiconv' +ld: form.o: in function `DilloHtmlForm::buildQueryData(DilloHtmlInput*)': +/work/dillo/build/src/../../src/form.cc:1244: undefined reference to `libiconv_close' +/work/dillo/build/src/../../src/form.cc:1244:(.text+0x3c7c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `libiconv_close' +ld: /work/dillo/build/src/../../src/form.cc:1142: undefined reference to `libiconv_open' +/work/dillo/build/src/../../src/form.cc:1142:(.text+0x4190): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `libiconv_open' +ld: /work/dillo/build/src/../../src/form.cc:1146: undefined reference to `libiconv_open' +/work/dillo/build/src/../../src/form.cc:1146:(.text+0x4260): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `libiconv_open'`
\ No newline at end of file diff --git a/410/index.md b/410/index.md new file mode 100644 index 0000000..cea18b8 --- /dev/null +++ b/410/index.md @@ -0,0 +1,71 @@ +Title: text-align affecting container positioning +Author: campaul +Created: Sat, 14 Jun 2025 05:32:28 +0000 +State: closed + +Given the following example: +```html +<!DOCTYPE html> +<html> + <head> + <style> + .outer { + background-color:coral; + } + .inner { + background-color:aquamarine; + text-align: center; + max-width: 300px; + } + </style> + </head> + <body> + <div class="outer"> + <div class="inner">Hello</div> + </div> +</html> +``` + +The text in the inner div should be centered, but the inner div itself should be left aligned. Instead the text is centered and the inner div is also centered. + +## Expected Behavior (taken from Firefox) + + +## Actual Behavior + + + +--%-- +From: rodarima +Date: Sat, 14 Jun 2025 19:59:20 +0000 + +Thanks, maybe we can make a test case with a table which seems to center it properly, something like this: + +```html +<!DOCTYPE html> +<html> + <head> + <style> + table, tr, td { + border-spacing: 0; + margin: 0; + padding: 0; + } + .outer { + background-color:coral; + width: 400px; + } + .inner { + background-color:aquamarine; + text-align: center; + width: 100px; + height: 50px; + } + </style> + </head> + <body> + <table class="outer"> + <tr><td class="inner">Hello</td><td></td></tr> + </table> +</html> +```
\ No newline at end of file diff --git a/411/index.md b/411/index.md new file mode 100644 index 0000000..4c2e80a --- /dev/null +++ b/411/index.md @@ -0,0 +1,6 @@ +Title: Add test for text-align: center +Author: campaul +Created: Sun, 15 Jun 2025 15:47:32 +0000 +State: closed + +Test for #410
\ No newline at end of file diff --git a/412/index.md b/412/index.md new file mode 100644 index 0000000..2588531 --- /dev/null +++ b/412/index.md @@ -0,0 +1,66 @@ +Title: Out of date HSTS preload list +Author: MrMinderbinder +Created: Tue, 17 Jun 2025 11:20:01 +0000 +State: open + +The current HSTS preload list has not been updated in 9 years. + +The links mentioned in hsts.c are dead, the Mozilla one should be https://hg.mozilla.org/mozilla-central/raw-file/tip/security/manager/ssl/nsSTSPreloadList.inc + +The latest list is over 3MB and contains over 150k entries versus ~190KB and ~10k entries for the current one. I have already taken the latest list and converted it into the format Dillo expects and startup is noticeably slower with it. Which leads me to think that HSTS preloading should just be removed as it seems a bit out of scope for a minimalist browser and there are many disadvantages compared to the value preloading brings. Or perhaps a slimmed down list for Dillo can be created? + +--%-- +From: rodarima +Date: Tue, 17 Jun 2025 19:20:50 +0000 + +I would be inclined to remove HSTS and enable `http_force_https=YES` by default, as it seems [98% of sampled sites use it since last year](https://almanac.httparchive.org/en/2024/security#transport-security). It can still be disabled from the menu for the current tab if needed. + +--%-- +From: MrMinderbinder +Date: Wed, 18 Jun 2025 02:57:35 +0000 + +There is no easy solution to this. + +Potentially having a small percentage of sites fail by default does not seem appealing especially when it is likely the majority of users will not know why. Also disabling and re-enabling is annoying and users might also forget to re-enable after disabling. Even the big browsers do not dare try this yet. I also do not really want to see the work that has been done on this already thrown away. + +After thinking about this some more I think we should either keep HSTS but get rid of preloading and trust on first use, accepting that there is no scalable solution to this on the browsers end or we make a smaller preload list that makes sense for Dillo. I am leaning towards making a new list that is the same size as the old one. Maybe we choose the smaller subset of domains at random from the full size list. + +The slowdown is not significant on average hardware today, it is still less than a second on my system. It goes from taking tens of milliseconds with no list at all to hundreds of milliseconds. However on low end or older hardware I suspect it will be more severe. Unless you want to explore ways to parse the list more quickly? + +--%-- +From: MrMinderbinder +Date: Wed, 18 Jun 2025 21:53:53 +0000 + +> ...we make a smaller preload list that makes sense for Dillo. I am leaning towards making a new list that is the same size as the old one. Maybe we choose the smaller subset of domains at random from the full size list. + +I have done this for myself and have a little script to automate it. + +--%-- +From: rodarima +Date: Sat, 21 Jun 2025 12:12:57 +0000 + +> I also do not really want to see the work that has been done on this already thrown away. + +HSTS can be used as a [supercookie by an attacker](https://github.com/ben174/hsts-cookie) and track the user across a session (until you close Dillo, unlike other browsers), is not that good idea either. The whole idea should be ditched. + +> Potentially having a small percentage of sites fail by default does not seem appealing especially when it is likely the majority of users will not know why. + +I would rather lean towards security by always forcing HTTPS even if it involves worse potential user experience. + +> However on low end or older hardware I suspect it will be more severe. + +We are using the RPi 2 as the standard "oldish hardware" benchmark. Reducing startup time is always appreciated, I can try later to measure this with/without HSTS (already got rid of it). + +--%-- +From: niutech +Date: Fri, 11 Jul 2025 10:16:07 +0000 + +How about localhost or internal URLs in LAN? Often they don't have SSL. Forcing HTTPS is too strict IMO. How about trimming down the HSTS list to 10k top domains on startup and lazy load the full list in background? + +--%-- +From: rodarima +Date: Fri, 11 Jul 2025 21:06:54 +0000 + +> How about localhost or internal URLs in LAN + +An easy solution is to invert the list and only add the exceptions that can use HTTP. We can add localhost by default, and let the user configure any other hosts, similar to domainrc.
\ No newline at end of file diff --git a/413/index.md b/413/index.md new file mode 100644 index 0000000..11de118 --- /dev/null +++ b/413/index.md @@ -0,0 +1,48 @@ +Title: Fix text align +Author: campaul +Created: Tue, 17 Jun 2025 22:41:19 +0000 +State: closed + +Fix for #410 ~~and a prerequisite for finishing #403~~ +Edit: this does have some interactions with #403 but turns out the fixes can be implemented independently. + +There are two components to this change: +1) Only apply text alignment if the element being aligned is `inline` or `inline-block`. +2) Use the `alignStlye` from the container instead of from the element being aligned. + +This PR also expands `test/text-align-center.html` with test cases for some other common scenarios + + +--%-- +From: campaul +Date: Wed, 18 Jun 2025 05:06:52 +0000 + +The text-align-center test is currently failing due to imperceptible differences in font rendering. There are a few pixels different in the "r" at the end of "inner" in the 4th example and the "r" at the end of outer in the 5th example. This issue also isn't consistent across systems, as the test actually passes for me on some of the devices I've checked. + +Do you think we should consider this a bug and try to get the font rendering identical, or would it be reasonable to add a small fuzz value to the comparison check? I've found a value of `-fuzz 6%` is enough to make this test pass. + +## Test + + +## Reference + + + + +--%-- +From: rodarima +Date: Sat, 21 Jun 2025 09:51:11 +0000 + +Interesting, not sure what is causing those differences. I'm leaving here a magnified picture of the problem: + + + +I would be inclined to think that they use floating point numbers internally to store the position of each glyph and there may be some rounding effects moving the `r` slightlighly to the right, causing the problem in one case but not in the other. It would be heavily dependant on your platform and the specific versions of the rendering libraries you use underneath. + +Could we reduce the text length (say to one word only) and see if the problem goes away? I would prefer not adding fuzzing as that may conceal other problems. + +--%-- +From: campaul +Date: Sat, 21 Jun 2025 16:27:54 +0000 + +Changing inner/outer to internal/external seems to have done the trick. Based on some other testing I did it seems like the issue has more to do with specific words than the length of the string.
\ No newline at end of file diff --git a/414/index.md b/414/index.md new file mode 100644 index 0000000..80245c0 --- /dev/null +++ b/414/index.md @@ -0,0 +1,55 @@ +Title: Add options to search custom MbedTLS installations +Author: winterheart +Created: Sat, 28 Jun 2025 13:34:07 +0000 +State: closed + +Some Linux distributions (like Gentoo or Arch) allows to install MbedTLS 2.x and 3.x branches simultaneously. This change helps to inding custom MbedTLS locations. + +--%-- +From: rodarima +Date: Wed, 02 Jul 2025 18:23:16 +0000 + +I have pushed a commit that works in Arch Linux for Mbed TLS 2: + +``` +% ../configure --disable-openssl --with-mbedtls-lib=/usr/lib/mbedtls2 --with-mbedtls-inc=/usr/include/mbedtls2 +% ldd src/dillo | grep libmbedtls + libmbedtls.so.14 => /usr/lib/libmbedtls.so.14 (0x00007f346b65f000) +% ls -l /usr/lib/mbedtls2/libmbedtls.so +lrwxrwxrwx 1 root root 19 Apr 6 14:40 /usr/lib/mbedtls2/libmbedtls.so -> ../libmbedtls.so.14 +% ls -l /usr/lib/libmbedtls.so.[0-9]? +lrwxrwxrwx 1 root root 21 Apr 6 14:40 /usr/lib/libmbedtls.so.14 -> libmbedtls.so.2.28.10 +lrwxrwxrwx 1 root root 19 Apr 6 06:26 /usr/lib/libmbedtls.so.21 -> libmbedtls.so.3.6.3 +``` + +And for Mbed TLS 3 (no need for extra flags): + +``` +% ../configure --disable-openssl +% ldd src/dillo | grep libmbedtls + libmbedtls.so.21 => /usr/lib/libmbedtls.so.21 (0x00007f488d3df000) +% ls -l /usr/lib/libmbedtls.so.[0-9]? +lrwxrwxrwx 1 root root 21 Apr 6 14:40 /usr/lib/libmbedtls.so.14 -> libmbedtls.so.2.28.10 +lrwxrwxrwx 1 root root 19 Apr 6 06:26 /usr/lib/libmbedtls.so.21 -> libmbedtls.so.3.6.3 +``` + +Let me know if that would fix it for Gentoo. + +--%-- +From: winterheart +Date: Wed, 02 Jul 2025 18:40:36 +0000 + +Building works in Gentoo with configure options: +``` +./configure --disable-openssl --enable-tls --with-mbedtls-inc=/usr/include/mbedtls3 +... + TLS enabled: yes + TLS library: mbedTLS + TLS flags : -lmbedtls-3 -lmbedcrypto-3 -lmbedx509-3 +``` + +--%-- +From: rodarima +Date: Wed, 02 Jul 2025 18:56:57 +0000 + +Perfect, then we can merge this if there are no futher issues.
\ No newline at end of file diff --git a/415/index.md b/415/index.md new file mode 100644 index 0000000..3d96842 --- /dev/null +++ b/415/index.md @@ -0,0 +1,16 @@ +Title: Fix newer compare output +Author: rodarima +Created: Sun, 29 Jun 2025 12:17:17 +0000 +State: closed + +The compare output command has now two numbers, so it will always fail if we compare it to "0". + +``` +++ compare -metric AE b-div.html_wdir/html.png b-div.html_wdir/ref.png b-div.html_wdir/diff.png ++ diffcount='0 (0)' ++ '[' '0 (0)' = 0 ']' ++ echo FAIL +FAIL +``` + +So we simply take the first one.
\ No newline at end of file diff --git a/416/index.md b/416/index.md new file mode 100644 index 0000000..d7ffad1 --- /dev/null +++ b/416/index.md @@ -0,0 +1,6 @@ +Title: Fix webp and brotli status variable in configure +Author: rodarima +Created: Sun, 29 Jun 2025 13:04:23 +0000 +State: closed + +We are interested in webp_ok and brotli_ok which indicates if we can use webp or brotli. Even if the user specifies `--enable-webp` setting enable_webp to yes, if it is not found it won't be available.
\ No newline at end of file diff --git a/417/index.md b/417/index.md new file mode 100644 index 0000000..d0136de --- /dev/null +++ b/417/index.md @@ -0,0 +1,38 @@ +Title: Google search +Author: ismaell +Created: Thu, 03 Jul 2025 06:01:31 +0000 +State: closed + +Google can still be used without javascript by pretending to be another browser, like W3M. + +--%-- +From: ismaell +Date: Thu, 03 Jul 2025 06:03:03 +0000 + +The search engine was removed by commit ab78cb4b3db6d63cb8da5a9d1390c2b6e50e69af. + +Tested with 'User-Agent: w3m/0.5.3' over HTTP and HTTPS. + +Perhaps ask Google to deliver this legacy page for Dillo too? + +--%-- +From: rodarima +Date: Thu, 03 Jul 2025 08:06:10 +0000 + +> Google can still be used without javascript by pretending to be another browser, like W3M. + +I know, but is a matter of time they ban them as well as bots become aware. I would recommend not disclosing this to protect those browsers that still work. They need to add our user agent to their OK list. + +> Perhaps ask Google to deliver this legacy page for Dillo too? + +I already asked via the "official" channel and got AI-walled (#338). There is also another attempt [here](https://support.google.com/websearch/thread/318978583), but again it seems to be just AI on the other side. You will need to find a way to send a message to their engineers directly. + +Notice you can add it yourself to the list of search engines by tweaking the configuration file. However, I would recomend reducing our dependency on Google and using alternative search engines not funded by advertising. + +In case their are listening, a better way of dealing with bots is to add a dynamic proof of work like Tor is doing, which is embedded directly on the TLS protocol so all tools transparently inherit the benefits, without all the JS non-sense. See https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/ and https://nlnet.nl/project/TLS-Client-PoW/. + +--%-- +From: rodarima +Date: Mon, 07 Jul 2025 21:26:50 +0000 + +Closing until they don't unblock Dillo.
\ No newline at end of file diff --git a/418/index.md b/418/index.md new file mode 100644 index 0000000..9c5c8c9 --- /dev/null +++ b/418/index.md @@ -0,0 +1,36 @@ +Title: Child combinator ignores <fieldset> +Author: ewpacol +Created: Fri, 04 Jul 2025 17:14:10 +0000 +State: open + +Tested with Dillo 3.2.0 on Fedora 42 via WSL 2.5.9.0 + +With the sample document: + +```html +<!DOCTYPE html> +<html lang="en"> +<head> + <meta charset="UTF-8"> + <style> + body > p { + color: blue; + } + </style> + <title>Document</title> +</head> +<body> + <p>Body paragraph</p> + <div> + <p>Div paragraph</p> + </div> + <fieldset> + <p>Fieldset paragraph</p> + </fieldset> +</body> +</html> +``` + +Only the first paragraph should be blue since it is the only child `<p>` of `<body>`. Dillo also colors the paragraph within `<fieldset>`. + +<img width="790" height="140" alt="<fieldset> bug demo" src="https://github.com/user-attachments/assets/8bc1920b-875e-4b85-a0c0-9fc16cadc410" />
\ No newline at end of file diff --git a/419/index.md b/419/index.md new file mode 100644 index 0000000..48a8412 --- /dev/null +++ b/419/index.md @@ -0,0 +1,12 @@ +Title: Detect IPv6 support at configure time +Author: rodarima +Created: Fri, 11 Jul 2025 20:22:12 +0000 +State: closed + +Adds a new configure test to detect if libc supports IPv6, **NOT if the current network supports IPv6**. + +At runtime, hosts that are only reachable via IPv6 when the support is enabled but the network doesn't support IPv6 will result in an inmediate error to connect that is displayed in the status bar. All IPs returned from the DNS are tested, and IPv4 seems to always be tested first. So I don't think we need to explictly disable IPv6 with a config option in dillorc, but we could add it later if we encounter problems. + +This change effectively **enables support for IPv6 by default** when Dillo is built in a platform that has IPv6 support, which is most of them. Users can override the detection and explicitly set the outcome by using `--enable-ipv6` or `--disable-ipv6`. + +Fixes #167
\ No newline at end of file diff --git a/42/index.md b/42/index.md new file mode 100644 index 0000000..11bfd4d --- /dev/null +++ b/42/index.md @@ -0,0 +1,6 @@ +Title: Add FreeBSD to the CI +Author: rodarima +Created: Thu, 28 Dec 2023 00:22:53 +0000 +State: closed + +Fixes #41
\ No newline at end of file diff --git a/420/index.md b/420/index.md new file mode 100644 index 0000000..0d01e48 --- /dev/null +++ b/420/index.md @@ -0,0 +1,10 @@ +Title: Show an error page in the canvas +Author: rodarima +Created: Fri, 11 Jul 2025 22:53:30 +0000 +State: open + +Instead of having to rely on the console log or the status bar to provide extra details, we can also display an internal page that explains what problem prevented the current page from loading so it is more user friendly. + +We can use a internal page like `about:error` so it is visible on the location bar that is coming from Dillo and not a website. Additional information like the URL and other messages can be passed in a POST request, so it is not exposed in the URL. + +We need to make sure that pages cannot embed, redirect or link to an error page, similar to DPI links.
\ No newline at end of file diff --git a/421/index.md b/421/index.md new file mode 100644 index 0000000..0b1abe2 --- /dev/null +++ b/421/index.md @@ -0,0 +1,6 @@ +Title: Document and group developer options in configure +Author: rodarima +Created: Sat, 12 Jul 2025 15:22:55 +0000 +State: closed + +Make sure they are not used accidentally by users.
\ No newline at end of file diff --git a/422/index.md b/422/index.md new file mode 100644 index 0000000..dd4b6fd --- /dev/null +++ b/422/index.md @@ -0,0 +1,13 @@ +Title: Protect against compression bomb +Author: rodarima +Created: Sat, 26 Jul 2025 11:02:43 +0000 +State: open + +Dillo will try to uncompress the complete HTML, which likely will cause it to run out of memory: + +https://ache.one/notes/html_zip_bomb (safe to open) +``` +https://ache.one/bomb.html (will likely crash your browser) +``` + +I think this could be prevented by capping the maximum Content-Length we would display before a question is asked to continue. However, this won't work if the server doesn't provide the header. Ideally we should cap this at the decoder.
\ No newline at end of file diff --git a/423/index.md b/423/index.md new file mode 100644 index 0000000..f5e73fa --- /dev/null +++ b/423/index.md @@ -0,0 +1,9 @@ +Title: Add NetBSD default path for CA certificate bundle +Author: rodarima +Created: Sun, 27 Jul 2025 18:36:27 +0000 +State: closed + +In NetBSD the default CA certificate bundle for OpenSSL is located at `/etc/openssl/certs/ca-certificates.crt`, so we include it in the default search list so it works out of the box. + +See: https://man.netbsd.org/certctl.8#FILES +See: https://wiki.netbsd.org/certctl-transition/
\ No newline at end of file diff --git a/424/index.md b/424/index.md new file mode 100644 index 0000000..e15cddc --- /dev/null +++ b/424/index.md @@ -0,0 +1,14 @@ +Title: Handle OpAbort from DPI CCC server side +Author: rodarima +Created: Fri, 01 Aug 2025 21:37:10 +0000 +State: closed + +When loading http://elpis.ws and then the issue 10, several images are requested via the data: URL which in turn causes many calls to the DPI datauri plugin, and it seems some may fail. When the DPI server fails to reply, an OpAbort is received by the CCC, but is ignored when it comes from the server side. This leaves the connection entry stale, and when navigating backwards, an attempt to read a free chunk of memory causes a crash. + +Instead of ignoring the OpAbort, we handle it as if the CCC had received an OpEnd event, which propagates the received operation to the chain and then removes the connection. + +--%-- +From: turboblack +Date: Tue, 05 Aug 2025 06:43:10 +0000 + +I am very surprised that Dillo developers read our humble magazine. Well, it is an honor.
\ No newline at end of file diff --git a/425/index.md b/425/index.md new file mode 100644 index 0000000..fa353a2 --- /dev/null +++ b/425/index.md @@ -0,0 +1,10 @@ +Title: Add about:cache and about:dicache internal pages +Author: rodarima +Created: Sun, 03 Aug 2025 13:55:01 +0000 +State: closed + +These internal pages show the statistics on the current state of the network cache and decompressed image cache (dicache). + +<img width="45%" alt="about-cache" src="https://github.com/user-attachments/assets/1906d695-c6e8-4732-b80e-e9d71f2f6a7b" /> + +<img width="45%" alt="about-dicache" src="https://github.com/user-attachments/assets/07de36a5-5916-4643-808a-1db828f82e63" />
\ No newline at end of file diff --git a/426/index.md b/426/index.md new file mode 100644 index 0000000..d7269d4 --- /dev/null +++ b/426/index.md @@ -0,0 +1,6 @@ +Title: Focus the N-th tab with Alt-<number> +Author: rodarima +Created: Mon, 04 Aug 2025 19:54:10 +0000 +State: closed + +Allows jumping directly to a given tab. It encourages a low number of tabs opened, otherwise it will exceed the 1 to 10 range.
\ No newline at end of file diff --git a/427/index.md b/427/index.md new file mode 100644 index 0000000..a2a681d --- /dev/null +++ b/427/index.md @@ -0,0 +1,6 @@ +Title: Middle click in Home or Book opens in new tab +Author: rodarima +Created: Mon, 04 Aug 2025 21:09:50 +0000 +State: closed + +Open the Home page or the Bookmarks in a new tab if the button is pressed with middle-click, following the same behavior for hyperlinks.
\ No newline at end of file diff --git a/428/index.md b/428/index.md new file mode 100644 index 0000000..ca10e34 --- /dev/null +++ b/428/index.md @@ -0,0 +1,16 @@ +Title: Search for fltk-config1.3 before fltk-config +Author: rodarima +Created: Fri, 08 Aug 2025 17:03:55 +0000 +State: closed + + +Arch Linux has changed the default FLTK version to 1.4 and the +fltk-config program for 1.3 is renamed to fltk-config1.3. + +See: https://gitlab.archlinux.org/archlinux/packaging/packages/fltk1.3/-/raw/e04fd1461dc0b6919cacfeee80a432893a4acd69/fltk1.3-1.3.11-integration.patch + +--%-- +From: rodarima +Date: Tue, 12 Aug 2025 20:00:38 +0000 + +Merged in https://github.com/dillo-browser/dillo/commit/b88506f619950640a7ea0dc3a1f615dc71068674
\ No newline at end of file diff --git a/429/index.md b/429/index.md new file mode 100644 index 0000000..2efb7e9 --- /dev/null +++ b/429/index.md @@ -0,0 +1,253 @@ +Title: Dillo 3.2.0: view source consistently freezes +Author: mbuechse +Created: Mon, 11 Aug 2025 10:29:45 +0000 +State: closed + +On Alpine: + +```shell +$ dillo file:/usr/share/doc/dillo/user_help.html +paths: Cannot open file '/home/mbue/.dillo/keysrc': No such file or directory +paths: Using /etc/dillo/keysrc +paths: Cannot open file '/home/mbue/.dillo/domainrc': No such file or directory +paths: Using /etc/dillo/domainrc +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.5.1 1 Jul 2025 +Disabling cookies. +paths: Cannot open file '/home/mbue/.dillo/hsts_preload': No such file or directory +paths: Using /etc/dillo/hsts_preload +Nav_open_url: new url='file:/usr/share/doc/dillo/user_help.html' +Nav_open_url: new url='dpi:/vsource/:file:/usr/share/doc/dillo/user_help.html' +^C + +$ ps -elf | grep vsource + 8695 mbue 0:06 /usr/lib/dillo/dpi/vsource/vsource.filter.dpi + 8727 mbue 0:00 grep vsource + +$ kill 8695 +``` + +The filter runs at a high CPU usage, causing my laptop's fan to spin up, but it doesn't produce anything. + +--%-- +From: rodarima +Date: Mon, 11 Aug 2025 11:34:02 +0000 + +Thanks for the report, but I cannot reproduce it here. Can you record a trace of the `vsource.filter.dpi` program with strace during the issue? Something like: + +``` +$ strace -o strace.log -s 500 -p $(pidof vsource.filter.dpi) +(wait a few seconds, then Ctrl+C to stop) +``` + +Then attach the strace.log file here. + +--%-- +From: mbuechse +Date: Mon, 11 Aug 2025 12:16:26 +0000 + +Thanks for the precise instructions! I'm afraid the file came out empty. +I could only start strace after I had opened the source view, because otherwise there was no process to attach to. +And then, apparently, nothing happened. +I will give it more time (longer than a few seconds). + +--%-- +From: mbuechse +Date: Mon, 11 Aug 2025 12:19:40 +0000 + +A quick check with `gdb` + +```shell +# gdb -p $(pidof vsource.filter.dpi) +GNU gdb (GDB) 15.2 +Copyright (C) 2024 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-alpine-linux-musl". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word". +Attaching to process 18067 +Reading symbols from /usr/lib/dillo/dpi/vsource/vsource.filter.dpi... +(No debugging symbols found in /usr/lib/dillo/dpi/vsource/vsource.filter.dpi) +Reading symbols from /lib/ld-musl-x86_64.so.1... +Reading symbols from /usr/lib/debug//lib/ld-musl-x86_64.so.1.debug... +printf_core (f=f@entry=0x7ffd23d137e0, + fmt=fmt@entry=0x55ad401ec073 "\n<html><head>\n<title>Source for %s</title>\n<style type=\"text/css\">\n body {\n white-space: pre-wrap;\n font-family: monospace;\n margin: 0;\n width: 100%;\n }\n table { border:0 }\n td.num {\n "..., ap=ap@entry=0x7ffd23d13648, + nl_arg=nl_arg@entry=0x7ffd23d136e0, nl_type=nl_type@entry=0x7ffd23d13660) + at src/stdio/vfprintf.c:457 + +warning: 457 src/stdio/vfprintf.c: No such file or directory +``` + +--%-- +From: rodarima +Date: Mon, 11 Aug 2025 12:20:58 +0000 + +Thanks!, can you share the backtrace with `bt`? + +--%-- +From: mbuechse +Date: Mon, 11 Aug 2025 12:26:29 +0000 + +Sure. It doesn't tell much, I'm afraid. + +```text +(gdb) bt +#0 printf_core (f=f@entry=0x7ffd23d137e0, + fmt=fmt@entry=0x55ad401ec073 "\n<html><head>\n<title>Source for %s</title>\n<style type=\"text/css\">\n body {\n white-space: pre-wrap;\n font-family: monospace;\n margin: 0;\n width: 100%;\n }\n table { border:0 }\n td.num {\n "..., ap=ap@entry=0x7ffd23d13648, + nl_arg=nl_arg@entry=0x7ffd23d136e0, nl_type=nl_type@entry=0x7ffd23d13660) + at src/stdio/vfprintf.c:457 +#1 0x00007f5de41c9100 in vfprintf (f=f@entry=0x7ffd23d137e0, + fmt=0x55ad401ec073 "\n<html><head>\n<title>Source for %s</title>\n<style type=\"text/css\">\n body {\n white-space: pre-wrap;\n font-family: monospace;\n margin: 0;\n width: 100%;\n }\n table { border:0 }\n td.num {\n "..., ap=<optimized out>) at src/stdio/vfprintf.c:690 +#2 0x00007f5de41c95af in vsnprintf (s=<optimized out>, n=<optimized out>, + fmt=<optimized out>, ap=<optimized out>) at src/stdio/vsnprintf.c:49 +#3 0x000055ad401eae98 in ?? () +#4 0x000055ad401eafb5 in ?? () +#5 0x000055ad401e9673 in ?? () +#6 0x000055ad401e91ac in ?? () +#7 0x00007f5de41a7496 in libc_start_main_stage2 (main=0x55ad401e9030, + argc=1, argv=0x7ffd23d13b78) at src/env/__libc_start_main.c:95 +#8 0x000055ad401e925d in ?? () +#9 0x0000000000000001 in ?? () +#10 0x00007ffd23d14beb in ?? () +#11 0x0000000000000000 in ?? () +``` + +--%-- +From: rodarima +Date: Mon, 11 Aug 2025 12:31:32 +0000 + +Based on the fact that you are not walking through any syscall, it looks that you may be looping here: + +https://github.com/dillo-browser/dillo/blob/v3.2.0/dlib/dlib.c#L407-L432 + +There may be a corner case for that particular size of the buffer that is causing it to never be able to find a suitable size for that string. + +Are you able to view the source code of other pages which have a different title? For example `about:splash`? + +--%-- +From: mbuechse +Date: Mon, 11 Aug 2025 12:40:54 +0000 + +No, other pages don't work either. Maybe it's connected to musl? +https://git.musl-libc.org/cgit/musl/tree/src/stdio/vsnprintf.c?h=v1.2.5 + +--%-- +From: rodarima +Date: Mon, 11 Aug 2025 13:16:25 +0000 + +Maybe. We can confirm that it is the case by adding these debug statements: + +```diff +diff --git a/dlib/dlib.c b/dlib/dlib.c +index 2cbd083e..801d8abc 100644 +--- a/dlib/dlib.c ++++ b/dlib/dlib.c +@@ -402,6 +402,8 @@ void dStr_vsprintfa (Dstr *ds, const char *format, va_list argp) + { + int n, n_sz; + ++ fprintf(stderr, "dStr_vprintfa: enter ds->len=%d, ds->sz=%d\n", ds->len, ds->sz); ++ + if (ds && format) { + va_list argp2; /* Needed in case of looping on non-32bit arch */ + while (1) { +@@ -428,9 +430,13 @@ void dStr_vsprintfa (Dstr *ds, const char *format, va_list argp) + n_sz = ds->sz * 2; + } + #endif ++ fprintf(stderr, "dStr_vprintfa: resizing, n=%d, n_sz=%d, keep=%d\n", ++ n, n_sz, (ds->len > 0) ? 1 : 0); + dStr_resize(ds, n_sz, (ds->len > 0) ? 1 : 0); + } + } ++ ++ fprintf(stderr, "dStr_vprintfa: exit ds->len=%d, ds->sz=%d\n", ds->len, ds->sz); + } + + /** +``` + +[debug-dlib.patch.txt](https://github.com/user-attachments/files/21715372/debug-dlib.patch.txt) + +You will need *first remove the current dillo 3.2.0* and then build it from source. I suggest trying with the tip of master, as it should be reproducible there: + + +``` +git clone https://github.com/dillo-browser/dillo.git +cd dillo +git apply < debug-dlib.patch.txt +./autogen.sh +mkdir build +cd build +../configure CFLAGS='-Og -g' CXXFLAGS='-Og -g' +make +doas make install # must be installed! +dpidc stop +``` + +Then try again, if it fails, it will start looping on the "dStr_vprintfa: resizing" line. We will see also which size parameter is causing it to loop. + +--%-- +From: rodarima +Date: Mon, 11 Aug 2025 13:31:49 +0000 + +Oh, I see what may be going on: + +https://github.com/dillo-browser/dillo/blob/b88506f619950640a7ea0dc3a1f615dc71068674/dpi/vsource.c#L127 + +That should be `%%` as otherwise is a printf format. It must be confusing musl. + +--%-- +From: mbuechse +Date: Mon, 11 Aug 2025 13:33:56 +0000 + +> That should be %% as otherwise is a printf format + +I won't be able to build and test until the evening (in 5 hrs maybe). Then I could test this hypothesis as well, while I'm at it. + +--%-- +From: rodarima +Date: Mon, 11 Aug 2025 13:38:57 +0000 + +Thanks, I tested this on my old RPI 2 with Alpine and it seems to be the case: + +``` +berry:~$ cat a.c +#include <stdio.h> + +int main() +{ + char buf[16]; + const char *fmt = "oops%;"; + int n = snprintf(buf, 16, fmt, "trash"); + printf("n=%d\n", n); + + return 0; +} +berry:~$ gcc a.c -o a +berry:~$ ldd ./a + /lib/ld-musl-armhf.so.1 (0x76f72000) + libc.musl-armv7.so.1 => /lib/ld-musl-armhf.so.1 (0x76f72000) +berry:~$ ./a +n=-1 +``` + +It always fails with -1, so it assumes that is the old glibc behavior so it keeps expanding the buffer thinking that the problem is that it is not big enough. + +I'll open a PR shortly. + +--%-- +From: mbuechse +Date: Mon, 11 Aug 2025 18:50:10 +0000 + +That was really quick. Thank you very much!
\ No newline at end of file diff --git a/429/meta b/429/meta new file mode 100644 index 0000000..1b9c8bd --- /dev/null +++ b/429/meta @@ -0,0 +1,4 @@ +title="Dillo 3.2.0: view source consistently freezes" +state=Closed +created="Aug 11, 2025, 12:29 PM GMT+2" +author=mbuechse diff --git a/43/index.md b/43/index.md new file mode 100644 index 0000000..f17b404 --- /dev/null +++ b/43/index.md @@ -0,0 +1,17 @@ +Title: Automatically jump to next page following rel="next" +Author: rodarima +Created: Fri, 29 Dec 2023 12:30:26 +0000 +State: open + +From https://web.archive.org/web/20151009110324/http://lists.dillo.org/pipermail/dillo-dev/2011-October/009123.html: + +> midori has a nice feature which really would be a nice addition to dillo. From the midori webpage: +> +> "Many people don't know about a nitfy feature in Midori, which is going Forward to the next page. From now on you can hit Space at the bottom of a page to go to the next page, just like in a mail client. Note that this depends on the page. Pages with links labelled "Next" or similar will be recognized. Ideally ‘rel="next"’ is used in the HTML so Midori knows what the next page is." +> +> It would be nice if dillo had it too, on low-end systems where using mouse is at a premium. +> +> Alternatively, can keybindings be made to mimic this (and similar features)? +> +> Many thanks, +> T
\ No newline at end of file diff --git a/430/index.md b/430/index.md new file mode 100644 index 0000000..9cd97bf --- /dev/null +++ b/430/index.md @@ -0,0 +1,8 @@ +Title: Escape CSS % in printf format +Author: rodarima +Created: Mon, 11 Aug 2025 13:44:17 +0000 +State: closed + +The `%` symbol causes a printf format for `%;` which fails in musl, causing the loop in `dStr_vprintfa()` to continue expading the buffer. + +Fixes: https://github.com/dillo-browser/dillo/issues/429
\ No newline at end of file diff --git a/431/index.md b/431/index.md new file mode 100644 index 0000000..5cdc2ad --- /dev/null +++ b/431/index.md @@ -0,0 +1,6 @@ +Title: Fix internal page leak +Author: rodarima +Created: Tue, 12 Aug 2025 18:31:03 +0000 +State: closed + +A copy of the buffer is done while injecting the content for about:cache and about:dicache, so the Dstr needs to be free'd after.
\ No newline at end of file diff --git a/432/index.md b/432/index.md new file mode 100644 index 0000000..5e24ca7 --- /dev/null +++ b/432/index.md @@ -0,0 +1,6 @@ +Title: Add mojeek search engine +Author: rodarima +Created: Tue, 12 Aug 2025 19:58:47 +0000 +State: closed + +See: https://en.wikipedia.org/wiki/Mojeek
\ No newline at end of file diff --git a/433/index.md b/433/index.md new file mode 100644 index 0000000..1b9aff1 --- /dev/null +++ b/433/index.md @@ -0,0 +1,114 @@ +Title: Form inputs are not hidden with display:none +Author: rodarima +Created: Sat, 23 Aug 2025 13:05:33 +0000 +State: closed + +Most form elements are not hidden with `display: none`. This causes weird elements to appear in many pages that try to hide a container with forms like the Wikipedia: + +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/7de5e40e-79e8-4658-b28c-a057bf2a5ccf" /> + +A side effect of fixing this problem would seem to cause the search bar to dissapear, but that is a different issue. I would still be reachable by disabling remote CSS. + +Reproducer: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test CSS margin auto</title> + <style> + div {height:100px} + .container { display: none; } + .child {width:100px; background: brown; margin:auto } + form { border: solid 1px blue; } + </style> + </head> + <body> + <hr> + <p>There are some elements below, but you shouldn't see any. Disable CSS to + see them.</p> + <!-- inherited from container --> + <div class="container"> + <form method="POST" enctype="multipart/form-data"> + + <label for="text">First name:</label> + <input type="text" id="text" name="text"> + <label for="cars">Choose a car:</label> + <select id="cars" name="cars"> + <option value="volvo">Volvo</option> + <option value="saab">Saab</option> + <option value="fiat">Fiat</option> + <option value="audi">Audi</option> + </select> + <textarea name="message" rows="10" cols="30"> + The cat was playing in the garden. + </textarea> + <input type="submit" id="submit" name="submit" value="Submit!"> + <input type="reset" id="reset" name="reset" value="Reset!"> + <input type="file" id="file" name="file" value="Select file..."> + <label> + <input type="checkbox" id="checkbox" name="checkbox" value=""> + Select me! + </label> + <input type="hidden" id="hidden" name="hidden" value="Hidden value"> + <button>Hello</button> + </form> + </div> + <hr> + <p>The ones below are outside the form</p> + <input style="display: none" type="text" name="out-text"> + </body> +</html> + +``` + +It seems to be a provision for hidding elements, namely `setDisplayable(false)`, but it is implemented in `FltkResource::setDisplayed`: + +https://github.com/dillo-browser/dillo/blob/f3e50968d86cd3f54f6d274a5abe72094cafd19d/dw/fltkui.cc#L525 + +Which is one of the two classes that elements inherit from. It is also implemented for the generic Resource: + +https://github.com/dillo-browser/dillo/blob/f3e50968d86cd3f54f6d274a5abe72094cafd19d/dw/ui.cc#L274 + +Which does nothing. Given the multiple inheritance, it seems the generic method is being called, which causes elements to not be hidden. + +The exception is FltkEntryResource::setDisplayed which defines its own, and it is properly handled: + +https://github.com/dillo-browser/dillo/blob/f3e50968d86cd3f54f6d274a5abe72094cafd19d/dw/fltkui.cc#L933 + +We would need to build the hierarchy of elements even if they are hidden as otherwise forms won't send all the values on submission. Elements are being created on tag open (before display_none is considered) and not in tag content. This makes all the elements always visible. + +A primitive solution is to redefine setDisplayed for each input, which seems to work more or less ok, but I would like for the generic FltkEntryResource::setDisplayed() method to be called. So far I was not able to make it work. + +Elements not only need to be hidden, but they must not take any space. We need to make sure the allocation returns a zero area size for all elements. + +--%-- +From: rodarima +Date: Sat, 23 Aug 2025 13:33:46 +0000 + +So, there are two issues here: + +- Input elements need to hide. This is relatively easy. +- Input elements need to have a zero allocation and not be able to have any interation. Not so easy, and we would need to have a way of debugging where they are, as they wil be hidden. + +--%-- +From: rodarima +Date: Sun, 24 Aug 2025 15:11:54 +0000 + +Managed to get rid of the input elements, but they are still added to the form. I should add a test to make sure that we continue to send the values properly. There is some blank space, but not sure where it is coming from: + +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/0c471bd8-be7d-4ab2-b549-7e7c26f28406" /> + +The margin is quite large: + +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/12cb2190-458f-4881-abfd-12e13df0afde" /> + +--%-- +From: rodarima +Date: Sun, 24 Aug 2025 15:45:55 +0000 + +The big margin seems to be a side effect of another problem, the navigation bar should be placed below the title, but it fails to appear. This is not related to this issue, so it should be covered in another one. This rule fixes it: + +```css +.vector-column-end { margin-top: 0 !important } +```
\ No newline at end of file diff --git a/434/index.md b/434/index.md new file mode 100644 index 0000000..9658247 --- /dev/null +++ b/434/index.md @@ -0,0 +1,38 @@ +Title: Fix hidden form inputs +Author: rodarima +Created: Sun, 24 Aug 2025 16:30:17 +0000 +State: closed + +Handle display:none properly for form elements. This is specially notable in the wikipedia. + +Fixes #433 + +--%-- +From: rodarima +Date: Sun, 24 Aug 2025 17:06:34 +0000 + +This is causing leaks due to elements being outside the tree. We need to find a way to clean them as well. + +--%-- +From: rodarima +Date: Sat, 30 Aug 2025 14:31:19 +0000 + +> This is causing leaks due to elements being outside the tree. We need to find a way to clean them as well. + +Managed to avoid creating new Embed and Resource elements, so there is no need to release them. + +Let's make sure the memory leaks are first detected and then fixed on the CI. + +--%-- +From: rodarima +Date: Sat, 30 Aug 2025 14:37:49 +0000 + +Fails as expected: https://github.com/dillo-browser/dillo/actions/runs/17344978575/job/49243747678?pr=434 + +> ==== Total leaks after filter: 51 ==== + +--%-- +From: rodarima +Date: Sat, 30 Aug 2025 20:41:02 +0000 + +No leaks detected, seems to be working fine now.
\ No newline at end of file diff --git a/435/index.md b/435/index.md new file mode 100644 index 0000000..2779030 --- /dev/null +++ b/435/index.md @@ -0,0 +1,6 @@ +Title: Add leak checks to CI +Author: rodarima +Created: Sun, 24 Aug 2025 17:08:08 +0000 +State: closed + +We should be able to pass the HTML test suite without leaking anything. This is not enough for detecting all leaks but it would catch the easy ones.
\ No newline at end of file diff --git a/436/index.md b/436/index.md new file mode 100644 index 0000000..cb4cf8f --- /dev/null +++ b/436/index.md @@ -0,0 +1,6 @@ +Title: Detect memory leaks in CI +Author: rodarima +Created: Sun, 24 Aug 2025 22:19:12 +0000 +State: closed + +Fixes #435
\ No newline at end of file diff --git a/437/index.md b/437/index.md new file mode 100644 index 0000000..d632979 --- /dev/null +++ b/437/index.md @@ -0,0 +1,8 @@ +Title: Fix hr width exceeding available space +Author: rodarima +Created: Sun, 31 Aug 2025 12:32:42 +0000 +State: closed + +The hr ruler was directly using the available content width to compute its allocation. However, the width needs to take into account the border of the hr element (1 pixel on each side) to avoid making the element larger than the available space. + +Co-authored-by: dogma
\ No newline at end of file diff --git a/438/index.md b/438/index.md new file mode 100644 index 0000000..4bad9ff --- /dev/null +++ b/438/index.md @@ -0,0 +1,19 @@ +Title: Assertion `refHeight != -1 || refWidget != NULL' failed +Author: rodarima +Created: Sun, 31 Aug 2025 16:55:06 +0000 +State: open + +When opening two `about:splash` tabs in Dillo, then resizing the window to the minimum size, the following assert fails: + +``` +hop% dillo about:splash about:splash +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.5.1 1 Jul 2025 +Enabling cookies as from cookiesrc... +Nav_open_url: new url='about:splash' +Nav_open_url: new url='about:splash' +dillo: ../../dw/widget.cc:1047: int dw::core::Widget::calcHeight(dw::core::style::Length, bool, int, dw::core::Widget*, bool): Assertion `refHeight != -1 || refWidget != NULL' failed. +[1] 2822457 IOT instruction src/dillo about:splash about:splash +``` + +It seems the viewport height goes below 0, and it interprets it as if the height is not set, which violates the precondition that either the height or the refWidget must be known. Reproduced on current master (47ab7c704f415454fb3c908f9fe0bdebb3239ef3) and v3.2.0.
\ No newline at end of file diff --git a/439/index.md b/439/index.md new file mode 100644 index 0000000..a8ba9d5 --- /dev/null +++ b/439/index.md @@ -0,0 +1,18 @@ +Title: Roadmap for FLTK 1.4 +Author: rodarima +Created: Sun, 31 Aug 2025 22:29:08 +0000 +State: open + +**This is an internal issue so I can organize myself (do not comment here, open another issue if you have a problem or suggestion).** + +There are several problems we need to solve, and not sure if it would be a good idea to wait until they are all solved before we integrate FLTK 1.4 support. + +First, we need to test many combinations of FLTK build configurations. We need at least support for X11, Wayland and Mac OS. Each backend can use cairo or not, depending on which. And on top of that, there is Pango vs Xft, which cause different font rendering issues. + +Apart from the backend, there is the issue of the High DPI screens. There are several problems that come from it. First, screens may report the wrong size so it would be a good idea to have a calibration method, so we know 1 cm of CSS is 1 cm in the physical world. Apart from this, the screen may have been configured wrongly (a 120 DPI display is configured as 96 DPI). Even if the screen is well configured, if the DPI is slightly higher than 96 (less than 10%) it will be clamped to 96 DPI by FLTK, which will cause issues when trying to render at a particular scale. + +One posible way forward is to release the support under an experimental flag, as we continue to add support for more backends and more modes of DPIs. For now, I think we can safely release X11 support with the Xft backend (no Cairo or Pango) and exclusively 96 DPI screens. So far I can see that FLTK 1.4 with 96 DPI and scale 1, using the Xft backend produces identical rendering results as FLTK 1.3.11, which is a good outcome. + +Another issue that I see is that it doesn't seem to be possible to query FLTK on which backend or which rendering engine is using. For example, Xft and Pango have different rules on how a font is matched depending on its name. + +Also, we may need to restrict which versions of FLTK 1.4 are allowed, as some issues may only be fixed in later releases. We should support the latest release 1.4.4.
\ No newline at end of file diff --git a/44/index.md b/44/index.md new file mode 100644 index 0000000..1e9ea9b --- /dev/null +++ b/44/index.md @@ -0,0 +1,61 @@ +Title: Restoration of test suite and bug tracker +Author: rodarima +Created: Sat, 30 Dec 2023 12:58:31 +0000 +State: open + +One of the parts that got lost from the dillo.org server is the test suite that was located at `dillo.org/test`, as referred from the commit messages: + +``` +commit 8c6caa83a1d686091bdf5668c4c6320ce191bb93 +Author: Jorge Arellano Cid <jcid@dillo.org> +Date: Tue Aug 9 09:23:55 2016 -0400 + + Merged commit #4653 (float clearance). + + Test case: + + <body> + <div id="a"> + <div id="b" style="float:left">main</div> + </div> + <div id="c" style="clear:left"></div> + <div id="d">footer</div> + </body> + + + Note: passes all the tests at + http://www.dillo.org/test/4648/test-suite.v1.txt +``` + +Another piece that is no longer available is the bug tracker: +``` +mio% git log | grep BUG\# + Made show_url dillorc option work again (BUG#1128) + BUG#1140: add show_ui_tooltip preference + call Fl_Window::show() from Xembed::show() to make embedding easier (BUG#1127) + Cancel the expected URL after offering a download, part 2 (BUG#982) + BUG#948 Example: hg.dillo.org ("Contact" link). + Cancel the expected URL after offering a download (BUG#982) +``` + +The last archival of the bug tracker that was not broken was this one from 2014, but none of the bugs got archived: + +https://web.archive.org/web/20140408095315/http://www.dillo.org/bugtrack/Dvolunteer.html + +Recovering those would be nice, so we can improve the current tests (which are very few) and get a list of pending issues, so we don't have to rediscover them again. + +CC @akemnade @jfhg + +--%-- +From: rodarima +Date: Sat, 30 Dec 2023 15:27:43 +0000 + +Some of the CSS tests got archived here: https://web.archive.org/web/20210727155831/https://www.dillo.org/css_compat/index.html + +I'll try to recover them. + +--%-- +From: rodarima +Date: Mon, 01 Jan 2024 16:01:15 +0000 + +Andreas managed to get the old web page running again, so I did a backup: https://archive.org/details/website.tar
\ No newline at end of file diff --git a/440/index.md b/440/index.md new file mode 100644 index 0000000..64293dc --- /dev/null +++ b/440/index.md @@ -0,0 +1,32 @@ +Title: Test font rendering in FLTK 1.4.4 with Xft backend +Author: rodarima +Created: Sun, 31 Aug 2025 22:34:36 +0000 +State: open + +So far it seems FLTK 1.3.11 vs FLTK 1.4.4 on Linux, using Xft on X11 and 96 DPI with scale overrided to 1 produces the same rendering results, all pixels are exactly the same: + +FLTK 1.3.11: +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/f90b52e8-780a-4fc0-aa70-59903826f5f5" /> + +FLTK 1.4.4: +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/714a460e-6cd6-46ae-86a2-7ebe2e6339a9" /> + +Same for the website, except the scrollbard buttons: + +FLTK 1.3.11: +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/62ae9284-f8b5-48f9-9ceb-f9fa432c997d" /> + +FLTK 1.4.4: +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/ba79f895-c12d-40d5-8d9c-3955e4e21dee" /> + +--%-- +From: rodarima +Date: Sun, 31 Aug 2025 23:50:39 +0000 + +Using Pango seems to cause blurred text: + +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/0b91f80a-27f0-44f3-ba64-6a9308534769" /> + +Here is the close up: + +<img width="2000" height="420" alt="Image" src="https://github.com/user-attachments/assets/7245f6a0-9f8f-4010-9a5d-76de69c10465" />
\ No newline at end of file diff --git a/441/index.md b/441/index.md new file mode 100644 index 0000000..da77ec5 --- /dev/null +++ b/441/index.md @@ -0,0 +1,8 @@ +Title: Missing content on fltk.org +Author: rodarima +Created: Mon, 01 Sep 2025 17:57:18 +0000 +State: open + +Loading https://www.fltk.org/newsgroups.php?s12046+gfltk.issues+v12057 on master without images and CSS cause the "Sun" part of the date to dissapear when the screen is made smaller. Similatly, loading it with CSS and images, cause the lastt image in the top to be partially visible. + +Reported-by: dogma
\ No newline at end of file diff --git a/442/index.md b/442/index.md new file mode 100644 index 0000000..495b308 --- /dev/null +++ b/442/index.md @@ -0,0 +1,10 @@ +Title: Increase location bar margin on the left side +Author: rodarima +Created: Wed, 03 Sep 2025 17:42:53 +0000 +State: closed + +One of the problems that has been bugging me for years is that the space between the [X] button and the start of the first character of the location bar is very narrow. This often causes missclicks or at least a very high time for landing the mouse in the right spot. + +<img width="780" height="580" alt="Image" src="https://github.com/user-attachments/assets/66311aee-b3f0-4581-a08d-fd81917e0eb4" /> + +Given that we are already using a custom input widget for the location bar, we may be able to add some extra space to make the selection easier.
\ No newline at end of file diff --git a/443/index.md b/443/index.md new file mode 100644 index 0000000..2322c53 --- /dev/null +++ b/443/index.md @@ -0,0 +1,12 @@ +Title: Increase horizontal margin in the location bar +Author: rodarima +Created: Wed, 03 Sep 2025 20:03:22 +0000 +State: closed + +Allows users to begin selecting the text or position the cursor at the beginning of the URL without requiring a high accuracy, as now there are at least 5 pixels of leading space. + +Fixes: https://github.com/dillo-browser/dillo/issues/442 + +See before and after: + +<img width="780" height="148" alt="dd" src="https://github.com/user-attachments/assets/a587ddef-70aa-492a-b717-fded378a38ff" />
\ No newline at end of file diff --git a/444/index.md b/444/index.md new file mode 100644 index 0000000..026add7 --- /dev/null +++ b/444/index.md @@ -0,0 +1,10 @@ +Title: Clipboard gets cleared whenever dillo closes +Author: Mineblock01 +Created: Wed, 10 Sep 2025 15:28:31 +0000 +State: open + +Whenever you copy something from dillo and close the window the clipboard clears, preserving neither what you copied nor what was already in it. +Ideally whenever dillo closes the clipboard stays inact. + +Version: Idk, I compiled from git, judging from it's behavior this (https://github.com/dillo-browser/dillo/pull/432) is the last pr that I got. +OS: Linux mint 22.1, Mate DE
\ No newline at end of file diff --git a/45/index.md b/45/index.md new file mode 100644 index 0000000..6cab34e --- /dev/null +++ b/45/index.md @@ -0,0 +1,38 @@ +Title: Restoration of the mailing list +Author: rodarima +Created: Sat, 30 Dec 2023 14:37:01 +0000 +State: open + +During the development of Dillo, there has been several mailing lists on different servers. Some of them are still available in archives of pipermail or similar web interfaces. In this issue I would like to recover as many as possible and create a single mbox file. + +| Mailing List | Period | Links | +| ------------- | ------------- | --- | +| `dillo-dev@lists.auriga.wearlab.de` | 2002-12-13 - 2007-10-09 | [mbox](https://web.archive.org/web/20071009211343/http://lists.auriga.wearlab.de/pipermail/dillo-dev.mbox/dillo-dev.mbox), [mbox mirror](https://github.com/dillo-browser/dillo/files/13798136/dillo-dev.mbox.tgz) | +| `dillo-dev@lists.auriga.wearlab.de` | 2002-12-13 - 2014-01-04 | [pipermail](https://web.archive.org/web/20140207085505/http://lists.auriga.wearlab.de/pipermail/dillo-dev/) | +| `dillo-dev@lists.auriga.wearlab.de` | 2002-11-20 - 2014-10-23 | [narkive](https://dillo-dev.auriga.wearlab.narkive.com/) | +| `dillo-dev@dillo.org` | 2002-12-13 - 2020-09-04 | [google groups](https://groups.google.com/g/dillo) | +| `dillo-dev@dillo.org` | 2002-12-13 - 2019-05-03 | [pipermail](https://web.archive.org/web/20190924044435/http://lists.dillo.org/pipermail/dillo-dev/) | + +--%-- +From: rodarima +Date: Sat, 30 Dec 2023 21:23:57 +0000 + +I managed to merge all mbox archives, but the ones from pipermail for `dillo-dev@dillo.org` are missing the attachments. + +[all.mbox.gz](https://github.com/dillo-browser/dillo/files/13799208/all.mbox.gz) + + + + +--%-- +From: rodarima +Date: Mon, 01 Jan 2024 23:49:02 +0000 + +Andreas has made an archive including the attachments. I uploaded it to the archive: https://archive.org/details/dillo-dev.tar + +--%-- +From: rodarima +Date: Sat, 01 Jun 2024 20:57:46 +0000 + +Another segment provided by pastebin: +[pastebin.mbox.gz](https://github.com/user-attachments/files/15524762/pastebin.mbox.gz)
\ No newline at end of file diff --git a/46/index.md b/46/index.md new file mode 100644 index 0000000..e26a7c3 --- /dev/null +++ b/46/index.md @@ -0,0 +1,12 @@ +Title: Add automatic rendering tests +Author: rodarima +Created: Sat, 30 Dec 2023 20:04:19 +0000 +State: closed + +These tests render a HTML page in Dillo and save a screenshot which is compared with another one rendered by a reference HTML file which doesn't make use of the feature under test. + +Running these tests require some additional dependencies to run a Xorg server and capture screenshots of the browser, so they are only enabled when configured with the --enable-html-tests option. + +Additionally, running Dillo and opening local files requires a working file dpi plugin. So, when running the HTML tests it is required that a working dpid server can be launched by Dillo. To do so, Dillo can be first installed to a prefix directory, the dpidrc file copied to ~/.dillo/ and then the DILLOBIN variable set to the path of the dillo binary under test. + +Implements #15
\ No newline at end of file diff --git a/47/index.md b/47/index.md new file mode 100644 index 0000000..5224442 --- /dev/null +++ b/47/index.md @@ -0,0 +1,107 @@ +Title: Add command line tool to control the browser +Author: rodarima +Created: Sat, 30 Dec 2023 21:03:51 +0000 +State: open + +In order to run the tests without human interaction, we need a way to drive the browser and perform some actions programmatically. These actions could be performed with a command line utility `dillocli` that connects to the dpid server. Here are some examples: + +- `dillocli open https://google.com/`: Open a new page. +- `dillocli wait [5s]`: Wait until the current page has loaded fully (maybe with a timeout). +- `dillocli geometry 100x100`: Get and change the window geometry (to test the page wrapping). +- `dillocli click submit-btn`: Click the element with the given id with the mouse. +- `dillocli hover submit-btn`: Hover the element with the given id with the mouse. +- `dillocli tls`: Get TLS information from the current page (required to test bad certificates, expired ones...). + +--%-- +From: crisdosaygo +Date: Wed, 03 Jan 2024 03:09:38 +0000 + +This will probably sound evil (because it mentions Chrome) which would seem to run counter to your project's more benevolent goals, but would it be a terrible idea to support a subset of [CDP](https://chromedevtools.github.io/devtools-protocol/tot/)? + +I [use](https://github.com/BrowserBox/BrowserBox/blob/4312247a3b949068a65ad1b1b7d3bcf900bf0db0/src/zombie-lord/connection.js#L381) this protocol for [BrowserBox](https://github.com/BrowserBox/BrowserBox) and it's just so useful. If you want a breakdown on how to understand it and work with it I'm happy to provide you that. + +I'm sure enabling CDP seems sorta like selling out. But it doesn't mean selling out, it just means speaking a common language -- sorta like HTML -- but from a developer point of view! 😄 And it's not just Cr-based browsers that use CDP, all the big ones do: even Safari and Firefox support subsets which enables them to be automated and instrumented! + +I really think it's the way to go not only for tests, but if you add CDP then tools like [pptr](https://pptr.dev/) and [playwright](https://github.com/microsoft/playwright) will be able to use Dillo, which could be a route to greatly expand its adoption, help more people contribute and get involved and generally support its goals of lowering barriers to entry by supporting older hardware and slower links! + +Regardless, the command-line tool to control the browser is a great idea and I think your current approach to creating an eloquent API (`dillocli <cmd> <selector | args>`) is gorgeous! Anyway sure you're super busy and totally get if you too busy to reply or if anything else make CDP support impossible for you -- no worries at all! -- just thanks for reading this far! + +--%-- +From: rodarima +Date: Wed, 03 Jan 2024 16:03:02 +0000 + +> This will probably sound evil (because it mentions Chrome) which would seem to run counter to your project's more benevolent goals, but would it be a terrible idea to support a subset of [CDP](https://chromedevtools.github.io/devtools-protocol/tot/)? + +I checked a bit of the details: + +``` +{"cmd":"Page.captureScreenshot","args":{"format": "jpeg"}} +``` +And https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-navigate + +But it looks gigantic, complex and full of experimental features. Keep in mind that Dillo doesn't even have a JSON parser. + +> I [use](https://github.com/BrowserBox/BrowserBox/blob/4312247a3b949068a65ad1b1b7d3bcf900bf0db0/src/zombie-lord/connection.js#L381) this protocol for [BrowserBox](https://github.com/BrowserBox/BrowserBox) and it's just so useful. If you want a breakdown on how to understand it and work with it I'm happy to provide you that. +> +> I'm sure enabling CDP seems sorta like selling out. But it doesn't mean selling out, it just means speaking a common language -- sorta like HTML -- but from a developer point of view! 😄 And it's not just Cr-based browsers that use CDP, all the big ones do: even Safari and Firefox support subsets which enables them to be automated and instrumented! + +I see the usefulness of implementing a subset too, but I don't think it would be a good starting point just yet. Currently Dillo already has its own simple protocol (which is friendly to text CLI processing tools) to manage the browser in a similar way (called the DPI protocol), and it would be much less work to expand it a bit to cover the use-cases I was think with the CLI tool. + +> I really think it's the way to go not only for tests, but if you add CDP then tools like [pptr](https://pptr.dev/) and [playwright](https://github.com/microsoft/playwright) will be able to use Dillo, which could be a route to greatly expand its adoption, help more people contribute and get involved and generally support its goals of lowering barriers to entry by supporting older hardware and slower links! +> +> Regardless, the command-line tool to control the browser is a great idea and I think your current approach to creating an eloquent API (`dillocli <cmd> <selector | args>`) is gorgeous! Anyway sure you're super busy and totally get if you too busy to reply or if anything else make CDP support impossible for you -- no worries at all! -- just thanks for reading this far! + +Thanks! I will consider it if I see that I need a more complicated protocol so other tools can interoperate. + + +--%-- +From: crisdosaygo +Date: Wed, 03 Jan 2024 17:02:17 +0000 + +Cool, man. I understand, thanks for your reply. It's really exciting to see where you will go with this, and I fully respect you taking care and stewardship of the Dillo Project! 🩵 + +> I see the usefulness of implementing a subset too, but I don't think it would be a good starting point just yet. Currently Dillo already has its own simple protocol (which is friendly to text CLI processing tools) to manage the browser in a similar way (called the DPI protocol) + +I would love the see documentation on this! Sounds fascinating 🤓 + +More generally, I think your approach espoused here of taking just the minimal necessary next steps, and avoiding unnecessary complexity is super sound, and super smart! I totally align with this and understand that decision, and I think it's the sensible way to manage yourself and ensure that you can persist with this project! That is how I handle development of my large projects as well, always pick the simple next step, maximal usefulness for minimal work, it really is the way to go! 👍🏻 ❤️ + +Thanks, again @rodarima best of luck with the Dillo! 😃 + +--%-- +From: rodarima +Date: Wed, 06 Mar 2024 09:36:45 +0000 + +I'm leaving these links as references so I don't forget: +- https://w3c.github.io/webdriver/ +- https://web-platform-tests.org/writing-tests/ + +--%-- +From: rodarima +Date: Mon, 25 Mar 2024 20:06:36 +0000 + +More ideas: when interacting with the browser we probably want to do it by using [sessions](https://w3c.github.io/webdriver/#sessions): + +```sh +$ dillocli session new +export DILLO_SESSION=1234 +$ eval $(dillocli session new) +``` +Now all the following commands will act on the same session. + +We can use the same technique to launch multiple sessions in parallel by using subshells: + +```sh +( + eval $(dillocli session new) + dillocli open ... + ... + dillocli session end +) & +( + eval $(dillocli session new) + dillocli open ... + ... + dillocli session end +) & +```
\ No newline at end of file diff --git a/48/index.md b/48/index.md new file mode 100644 index 0000000..c745729 --- /dev/null +++ b/48/index.md @@ -0,0 +1,6 @@ +Title: Missing support for CSS units: ch, rem, vw, vh... +Author: rodarima +Created: Sun, 31 Dec 2023 19:59:51 +0000 +State: closed + +Some of these units are commonly used to constraint element sizes, causing very visible rendering problems. Adding support for them shouldn't be too costly.
\ No newline at end of file diff --git a/49/index.md b/49/index.md new file mode 100644 index 0000000..166b206 --- /dev/null +++ b/49/index.md @@ -0,0 +1,121 @@ +Title: Segfault when opening https://odd.codes +Author: rodarima +Created: Mon, 01 Jan 2024 01:36:24 +0000 +State: closed + +Using OpenSSL 3.2.0. +``` +$ dillo https://odd.codes +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +Disabling cookies. +Nav_open_url: new url='https://odd.codes' +Dns_server [0]: odd.codes is 198.54.114.150 +Connecting to 198.54.114.150:443 +odd.codes: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /CN=*.web-hosting.com +sha384 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA +sha384 4096-bit RSA: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority +** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. +sha1 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +root: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +odd.codes: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /CN=*.web-hosting.com +sha384 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA +sha384 4096-bit RSA: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority +** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. +sha1 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +root: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +odd.codes: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /CN=*.web-hosting.com +sha384 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA +sha384 4096-bit RSA: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority +** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. +sha1 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +root: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +odd.codes: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /CN=*.web-hosting.com +sha384 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA +sha384 4096-bit RSA: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority +** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. +sha1 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +root: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +odd.codes: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /CN=*.web-hosting.com +sha384 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA +sha384 4096-bit RSA: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority +** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. +sha1 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +root: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +odd.codes: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /CN=*.web-hosting.com +... +odd.codes: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /CN=*.web-hosting.com +sha384 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA +sha384 4096-bit RSA: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority +** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. +sha1 2048-bit RSA: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +root: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services +odd.codes: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +[1] 806346 segmentation fault (core dumped) dillo https://odd.codes +``` + +--%-- +From: rodarima +Date: Mon, 01 Jan 2024 01:37:30 +0000 + +With mbedTLS works fine. + +--%-- +From: rodarima +Date: Mon, 01 Jan 2024 01:41:02 +0000 + +Address sanitizer reports that is a stack overflow: +``` +AddressSanitizer:DEADLYSIGNAL +================================================================= +==806820==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe7b20cb90 (pc 0x7fa4fa6e12cd bp 0x7ffe7b20d3d0 sp 0x7ffe7b20cb90 T0) + #0 0x7fa4fa6e12cd in __sanitizer::StackTrace::StackTrace(unsigned long const*, unsigned int) /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:53 + #1 0x7fa4fa6e12cd in __sanitizer::BufferedStackTrace::BufferedStackTrace() /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:113 + #2 0x7fa4fa6e12cd in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69 + #3 0x7fa4f9bd2241 in CRYPTO_malloc (/usr/lib/libcrypto.so.3+0x1d2241) (BuildId: 5a9162ecea246a6e3aca345c09b7fb5a4236f1d6) + #4 0x7fa4f9bd23fd in CRYPTO_zalloc (/usr/lib/libcrypto.so.3+0x1d23fd) (BuildId: 5a9162ecea246a6e3aca345c09b7fb5a4236f1d6) + #5 0x7fa4f9ae13fd in BIO_new_ex (/usr/lib/libcrypto.so.3+0xe13fd) (BuildId: 5a9162ecea246a6e3aca345c09b7fb5a4236f1d6) + #6 0x5652ec83ece6 in Tls_check_cert_strength IO/../../../src/IO/tls_openssl.c:459 + #7 0x5652ec83ece6 in Tls_examine_certificate IO/../../../src/IO/tls_openssl.c:828 + #8 0x5652ec83ece6 in Tls_connect IO/../../../src/IO/tls_openssl.c:1138 + #9 0x7fa4fa577c2c in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa8c2c) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #10 0x7fa4fa51a06f in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4b06f) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #11 0x7fa4fa51a161 in Fl::wait() (/usr/lib/libfltk.so.1.3+0x4b161) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #12 0x5652ec7b0d25 in a_Dialog_choice ../../src/dialog.cc:389 + #13 0x5652ec83e19d in Tls_check_cert_hostname IO/../../../src/IO/tls_openssl.c:666 + #14 0x5652ec83ef12 in Tls_examine_certificate IO/../../../src/IO/tls_openssl.c:829 + #15 0x5652ec83ef12 in Tls_connect IO/../../../src/IO/tls_openssl.c:1138 + #16 0x7fa4fa577c2c in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa8c2c) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #17 0x7fa4fa51a06f in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4b06f) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #18 0x7fa4fa51a161 in Fl::wait() (/usr/lib/libfltk.so.1.3+0x4b161) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #19 0x5652ec7b0d25 in a_Dialog_choice ../../src/dialog.cc:389 + #20 0x5652ec83e19d in Tls_check_cert_hostname IO/../../../src/IO/tls_openssl.c:666 + #21 0x5652ec83ef12 in Tls_examine_certificate IO/../../../src/IO/tls_openssl.c:829 + #22 0x5652ec83ef12 in Tls_connect IO/../../../src/IO/tls_openssl.c:1138 + #23 0x7fa4fa577c2c in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa8c2c) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #24 0x7fa4fa51a06f in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4b06f) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #25 0x7fa4fa51a161 in Fl::wait() (/usr/lib/libfltk.so.1.3+0x4b161) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #26 0x5652ec7b0d25 in a_Dialog_choice ../../src/dialog.cc:389 + #27 0x5652ec83e19d in Tls_check_cert_hostname IO/../../../src/IO/tls_openssl.c:666 + #28 0x5652ec83ef12 in Tls_examine_certificate IO/../../../src/IO/tls_openssl.c:829 + #29 0x5652ec83ef12 in Tls_connect IO/../../../src/IO/tls_openssl.c:1138 + #30 0x7fa4fa577c2c in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa8c2c) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #31 0x7fa4fa51a06f in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4b06f) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #32 0x7fa4fa51a161 in Fl::wait() (/usr/lib/libfltk.so.1.3+0x4b161) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #33 0x5652ec7b0d25 in a_Dialog_choice ../../src/dialog.cc:389 + #34 0x5652ec83e19d in Tls_check_cert_hostname IO/../../../src/IO/tls_openssl.c:666 + #35 0x5652ec83ef12 in Tls_examine_certificate IO/../../../src/IO/tls_openssl.c:829 + #36 0x5652ec83ef12 in Tls_connect IO/../../../src/IO/tls_openssl.c:1138 + #37 0x7fa4fa577c2c in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa8c2c) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #38 0x7fa4fa51a06f in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4b06f) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #39 0x7fa4fa51a161 in Fl::wait() (/usr/lib/libfltk.so.1.3+0x4b161) (BuildId: e56a0c2bbd29f4522bca2e4c3f0bc13c2dc8803a) + #40 0x5652ec7b0d25 in a_Dialog_choice ../../src/dialog.cc:389 +... +```
\ No newline at end of file diff --git a/5/index.md b/5/index.md new file mode 100644 index 0000000..684b244 --- /dev/null +++ b/5/index.md @@ -0,0 +1,56 @@ +Title: fix for gcc 10 +Author: walley +Created: Tue, 24 Jan 2023 09:11:13 +0000 +State: closed + + + +--%-- +From: rodarima +Date: Fri, 02 Jun 2023 10:39:37 +0000 + +Hi walley, thanks for the patch and sorry for the long delay, I have not +used dillo for a while. I will test the gcc 10 fix with my current +version (gcc 13.1.1). + +Can you split the tbody implementation in another MR? + +Best, Rodrigo. + + +--%-- +From: rodarima +Date: Fri, 02 Jun 2023 11:04:48 +0000 + +>I will test the gcc 10 fix with my current version (gcc 13.1.1). + +The `--enable-ssl` seems to be broken due to the API major upgrade in +mbedtls: + +``` +../../../src/IO/tls.c:52:10: fatal error: mbedtls/net.h: No such file or directory + 52 | #include <mbedtls/net.h> /* net_send, net_recv */ +``` + +It is taking the headers from mbedtls 3 instead of from the 2: + +``` +% pacman -Ql mbedtls | grep net.h +% pacman -Ql mbedtls2 | grep net.h +mbedtls2 /usr/include/mbedtls2/mbedtls/net.h +``` + +I'll try to build without SSL. + + +--%-- +From: rodarima +Date: Fri, 02 Jun 2023 11:26:45 +0000 + +Merged with 4d35673f69d837db894305f3b3b618a26d0277c7 + +--%-- +From: walley +Date: Fri, 02 Jun 2023 14:12:32 +0000 + +that tbody patch should not be here, i pushed it to wrong branch
\ No newline at end of file diff --git a/50/index.md b/50/index.md new file mode 100644 index 0000000..d599320 --- /dev/null +++ b/50/index.md @@ -0,0 +1,20 @@ +Title: Dillo Plugins +Author: dimaguy +Created: Tue, 02 Jan 2024 23:40:59 +0000 +State: open + +As discussed on Hacker News, here's the zip files with the plugins I have +[dillo-plugins.zip](https://github.com/dillo-browser/dillo/files/13814689/dillo-plugins.zip) +[dillo-plugins2.zip](https://github.com/dillo-browser/dillo/files/13814686/dillo-plugins2.zip) +[dillo-dat.zip](https://github.com/dillo-browser/dillo/files/13814697/dillo-dat.zip) + +Compared to the list you've sent, I seem to be missing zet and history, but given the OG repos are still up, should be a breeze to fetch them +Edit: almost sent an empty folder, good job Xarchiver, had to cut out node_modules from dillo-dat too + +--%-- +From: rodarima +Date: Wed, 03 Jan 2024 11:33:43 +0000 + +Thanks! I'll add then eventually to their own repositories. I leave here the link to the Hacker News discussion: + +https://news.ycombinator.com/item?id=38848464
\ No newline at end of file diff --git a/500/index.md b/500/index.md new file mode 100644 index 0000000..9681141 --- /dev/null +++ b/500/index.md @@ -0,0 +1,8 @@ +Title: Migrate issue tracker outside GitHub +Author: Rodrigo Arias Mallo +Created: Sun, 28 Sep 2025 20:22:13 +0200 +State: open + +The GitHub issue tracker has multiple issues and it doesn't work without +JavaScript. We can migrate the issues to a new issue tracker and host it +ourselves. diff --git a/501/index.md b/501/index.md new file mode 100644 index 0000000..f4d44fa --- /dev/null +++ b/501/index.md @@ -0,0 +1,40 @@ +Title: Indentation error on cgit diff +Author: Rodrigo Arias Mallo +Created: Sun, 28 Sep 2025 14:44:28 +0200 +State: open + +Indentation with tabs in cgit diff seems to be broken, elements don't get +aligned as expected. + +Here is one [example][1] for cgit which shows: + +[1]: https://git.dillo-browser.org/dillo/commit/?id=1d55cf26a355b89a007e4a9bf7361d8a5c2c64cd + +``` + render/form-display-none.html \ + render/github-infinite-loop.html \ + render/hackernews.html \ ++ render/hr.html \ + render/img-aspect-ratio-absolute.html \ + render/img-aspect-ratio-div.html \ + render/img-aspect-ratio-mix-border.html \ +``` + +Here is an inline reproducer: + +<section style="font-family: monospace; white-space: pre;"> +<div>@@ -18,6 +18,7 @@ TESTS = \</div><div> render/form-display-none.html \</div><div> render/github-infinite-loop.html \</div><div> render/hackernews.html \</div><div>+ render/hr.html \</div><div> render/img-aspect-ratio-absolute.html \</div><div> render/img-aspect-ratio-div.html \</div><div> render/img-aspect-ratio-mix-border.html \</div></section> + +It seems to be caused by the whole diff being in **one line**, as if I split the +div elements into separate lines it works fine (but adds extra empty lines). + +<section style="font-family: monospace; white-space: pre;"> +<div>@@ -18,6 +18,7 @@ TESTS = \</div> +<div> render/form-display-none.html \</div> +<div> render/github-infinite-loop.html \</div> +<div> render/hackernews.html \</div> +<div>+ render/hr.html \</div> +<div> render/img-aspect-ratio-absolute.html \</div> +<div> render/img-aspect-ratio-div.html \</div> +<div> render/img-aspect-ratio-mix-border.html \</div> +</section> diff --git a/502/index.md b/502/index.md new file mode 100644 index 0000000..7366d8c --- /dev/null +++ b/502/index.md @@ -0,0 +1,12 @@ +Title: Implement deep reload +Author: Rodrigo Arias Mallo +Created: Sun, 28 Sep 2025 16:28:42 +0200 +State: open + +When reloading a file we sometimes want to reload all the embedded files +including images or linked CSS files. We can make it so that when pressing the +reload button with a modifier, the deep reload is done. By default we keep it as +it is now. + +The SIGUSR1 should also perform a deep reload, so changes in CSS are also +taken into account. diff --git a/51/index.md b/51/index.md new file mode 100644 index 0000000..c5066fe --- /dev/null +++ b/51/index.md @@ -0,0 +1,305 @@ +Title: a_Tls_openssl_connect: Assertion `!ERR_get_error()' failed. +Author: badsectoracula +Created: Wed, 03 Jan 2024 03:09:50 +0000 +State: closed + +Trying to open a site with https causes an assertion error to kill Dillo. + +Console output from after trying to visit `lite.duckduckgo.com`: + +```Nav_open_url: new url='http://lite.duckduckgo.com' +Dns_server [0]: lite.duckduckgo.com is 40.114.177.156 +Connecting to 40.114.177.156:80 +Nav_open_url: new url='https://lite.duckduckgo.com/' +Connecting to 40.114.177.156:443 +lite.duckduckgo.com: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /C=US/ST=Pennsylvania/L=Paoli/O=Duck Duck Go, Inc./CN=*.duckduckgo.com +sha256 2048-bit RSA: /C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 +root: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 +Nav_open_url: new url='https://lite.duckduckgo.com/lite/' +Connecting to 40.114.177.156:443 +dillo: tls_openssl.c:1183: a_Tls_openssl_connect: Assertion `!ERR_get_error()' failed. +Aborted (core dumped) +``` + +Notice the **tls_openssl.c:1183** part. The [relevant line](https://github.com/dillo-browser/dillo/blob/95627efadf55c39901928ee730d22de55cdcc209/src/IO/tls_openssl.c#L1183). + +I'm using **OpenSSL 3.1.4** from **openSUSE**. This does not happen with mbedSSL though i don't think the SSL library is the issue, the linked code seems to assume there are no OpenSSL errors before entering this function, but somewhere an error is added to OpenSSL's error queue that isn't checked. + +--%-- +From: crisdosaygo +Date: Wed, 03 Jan 2024 03:20:10 +0000 + +Could be related to [this](https://news.ycombinator.com/item?id=38849994). The author talks about some possible causes and workarounds in that comment! @badsectoracula cool profile image -- classic Netscape animation! 😸 + +--%-- +From: badsectoracula +Date: Wed, 03 Jan 2024 03:25:39 +0000 + +I wrote toplevel comment and made this bug report as rodarima asked :-). + +I placed a breakpoint in OpenSSL's `ERR_put_error` function (openSUSE has debug symbol download configured for gdb) to see where that error comes from. It seems to be [this line](https://github.com/dillo-browser/dillo/blob/95627efadf55c39901928ee730d22de55cdcc209/src/IO/tls_openssl.c#L1049). Judging from the comment it used to have issues with old versions of OpenSLL? Perhaps new versions also have the same issue? Sadly there is no debug info for libssl nor i could see what error exactly was added. + +--%-- +From: crisdosaygo +Date: Wed, 03 Jan 2024 04:33:35 +0000 + +@badsectoracula seems a bit of discussion on this here: https://github.com/nodejs/node-v0.x-archive/issues/1719 + +Error queue is not drained and that thread seems to suggest draining it. 😹 + +As it's error queue it might be hard to locate the origin of anything in it. In the same file they drain it [here](https://github.com/dillo-browser/dillo/blob/95627efadf55c39901928ee730d22de55cdcc209/src/IO/tls_openssl.c#L239C1-L242C2) + + + +--%-- +From: rodarima +Date: Wed, 03 Jan 2024 11:43:00 +0000 + +Thanks for reporting it @badsectoracula + +> Perhaps new versions also have the same issue? + +I cannot reproduce it with OpenSSL 3.2.0 or 1.1.1.w (the ones I have available in Arch Linux): + +``` +% dillo 'https://lite.duckduckgo.com/' +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +Disabling cookies. +Nav_open_url: new url='https://lite.duckduckgo.com/' +Dns_server [0]: lite.duckduckgo.com is 52.142.124.215 +Connecting to 52.142.124.215:443 +lite.duckduckgo.com: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /C=US/ST=Pennsylvania/L=Paoli/O=Duck Duck Go, Inc./CN=*.duckduckgo.com +sha256 2048-bit RSA: /C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 +root: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 +peer name *.duckduckgo.com +Nav_open_url: new url='https://lite.duckduckgo.com/lite/' +Connecting to 52.142.124.215:443 +peer name *.duckduckgo.com +Layout::resizeIdle calls = 1 +``` + +Also, here my connection is not very fast so I might not be fast enough for the redirect to cause the error. I will try to link with the same version of OpenSSL in case is an issue of that specific version. + +--%-- +From: rodarima +Date: Mon, 08 Jan 2024 23:30:21 +0000 + +Cannot reproduce with OpenSSL 3.1.4 either and setting the duckduckgo host to the same IP (via /etc/hosts): +``` +% LD_LIBRARY_PATH=/home/ram/dev/dillo/misc/openssl-3.1.4/install/lib64 src/dillo lite.duckduckgo.com +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +Disabling cookies. +Nav_open_url: new url='http://lite.duckduckgo.com' +Dns_server [0]: lite.duckduckgo.com is 40.114.177.156 +Connecting to 40.114.177.156:80 +Nav_open_url: new url='https://lite.duckduckgo.com/' +Connecting to 40.114.177.156:443 +lite.duckduckgo.com: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /C=US/ST=Pennsylvania/L=Paoli/O=Duck Duck Go, Inc./CN=*.duckduckgo.com +sha256 2048-bit RSA: /C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 +root: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 +Nav_open_url: new url='https://lite.duckduckgo.com/lite/' +Connecting to 40.114.177.156:443 +Layout::resizeIdle calls = 1 +Dillo: normal exit! +``` + +This could still be explained by a race between closing the connection and the new one being opened, which in my setup occurs later. + +I checked the code and it looks that the shutdown [is not very well done](https://www.openssl.org/docs/man3.2/man3/SSL_shutdown.html), we need to do some checking before ensuring the connection is closed (at least it is recommended) and ensure there are no errors in the queue. Here is how curl closes it: https://github.com/curl/curl/blob/912d80c68019d3d9a4ceb9993a596dff8009f4d0/lib/vtls/openssl.c#L1880 + +--%-- +From: rodarima +Date: Wed, 10 Jan 2024 18:04:43 +0000 + +Managed to reproduce a similar error after shaping the bandwidth to 10KB/s and loading a big page via TLS (it takes a bit of time): + +``` +% trickle -s -d 10k -u 10k gdb --args build/src/dillo https://www.w3.org/TR/2011/WD-html5-20110405/Overview.html +... +Layout::resizeIdle calls = 104 +Layout::resizeIdle calls = 105 +Layout::resizeIdle calls = 106 +TLS ALERT on write: decode error +dillo: ../../../src/IO/tls_openssl.c:1183: a_Tls_openssl_connect: Assertion `!ERR_get_error()' failed. +``` + +Although this is failing due to an ALERT, the same assert is triggering. + +--%-- +From: rodarima +Date: Wed, 10 Jan 2024 21:52:10 +0000 + +Similar symptoms as https://groups.google.com/g/dillo/c/zMRHPF1Aa7o/ + +--%-- +From: rodarima +Date: Wed, 10 Jan 2024 22:16:23 +0000 + +> I placed a breakpoint in OpenSSL's ERR_put_error function + +Hmm, I don't think this is possible in OpenSSL 3.1.4, the ERR_put_error function has been deprecated, and it is [only defined now with a macro](https://github.com/openssl/openssl/blob/openssl-3.1.4/include/openssl/err.h.in#L396-L402). + +I suspect that you have another OpenSSL library installed, which is the one that Dillo is using and that still provides ERR_put_error() in which you have placed your breakpoint. + +You can see which OpenSSL library is loaded by using: +``` +$ ldd /usr/bin/dillo +``` + +Based on openSUSE website, they include the 1.1.1w version in the [openssl-1_1 package](https://software.opensuse.org/package/openssl-1_1). + +I will try to reproduce it with 1.1.1w again, following this hypothesis. + +Created issue #57 to prevent this situation in the future. + +--%-- +From: rodarima +Date: Thu, 11 Jan 2024 00:45:10 +0000 + +At least one of the problems is that SSL_shutdown() is trying to perform a write in the fd=7 to send a close notification, but the file descriptor was closed. This causes SSL_shutdown to return -1 (failure) and errno=6 (Bad file descriptor): + +``` +% gdb --args src/dillo duckduckgo.com +[...] +Using host libthread_db library "/usr/lib/libthread_db.so.1". +paths: Cannot open file '/home/ram/.dillo/dillorc': No such file or directory +paths: Using /home/ram/dev/dillo/git/install/etc/dillo/dillorc +Domain: Default accept. +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.2.0 23 Nov 2023 +Disabling cookies. +** WARNING **: preferred cursive font "URW Chancery L" not found. +Nav_open_url: new url='http://duckduckgo.com' +[New Thread 0x7ffff619f6c0 (LWP 134332)] +Dns_server [0]: duckduckgo.com is 52.142.124.215 +Connecting to 52.142.124.215:80 +[Thread 0x7ffff619f6c0 (LWP 134332) exited] +Nav_open_url: new url='https://duckduckgo.com/' +Connecting to 52.142.124.215:443 + +Thread 1 "dillo" hit Breakpoint 1, a_Tls_openssl_connect (fd=7, url=0x5555559ddb60) at IO/../../../src/IO/tls_openssl.c:1249 +1249 bool_t success = TRUE; +(gdb) b close +Breakpoint 2 at 0x7ffff6f1ca80 (25 locations) +(gdb) c +Continuing. +duckduckgo.com: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /C=US/ST=Pennsylvania/L=Paoli/O=Duck Duck Go, Inc./CN=*.duckduckgo.com +sha256 2048-bit RSA: /C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 +root: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 +NumPendingStyleSheets=1 +NumPendingStyleSheets=2 + +Thread 1 "dillo" hit Breakpoint 2.1, 0x00007ffff6f1ca80 in close () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff6f1ca80 in close () from /usr/lib/libc.so.6 +#1 0x00005555556100e3 in dClose (fd=7) at ../../dlib/dlib.c:954 <----------------- Notice closing fd 7 +#2 0x00005555555de2b0 in Http_socket_reuse (SKey=2) at IO/../../../src/IO/http.c:870 +#3 0x00005555555debb1 in a_Http_ccc (Op=2, Branch=2, Dir=2, Info=0x5555559dd920, Data1=0x0, Data2=0x55555566d0c1) at IO/../../../src/IO/http.c:1012 +#4 0x000055555560148c in a_Chain_bcb (Op=2, Info=0x5555559dd8d0, Data1=0x0, Data2=0x55555566d0c1) at ../../src/chain.c:137 +#5 0x0000555555609391 in a_Capi_ccc (Op=2, Branch=2, Dir=1, Info=0x5555559dd8d0, Data1=0x5555559eac70, Data2=0x555555662a18) at ../../src/capi.c:778 +#6 0x00005555556013de in a_Chain_fcb (Op=2, Info=0x5555559dd920, Data1=0x5555559eac70, Data2=0x555555662a18) at ../../src/chain.c:114 +#7 0x00005555555de8a1 in a_Http_ccc (Op=2, Branch=2, Dir=1, Info=0x5555559dd920, Data1=0x5555559eac70, Data2=0x0) at IO/../../../src/IO/http.c:964 +#8 0x00005555556013de in a_Chain_fcb (Op=2, Info=0x5555559dd970, Data1=0x5555559eac70, Data2=0x0) at ../../src/chain.c:114 +#9 0x00005555555e4e7b in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x5555559dd970, Data1=0x555555a02eb0, Data2=0x0) at IO/../../../src/IO/IO.c:454 +#10 0x00005555555e4465 in IO_read (io=0x555555a02eb0) at IO/../../../src/IO/IO.c:200 +#11 0x00005555555e46ab in IO_callback (io=0x555555a02eb0) at IO/../../../src/IO/IO.c:273 +#12 0x00005555555e4759 in IO_fd_read_cb (fd=7, data=0x3) at IO/../../../src/IO/IO.c:294 +#13 0x00007ffff7e15c2d in fl_wait(double) () from /usr/lib/libfltk.so.1.3 +#14 0x00007ffff7db8070 in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 +#15 0x00007ffff7db812a in Fl::run() () from /usr/lib/libfltk.so.1.3 +#16 0x00005555555a9c4f in main (argc=2, argv=0x7fffffffdd38) at ../../src/dillo.cc:578 +(gdb) b SSL_shutdown +Breakpoint 3 at 0x7ffff7358f60 +(gdb) c +Continuing. + +Thread 1 "dillo" hit Breakpoint 3, 0x00007ffff7358f60 in SSL_shutdown () from /usr/lib/libssl.so.3 +(gdb) up +#1 0x00005555555e167a in Tls_close_by_key (connkey=1) at IO/../../../src/IO/tls_openssl.c:1102 +1102 int ret = SSL_shutdown(c->ssl); +(gdb) p c->fd +$1 = 7 <------------------------- But later trying to perform a shutdown on it +(gdb) bt +#0 0x00007ffff7358f60 in SSL_shutdown () from /usr/lib/libssl.so.3 +#1 0x00005555555e167a in Tls_close_by_key (connkey=1) at IO/../../../src/IO/tls_openssl.c:1102 +#2 0x00005555555e2098 in a_Tls_openssl_close_by_fd (fd=7) at IO/../../../src/IO/tls_openssl.c:1328 +#3 0x00005555555df11f in a_Tls_close_by_fd (fd=7) at IO/../../../src/IO/tls.c:143 +#4 0x00005555555dc8a7 in Http_socket_free (SKey=2) at IO/../../../src/IO/http.c:318 +#5 0x00005555555de2ba in Http_socket_reuse (SKey=2) at IO/../../../src/IO/http.c:871 +#6 0x00005555555debb1 in a_Http_ccc (Op=2, Branch=2, Dir=2, Info=0x5555559dd920, Data1=0x0, Data2=0x55555566d0c1) at IO/../../../src/IO/http.c:1012 +#7 0x000055555560148c in a_Chain_bcb (Op=2, Info=0x5555559dd8d0, Data1=0x0, Data2=0x55555566d0c1) at ../../src/chain.c:137 +#8 0x0000555555609391 in a_Capi_ccc (Op=2, Branch=2, Dir=1, Info=0x5555559dd8d0, Data1=0x5555559eac70, Data2=0x555555662a18) at ../../src/capi.c:778 +#9 0x00005555556013de in a_Chain_fcb (Op=2, Info=0x5555559dd920, Data1=0x5555559eac70, Data2=0x555555662a18) at ../../src/chain.c:114 +#10 0x00005555555de8a1 in a_Http_ccc (Op=2, Branch=2, Dir=1, Info=0x5555559dd920, Data1=0x5555559eac70, Data2=0x0) at IO/../../../src/IO/http.c:964 +#11 0x00005555556013de in a_Chain_fcb (Op=2, Info=0x5555559dd970, Data1=0x5555559eac70, Data2=0x0) at ../../src/chain.c:114 +#12 0x00005555555e4e7b in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x5555559dd970, Data1=0x555555a02eb0, Data2=0x0) at IO/../../../src/IO/IO.c:454 +#13 0x00005555555e4465 in IO_read (io=0x555555a02eb0) at IO/../../../src/IO/IO.c:200 +#14 0x00005555555e46ab in IO_callback (io=0x555555a02eb0) at IO/../../../src/IO/IO.c:273 +#15 0x00005555555e4759 in IO_fd_read_cb (fd=7, data=0x3) at IO/../../../src/IO/IO.c:294 +#16 0x00007ffff7e15c2d in fl_wait(double) () from /usr/lib/libfltk.so.1.3 +#17 0x00007ffff7db8070 in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 +#18 0x00007ffff7db812a in Fl::run() () from /usr/lib/libfltk.so.1.3 +#19 0x00005555555a9c4f in main (argc=2, argv=0x7fffffffdd38) at ../../src/dillo.cc:578 +``` + +--%-- +From: badsectoracula +Date: Thu, 11 Jan 2024 04:20:13 +0000 + +> > I placed a breakpoint in OpenSSL's ERR_put_error function +> +> Hmm, I don't think this is possible in OpenSSL 3.1.4, the ERR_put_error function has been deprecated, and it is [only defined now with a macro](https://github.com/openssl/openssl/blob/openssl-3.1.4/include/openssl/err.h.in#L396-L402). +> +> I suspect that you have another OpenSSL library installed, which is the one that Dillo is using and that still provides ERR_put_error() in which you have placed your breakpoint. + +You are right, i saw i had OpenSSL installed and assumed Dillo would use "the" OpenSSL. + +Turns out i was wrong, Dillo is linked against _LibreSSL_, not OpenSSL. Specifically it is linked against **LibreSSL 3.7.0**. It links against the `libssl.so.53` and `libcrypto.so.50` shared objects which are provided by the `libssl53` and `libcrypto50` packages respectively, both of which mention they come from LibreSSL 3.7.0 in their descriptions and versions. + +So perhaps the issue happens only with LibreSSL? + + +--%-- +From: rodarima +Date: Thu, 11 Jan 2024 12:11:59 +0000 + +> You are right, i saw i had OpenSSL installed and assumed Dillo would use "the" OpenSSL. +> +> Turns out i was wrong, Dillo is linked against _LibreSSL_, not OpenSSL. Specifically it is linked against **LibreSSL 3.7.0**. It links against the `libssl.so.53` and `libcrypto.so.50` shared objects which are provided by the `libssl53` and `libcrypto50` packages respectively, both of which mention they come from LibreSSL 3.7.0 in their descriptions and versions. +> +> So perhaps the issue happens only with LibreSSL? + +It looks like. I can reproduce it with LibreSSL (now it shows which library is in use): + +``` +% src/dillo lite.duckduckgo.com +[...] +TLS library: LibreSSL 3.8.2 <------- here +Disabling cookies. +** WARNING **: preferred cursive font "URW Chancery L" not found. +Nav_open_url: new url='http://lite.duckduckgo.com' +[New Thread 0x7ffff653b6c0 (LWP 145386)] +Dns_server [0]: lite.duckduckgo.com is 40.114.177.156 +Connecting to 40.114.177.156:80 +[Thread 0x7ffff653b6c0 (LWP 145386) exited] +Nav_open_url: new url='https://lite.duckduckgo.com/' +Connecting to 40.114.177.156:443 +lite.duckduckgo.com: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 +sha256 2048-bit RSA: /C=US/ST=Pennsylvania/L=Paoli/O=Duck Duck Go, Inc./CN=*.duckduckgo.com +sha256 2048-bit RSA: /C=US/O=DigiCert Inc/CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 +root: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 +Nav_open_url: new url='https://lite.duckduckgo.com/lite/' +Connecting to 40.114.177.156:443 +dillo: ../../../src/IO/tls_openssl.c:1187: a_Tls_openssl_connect: Assertion `!ERR_get_error()' failed. + +``` + + It seems to be caused by the attempt to shutdown the session with the file descriptor closed. In OpenSSL doesn't cause an error to be added to the queue (it just returns -1) but in LibreSSL it does. I'll test a bit more my fix and prepare a PR shortly. + +Also, I never tried LibreSSL, didn't expected it to just link and run. I'll also consider adding it to the supported libraries.
\ No newline at end of file diff --git a/52/index.md b/52/index.md new file mode 100644 index 0000000..5a58985 --- /dev/null +++ b/52/index.md @@ -0,0 +1,84 @@ +Title: MacOS linker error, might need more info in the README +Author: ghovax +Created: Wed, 03 Jan 2024 09:18:12 +0000 +State: open + +When compiling with libs installed via Homebrew, I get this error that I couldn't fix (even with the way suggested on HackerNews): +``` +ld: Undefined symbols: + _iconv, referenced from: + _Decode_charset in decode.o + DilloHtmlForm::encodeText(__tag_iconv_t*, Dstr**) in form.o + _iconv_close, referenced from: + _Decode_charset_free in decode.o + DilloHtmlForm::buildQueryData(DilloHtmlInput*) in form.o + _iconv_open, referenced from: + _a_Decode_charset_init in decode.o + DilloHtmlForm::buildQueryData(DilloHtmlInput*) in form.o + DilloHtmlForm::buildQueryData(DilloHtmlInput*) in form.o +clang: error: linker command failed with exit code 1 (use -v to see invocation) +``` + +How would you suggest fixing it? Adding `LDFLAGS` `-L/opt/homebrew/opt/libiconv/lib` didn't work. + +--%-- +From: rodarima +Date: Wed, 03 Jan 2024 11:48:09 +0000 + +Could you paste the output of the "./configure" or upload the config.log file? The procedure to locate the iconv library seems to be failing in your system or we are mixing libiconv / libc iconv for some targets. + +As a workaround you could try adding `CPPFLAGS=-DLIBICONV_PLUG` to the configure arguments so libiconv uses the same API as the one in the libc. + +--%-- +From: ghovax +Date: Wed, 03 Jan 2024 12:56:32 +0000 + +I tried as you suggested, nothing changed. Here's the `config.log`: [https://pastebin.com/mEFG5fMc](https://pastebin.com/mEFG5fMc). + +--%-- +From: rodarima +Date: Mon, 08 Jan 2024 21:26:53 +0000 + +Thanks, I'll keep the log here too in case it expires: [log.txt](https://github.com/dillo-browser/dillo/files/13865881/log.txt) + +From the log, libiconv seems to be available in your system: + +> PATH: /opt/homebrew/opt/libiconv/bin/ + +And it is found by the configure: + +``` +configure:7396: checking for iconv.h +configure:7396: gcc -c -g -O2 -I/opt/homebrew/Cellar/openssl@3/3.2.0_1/include conftest.c >&5 +configure:7396: $? = 0 +configure:7396: result: yes +configure:7406: checking for iconv_open in -liconv +configure:7435: gcc -o conftest -g -O2 -I/opt/homebrew/Cellar/openssl@3/3.2.0_1/include -L/opt/homebrew/Cellar/openssl@3/3.2.0_1/lib conftest.c -liconv >&5 +configure:7435: $? = 0 +configure:7447: result: yes +``` + +I'm thinking your issue may be related to this: https://stackoverflow.com/questions/57734434/libiconv-or-iconv-undefined-symbol-on-mac-osx + +We don't provide yet a `--with-iconv` option but it should be equivalent of using: +``` +./configure 'LDFLAGS=-L/opt/homebrew/opt/libiconv/lib' 'CPPFLAGS=-I/opt/homebrew/opt/libiconv/include' +``` + +--%-- +From: orbit-stabilizer +Date: Fri, 19 Jan 2024 20:11:01 +0000 + +I have the same issue. Installed via Homebrew on an Intel based Mac. + +--%-- +From: rodarima +Date: Thu, 01 Feb 2024 18:28:23 +0000 + +This issue is likely happening because there are several iconv libraries installed in your system, which are incompatible among themselves and they are in the same library directory also used for other dependencies of Dillo. A way to discover multiple iconv installations is by running `which -a iconv` or better (but slower) `find / -name "libiconv.so*"`. + +When the autoconf script finds one iconv library that is working, assumes that it will work for the next discovery steps. This assumption is not correct as adding the search path for other libraries may switch the selection of the iconv library, and should be corrected so that once a iconv library is found, the full path is used to link to that one specifically. Otherwise, other -L flags used for other libraries will cause the linker to choose another iconv library that is not compatible with objects already built. + +We could spend some effort trying to fix the iconv search procedure, but I believe it would be better invested if we instead switch to another build system like cmake which [already has the logic to search and pin the full iconv library path](https://cmake.org/cmake/help/latest/module/FindIconv.html) (and also would solve some other problems). + +However, I don't want to introduce those big changes for the 3.1 release, so the proper solution would have to wait a bit. For now, fiddling with the CFLAGS and LDFLAGS or removing the other iconv libraries should be a viable workaround.
\ No newline at end of file diff --git a/53/index.md b/53/index.md new file mode 100644 index 0000000..f0ac935 --- /dev/null +++ b/53/index.md @@ -0,0 +1,104 @@ +Title: Consider other forks of Dillo +Author: bkil +Created: Thu, 04 Jan 2024 09:35:57 +0000 +State: open + +Instead of encouraging contribution to this repository forked from source code many years old, please migrate all issues & contribution to the vastly more advanced Dillo-Plus. Thanks. + +--%-- +From: kuchikuu +Date: Mon, 08 Jan 2024 13:35:06 +0000 + +Well, I am neutral but I would like [rodarima](https://github.com/dillo-browser/dillo/commits?author=rodarima) to comment because I plan on making some commits and NOW I'm not sure whether I should do it here or to Dillo-plus. + +[rodarima](https://github.com/dillo-browser/dillo/commits?author=rodarima), do you plan on adding minor fixes and enhancements only (keeping it old-school) or are you willing to add more functionality to Dillo? + +--%-- +From: rodarima +Date: Mon, 08 Jan 2024 14:22:30 +0000 + +> Well, I am neutral but I would like [rodarima](https://github.com/dillo-browser/dillo/commits?author=rodarima) to comment because I plan on making some commits and NOW I'm not sure whether I should do it here or to Dillo-plus. +> +> +> +> [rodarima](https://github.com/dillo-browser/dillo/commits?author=rodarima), do you plan on adding minor fixes and enhancements only (keeping it old-school) or are you willing to add more functionality to Dillo? + +(I'm away from computer) I plan to continue with the original objective of Dillo which is bring access to the web to most devices. Adding new features is fine too. + + +--%-- +From: bkil +Date: Mon, 08 Jan 2024 16:31:25 +0000 + +I've opened a clone of this issue for dillo-plus. The maintainer is open for collaboration, with the condition that BSD support is a must for them. +* https://github.com/crossbowerbt/dillo-plus/issues/21 + +--%-- +From: rodarima +Date: Mon, 08 Jan 2024 20:08:06 +0000 + +Hi, sorry I couldn't answer very well. I'll expand my reply a bit and also mention @crossbowerbt to join the thread. + +> Instead of encouraging contribution to this repository forked from source code many years old, please migrate all issues & contribution to the vastly more advanced Dillo-Plus. + +It is nice to have multiple forks of Dillo to test other features or experiment new concepts. And there is no problem contributing in one repository or the other as most of the patches can be transferred among repositories without much work (you can see that we recommend people to also check other forks in the README.md, no gatekeeping). I should add a contributing guide so it becomes a bit clearer for someone to send a patch or PR. + +Regarding dillo-plus, some features they have introduced are interesting and I would like to eventually introduce in Dillo. In fact, my initial idea of creating an organization is to eventually converge the several Dillo forks into one, to join forces. + +> I've opened a clone of this issue for dillo-plus. The maintainer is open for collaboration, with the condition that BSD support is a must for them. + +We run the tests on FreeBSD in the CI, and other BSD systems could be added too (contributions are welcome), but getting more human testers in BSD systems would be nice. + +I have in my TODO list to check in detail the commits of dillo-plus, but right now the first priority is to stabilize the version 3.1 so we can finally make a release. Check https://github.com/dillo-browser/dillo/milestone/1 to see what is planned. + +From your issue in dillo-plus: + +> Otherwise, if our objectives are different, I'm open to periodically exchange patches to improve both projects + +I hope we can eventually converge into similar objectives but exchanging patches is also fine. + +Regarding the title of this issue "Please archive this repository", I'll switch to something more descriptive as I don't plan to archive this repository for now, but is nice to still keep this issue for reference. + +--%-- +From: bkil +Date: Mon, 08 Jan 2024 22:07:47 +0000 + +Glad to hear we are all on the same page. It helps future exchange of patches if the codebase (or at least the core architecture) is as close as possible between the two repositories. + +This will be crucial in the future as I was considering contributing JavaScript0 support later on and it would be great if it would be enough to develop it only once within a single module, as some small interface hooks will also be required. + +--%-- +From: crossbowerbt +Date: Tue, 09 Jan 2024 05:56:00 +0000 + +Hello everyone! Nice to see that people still like and work on dillo and that the project isn't dead. + +I'd like to share what I'm planning to implement this year (in my spare time, so don't hold your breath...): +- re-implement the download module internally to handle more protocols (ftp, gopher, gemini) without requiring an external tools +- re-implement the FTP module in C to avoid the wget dependency +- adding support for SVG and WEBP images (if and only if the libraries needed require few and simple dependencies) +- rewrite all DLS (the external scripts dillo-plus uses to add additional functionalities) to use only standard shell scripts and simple external tools (and so remove python dependency) +- various fixes to css, ui, markdown parser, etc... + +--%-- +From: crossbowerbt +Date: Tue, 09 Jan 2024 06:02:55 +0000 + +I see that your repo contains dillo plugins for gopher and man, written in C. I didn't know they existed, i should consider integrating them in my fork + +--%-- +From: bkil +Date: Tue, 09 Jan 2024 11:41:16 +0000 + +@crossbowerbt NetSurf uses libsvgtiny for minimalism: + +* https://git.netsurf-browser.org/libsvgtiny.git/tree/README + +--%-- +From: RokerHRO +Date: Fri, 02 Feb 2024 19:19:32 +0000 + +FLTK has its own minimal SVG library, which is already part of FLTK 1.3: +* https://github.com/fltk/nanosvg + +For WebP I already plan a "clone" of the Fl_JPEG_Image class for WebP images. The library libwebp is small and easy to use: https://chromium.googlesource.com/webm/libwebp
\ No newline at end of file diff --git a/54/index.md b/54/index.md new file mode 100644 index 0000000..f0d3522 --- /dev/null +++ b/54/index.md @@ -0,0 +1,33 @@ +Title: Missing table content on resizing +Author: rodarima +Created: Mon, 08 Jan 2024 21:09:07 +0000 +State: closed + +When loading https://www.fltk.org/newsgroups.php?s21875+gfltk.coredev+v21894 without enabling any CSS and resizing the window to make it smaller some text is missing, but should be properly wrapped. + +Reproduced on master with 95627efadf55c39901928ee730d22de55cdcc209 but not with 3.0.5. + +Reported-By: dogma + +--%-- +From: rodarima +Date: Mon, 26 Feb 2024 23:24:03 +0000 + +Seems to be introduced by 6f66fd86, as well as #84 +``` +6f66fd861ef1d1bd583c31c2ce3d9c4a9896ede1 is the first bad commit +commit 6f66fd861ef1d1bd583c31c2ce3d9c4a9896ede1 +Author: Rodrigo Arias Mallo <rodarima@gmail.com> +Date: Mon Dec 25 01:09:26 2023 +0100 + + Fix bogus comparison of oofContainer[i] + + The same index was being used in both sides of the comparison. + + dw/textblock.cc | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) +``` + +> Reproduced on master with https://github.com/dillo-browser/dillo/commit/95627efadf55c39901928ee730d22de55cdcc209 but not with 3.0.5. + +This is not consistent, I cannot reproduce it with 95627efa.
\ No newline at end of file diff --git a/55/index.md b/55/index.md new file mode 100644 index 0000000..c33586a --- /dev/null +++ b/55/index.md @@ -0,0 +1,8 @@ +Title: Update references to website and repository +Author: rodarima +Created: Mon, 08 Jan 2024 22:48:24 +0000 +State: closed + +The website is now at https://dillo-browser.github.io/ and the repository at https://github.com/dillo-browser/dillo. + +Fixes #32
\ No newline at end of file diff --git a/56/index.md b/56/index.md new file mode 100644 index 0000000..e70aa83 --- /dev/null +++ b/56/index.md @@ -0,0 +1,78 @@ +Title: Split protocol and content handling in plugins +Author: rodarima +Created: Tue, 09 Jan 2024 22:47:20 +0000 +State: open + +Currently, the Dillo plugin design shows some shortcomings. + +Considering the plugin for [man pages](https://github.com/dillo-browser/dillo-plugin-man) that can load a manual page with `man:bash` and present it as a HTML page. The plugin breaks when trying to open a page from a file or from any other protocol like https. + +What is happening here is that we have plugins performing two actions at the same time: + +- Adapt the protocol to HTTP. +- Convert the content in the document to HTML. + +These two actions are coupled in the same plugin. For example, we cannot open a local man page using only the conversion to HTML feature of the man plugin. + +Ideally, plugins should offer both actions, but also allow Dillo to use them on their own if needed. This way, opening a file with `file:/path/to/man/page.1` will use the `file:` protocol plugin to make the request and get the content and then the content type of the file will be used to select how to present it. In this case, by sending it to the man plugin function that converts it to HTML. + +Similarly, the rules to select which content handler is used can be made to match the URL, so a single page can be forwarded to one or several content handling plugins. + +Here is an example of a possible configuration file, inspired by the syntax of [smtp.conf(8)](https://man.openbsd.org/smtpd.conf): + +```sh +# Finds the corresponding man page and fetches it decompressing if needed. +# The content type will be set to "text/troff". +match protocol "man" adapter "/path/to/man.adapter.dpi" + +# Then the man page will be read from the stdin and HTML will be written in the stdout, +# with the appropriate patching to fix HTML problems. This would also work for remote +# manual pages. +match content "text/troff" filter "/path/to/man.filter.dpi" +``` + +This also would implement support for any viewer or media player. For example, to open YouTube pages in Invidious (so comments can be loaded) and play the video in a player: +```sh +# Redirect a YouTube URL to a working instance of Invidious, so we can render it without JS +match url "http[s]://[www\.]youtube\.com" adapter "yt2invidious.sh" +# Then just play it with vlc, but only if the URL comes from Invidious +match url "/videoplayback.*googlevideo" content "video/.*" command "vlc" +``` + +This could also be used to fix other pages that have a broken HTML or CSS, or even try to repair pages so they don't require JS for the most common usage: +```sh +# Apply special CSS for reddit +match host "[www\.]reddit\.com" style "reddit.css" +# Fix HTML in Twitter and load special CSS +match host "twitter\.com" filter "twitter.filter.dpi" style "twitter.css" +``` + +The `style` could be injected by a dpi filter plugin, but it would require plugins to properly parse the HTML. Using a specific option for it allows Dillo to preload the CSS before the server is even contacted and enforce it to have always higher priority. + +Both the protocol adapters and filters work in stream mode, so they can begin piping data to the next stages and eventually to the screen much earlier than the complete page is fetched. + +--%-- +From: rodarima +Date: Sun, 14 Jan 2024 16:12:12 +0000 + +One of the problems of using a simple stdin/stdout program to rewrite the HTML is that we would need to run it on every website. This would cause parsing the HTML multiple times, at least one for each plugin, which would be wasteful. + +A plugin would benefit from being able to work directly on the DOM tree, but that would restrict the plugins to interface via an API instead of a simple I/O interface. Writting plugins should be easy. + +--%-- +From: rodarima +Date: Sun, 21 Jan 2024 12:18:18 +0000 + +I created #65 to discuss the design of the "filter" types of plugins. + +--%-- +From: rodarima +Date: Sun, 14 Apr 2024 13:43:46 +0000 + +Regarding the matching rules, there are several stages at which a plugin may need to be hooked: + +- Pre-request: Before any network activity is made. Allows rewriting the URL for example http to https or changing the host. We may want to create an small syntax for this stage so it can be manipulated as text. Here is were protocol handlers would wook to. +- Request: When a connection is opened with a server, we may still want to modify the HTTP headers before sending them. +- Response: Data coming from the server may need to be adjusted or rewritten. That includes HTTP headers as well as the content itself. Here is where all those content handling plugins would hook to. + +Plugins may operate as HTTP servers as well (CGI), so we can for example allow cookies to work for plugins too.
\ No newline at end of file diff --git a/57/index.md b/57/index.md new file mode 100644 index 0000000..08db214 --- /dev/null +++ b/57/index.md @@ -0,0 +1,6 @@ +Title: Report which TLS library is selected and the version +Author: rodarima +Created: Wed, 10 Jan 2024 22:22:54 +0000 +State: closed + +When having multiple versions of the OpenSSL and mbedTLS libraries, it may happen that Dillo is linked with the incorrect choice. We should indicate which library is found and which version. This information should also be printed in the log, so they can be shared when reporting bugs.
\ No newline at end of file diff --git a/58/index.md b/58/index.md new file mode 100644 index 0000000..bc52194 --- /dev/null +++ b/58/index.md @@ -0,0 +1,6 @@ +Title: Report OpenSSL and mbedTLS versions +Author: rodarima +Created: Wed, 10 Jan 2024 23:21:11 +0000 +State: closed + +Fixes #57
\ No newline at end of file diff --git a/59/index.md b/59/index.md new file mode 100644 index 0000000..4e9f8c3 --- /dev/null +++ b/59/index.md @@ -0,0 +1,24 @@ +Title: Free SSL connection before closing file descriptor +Author: rodarima +Created: Sun, 14 Jan 2024 07:43:12 +0000 +State: closed + +Attempting to shutdown an SSL conection in LibreSSL was causing an error to be queued in the error queue, which was triggering the `assert(!ERR_get_error())` for a new connection. In OpenSSL this error was not queue in the "main" error queue, but only recorded for that SSL connection. so it was not triggering the assert. + +The fix simply closes the file descriptor *after* performing the free operation. + +@badsectoracula could you test this PR and check that fixes the #51 issue? + +Fixes #51 + +--%-- +From: badsectoracula +Date: Mon, 15 Jan 2024 09:48:49 +0000 + +I checked the branch and the bug seems to be gone, https sites load fine. + +--%-- +From: rodarima +Date: Mon, 15 Jan 2024 18:01:00 +0000 + +Thanks! I'll merge it then.
\ No newline at end of file diff --git a/6/index.md b/6/index.md new file mode 100644 index 0000000..85288b7 --- /dev/null +++ b/6/index.md @@ -0,0 +1,69 @@ +Title: mbedtls/net.h: No such file or directory +Author: rodarima +Created: Fri, 02 Jun 2023 11:28:34 +0000 +State: closed + +The mbedtls library has upgraded the API to the version 3 and no longer provides `mbedtls/net.h`: + +``` +../../../src/IO/tls.c:52:10: fatal error: mbedtls/net.h: No such file or +directory + 52 | #include <mbedtls/net.h> /* net_send, net_recv */ +``` + +However dillo is taking the headers from mbedtls 3 instead of from the 2: + +``` +% pacman -Ql mbedtls | grep net.h +% pacman -Ql mbedtls2 | grep net.h +mbedtls2 /usr/include/mbedtls2/mbedtls/net.h +``` + +--%-- +From: rodarima +Date: Sun, 17 Dec 2023 19:19:03 +0000 + +The problem with mbedtls is that they have the version 2 and 3, which are both maintained at the same time, but the version 3 is missing in some distros. In Arch Linux is available and is causing confusion to the configure script. + +Ideally we should be able to build it with any of the version 2 or 3, but so far I was unable to setup the CI to test the version 3. + +--%-- +From: rodarima +Date: Fri, 22 Dec 2023 20:19:28 +0000 + +Fixed in #27. For Arch Linux, if no other configure option is given it will link with OpenSSL by default. Otherwise, with `--disable-openssl` will attempt to link with mbedTLS 3. + +If for any reason we need to link with mbedTLS 2 in Arch (not recommended), we need to specify the include and library paths with: +``` +$ ./configure --disable-openssl CFLAGS='-I/usr/include/mbedtls2 -L/usr/lib/mbedtls2' CXXFLAGS='-I/usr/include/mbedtls2 -L/usr/lib/mbedtls2' +... + +Configuration summary: + + CXX : g++ + CXXFLAGS: -I/usr/include/mbedtls2 -L/usr/lib/mbedtls2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions + + TLS enabled: yes + TLS library: mbedTLS + TLS flags : -lmbedtls -lmbedx509 -lmbedcrypto + + Cookies enabled: yes + XEmbed enabled : yes + RTFL enabled : no + JPEG enabled : yes + PNG enabled : yes + GIF enabled : yes + +$ make +... +$ ldd src/dillo | grep mbed + libmbedtls.so.14 => /usr/lib/libmbedtls.so.14 (0x00007f1f31ab5000) + libmbedx509.so.1 => /usr/lib/libmbedx509.so.1 (0x00007f1f31a93000) + libmbedcrypto.so.7 => /usr/lib/libmbedcrypto.so.7 (0x00007f1f31a1b000) + +$ ls -l /usr/lib/mbedtls2/ +total 0 +lrwxrwxrwx 1 root root 21 Nov 20 14:55 libmbedcrypto.so -> ../libmbedcrypto.so.7 +lrwxrwxrwx 1 root root 19 Nov 20 14:55 libmbedtls.so -> ../libmbedtls.so.14 +lrwxrwxrwx 1 root root 19 Nov 20 14:55 libmbedx509.so -> ../libmbedx509.so.1 +```
\ No newline at end of file diff --git a/60/index.md b/60/index.md new file mode 100644 index 0000000..e24df8a --- /dev/null +++ b/60/index.md @@ -0,0 +1,6 @@ +Title: Fix TLS loop while in certificate dialog +Author: rodarima +Created: Sun, 14 Jan 2024 09:03:03 +0000 +State: closed + +Fixes #49
\ No newline at end of file diff --git a/61/index.md b/61/index.md new file mode 100644 index 0000000..1961345 --- /dev/null +++ b/61/index.md @@ -0,0 +1,6 @@ +Title: Add ui_tab_height option +Author: rodarima +Created: Sun, 14 Jan 2024 09:06:32 +0000 +State: closed + +The default tab height of 16 pixels was causing some usability issues as the tabs are quite small in large monitors. The default size is increased to 20 pixels and the new option "ui_tab_height" allows the user to specify a different value.
\ No newline at end of file diff --git a/62/index.md b/62/index.md new file mode 100644 index 0000000..55573f8 --- /dev/null +++ b/62/index.md @@ -0,0 +1,12 @@ +Title: Allow mouse wheel to switch tabs +Author: rodarima +Created: Sun, 14 Jan 2024 09:10:18 +0000 +State: closed + +Switches tabs when scrolling with the mouse wheel with the mouse over the tabs. + +--%-- +From: rodarima +Date: Tue, 16 Jan 2024 19:55:17 +0000 + +We should add a way to disable this feature from the configuration file.
\ No newline at end of file diff --git a/63/index.md b/63/index.md new file mode 100644 index 0000000..8a65090 --- /dev/null +++ b/63/index.md @@ -0,0 +1,63 @@ +Title: Detect RSS on a page and make it visible +Author: rodarima +Created: Sun, 14 Jan 2024 15:39:52 +0000 +State: open + +From https://alpha.polymaths.social/@amin/statuses/01HH6G3MX196P4AWMT7CA7SB2R + +> A neat thing about lynx I've noticed is that it makes the link to the RSS feed (which I mentioned the syntax for to you earlier) visible, as "[#RSS](https://fosstodon.org/tags/RSS)", the first thing on the page. I rather like that. Wish browsers were better about integrating feed-related features. + +We may be able to integrate such feature by adding a plugin that rewrites the head link tag into something visible in the body. The links have this look: +```html +<link rel="alternate" type="application/rss+xml" href="/feed.xml" /> +``` + +Would require to have #56 working. + +--%-- +From: benjaminbhollon +Date: Sun, 14 Jan 2024 16:55:47 +0000 + +A note; looks like lynx uses the `title` attribute of these links as the link text. I have multiple feeds on https://benjaminhollon.com, for example, with different titles, and it uses the titles I set. :) + +--%-- +From: rodarima +Date: Sun, 14 Jan 2024 17:12:43 +0000 + +Thanks, I leave here a picture of lynx for reference: + + + +With the following link tags: + +```html +<link rel="alternate" type="application/atom+xml" title="Musings Blog Atom Feed" href="https://benjaminhollon.com/musings/feed/"> +<link rel="alternate" type="application/atom+xml" title="Aggregrated Atom Feeds" href="https://benjaminhollon.com/feed/?from=musings%2Ctty1%2Cpoetry%2Cblurbs"> +<link rel="alternate" hreflang="en" href="http://localhost/"> +``` + +This should be doable with a small plugin that rewrites the HTML, parsing the link tags and injects them in the body with the proper title and hyperlinks. We still need to work in the infrastructure to make rewriting HTML easier. + +--%-- +From: benjaminbhollon +Date: Mon, 15 Jan 2024 02:44:53 +0000 + +Huh, that last alternate link is odd. Not sure why it's there. + +I'll check my site's code. Wasn't expecting to find an issue via this issue. XD + +Edit: looks like it's from my SSG's multilanguage plugin, but with the root domain messed up. (Also not sure why it's adding it with the current page language.) + +Might be worth excluding rel="alternate" links that have the `hreflang` attribute, or displaying them differently, since those are links to alternate translations of the page. + +--%-- +From: rodarima +Date: Sat, 27 Jan 2024 10:57:01 +0000 + +> I'll check my site's code. Wasn't expecting to find an issue via this issue. XD + +Sometimes it happens :-) + +> Might be worth excluding rel="alternate" links that have the hreflang attribute, or displaying them differently, since those are links to alternate translations of the page. + +Yeah, probably we should first only focus on `application/atom+xml` and exclude everything else. In Dillo there is already a [hack to inject a table at the beginning of a page](https://github.com/dillo-browser/dillo/blob/master/src/html.cc#L3104-L3110) to "support" the meta refresh tag, but I want to use this as an example to make the design of plugins that can do those tasks, instead of making more hacks.
\ No newline at end of file diff --git a/64/index.md b/64/index.md new file mode 100644 index 0000000..c411536 --- /dev/null +++ b/64/index.md @@ -0,0 +1,6 @@ +Title: Improve about:splash +Author: rodarima +Created: Wed, 17 Jan 2024 22:06:16 +0000 +State: closed + +The first page that users see for the first time must be polished so they have a good first experience and also they can check more information about how to use the browser. It is also convenient to keep the page local, so we don't need a network, including the help page.
\ No newline at end of file diff --git a/65/index.md b/65/index.md new file mode 100644 index 0000000..5309f93 --- /dev/null +++ b/65/index.md @@ -0,0 +1,395 @@ +Title: Rewrite HTML plugin design +Author: rodarima +Created: Sun, 21 Jan 2024 12:16:30 +0000 +State: open + +Users should have the ability to modify pages on their own, *easily* and by using their preferred language. They should be able to place rules so that pages matching the rules perform some changes and others don't. + +Here are some examples that could use such feature: + +- Some pages are really broken when no JS is available, but they could be fixed if we could rewrite some parts. This is generally page specific. +- Generate a table of contents and place it in the top of the page. +- Read `<link>` tags for alternate pages and display them (RSS). + +Ideally, we would like to have a design such that it has the following features: + +- Low performance cost +- Stream mode, where the page is loading but we begin the transformation and pass the data to the next stage without delays +- Allow rewrite plugins to be chained together + +For this to happen, we would need to make a decision about how the data is sent from the website to the plugins. We have some options, which are not mutually exclusive. + +## Raw HTML + +Just send the page as-is to the plugin stdin and then read the stdout to get the transformed HTML. This is the simplest design, but has the drawback that we would (likely) need to implement a HTML parser in each plugin and parse the page again in each transformation. + +## Intermediate language + +Instead of using HTML, we could transform it to something intermediate that is easier to parse in such a way that the plugins can simply disregard all the content they are not interested in and then just apply match rules that only require a minimal amount of processing. A simple language should allow users to write simple sed or awk plugins to perform simple tasks, without requiring to parse of the whole document tree. This would reduce the amount of processing for plugins, but it would require learning a new language which may be costly. + +## Document tree in memory + +Another option is to allow plugins to read and modify the document tree in memory. As we will be processing the HTML in stream mode, we cannot wait until the whole tree is created and the post-process it. It must be updated in iterations where new content is added to the tree and this new content can be send to plugins for processing. The plugins could hook into some elements or rules so only that content is sent to them. + +This is probably the most efficient way to do it, but it would restrict writting the plugins in a way that is compatible with the document tree API, and that would also restrict the languages. Furthermore, as we change the API the plugins will become outdated, so this is not such a great idea. + +## Use JavaScript + +Finally, the option that I would hate the most, is to implement something similar (or just the same) as JavaScript, where the plugins are written in a language that can be executed by the browser to manipulate the document tree. This would hide internal changes in the API and allow writting simpler programs. However, this would only allow plugins to be written in JS, and the emulation of the language would introduce more performance cost. + +This option may also not be suitable for the stream mode, where the document tree is still loading, and may cause cascade effects when two plugins are hooked in the same change events. In any case, this would require us to implement support for JavaScript, which would not be an easy task. + +--- + +To determine which option or options to implement, a simple plan is to just try to code some plugins as a proof of concept and see how they behave. Then, we would have real data on how the performance is affected, instead of just performing some premature optimization. + +See also #56 + +--%-- +From: rodarima +Date: Sun, 21 Jan 2024 13:03:37 +0000 + +Here is an example of how a intermediate language for HTML bassed on troff could be used by standard text processing utils like AWK: + +```groff +% cat test.mm +.tb html +.tb head +.tb link +.ta rel "alternate" +.ta type "application/rss+xml" +.ta href "/feed.xml" +.te link +.tb link +.ta rel "alternate" +.ta type "application/atom+xml" +.ta href "/atom.xml" +.te link +.te head +.tb body +.tb p +Hello from the body +.te p +.te body +.te html +``` +Where commands begin with a dot in the first character. Commands are `tb` for begin tag, `te` for end tag and `ta` for tag attribute. + +And here is the AWK program that injects the links after the body: +```awk +% cat parse.awk +BEGIN { n=0 } +/^\.tb head/ { inhead=1 } +/^\.tb link/ && inhead { inlink=1; href=""; type="" } +/^\.ta type/ && inlink { type=$3 } # FIXME: Handle spaces +/^\.ta href/ && inlink { href=$3 } +/^\.te link/ && inlink \ + && href != "" \ + && type != "" { hrefs[n]=href; types[n]=type; n++; inlink=0 } + +{ print } # Print the page as is by default + +/^.tb body/ && n > 0 { + print ".tb div" + print ".ta class dillo-plugin-rss" + for (i = 0; i < n; i++) { + print ".tb p" + printf "Feed with type %s at %s\n", types[i], hrefs[i] + print ".te p" + } + print ".te div" +} +``` +After running it: +```diff +% awk -f parse.awk < test.mm > test.pp +% diff -up test.mm test.pp +--- test.mm 2024-01-21 13:48:35.493905662 +0100 ++++ test.pp 2024-01-21 13:56:26.554871231 +0100 +@@ -12,6 +12,15 @@ + .te link + .te head + .tb body ++.tb div ++.ta class dillo-plugin-rss ++.tb p ++Feed with type "application/rss+xml" at "/feed.xml" ++.te p ++.tb p ++Feed with type "application/atom+xml" at "/atom.xml" ++.te p ++.te div + .tb p + Hello from the body + .te p +``` + +--%-- +From: rodarima +Date: Sun, 21 Jan 2024 15:34:20 +0000 + +Here is a rewrite of the previous plugin in C, showing how we can partially parse a pseudo-HTML document: + +```c +#include <stdio.h> +#include <string.h> + +#define MAXLINKS 32 +#define MAXLINE 4096 + +struct link { + char *href; + char *type; +}; + +struct state { + int nlinks; + struct link links[MAXLINKS]; + + int in_head; + int in_link; + int in_body; + int emitted; +}; + +void parsebegin(struct state *st, char *token) +{ + if (strncmp(token, "head", 4) == 0) { + st->in_head = 1; + } else if (st->in_head && strncmp(token, "link", 4) == 0) { + st->in_link = 1; + } else if (strncmp(token, "body", 4) == 0) { + st->in_body = 1; + } +} + +char *cleanstr(char *str) +{ + int n = strlen(str); + if (str[n-1] == '\n') + str[n-1] = '\0'; + + return str; +} + +void parseattr(struct state *st, char *token) +{ + if (!st->in_link) + return; + + struct link *link = &st->links[st->nlinks]; + + if (strncmp(token, "type", 4) == 0) { + link->type = cleanstr(strdup(token + 5)); + } else if (strncmp(token, "href", 4) == 0) { + link->href = cleanstr(strdup(token + 5)); + } +} + +void parseend(struct state *st, char *token) +{ + struct link *link = &st->links[st->nlinks]; + + if (st->in_head && strncmp(token, "head", 4) == 0) { + st->in_head = 0; + } else if (st->in_body && strncmp(token, "body", 4) == 0) { + st->in_body = 0; + } else if (st->in_link && strncmp(token, "link", 4) == 0) { + st->in_link = 0; + + /* Accept */ + if (link->href && link->type) + st->nlinks++; + } +} + +void parseline(struct state *st, char *line) +{ + if (st->nlinks >= MAXLINKS) + return; + + int n = strlen(line); + if (n < 4) + return; + + int a = line[0], b = line[1], c = line[2], d = line[3]; + + if (a != '.' || d != ' ') + return; + + if (b != 't') + return; + + char *next = line + 4; + if (c == 'b') + parsebegin(st, next); + else if (c == 'a') + parseattr(st, next); + else if (c == 'e') + parseend(st, next); +} + +void post(struct state *st) +{ + if (!st->in_body || st->emitted) + return; + + printf(".tb div\n"); + printf(".ta class dillo-plugin-rss\n"); + for (int i = 0; i < st->nlinks; i++) { + struct link *link = &st->links[i]; + printf(".tb p\n"); + printf("Feed with type %s at %s\n", link->type, link->href); + printf(".te p\n"); + } + printf(".te div\n"); + + st->emitted = 1; +} + +int main() +{ + char line[MAXLINE]; + struct state st = { 0 }; + + while (fgets(line, MAXLINE, stdin)) { + parseline(&st, line); + + fprintf(stdout, "%s", line); + + post(&st); + } + + return 0; +} + +``` + +And here is the comparison with perf: + +``` +% perf stat awk -f parse.awk < test.mm > /dev/null + + Performance counter stats for 'awk -f parse.awk': + + 5,58 msec task-clock:u # 0,816 CPUs utilized + 0 context-switches:u # 0,000 /sec + 0 cpu-migrations:u # 0,000 /sec + 268 page-faults:u # 48,010 K/sec + 6.409.278 cycles:u # 1,148 GHz + 10.779.901 instructions:u # 1,68 insn per cycle + 2.305.817 branches:u # 413,064 M/sec + 68.228 branch-misses:u # 2,96% of all branches + + 0,006839612 seconds time elapsed + + 0,006870000 seconds user + 0,000000000 seconds sys + + +% perf stat ./parse < test.mm > /dev/null + + Performance counter stats for './parse': + + 1,27 msec task-clock:u # 0,492 CPUs utilized + 0 context-switches:u # 0,000 /sec + 0 cpu-migrations:u # 0,000 /sec + 61 page-faults:u # 47,852 K/sec + 241.231 cycles:u # 0,189 GHz + 165.656 instructions:u # 0,69 insn per cycle + 37.918 branches:u # 29,745 M/sec + 2.722 branch-misses:u # 7,18% of all branches + + 0,002591042 seconds time elapsed + + 0,000000000 seconds user + 0,002544000 seconds sys + +``` + +I uses 65 times less instructions (but is not 65 times faster). + +--%-- +From: rodarima +Date: Sun, 21 Jan 2024 17:13:57 +0000 + +CloudFlare has done some work in this area to rewrite parts of the websites they intercept using [a stream parser](https://github.com/cloudflare/lazyhtml). They have [a blog post](https://blog.cloudflare.com/html-parsing-1) where they explain some details. + +As far as I understand, this would be an example where we transform the tree in memory, updating it chunk by chunk. + +They claim they process a large document (8 MiB) at up to 160 MiB/s, but they don't mention the HW used. Maybe it could serve as a comparison if we manage to do something similar with an intermediate language. + +--%-- +From: rodarima +Date: Thu, 25 Jan 2024 21:53:27 +0000 + +If we continue with the intermediate language idea, we should also make it a larger subset that just HTML. For example, it would be nice if we have access to the response HTTP headers too. + +This makes me think that plugins may also need to rewrite the requests and not only the response. For example, we may want to redirect petitions *before* they are made, or change HTTP headers. + +--%-- +From: rodarima +Date: Sat, 27 Jan 2024 12:38:48 +0000 + +Another problem that we face how to solve transformations that requires double or more passes. An example of this is the table of contents, where we index the secions (h1, h2, ...) and then display a menu in the top of the page with the table of contents. + +A way to solve this problem is to allow plugins to work with auxiliary streams and allow adding a reference to inject content from other streams. Example: + +```html +<html> + <body> + <h1>Main title</h1> + <p>blah blah</p> + <h2>Section 1</h2> + <p>blah blah</p> + <h2>Section 2</h2> + <p>blah blah</p> + </body> +</html> +``` + +To produce something like this: + +```html +<html> + <body> + <div class="toc"> + <ul> + <li>Main title + <ul> + <li>Section 1</li> + <li>Section 2</li> + </ul> + </li> + <li>Another title</li> + </div> + <h1>Main title</h1> + <p>blah blah</p> + <h2>Section 1</h2> + <p>blah blah</p> + <h2>Section 2</h2> + <p>blah blah</p> + <h1>Another title</h1> + </body> +</html> +``` + +We could inject an element that includes content from another file descriptor. Like this: + +```html +<html> + <body> + <specialref fd="42"/> + <h1>Main title</h1> + <p>blah blah</p> + <h2>Section 1</h2> + <p>blah blah</p> + <h2>Section 2</h2> + <p>blah blah</p> + <h1>Another title</h1> + </body> +</html> +``` +And then the plugin would write in another fd the table of content as it is being processed from the main stream. The content is not blocked and can continue to be processed in stream mode. The TOC plugin should also make the headers have a unique id, so we can properly link them. + +We could also inject the content after the main stream is processed, but that would require the plugin to store all the intermediate information in memory. The clean solution is allowing multiple streams.
\ No newline at end of file diff --git a/66/index.md b/66/index.md new file mode 100644 index 0000000..56f857b --- /dev/null +++ b/66/index.md @@ -0,0 +1,6 @@ +Title: Display current key maps in a page +Author: rodarima +Created: Sat, 27 Jan 2024 12:20:33 +0000 +State: closed + +It would be nice if we can have some `about:keys` page where we list the current key maps, to serve as a reminder.
\ No newline at end of file diff --git a/67/index.md b/67/index.md new file mode 100644 index 0000000..a3ad66b --- /dev/null +++ b/67/index.md @@ -0,0 +1,83 @@ +Title: CSS margin auto is not working +Author: rodarima +Created: Thu, 01 Feb 2024 17:59:02 +0000 +State: open + +The red div should appear in the center: + + + +Tested with: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test CSS margin auto</title> + <style> + div {height:100px} + .container {width:300px; background: lightgreen} + .child {width:100px; background: brown; margin:auto } + </style> + </head> + <body> + <div class="container"> + <div class="child"></div> + </div> + </body> +</html> +``` + +This breaks a lot of pages that rely on this method to center content on the page. + +--%-- +From: campaul +Date: Thu, 10 Apr 2025 17:02:28 +0000 + +I'm interested in working on this if it's not already in progress. I put together a rough proof of concept to get an idea of what would be involved and collected my notes from the process below. Let me know if you'd like me to start working on this and if this sounds like a reasonable approach. + +--- + +The relevant portion of the CSS spec for calculating widths and margins is https://www.w3.org/TR/CSS2/visudet.html#Computing_widths_and_margins. There are several different cases that have to be handled, but the main issue is that widths and margins are dependent on each other. In some cases margin is used to compute width, and in other cases width is used to compute margin. Unfortunately, the current dillo code assumes that margin is always an absolute value. + +Some potential steps to make this work: +1) Convert `style->margin.left` and `style->margin.right` values to be Lengths +2) Remove `boxOffsetX`, `boxRestWidth`, and `boxDiffWidth`, from `style.hh`. Because calculating them sometimes requires knowing the width of the parent element, they can't actually be calculated using just the style. +3) Update `Widget::calcWidth`, `Widget::getAvailWidth`, and `Widget::getAvailWidthOfChild` to not make use of any of the functions listed in the last step and instead compute all of the margin and width values based on the rules in the linked spec. I would also expand `calcWidth` to take pointers for setting `marginLeft` and `marginRight`. +4) Update anything that accessed `style->margin.left`, `style->margin.right`, or any of the removed functions to instead use values computed by `calcWidth`. + +--- + +Once this is issue is complete, similar work should be done for the corresponding height functions based on the heights and margins spec https://www.w3.org/TR/CSS2/visudet.html#Computing_heights_and_margins + +--%-- +From: rodarima +Date: Thu, 10 Apr 2025 17:54:21 +0000 + +> I'm interested in working on this if it's not already in progress. I put together a rough proof of concept to get an idea of what would be involved and collected my notes from the process below. Let me know if you'd like me to start working on this and if this sounds like a reasonable approach. + +Thanks!, the renderer can use more help :) + +> The relevant portion of the CSS spec for calculating widths and margins is https://www.w3.org/TR/CSS2/visudet.html#Computing_widths_and_margins. There are several different cases that have to be handled, but the main issue is that widths and margins are dependent on each other. In some cases margin is used to compute width, and in other cases width is used to compute margin. Unfortunately, the current dillo code assumes that margin is always an absolute value. +> +> Some potential steps to make this work: +> +> 1. Convert `style->margin.left` and `style->margin.right` values to be Lengths +> +> 2. Remove `boxOffsetX`, `boxRestWidth`, and `boxDiffWidth`, from `style.hh`. Because calculating them sometimes requires knowing the width of the parent element, they can't actually be calculated using just the style. +> +> 3. Update `Widget::calcWidth`, `Widget::getAvailWidth`, and `Widget::getAvailWidthOfChild` to not make use of any of the functions listed in the last step and instead compute all of the margin and width values based on the rules in the linked spec. I would also expand `calcWidth` to take pointers for setting `marginLeft` and `marginRight`. +> +> 4. Update anything that accessed `style->margin.left`, `style->margin.right`, or any of the removed functions to instead use values computed by `calcWidth`. +> + +Sounds like a reasonable plan. I would recommend adding more tests, as I only added a very simple one, but we would need to handle multiple nested elements with relative margins and widths. + +We would also need to keep an eye on any extra performance cost. + +It would be convenient to extend the Doxygen documentation about the renderer in those parts that it are not well covered and to document how the new computation behaves. We also need to make sure that is clear what box is used to resolve the relative lengths. + +> Once this is issue is complete, similar work should be done for the corresponding height functions based on the heights and margins spec https://www.w3.org/TR/CSS2/visudet.html#Computing_heights_and_margins + +I recommend leaving this for another PR/issue. + diff --git a/68/index.md b/68/index.md new file mode 100644 index 0000000..ba11595 --- /dev/null +++ b/68/index.md @@ -0,0 +1,6 @@ +Title: Add margin auto HTML render test +Author: rodarima +Created: Thu, 01 Feb 2024 18:00:51 +0000 +State: closed + +For now we just add the failing test, see #67.
\ No newline at end of file diff --git a/69/index.md b/69/index.md new file mode 100644 index 0000000..bcb481c --- /dev/null +++ b/69/index.md @@ -0,0 +1,74 @@ +Title: Document the system requirements for users & developers/contributors +Author: RokerHRO +Created: Fri, 02 Feb 2024 19:47:40 +0000 +State: open + +As a user I'd like to know which platforms are currently supported / are planned to be supported in the near future. + +As a developer I'd like to know which (minimalistic) platforms (CPU, OS version, compiler version, C++ language version, RAM usage) I have to consider when adding code or dependencies. + + + +--%-- +From: rodarima +Date: Fri, 02 Feb 2024 22:11:46 +0000 + +> As a user I'd like to know which platforms are currently supported / are planned to be supported in the near future. + +Good point. I think we could divide the support into tiers or groups, as we currently cannot perform the same tests on architectures or platforms we don't have available (like Atari hardware) vs the ones on CI. As of now, we build Dillo on the GitHub CI for every PR on Ubuntu 22.04 and 20.04, macOS 13 and FreeBSD 14, but only in Ubuntu 22.04 we pass the rendering tests. + +The rendering tests launch a full X server, open several pages in Dillo and compare the rendered outcome using an screenshot with a reference page. These tests are slow, so we also have to have that into mind, as we don't have infinite compute resources. Apart from that, the current set of tests is very limited, so we need to improve that before we could claim that we run on a system "properly". + +I guess we could make at least three groups for a given platform: + +1. Builds and pass the rendering tests in every merge in CI. +2. Builds only in CI +3. It should work and/or somebody claimed that it worked. + +As of now, we would like to support most Linux based distributions, BSD and recent MacOS systems. + +Regarding Windows, I saw some efforts with cygwin but I never tried as I don't own any Windows machine anymore. I wouldn't mind if someone makes the effort of making a pipeline in the CI to integrate it and we could try to maintain it working. As of now I would say is not supported, and I don't plan to add support for it in the near future. + +> As a developer I'd like to know which (minimalistic) platforms (CPU, OS version, compiler version, C++ language version, RAM usage) I have to consider when adding code or dependencies. + +You should try to avoid bringing more dependencies on Dillo as they are often not available in less common systems and make the browser more bloated. Sometimes this can be avoided by coding the features in external plugins that don't have these restrictions. If there is no other choice, placing the dependant code inside Dillo may be a better option, or making the feature optional. + +Regarding the hardware, Dillo should be able to run reasonably well on any CPU of the last 20-30 years, but there are not explicit tests yet. It is posible to emulate an old system and see how it behaves, but I think we could find a metric like instructions per page rendered to measure and keep the performance monitored. + +Dillo should be reasonably portable to systems that support POSIX and FLTK, so the specific OS version shouldn't matter much. Again, there are no tests for this, so we cannot enforce this. + +The compiler should be fine with both gcc and clang, but it should support C++11 at least. We build Dillo in the CI with gcc and clang, but we don't test older versions. + +The RAM usage is a bit tricky, as it scales with the page complexity. Additionally, Dillo caches pages in memory, which causes it to always increase the RSS. However, during an "average" session I would say I don't make it go above 100 MiB RSS. A metric that was used before is how much RAM is used (a factor) per MiB of HTML parsed. That number should be kept low. + +I have in my TODO to add a CONTRIBUTING.md file. + +--%-- +From: RokerHRO +Date: Fri, 02 Feb 2024 22:50:18 +0000 + +@rodarima : Thanks for your quick answer! :-) + +The reason why I ask is: If I'll to add some features the code will necessarily grow, and often there are CPU/memory tradeoffs for different implementations or algorithms etc. So I want to be able to check whether my code would kick out the old but still demanded platform X, compiler Y or increase resource Z to a higher limit L. + +The discussion ran in the FLTK team too, 2 months ago: Shall the C-style code be changed to a more modern C++-style code, with contemporary C++ features (and allow C++14, C++17), which would ease development, simplify the code base (because C++ standard lib contains these features already), make it more platform independent, of course without losing maximal performance and minimal memory footprint. + +Another singular example: I saw bugfixes for IRIX and non-C99-compliant compilers in the code. Are they still necessary? + +--%-- +From: rodarima +Date: Fri, 02 Feb 2024 23:22:46 +0000 + +> @rodarima : Thanks for your quick answer! :-) +> +> The reason why I ask is: If I'll to add some features the code will necessarily grow, and often there are CPU/memory tradeoffs for different implementations or algorithms etc. So I want to be able to check whether my code would kick out the old but still demanded platform X, compiler Y or increase resource Z to a higher limit L. + +I don't think I can provide a generic answer to this, but if you have an specific feature in mind that you would like to work on, I suggest you open an issue to discuss it (check first it is not already created), and then we can try to investigate if there is any conflict. + +> The discussion ran in the FLTK team too, 2 months ago: Shall the C-style code be changed to a more modern C++-style code, with contemporary C++ features (and allow C++14, C++17), which would ease development, simplify the code base (because C++ standard lib contains these features already), make it more platform independent, of course without losing maximal performance and minimal memory footprint. + +For now I would like to continue using C and C++11, until we can see more clearly the benefits of the change. + +> Another singular example: I saw bugfixes for IRIX and non-C99-compliant compilers in the code. Are they still necessary? + +If they don't annoy you, I would leave them as they are. Old thread: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/F3O6QUHJAK3HULV7TDA2PHU52RD3HSAY/#RCHNSBOXAUL5XN5QAVQJ2DEYMPH2LIT3
\ No newline at end of file diff --git a/7/index.md b/7/index.md new file mode 100644 index 0000000..a53638b --- /dev/null +++ b/7/index.md @@ -0,0 +1,20 @@ +Title: thead tbody and tfoot tag "activation" +Author: walley +Created: Tue, 06 Jun 2023 19:55:12 +0000 +State: closed + + + +--%-- +From: rodarima +Date: Mon, 11 Dec 2023 00:58:22 +0000 + +Hi, thanks for the PR. I added a test case that shows the proper colors when the thead, tbody or tfoot selectors are used (right): + + + +--%-- +From: rodarima +Date: Mon, 11 Dec 2023 01:14:46 +0000 + +Merged in https://github.com/rodarima/dillo/commit/d2d000c4d0bd303a32edcd998804fcc5a820f786
\ No newline at end of file diff --git a/70/index.md b/70/index.md new file mode 100644 index 0000000..9b19a1b --- /dev/null +++ b/70/index.md @@ -0,0 +1,51 @@ +Title: Add support for SVG images +Author: rodarima +Created: Fri, 02 Feb 2024 22:30:44 +0000 +State: closed + +Add support for SVG images, as they are becoming more frequent in the web. + +We probably should link or embed a SVG library that performs the rastering, but make it optional so it can be disabled on build time. + +Some options from #53 : + +- https://git.netsurf-browser.org/libsvgtiny.git/tree/README +- https://github.com/fltk/nanosvg (already in FLTK) +- https://github.com/RazrFalcon/resvg + +In other to test that it works fine, we could have a reference page with a image already rendered to PNG or a similar format, and compare the result with the new library rendering the same SVG image. + +--%-- +From: rodarima +Date: Sun, 12 May 2024 20:49:09 +0000 + +One of the main good uses of SVG images is to read Wikipedia equations, which are included as a fallback for non-JS browsers. The equations are all rendered with MathJax, which defines all the glyphs using `<defs>` and then places each glyph in the proper position using the `<use>` tag. + +This is problematic, as both libsvgtiny and nanosvg lack support for them and cannot render Wikipedia equations. I tested librsvg and renders properly those equations, but is by far a very large and complex library: + + + + + + + + +(We also need to avoid rendering the MathML parts of the Wikipedia) + +Ideally we should either implement support for defs/use or find another less complicated library that implements it. The size of librsvg is a wopping 3MiB, without dependencies. + +--%-- +From: rodarima +Date: Sat, 06 Jul 2024 12:33:13 +0000 + +Nanosvg doesn't support text or tspan tags either. + +--%-- +From: rodarima +Date: Sat, 27 Jul 2024 11:17:50 +0000 + +Basic support for SVG added in https://github.com/dillo-browser/dillo/pull/211 + +This is enough to render Wikipedia equations, but it lacks a lot of other SVG features that should be handled by a more elaborate SVG library. The benefit of using nanosvg is that it is builtin into Dillo without dependencies. + +In the future we may want to add an support for other libraries, so that they can be enabled at configure time.
\ No newline at end of file diff --git a/71/index.md b/71/index.md new file mode 100644 index 0000000..4d7db72 --- /dev/null +++ b/71/index.md @@ -0,0 +1,27 @@ +Title: Add support for WebP images +Author: rodarima +Created: Fri, 02 Feb 2024 22:33:33 +0000 +State: closed + +Similarly as for SVG images, support for WebP images would be nice. + +Libraries from #53: +- https://chromium.googlesource.com/webm/libwebp + +The test procedure is simple as we only need to generate a pair of images like PNG and WebP, and ensure the rendering is the same for both. + +--%-- +From: MrMinderbinder +Date: Thu, 20 Jun 2024 09:01:40 +0000 + +SVG support sounds good, WebP not so much... + +https://siipo.la/blog/is-webp-really-better-than-jpeg +https://eng.aurelienpierre.com/2021/10/webp-is-so-great-except-its-not/ +https://www.jwz.org/blog/2023/09/webp-is-going-great/ + +--%-- +From: JessFairbairn +Date: Tue, 23 Jul 2024 13:01:27 +0000 + +Probably a separate bug but if and when webp or SVG support is added it would be worth adding support for the `<picture>` tag (assuming it isn't already)
\ No newline at end of file diff --git a/72/index.md b/72/index.md new file mode 100644 index 0000000..1ab858f --- /dev/null +++ b/72/index.md @@ -0,0 +1,8 @@ +Title: Add a CONTRIBUTING file +Author: rodarima +Created: Fri, 02 Feb 2024 22:41:58 +0000 +State: open + +In order to make it easier for others to contribute, we should add a CONTRIBUTING file that describes the main guidelines. + +See #69
\ No newline at end of file diff --git a/73/index.md b/73/index.md new file mode 100644 index 0000000..fdddef1 --- /dev/null +++ b/73/index.md @@ -0,0 +1,6 @@ +Title: Improve help page +Author: rodarima +Created: Sun, 04 Feb 2024 14:35:37 +0000 +State: closed + +The help page available when pressing the <kbd>?</kbd> button should be improved at least in terms of readability and making sure that is still up to date.
\ No newline at end of file diff --git a/74/index.md b/74/index.md new file mode 100644 index 0000000..7484da5 --- /dev/null +++ b/74/index.md @@ -0,0 +1,29 @@ +Title: Incorrect padding in span or other inline tags +Author: rodarima +Created: Sun, 04 Feb 2024 14:50:20 +0000 +State: open + +The following render test: + +```html +<!DOCTYPE html> +<html> + <head> + <title>Test span with padding CSS property</title> + <style> + span {padding: 20px; background: lightgreen} + p {margin-top: 40px} + </style> + </head> + <body> + <p>hello <span>world</span></p> + </body> +</html> +``` +Renders properly in Firefox as: + + +But not in Dillo: + + +The same problem seems to happen with other inline tags. diff --git a/75/index.md b/75/index.md new file mode 100644 index 0000000..791a7a9 --- /dev/null +++ b/75/index.md @@ -0,0 +1,6 @@ +Title: Add span padding HTML render test +Author: rodarima +Created: Sun, 04 Feb 2024 15:05:01 +0000 +State: closed + +Adds the failing test only, see #74.
\ No newline at end of file diff --git a/76/index.md b/76/index.md new file mode 100644 index 0000000..24e989b --- /dev/null +++ b/76/index.md @@ -0,0 +1,8 @@ +Title: Simplify about:splash page +Author: rodarima +Created: Tue, 06 Feb 2024 22:12:14 +0000 +State: closed + +As this is the page that new users will see for the first time, we want to show them a very simple introduction so they can reach the full help when they need it. + +Fixes #64
\ No newline at end of file diff --git a/77/index.md b/77/index.md new file mode 100644 index 0000000..cb63ccb --- /dev/null +++ b/77/index.md @@ -0,0 +1,15 @@ +Title: Respect Cache-Control header to ignore cached version +Author: rodarima +Created: Sat, 10 Feb 2024 10:31:00 +0000 +State: open + +When following some of the sorting links of https://bluedwarf.top/cackle/index.php Dillo goes back to the index without re-fetching the new sorted content. The Cache-Control header should be tested determine if Dillo should to fetch again for new content. + +--%-- +From: Jullyfish +Date: Mon, 30 Jun 2025 10:00:42 +0000 + +And also doesn't work the header: +``` +Expired: 0 +```
\ No newline at end of file diff --git a/78/index.md b/78/index.md new file mode 100644 index 0000000..ade8050 --- /dev/null +++ b/78/index.md @@ -0,0 +1,19 @@ +Title: Reduce friction to add cookie rules +Author: rodarima +Created: Sat, 10 Feb 2024 16:26:44 +0000 +State: open + +When a site tries to store cookies in the browser but they are set as DENY by default, the user will need to: + +- Detect that the site is trying to store cookies and are being rejected. +- Find out how to configure the cookies for that site. +- Edit manually cookiesrc and add an exception. +- Restart the dpidc daemon. + +We could reduce the friction of adding new exceptions by: + +- Stating that there are cookies being rejected. +- Allowing the user to add an exception from the UI directly. +- Have the configuration automatically reloaded when this happens. + +See: http://bluedwarf.top/cackle/view-post.php?post_num=2584#C6
\ No newline at end of file diff --git a/79/index.md b/79/index.md new file mode 100644 index 0000000..5956f37 --- /dev/null +++ b/79/index.md @@ -0,0 +1,314 @@ +Title: TLS ALERT on write: decode error +Author: rodarima +Created: Sat, 10 Feb 2024 22:05:50 +0000 +State: closed + +Abort when loading https://gopher.floodgap.com/gopher/gw: + +``` +dillo_dns_init: Here we go! (threaded) +TLS library: OpenSSL 3.1.4 24 Oct 2023 +Enabling cookies as from cookiesrc... +** WARNING **: preferred cursive font "URW Chancery L" not found. +Nav_open_url: new url='https://gopher.floodgap.com/gopher/gw' +[New Thread 0x7ffff61f66c0 (LWP 663334)] +Dns_server [0]: gopher.floodgap.com is 107.132.118.74 +[Thread 0x7ffff61f66c0 (LWP 663334) exited] +Connecting to 107.132.118.74:443 +gopher.floodgap.com: TLSv1.2, cipher ECDHE-RSA-AES128-GCM-SHA256 +sha256 2048-bit RSA: /CN=gopher.floodgap.com +sha256 2048-bit RSA: /C=US/O=Let's Encrypt/CN=R3 +sha256 4096-bit RSA: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 +root: /O=Digital Signature Trust Co./CN=DST Root CA X3 +Layout::resizeIdle calls = 1 +Layout::resizeIdle calls = 2 +Layout::resizeIdle calls = 3 +Layout::resizeIdle calls = 4 +Layout::resizeIdle calls = 5 +Layout::resizeIdle calls = 6 +Layout::resizeIdle calls = 7 +Layout::resizeIdle calls = 8 +Layout::resizeIdle calls = 9 +Layout::resizeIdle calls = 10 +TLS ALERT on write: decode error +Layout::resizeIdle calls = 11 +TLS ALERT on write: decode error +Layout::resizeIdle calls = 12 +TLS ALERT on write: decode error +Layout::resizeIdle calls = 13 +TLS ALERT on write: decode error +Layout::resizeIdle calls = 14 +a_Tls_openssl_connect: queued error: error:0A000126:SSL routines::unexpected eof while reading +a_Tls_openssl_connect: queued error: error:0A000126:SSL routines::unexpected eof while reading +a_Tls_openssl_connect: queued error: error:0A000126:SSL routines::unexpected eof while reading +a_Tls_openssl_connect: queued error: error:0A000126:SSL routines::unexpected eof while reading + +Thread 1 "dillo" received signal SIGABRT, Aborted. +0x00007ffff6eac83c in ?? () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff6eac83c in ?? () from /usr/lib/libc.so.6 +#1 0x00007ffff6e5c668 in raise () from /usr/lib/libc.so.6 +#2 0x00007ffff6e444b8 in abort () from /usr/lib/libc.so.6 +#3 0x00005555555e1c84 in a_Tls_openssl_connect (fd=10, url=0x555555ae5e10) at IO/../../../src/IO/tls_openssl.c:1212 +#4 0x00005555555df180 in a_Tls_connect (fd=10, url=0x555555ae5e10) at IO/../../../src/IO/tls.c:130 +#5 0x00005555555dd349 in Http_connect_tls (info=0x555555adc5c0) at IO/../../../src/IO/http.c:521 +#6 0x00005555555dd51c in Http_connect_socket_cb (fd=10, data=0x5) at IO/../../../src/IO/http.c:555 +#7 0x00007ffff7e0111d in fl_wait(double) () from /usr/lib/libfltk.so.1.3 +#8 0x00007ffff7da36bb in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 +#9 0x00007ffff7da37da in Fl::run() () from /usr/lib/libfltk.so.1.3 +#10 0x00005555555a9c4f in main (argc=2, argv=0x7fffffffd838) at ../../src/dillo.cc:578 +``` + +--%-- +From: rodarima +Date: Sat, 10 Feb 2024 23:17:51 +0000 + +Using mbedTLS 2 and 3 work fine. Dillo is fetching 4 more resources over the same TLS session: + +``` +% src/dillo https://gopher.floodgap.com/gopher/gw +dillo_dns_init: Here we go! (threaded) +TLS library: mbed TLS 3.4.1 +Trusting 146 TLS certificates. +Enabling cookies as from cookiesrc... +** WARNING **: preferred cursive font "URW Chancery L" not found. +Nav_open_url: new url='https://gopher.floodgap.com/gopher/gw' +Dns_server [0]: gopher.floodgap.com is 107.132.118.74 +Connecting to 107.132.118.74:443 +TLS: Fetching https://gopher.floodgap.com/gopher/gw +gopher.floodgap.com TLSv1.2, cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 +Layout::resizeIdle calls = 1 +Layout::resizeIdle calls = 2 +Layout::resizeIdle calls = 3 +Layout::resizeIdle calls = 4 +Layout::resizeIdle calls = 5 +Layout::resizeIdle calls = 6 +Layout::resizeIdle calls = 7 +TLS: Fetching https://gopher.floodgap.com/gopher/icons/text.gif +TLS: Fetching https://gopher.floodgap.com/gopher/icons/search.gif +Layout::resizeIdle calls = 8 +TLS: Fetching https://gopher.floodgap.com/gopher/icons/menu.gif +Layout::resizeIdle calls = 9 +Layout::resizeIdle calls = 10 +Layout::resizeIdle calls = 11 +TLS: Fetching https://gopher.floodgap.com/gopher/icons/url.gif +Layout::resizeIdle calls = 12 +Layout::resizeIdle calls = 13 +Layout::resizeIdle calls = 14 +Layout::resizeIdle calls = 15 +``` + +--%-- +From: rodarima +Date: Sat, 10 Feb 2024 23:33:37 +0000 + +LibreSSL 3.8.2 works fine too + +--%-- +From: rodarima +Date: Sun, 11 Feb 2024 10:38:14 +0000 + +In OpenSSL, SSL_in_init() is returning 1, so the branch that shutsdown the SSL connection is not taken, calling SSL_free() directly. On LibreSSL this doesn't happen, and the connection is shutdown first. + +--%-- +From: rodarima +Date: Mon, 12 Feb 2024 23:03:50 +0000 + +Rebuilding OpenSSL 3.2.1 with debug symbols produces this backtrace when the alert is issued: +``` +(gdb) bt +#0 Tls_info_cb (ssl=0x555555907e00, where=16392, ret=562) at IO/../../../src/IO/tls_openssl.c:193 +#1 0x00007ffff70f4f0a in ssl3_dispatch_alert (s=0x555555907e00) at ssl/s3_msg.c:155 +#2 0x00007ffff70f4b66 in ssl3_send_alert (s=0x555555907e00, level=2, desc=50) at ssl/s3_msg.c:69 +#3 0x00007ffff7191009 in ossl_statem_send_fatal (s=0x555555907e00, al=50) at ssl/statem/statem.c:152 +#4 0x00007ffff71910db in ossl_statem_fatal (s=0x555555907e00, al=50, reason=294, fmt=0x0) at ssl/statem/statem.c:170 +#5 0x00007ffff716ba70 in ossl_tls_handle_rlayer_return (s=0x555555907e00, writing=0, ret=-3, file=0x7ffff71ca130 "ssl/record/rec_layer_s3.c", line=645) at ssl/record/rec_layer_s3.c:475 +#6 0x00007ffff716c047 in ssl3_read_bytes (ssl=0x555555907e00, type=23 '\027', recvd_type=0x0, + buf=0x7fffffffb3d0 " \"/gopher/gw\">Floodgap home gopher</a> </td>\n<td align = \"center\" valign=\"middle\">version 632 port 2</td>\n<td align = \"right\" valign = \"middle\"><i>All access must be in\naccordance with <a href = \"http"..., len=8192, peek=0, readbytes=0x7fffffffb310) at ssl/record/rec_layer_s3.c:645 +#7 0x00007ffff70f30c4 in ssl3_read_internal (s=0x555555907e00, buf=0x7fffffffb3d0, len=8192, peek=0, readbytes=0x7fffffffb310) at ssl/s3_lib.c:4528 +#8 0x00007ffff70f3194 in ssl3_read (s=0x555555907e00, buf=0x7fffffffb3d0, len=8192, readbytes=0x7fffffffb310) at ssl/s3_lib.c:4551 +#9 0x00007ffff71065c9 in ssl_read_internal (s=0x555555907e00, buf=0x7fffffffb3d0, num=8192, readbytes=0x7fffffffb310) at ssl/ssl_lib.c:2343 +#10 0x00007ffff7106664 in SSL_read (s=0x555555907e00, buf=0x7fffffffb3d0, num=8192) at ssl/ssl_lib.c:2357 +#11 0x00005555555e2208 in a_Tls_openssl_read (conn=0x555555903480, buf=0x7fffffffb3d0, len=8192) at IO/../../../src/IO/tls_openssl.c:1276 +#12 0x00005555555df233 in a_Tls_read (conn=0x555555903480, buf=0x7fffffffb3d0, len=8192) at IO/../../../src/IO/tls.c:158 +#13 0x00005555555e4588 in IO_read (io=0x555555901fa0) at IO/../../../src/IO/IO.c:172 +#14 0x00005555555e4941 in IO_callback (io=0x555555901fa0) at IO/../../../src/IO/IO.c:273 +#15 0x00005555555e49ef in IO_fd_read_cb (fd=6, data=0x1) at IO/../../../src/IO/IO.c:294 +#16 0x00007ffff7e0111d in fl_wait(double) () from /usr/lib/libfltk.so.1.3 +#17 0x00007ffff7da36bb in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 +#18 0x00007ffff7da37da in Fl::run() () from /usr/lib/libfltk.so.1.3 +#19 0x00005555555a9c4f in main (argc=2, argv=0x7fffffffd828) at ../../src/dillo.cc:578 +``` + +--%-- +From: rodarima +Date: Tue, 13 Feb 2024 22:08:12 +0000 + +So, what seems to be hapenning is that the server is sending the page in small chunks but there is some delay in sending the last parts, and then OpenSSL cannot decode it: + + + +However, the parts being decoded are enough for Dillo to begin requesting other parts of the website, which spawn another three extra connections *before* the complete page is sent: + + + +Can this be a limit on the server of only 3 connections per client? + +--%-- +From: rodarima +Date: Tue, 13 Feb 2024 22:16:58 +0000 + +Setting `http_max_conn=1` in dillorc continues to cause the same problem, but this time there are no other request in flight: + + + + +--%-- +From: rodarima +Date: Tue, 13 Feb 2024 22:29:49 +0000 + +A similar problem is reproduced with cURL and OpenSSL: + +``` +% curl -sv https://gopher.floodgap.com/gopher/gw > /dev/null +* Trying 107.132.118.74:443... +* Connected to gopher.floodgap.com (107.132.118.74) port 443 +* ALPN: curl offers h2,http/1.1 +} [5 bytes data] +* TLSv1.3 (OUT), TLS handshake, Client hello (1): +} [512 bytes data] +* CAfile: /etc/ssl/certs/ca-certificates.crt +* CApath: none +{ [5 bytes data] +* TLSv1.3 (IN), TLS handshake, Server hello (2): +{ [57 bytes data] +* TLSv1.2 (IN), TLS handshake, Certificate (11): +{ [3972 bytes data] +* TLSv1.2 (IN), TLS handshake, Server key exchange (12): +{ [333 bytes data] +* TLSv1.2 (IN), TLS handshake, Server finished (14): +{ [4 bytes data] +* TLSv1.2 (OUT), TLS handshake, Client key exchange (16): +} [70 bytes data] +* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): +} [1 bytes data] +* TLSv1.2 (OUT), TLS handshake, Finished (20): +} [16 bytes data] +* TLSv1.2 (IN), TLS handshake, Finished (20): +{ [16 bytes data] +* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 +* ALPN: server did not agree on a protocol. Uses default. +* Server certificate: +* subject: CN=gopher.floodgap.com +* start date: Jan 1 12:33:16 2024 GMT +* expire date: Mar 31 12:33:15 2024 GMT +* subjectAltName: host "gopher.floodgap.com" matched cert's "gopher.floodgap.com" +* issuer: C=US; O=Let's Encrypt; CN=R3 +* SSL certificate verify ok. +* using HTTP/1.x +} [5 bytes data] +> GET /gopher/gw HTTP/1.1 +> Host: gopher.floodgap.com +> User-Agent: curl/8.4.0 +> Accept: */* +> +{ [5 bytes data] +< HTTP/1.1 200 Floodgap Gopher Proxy Okay +< Server: gopher/gw +< Content-type: text/html +< Connection: close +< +{ [923 bytes data] +* OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0 +* Closing connection +} [5 bytes data] +* TLSv1.2 (OUT), TLS alert, close notify (256): +} [2 bytes data] +% echo $? +56 +``` + +However, they only send a close notify alert and then close the connection: + + + + +--%-- +From: rodarima +Date: Tue, 13 Feb 2024 22:33:21 +0000 + +With OpenSSL 3.1.4, cURL doesn't exit with an error: + +``` +% curl -vq https://gopher.floodgap.com/gopher/gw > /dev/null + % Total % Received % Xferd Average Speed Time Time Time Current + Dload Upload Total Spent Left Speed + 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 107.132.118.74:443... +* Connected to gopher.floodgap.com (107.132.118.74) port 443 +* ALPN: curl offers h2,http/1.1 +} [5 bytes data] +* TLSv1.3 (OUT), TLS handshake, Client hello (1): +} [512 bytes data] +* CAfile: /etc/ssl/certs/ca-certificates.crt +* CApath: none +{ [5 bytes data] +* TLSv1.3 (IN), TLS handshake, Server hello (2): +{ [57 bytes data] +* TLSv1.2 (IN), TLS handshake, Certificate (11): +{ [3972 bytes data] +* TLSv1.2 (IN), TLS handshake, Server key exchange (12): +{ [333 bytes data] +* TLSv1.2 (IN), TLS handshake, Server finished (14): +{ [4 bytes data] +* TLSv1.2 (OUT), TLS handshake, Client key exchange (16): +} [70 bytes data] +* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): +} [1 bytes data] +* TLSv1.2 (OUT), TLS handshake, Finished (20): +} [16 bytes data] + 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* TLSv1.2 (IN), TLS handshake, Finished (20): +{ [16 bytes data] +* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 +* ALPN: server did not agree on a protocol. Uses default. +* Server certificate: +* subject: CN=gopher.floodgap.com +* start date: Jan 1 12:33:16 2024 GMT +* expire date: Mar 31 12:33:15 2024 GMT +* subjectAltName: host "gopher.floodgap.com" matched cert's "gopher.floodgap.com" +* issuer: C=US; O=Let's Encrypt; CN=R3 +* SSL certificate verify ok. +* using HTTP/1.x +} [5 bytes data] +> GET /gopher/gw HTTP/1.1 +> Host: gopher.floodgap.com +> User-Agent: curl/8.4.0 +> Accept: */* +> +{ [5 bytes data] +< HTTP/1.1 200 Floodgap Gopher Proxy Okay +< Server: gopher/gw +< Content-type: text/html +< Connection: close +< +{ [923 bytes data] +100 19659 0 19659 0 0 8834 0 --:--:-- 0:00:02 --:--:-- 8835 +* Closing connection +} [5 bytes data] +* TLSv1.2 (OUT), TLS alert, close notify (256): +} [2 bytes data] +% echo $? +0 +``` + +--%-- +From: rodarima +Date: Sat, 17 Feb 2024 09:41:01 +0000 + +Related: + +> $ man SSL_get_error +> ... +> NOTES +> Some TLS implementations do not send a close_notify alert on shutdown. +> +> On an unexpected EOF, versions before OpenSSL 3.0 returned SSL_ERROR_SYSCALL, nothing was added to the error stack, and errno was 0. Since OpenSSL 3.0 the returned error is SSL_ERROR_SSL with a meaningful error on the error stack. diff --git a/8/index.md b/8/index.md new file mode 100644 index 0000000..3b1e86b --- /dev/null +++ b/8/index.md @@ -0,0 +1,59 @@ +Title: Duckduckgo search is broken +Author: rodarima +Created: Fri, 08 Dec 2023 20:20:42 +0000 +State: closed + +When searching a term via the duckduckgo default search option, all the results are broken. + +This seems to be happening because the results are a link to a duckduckgo redirection page, with a broken noscript+meta refresh tag inside the body: + +Query: https://lite.duckduckgo.com/lite/?kp=-1&q=arch +First link: https://duckduckgo.com/l/?uddg=https%3A%2F%2Farchlinux.org%2F&rut=da8bb6bd1cd584ec22ab762b3b772597b539d583acf75aaab0a45c2b330f4a90 + +Content: +``` +<html> +<head> + <meta name='referrer' content='origin'> +</head> +<body> + <script language='JavaScript'>window.parent.location.replace("https://archlinux.org/");</script> + <noscript><META http-equiv='refresh' content="0;URL=https://archlinux.org/"></noscript> +</body> +</html> +``` + +The bug section of dillo warns about it: + +``` +HTML warning: line 1, The required DOCTYPE declaration is missing. Handling as HTML4. +HTML warning: line 1, <head> lacks <title>. +HTML warning: line 1, This <meta> element must be inside the HEAD section. <-- here +``` + +The easiest solution would be to switch to the full duckduckgo page by default (not the lite version) which seems to work fine. + +--%-- +From: rodarima +Date: Sat, 09 Dec 2023 14:18:05 +0000 + +[Here](https://salsa.debian.org/debian/dillo/-/blob/master/debian/patches/fix-duckduckgo-shortcut-in-dillorc.patch) is another solution adding the `kd=-1` argument which avoids the redirection: + +```patch +Description: Fix DuckDuckGo shortcut to make result links working +Bug-Debian: https://bugs.debian/org/924357 +Forwarded: no +Author: liftof+dbug@gmail.com + +--- a/dillorc ++++ b/dillorc +@@ -157,7 +157,7 @@ + # You can enable multiple search_url strings at once and select from among + # them at runtime, with the first being the default. + # (the prefix serves to search from the Location Bar. e.g. "dd dillo image") +-search_url="dd DuckDuckGo (https) https://duckduckgo.com/lite/?kp=-1&q=%s" ++search_url="dd DuckDuckGo (https) https://duckduckgo.com/lite/?kp=-1&q=%s&kd=-1" + search_url="Wikipedia http://www.wikipedia.org/w/index.php?search=%s&go=Go" + search_url="Free Dictionary http://www.thefreedictionary.com/%s" + search_url="Startpage (https) https://www.startpage.com/do/search?query=%s" +```
\ No newline at end of file diff --git a/80/index.md b/80/index.md new file mode 100644 index 0000000..c336654 --- /dev/null +++ b/80/index.md @@ -0,0 +1,10 @@ +Title: Handle errors in SSL_read() and SSL_write() +Author: rodarima +Created: Sat, 17 Feb 2024 12:04:39 +0000 +State: closed + +We cannot rely on the return value and the errno, the function SSL_get_error() must be used to determine what happen and if we need to retry again. A wrapper function translates the SSL error into a proper errno value. + +In the case a premature EOF is sent by the server, the error queue is emptied before the error is returned. + +Fixes: https://github.com/dillo-browser/dillo/issues/79
\ No newline at end of file diff --git a/81/index.md b/81/index.md new file mode 100644 index 0000000..2fa6324 --- /dev/null +++ b/81/index.md @@ -0,0 +1,6 @@ +Title: Opening file:~/.dillo/ fails +Author: rodarima +Created: Sun, 18 Feb 2024 13:11:27 +0000 +State: closed + +Opening `file:~/.dillo/` fails or any other existing directory in home, but `file:~` works well.
\ No newline at end of file diff --git a/82/index.md b/82/index.md new file mode 100644 index 0000000..360b864 --- /dev/null +++ b/82/index.md @@ -0,0 +1,8 @@ +Title: Expand tilde to home directory in local URLs +Author: rodarima +Created: Sun, 18 Feb 2024 15:07:39 +0000 +State: closed + +Allows paths like `file:~/` and `file:~/.dillo/dillorc` to be opened by Dillo by expanding the tilde character `~` to the value of the `$HOME` environment variable. + +Fixes: https://github.com/dillo-browser/dillo/issues/81
\ No newline at end of file diff --git a/83/index.md b/83/index.md new file mode 100644 index 0000000..5a16286 --- /dev/null +++ b/83/index.md @@ -0,0 +1,6 @@ +Title: Improve help page +Author: rodarima +Created: Sun, 18 Feb 2024 18:46:29 +0000 +State: closed + +Adresses #73
\ No newline at end of file diff --git a/84/index.md b/84/index.md new file mode 100644 index 0000000..c124672 --- /dev/null +++ b/84/index.md @@ -0,0 +1,52 @@ +Title: Bad rendering of https://forums.irixnet.org/thread-2819.html +Author: rodarima +Created: Tue, 20 Feb 2024 21:24:22 +0000 +State: closed + +Bad rendering of https://forums.irixnet.org/thread-2819.html + +With 6f66fd861ef1d1bd583c31c2ce3d9c4a9896ede1 rendering is okay: +<img src="https://github.com/dillo-browser/dillo/assets/3866127/42a65669-e3cd-487d-b51c-9da7ab89e55c" width="300"> + + +But after 24bcd67df29a5418d05600b038a9283a00e555d2 there is a problem with the layout: +<img src="https://github.com/dillo-browser/dillo/assets/3866127/00c40276-3af8-40f6-b3a2-3fd83b3e5829" width=300> + + +--%-- +From: rodarima +Date: Mon, 26 Feb 2024 15:48:24 +0000 + +Reproduced: +```html +<!DOCTYPE html> +<html> + <body> + <table> + <tr> + <td width="200" style="background: lightblue"> + The next cell is 15% + </td> + <td width="30%" style="background: lightgreen"> + <div> + <img src="pic.png"> + </div> + </td> + </tr> + </table> + </body> +</html> + +``` + +--%-- +From: rodarima +Date: Tue, 27 Feb 2024 22:04:55 +0000 + +There are two problems here: +- Using the td *attribute* `width` is **not valid**. In HTML 5 the width attribute is obsolete, and in HTML 4.01 [is deprecated](https://www.w3.org/TR/html401/struct/tables.html#adef-width-TH). Only in transitional HTML 4.01 this is acceptable. +- The available width for the text in the cell is not matching the cell margin box. This is causing missing content. + +Also the HTML 4.01 specification states that the [percent length](https://www.w3.org/TR/html401/types.html#type-length) refers to the space available to the table, not the table size itself, which currently Dillo does properly: + +> A percentage specification (e.g., width="20%") is based on the percentage of the horizontal space available to the table (between the current left and right margins, including floats). Note that this space does not depend on the table itself, and thus percentage specifications enable incremental rendering.
\ No newline at end of file diff --git a/85/index.md b/85/index.md new file mode 100644 index 0000000..0bb1232 --- /dev/null +++ b/85/index.md @@ -0,0 +1,37 @@ +Title: Consider integrating the RTFL library into Dillo +Author: rodarima +Created: Mon, 26 Feb 2024 23:03:06 +0000 +State: closed + +Sebastian Geerken developed the RTFL library to ease the debugging of Dillo: + +> RTFL, which stands for "Read The Figurative Logfile", is a both a +protocol for structured debug messages, as well as a collection of +programs (currently two) displaying these debug messages in a +semi-graphical way, so that it becomes simpler to determine what the +debugged program does. +> +> Programs are prepared to print these special debug messages to +standard output, which are then passed to a viewer program like +"rtfl-objcount" or "rtfl-objview". + + +It is stored on the web archive: https://web.archive.org/web/20170310013459/http://home.gna.org/rtfl + +Here is an snapshot from Sebastian: + + + + +I'll also upload it here to save a copy: [rtfl-0.1.1.tar.gz](https://github.com/dillo-browser/dillo/files/14412264/rtfl-0.1.1.tar.gz) + +Dillo must be configure with `--enable-rtfl` to use it. + + +--%-- +From: rodarima +Date: Tue, 10 Dec 2024 22:04:03 +0000 + +Uploaded to https://github.com/dillo-browser/rtfl + +There is no need to add it to Dillo repository, we can keep it in its own.
\ No newline at end of file diff --git a/86/index.md b/86/index.md new file mode 100644 index 0000000..868b29c --- /dev/null +++ b/86/index.md @@ -0,0 +1,18 @@ +Title: Ignore td relative width attribute +Author: rodarima +Created: Tue, 27 Feb 2024 23:43:02 +0000 +State: closed + +Fixes #84, #54 + +Before: + + +After: + + +See the date in the top right corner being cut: + + +Which is now visible: + diff --git a/87/index.md b/87/index.md new file mode 100644 index 0000000..b422f1d --- /dev/null +++ b/87/index.md @@ -0,0 +1,8 @@ +Title: Fix leak of tmp variable +Author: rodarima +Created: Sat, 02 Mar 2024 18:43:16 +0000 +State: closed + +Introduced by https://github.com/dillo-browser/dillo/pull/82. + +Reported-by: dogma
\ No newline at end of file diff --git a/88/index.md b/88/index.md new file mode 100644 index 0000000..69b316c --- /dev/null +++ b/88/index.md @@ -0,0 +1,30 @@ +Title: Resolve / and ~/ to local directories +Author: rodarima +Created: Sat, 02 Mar 2024 18:51:35 +0000 +State: open + +Currently they are resolving to http, which doesn't make much sense. + +Commented-by: dogma + +--%-- +From: zzo38 +Date: Tue, 02 Apr 2024 23:13:13 +0000 + +I would rather want a "relative mode". For example, if the current URL is `http://example.net/examples/42.html` and you type `/` then it will go to `http://example.net/` and if you type `~/` then it will go to `http://example.net/examples/~/`. It would do this with all URLs, not only those ones. If you include the scheme then it is an absolute URL. (I have managed to modify Firefox to work like this.) + +--%-- +From: rodarima +Date: Wed, 03 Apr 2024 09:49:40 +0000 + +> I would rather want a "relative mode". For example, if the current URL is `http://example.net/examples/42.html` and you type `/` then it will go to `http://example.net/` and if you type `~/` then it will go to `http://example.net/examples/~/`. It would do this with all URLs, not only those ones. If you include the scheme then it is an absolute URL. (I have managed to modify Firefox to work like this.) + +I opened #119 to address this specific feature. This issue is to solve the problem of running: + +``` +$ dillo '~/' +``` + +And end up loading `http://~/`. + +Loading paths that start with `/` already works from the command line, including only `/` (opens `file:/`). But not if opened directly from the location bar, which tries to load `http:/`.
\ No newline at end of file diff --git a/89/index.md b/89/index.md new file mode 100644 index 0000000..6565f7d --- /dev/null +++ b/89/index.md @@ -0,0 +1,307 @@ +Title: Missing column in table with max-width and min-width +Author: rodarima +Created: Sat, 02 Mar 2024 20:59:11 +0000 +State: closed + +There should be three columns: + + +Reproducer: + +```html +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <title>Test table in container with max-width and min-width</title> + <style type="text/css"> + .main { + background: lightgreen; + max-width: 500px; + min-width: 200px; + padding: 10px; + } + table, th, td { + padding: 0.25em; + background: lightblue; + border: solid 1px black; + } + </style> +</head> +<body> + <div class="main"> + <table width="100%"> + <tr> + <th>AAAAAA</th> + <th>BBBBBB</th> + <th>CCCCCC</th> + </tr> + <tr> + <td>aaaaaa</td> + <td>bbbbbb</td> + <td>cccccc</td> + </tr> + </table> + </div> +</body> +</html> +``` + +--%-- +From: rodarima +Date: Sun, 10 Mar 2024 12:00:23 +0000 + +So, this problem is happening because the table gets an allocation smaller than the container div, even though the CSS style has a 100% width (the table `width` attribute is converted to a CSS value): + + + + + + +As the table doesn't have the `auto` value, it enters [this branch](https://github.com/dillo-browser/dillo/blob/d61bf779f41617bbc31c3c5697e9275a6fbb1bcd/dw/table.cc#L942-L952) when updating the table size, setting `totalWidthSpecified` to `true`: + +```c++ + // CSS 'width' defined and effective? + bool totalWidthSpecified = false; + if (getStyle()->width != core::style::LENGTH_AUTO) { + // Even if 'width' is defined, it may not have a defined value. We try + // this trick (should perhaps be replaced by a cleaner solution): + core::Requisition testReq = { -1, -1, -1 }; + correctRequisition (&testReq, core::splitHeightPreserveDescent, true, + false); + if (testReq.width != -1) + totalWidthSpecified = true; + } +``` + +This flag causes it to enter [the "case 2" branch](https://github.com/dillo-browser/dillo/blob/d61bf779f41617bbc31c3c5697e9275a6fbb1bcd/dw/table.cc#L1049) of the size calculation for tables: + +```c++ + } else if (totalWidthSpecified && totalWidth > maxWidth) { + DBG_OBJ_MSG ("resize", 1, + "case 2: totalWidthSpecified && totalWidth > maxWidth"); + + // The width is specified (and so enforced), but all maxima sum + // up to less than this specified width. The columns will have + // there maximal width, and the extra space is apportioned + // according to the column widths, and so to the column + // maxima. This is done by simply passing MAX twice to the + // apportioning function. + + // When column widths are specified (numColWidthSpecified > 0, + // as calculated in forceCalcColumnExtremes()), they are treated + // specially and excluded from the apportioning, so that the + // specified column widths are enforced. An exception is when + // all columns are specified: in this case they must be + // enlargened to fill the whole table width. +``` + +--%-- +From: rodarima +Date: Sun, 10 Mar 2024 12:08:27 +0000 + +The table doesn't have any width specification among columns (`numColWidthSpecified` is 0), so it enters this [branch](https://github.com/dillo-browser/dillo/blob/d61bf779f41617bbc31c3c5697e9275a6fbb1bcd/dw/table.cc#L1067-L1073), which calls the `Table::apportion2()` method: + +```c++ + if (numColWidthSpecified == 0 || + numColWidthSpecified == colExtremes->size()) { + DBG_OBJ_MSG ("resize", 1, + "subcase 2a: no or all columns with specified width"); + apportion2 (totalWidth, 0, colExtremes->size() - 1, MAX, MAX, NULL, + colWidths, 0); + } else { +``` +With this arguments (this is the first call): +``` +dw::Table::apportion2 (this=0x5555558452a0, totalWidth=488, firstCol=0, + lastCol=-1, minExtrMod=dw::Table::MAX, + maxExtrMod=dw::Table::MAX, extrData=0x0, + dest=0x5555559185c0, destOffset=0) +``` +The `totalWidth` is still correct, as it comes from the 500 px of the parent div, minus some border width. As `lastCol=-1` and `firstCol=0` no cell width computation is done (the table has no cells yet). It returns to `dw::Table::forceCalcCellSizes()` without modifying any cell sizes. + +--%-- +From: rodarima +Date: Sun, 10 Mar 2024 12:41:48 +0000 + +After `dw::Table::forceCalcCellSizes()` returns to `dw::Table::sizeRequestSimpl`, a [requisition correction is made](https://github.com/dillo-browser/dillo/blob/d61bf779f41617bbc31c3c5697e9275a6fbb1bcd/dw/table.cc#L112-L125): + +```c++ + /** + * \bug Baselines are not regarded here. + */ + requisition->width = + boxDiffWidth () + (numCols + 1) * getStyle()->hBorderSpacing; + for (int col = 0; col < numCols; col++) + requisition->width += colWidths->get (col); + + requisition->ascent = + boxDiffHeight () + cumHeight->get (numRows) + getStyle()->vBorderSpacing; + requisition->descent = 0; + + correctRequisition (requisition, core::splitHeightPreserveDescent, true, + false); +``` + +With the following values (before the `correctRequision()` call: + +``` +(gdb) p *requisition +$37 = {width = 12, ascent = 12, descent = 0} +``` + +This is taken by `dw::core::Widget::correctRequisition()` with `parent != NULL` and `quasiParent == NULL`, so [it delegates it to the parent](https://github.com/dillo-browser/dillo/blob/d61bf779f41617bbc31c3c5697e9275a6fbb1bcd/dw/widget.cc#L802-L808): +```c++ + } else if (parent) { + DBG_OBJ_MSG ("resize", 1, "delegated to parent"); + DBG_OBJ_MSG_START (); + parent->correctRequisitionOfChild (this, requisition, splitHeightFun, + allowDecreaseWidth, + allowDecreaseHeight); + DBG_OBJ_MSG_END (); +``` + +The parent (the `div` which is a `dw::Textblock`) then calls `dw::core::Widget::correctReqWidthOfChild()` and then `dw::core::Widget::calcFinalWidth`: + +``` +(gdb) +dw::core::Widget::calcFinalWidth (this=0x5555558449f0, style=0x555555912f40, + refWidth=-1, refWidget=0x555555849d70, + limitMinWidth=10, forceValue=false, finalWidth=0x7fffffffd3bc) + at ../../dw/widget.cc:938 +938 int width = calcWidth (style->width, refWidth, refWidget, limitMinWidth, +(gdb) p *finalWidth +$56 = 12 +``` + +--%-- +From: rodarima +Date: Sun, 10 Mar 2024 12:53:29 +0000 + +In `dw::core::Widget::calcFinalWidth()`, the width is computed by the CSS style which indicates `width: 100%`: +``` +(gdb) p (100. * dw::core::style::perLengthVal_useThisOnlyForDebugging(cssValue)) +$68 = 100 +``` +In `dw::core::Widget::calcWidth()`, `refWidth == -1` so the table [asks the div to provide the available width](https://github.com/dillo-browser/dillo/blob/d61bf779f41617bbc31c3c5697e9275a6fbb1bcd/dw/widget.cc#L906-L914): + +```c++ + else { + int availWidth = refWidget->getAvailWidth (forceValue); + if (availWidth != -1) { + int containerWidth = availWidth - refWidget->boxDiffWidth (); + width = misc::max (applyPerWidth (containerWidth, cssValue), + limitMinWidth); + } else + width = -1; + } +``` + +The value `width` is set to `220` by [calcFinalWidth()](https://github.com/dillo-browser/dillo/blob/d61bf779f41617bbc31c3c5697e9275a6fbb1bcd/dw/widget.cc#L680-L683) when constraining by the div min-width value: + +```c++ + /* Constraint the width with min-width and max-width */ + calcFinalWidth (getStyle (), refWidth, NULL, 0, forceValue, &width); + if (width == -1) + width = refWidth; +``` +So here is where it goes wrong. + +--%-- +From: rodarima +Date: Sun, 10 Mar 2024 21:02:09 +0000 + +I modified the test case so the text in the cells have an space, so the extremes are different. A cell can be made smaller until the longes word, and it can be made bigger until all the words are in the same line, at which point there is not need to make it bigger: + +```html +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <title>Test table in container with max-width and min-width</title> + <style type="text/css"> + .main { + background: lightgreen; + max-width: 500px; + min-width: 200px; + padding: 10px; + } + table, th, td { + padding: 0.25em; + background: lightblue; + border: solid 1px black; + } + </style> +</head> +<body> + <div class="main"> + <table width="100%"> + <tr> + <th>AAA AAA</th> + <th>BBB BBB</th> + <th>CCC CCC</th> + </tr> + <tr> + <td>aaa aaa</td> + <td>bbb bbb</td> + <td>ccc ccc</td> + </tr> + </table> + </div> +</body> +</html> +``` + +With the test, the extremes now show the different values 144 and 255 for the table, for the intrinsic values: + + + +But the minWidth and maxWidth both show 200. The maxWidth should be around 500 pixels, as it is the contentWidth available in the container div. + +--%-- +From: rodarima +Date: Sun, 10 Mar 2024 22:53:31 +0000 + +The problem is caused by [this correctRequisition()](https://github.com/dillo-browser/dillo/blob/d61bf779f41617bbc31c3c5697e9275a6fbb1bcd/dw/table.cc#L124), which sets the witdh to 200 instead of leaving the correct value in 500. Adding a simple patch to comment the correction leads to a proper table: + + + +I need to investigate what is causing the correctRequisition() call to reduce the width to 200, as it should be left as is. + +--%-- +From: rodarima +Date: Sun, 10 Mar 2024 22:58:50 +0000 + +This also solves (one of) the layouting issue(s) of Hacker News: + + + +Which had a table too small: + + + + +--%-- +From: rodarima +Date: Sun, 17 Mar 2024 09:32:27 +0000 + +The issue was far more complicated than just the requisition being corrected to a smaller value. I needed to develop a mechanism to instrument calls to see what was going on: + + + +Basically, there are two tasks to perform: + +- Compute the available with of the table so it can size the columns. +- Return the size of the table. + +The first task was using an incorrect width, as the Widget and Textblock logic handle the case when the CSS width is set to auto in a different way. In this branch, the min-width and max-width of CSS were not used. + +The second problem is that when the available width is queried for a widget of which the width is set to auto, the min-width was setting the width first, not expanding the value to max-width in Widget::calcFinalWidth(). + +Fixing these two issues solves the problem. + +--%-- +From: rodarima +Date: Sun, 17 Mar 2024 18:40:13 +0000 + +The requisition correction is breaking Hacker News, but not this particular test, so let's handle that in another issue.
\ No newline at end of file diff --git a/9/index.md b/9/index.md new file mode 100644 index 0000000..f9188cd --- /dev/null +++ b/9/index.md @@ -0,0 +1,6 @@ +Title: Add CI with github actions +Author: rodarima +Created: Sun, 10 Dec 2023 23:57:55 +0000 +State: closed + +Adds a CI and fixes some problems with the distcheck target.
\ No newline at end of file diff --git a/90/index.md b/90/index.md new file mode 100644 index 0000000..84d1410 --- /dev/null +++ b/90/index.md @@ -0,0 +1,20 @@ +Title: Fix table with max-width and min-width +Author: rodarima +Created: Sat, 02 Mar 2024 21:04:19 +0000 +State: closed + +Fix #89 + +--%-- +From: rodarima +Date: Sun, 17 Mar 2024 12:25:06 +0000 + +It breaks another case where a widget with `width: auto` and `max-width: 9999px` gets a width larger than the viewport. + + + +And similarly, it set the available width to `min-width` when `width` is set to auto: + + + +I added both tests.
\ No newline at end of file diff --git a/91/index.md b/91/index.md new file mode 100644 index 0000000..43e06bf --- /dev/null +++ b/91/index.md @@ -0,0 +1,41 @@ +Title: Building under Termux half-fails +Author: Usinganame +Created: Sun, 03 Mar 2024 17:10:42 +0000 +State: closed + +When running make, it generates various warnings and an error. Apparently it has an undeclared function "bzero". It still compiles though, the binary is in the src/ directory and it's runnable. It works for the most part except for downloads. + +I tried to fix it myself by putting +`#include <strings.h>` +Into dpid.c. +That still doesn't work. When I ran configure it stated that I have strings.h, so why won't it work? + +Here is the specific error generated by make + + + +--%-- +From: rodarima +Date: Sun, 03 Mar 2024 17:21:28 +0000 + +Good catch. + +The `bzero()` function has been deprecated in POSIX.1-2001 and removed from POSIX.1-2008, we shouldn't be using it. + +Replace bzero() call in line 82 by: + +```c +memset(&serv_addr, 0, sizeof(serv_addr)); +``` + +There is another one in line 101, which should be: + +```c +memset(buffer, 0, 256); +``` + +Let's see if that fixes it. + +> It still compiles though, the binary is in the src/ directory and it's runnable. + +Well, it compiles first src/dillo, but fails to build the dpid program (and stops) which is used to comunicate with the plugins.
\ No newline at end of file diff --git a/92/index.md b/92/index.md new file mode 100644 index 0000000..37539be --- /dev/null +++ b/92/index.md @@ -0,0 +1,8 @@ +Title: Use memset() instead of bzero() +Author: rodarima +Created: Sun, 03 Mar 2024 17:32:21 +0000 +State: closed + +The bzero() function is removed in POSIX.1-2008. + +Fixes: https://github.com/dillo-browser/dillo/issues/91
\ No newline at end of file diff --git a/93/index.md b/93/index.md new file mode 100644 index 0000000..060415d --- /dev/null +++ b/93/index.md @@ -0,0 +1,65 @@ +Title: Add support for the "download" attribute +Author: dirwiz +Created: Thu, 07 Mar 2024 20:28:44 +0000 +State: open + +Happy to see Dillo active again! This is just a wish list item, Data URL support would be pretty neat and very low on resource usage. + +For reference: +[Wikipedia](https://en.wikipedia.org/wiki/Data_URI_scheme) +[Mozilla](https://developer.mozilla.org/en-US/docs/web/http/basics_of_http/data_urls#datatextplainbase64sgvsbg8sifdvcmxkiq) + +--%-- +From: rodarima +Date: Fri, 08 Mar 2024 09:46:16 +0000 + +Do you have an specific example that doesn't work with master? + +Dillo already supports the `data:` URI (since Dillo 0.8.6, from 2006): + +- Simple HTML: + + + + +- With base64: + + + +- Inline in a HTML document: + +```html +<p>You should see a red dot below</p> +<img alt="" + src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" + style="width:10px;height:10px" /> +``` + + + + +--%-- +From: dirwiz +Date: Fri, 08 Mar 2024 10:38:17 +0000 + +My fault. I can confirm it does work perfectly! + +My testing involved using an SVG for the data part of an IMG. This didn't appear in the browser. + +Also I wanted to embed downloads using data url's. HTML5 has a "download" attribute for href where you can specify the filename for download when you click on the link. +Many thanks for the fast response! + + + + +--%-- +From: rodarima +Date: Fri, 08 Mar 2024 11:20:01 +0000 + +> My testing involved using an SVG for the data part of an IMG. This didn't appear in the browser. + +Yeah, SVG images are not supported yet, but they [are planned](https://github.com/dillo-browser/dillo/issues/70). + +> Also I wanted to embed downloads using data url's. HTML5 has a "download" attribute for href where you can specify the filename for download when you click on the link. + +Then I will reuse this issue to request this feature (rather than opening a new one).
\ No newline at end of file diff --git a/94/index.md b/94/index.md new file mode 100644 index 0000000..07c87c2 --- /dev/null +++ b/94/index.md @@ -0,0 +1,10 @@ +Title: Split dw::core and dw::fltk into directories +Author: rodarima +Created: Fri, 08 Mar 2024 22:08:25 +0000 +State: open + +We have all Dillo widget classes in the same directory `dw/` but they are two very well differentiated groups. The dw::core namespace contains platform agnostic classes, they don't depend on FLTK. On the other hand, dw::fltk implements all the functionality over FLTK for the widgets. This separation allows adding more UI backends to Dillo. + +This is well explained in the [dw overview page](https://dillo-browser.github.io/old/dw/html/dw-overview.html): + + diff --git a/95/index.md b/95/index.md new file mode 100644 index 0000000..c14144e --- /dev/null +++ b/95/index.md @@ -0,0 +1,16 @@ +Title: Consider making Dillo double-buffered by default +Author: rodarima +Created: Sat, 09 Mar 2024 11:20:14 +0000 +State: open + +The option `buffered_drawing` is by default set to 1, which results in single-buffered windows: + +``` +# Change the buffering scheme for drawing +# 0 no double buffering - useful for debugging +# 1 light buffering using a single back buffer for all windows +# 2 full fltk-based double buffering for all windows +#buffered_drawing=1 +``` + +We may want to move the default to double buffering if there are no further issues, so we remove the artifacts on resizing the Dillo window.
\ No newline at end of file diff --git a/96/index.md b/96/index.md new file mode 100644 index 0000000..2e29772 --- /dev/null +++ b/96/index.md @@ -0,0 +1,6 @@ +Title: Build C documentation too with Doxygen +Author: rodarima +Created: Sat, 09 Mar 2024 13:58:35 +0000 +State: closed + +Only dw was being generated.
\ No newline at end of file diff --git a/97/index.md b/97/index.md new file mode 100644 index 0000000..e4ee123 --- /dev/null +++ b/97/index.md @@ -0,0 +1,17 @@ +Title: Display more parsing errors and deprecation warnings +Author: rodarima +Created: Sun, 10 Mar 2024 16:21:42 +0000 +State: open + +We should differentiate between at least the following: +- CSS or HTML parsing errors (typically a mismatch of open and close tags) +- Non implemented features: Things that are not implemented but the page is trying to make use of. For example the `media()` CSS request. +- Deprecation warnings: For example, in an HTML 5 document, using a table with the align attribute. + +We may want to display them in a similar way as the "bug meter", so the user can determine if the page that it is seeing it is expected to be properly rendered. Or if the problems found in the page are "minor" and it is expected to be rendered properly anyway. + +--%-- +From: rodarima +Date: Sat, 06 Jul 2024 10:29:06 +0000 + +This should also include features that we don't support from SVG images.
\ No newline at end of file diff --git a/98/index.md b/98/index.md new file mode 100644 index 0000000..8498ae7 --- /dev/null +++ b/98/index.md @@ -0,0 +1,22 @@ +Title: Add event debugging mechanism +Author: rodarima +Created: Tue, 12 Mar 2024 21:18:59 +0000 +State: open + +Similarly as the RTFL tools, we need a way to record step by step how the layouting engine is processing the tree. It is not enough that we show the last values of the widget tree as the [debug window is currently doing](https://github.com/dillo-browser/dillo/issues/40). + +In particular, I'm observing problems such as widget computing the available space by asking up in the tree until the root several times. This computation must be cached, as once a parent widget has computed the available size it shouldn't change until we finish the sizeRequest. + +I'm thinking in adding a debugging mode in which Dillo records the last sizeRequests in a list, so we can explore one by one. Then, we also record the calls done by every widget, similarly as RTFL, but displayed directly on the browser. The idea is that we already distribute all the tools to debug problems builtin, so other people can take a look at what may be happening with low effort. + +Ideally we should be able to turn it on only when the user requests it, otherwise we will introduce a lot of performance and memory problems. + +--%-- +From: rodarima +Date: Sun, 17 Mar 2024 09:11:30 +0000 + +Here is an example using a tree, where we instrument some functions, much like RTFL: + + + +The difference is we can expand the nodes interactively, which helps hiding information that is not relevant. diff --git a/99/index.md b/99/index.md new file mode 100644 index 0000000..a1b5077 --- /dev/null +++ b/99/index.md @@ -0,0 +1,100 @@ +Title: Hacker News table too small +Author: rodarima +Created: Sun, 17 Mar 2024 18:45:19 +0000 +State: closed + +The Hacker News table has some unexpected empty space in the right: + + + +Related to #89 + +--%-- +From: rodarima +Date: Sun, 17 Mar 2024 18:52:39 +0000 + +This was introduced after the mercurial version. + +--%-- +From: rodarima +Date: Sun, 17 Mar 2024 19:11:49 +0000 + +Simplified reproducer: +```html +<!DOCTYPE html> +<html> + <head> + <title>Hacker News table test</title> + </head> + <body> + <table width="85%" bgcolor="#f6f6ef"> + <tr> + <td bgcolor="#ff6600"> + <table width="100%"> + <tr> + <td> + Hello world. + </td> + </tr> + </table> + </td> + </tr> + </table> + </body> +</html> +``` + + + + +--%-- +From: rodarima +Date: Fri, 22 Mar 2024 21:56:50 +0000 + +This problem seems to be hapenning due to 24bcd67df29a5418d05600b038a9283a00e555d2, as we are applying the CSS styles twice: + + + +One in `Textblock::getAvailWidthOfChild()` (which returns 300, the proper value) and another one due to my fix, which applies the relative width at the end of `Widget::getAvailWidth()` (which halves 300 into 150). + +--%-- +From: rodarima +Date: Fri, 22 Mar 2024 22:01:42 +0000 + +Reverting the commit fixes the issue, but now makes the `render/table-max-width.html` test fail (at least now we have tests). It shouldn't be relying on this behavior to size the table. + + + + +--%-- +From: rodarima +Date: Fri, 22 Mar 2024 22:39:25 +0000 + +The problem with the table-max-width test is caused by the mechanism in which we are checking if the CSS [width is effective](https://github.com/dillo-browser/dillo/blob/b0f6a3f055039c5c9c3ab651029a315a88eb6134/dw/table.cc#L942-L952), which is leaving `totalWidthSpecified` to false: + +```cpp + // CSS 'width' defined and effective? + bool totalWidthSpecified = false; + if (getStyle()->width != core::style::LENGTH_AUTO) { + // Even if 'width' is defined, it may not have a defined value. We try + // this trick (should perhaps be replaced by a cleaner solution): + core::Requisition testReq = { -1, -1, -1 }; + correctRequisition (&testReq, core::splitHeightPreserveDescent, true, + false); + if (testReq.width != -1) + totalWidthSpecified = true; + } +``` + +The problem with the correctRequisition call is that is leaving the width to -1, as is calling `Widget::getAvailWidth()` with forceValue set to false *and* the parent (the main div) has no width set (only min-width and max-width): + + + + +--%-- +From: rodarima +Date: Fri, 22 Mar 2024 22:48:10 +0000 + +Setting the forceValue argument to true in the `calcFinalWidth()` call of `Widget::correctReqWidthOfChild()` solves the problem and fixes all tests, but I'm not sure if it will break other cases or introduce more overhead for large documents. The documentation at least states that it is allowed: + +> sizeRequestImpl (and correctRequisition) is allowed to call getAvailWidth* and getAvailHeight with forceValue set
\ No newline at end of file @@ -0,0 +1,674 @@ + GNU GENERAL PUBLIC LICENSE + Version 3, 29 June 2007 + + Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The GNU General Public License is a free, copyleft license for +software and other kinds of works. + + The licenses for most software and other practical works are designed +to take away your freedom to share and change the works. By contrast, +the GNU General Public License is intended to guarantee your freedom to +share and change all versions of a program--to make sure it remains free +software for all its users. We, the Free Software Foundation, use the +GNU General Public License for most of our software; it applies also to +any other work released this way by its authors. You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +them if you wish), that you receive source code or can get it if you +want it, that you can change the software or use pieces of it in new +free programs, and that you know you can do these things. + + To protect your rights, we need to prevent others from denying you +these rights or asking you to surrender the rights. Therefore, you have +certain responsibilities if you distribute copies of the software, or if +you modify it: responsibilities to respect the freedom of others. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must pass on to the recipients the same +freedoms that you received. You must make sure that they, too, receive +or can get the source code. And you must show them these terms so they +know their rights. + + Developers that use the GNU GPL protect your rights with two steps: +(1) assert copyright on the software, and (2) offer you this License +giving you legal permission to copy, distribute and/or modify it. + + For the developers' and authors' protection, the GPL clearly explains +that there is no warranty for this free software. For both users' and +authors' sake, the GPL requires that modified versions be marked as +changed, so that their problems will not be attributed erroneously to +authors of previous versions. + + Some devices are designed to deny users access to install or run +modified versions of the software inside them, although the manufacturer +can do so. This is fundamentally incompatible with the aim of +protecting users' freedom to change the software. The systematic +pattern of such abuse occurs in the area of products for individuals to +use, which is precisely where it is most unacceptable. Therefore, we +have designed this version of the GPL to prohibit the practice for those +products. If such problems arise substantially in other domains, we +stand ready to extend this provision to those domains in future versions +of the GPL, as needed to protect the freedom of users. + + Finally, every program is threatened constantly by software patents. +States should not allow patents to restrict development and use of +software on general-purpose computers, but in those that do, we wish to +avoid the special danger that patents applied to a free program could +make it effectively proprietary. To prevent this, the GPL assures that +patents cannot be used to render the program non-free. + + The precise terms and conditions for copying, distribution and +modification follow. + + TERMS AND CONDITIONS + + 0. Definitions. + + "This License" refers to version 3 of the GNU General Public License. + + "Copyright" also means copyright-like laws that apply to other kinds of +works, such as semiconductor masks. + + "The Program" refers to any copyrightable work licensed under this +License. Each licensee is addressed as "you". "Licensees" and +"recipients" may be individuals or organizations. + + To "modify" a work means to copy from or adapt all or part of the work +in a fashion requiring copyright permission, other than the making of an +exact copy. The resulting work is called a "modified version" of the +earlier work or a work "based on" the earlier work. + + A "covered work" means either the unmodified Program or a work based +on the Program. + + To "propagate" a work means to do anything with it that, without +permission, would make you directly or secondarily liable for +infringement under applicable copyright law, except executing it on a +computer or modifying a private copy. Propagation includes copying, +distribution (with or without modification), making available to the +public, and in some countries other activities as well. + + To "convey" a work means any kind of propagation that enables other +parties to make or receive copies. Mere interaction with a user through +a computer network, with no transfer of a copy, is not conveying. + + An interactive user interface displays "Appropriate Legal Notices" +to the extent that it includes a convenient and prominently visible +feature that (1) displays an appropriate copyright notice, and (2) +tells the user that there is no warranty for the work (except to the +extent that warranties are provided), that licensees may convey the +work under this License, and how to view a copy of this License. If +the interface presents a list of user commands or options, such as a +menu, a prominent item in the list meets this criterion. + + 1. Source Code. + + The "source code" for a work means the preferred form of the work +for making modifications to it. "Object code" means any non-source +form of a work. + + A "Standard Interface" means an interface that either is an official +standard defined by a recognized standards body, or, in the case of +interfaces specified for a particular programming language, one that +is widely used among developers working in that language. + + The "System Libraries" of an executable work include anything, other +than the work as a whole, that (a) is included in the normal form of +packaging a Major Component, but which is not part of that Major +Component, and (b) serves only to enable use of the work with that +Major Component, or to implement a Standard Interface for which an +implementation is available to the public in source code form. A +"Major Component", in this context, means a major essential component +(kernel, window system, and so on) of the specific operating system +(if any) on which the executable work runs, or a compiler used to +produce the work, or an object code interpreter used to run it. + + The "Corresponding Source" for a work in object code form means all +the source code needed to generate, install, and (for an executable +work) run the object code and to modify the work, including scripts to +control those activities. However, it does not include the work's +System Libraries, or general-purpose tools or generally available free +programs which are used unmodified in performing those activities but +which are not part of the work. For example, Corresponding Source +includes interface definition files associated with source files for +the work, and the source code for shared libraries and dynamically +linked subprograms that the work is specifically designed to require, +such as by intimate data communication or control flow between those +subprograms and other parts of the work. + + The Corresponding Source need not include anything that users +can regenerate automatically from other parts of the Corresponding +Source. + + The Corresponding Source for a work in source code form is that +same work. + + 2. Basic Permissions. + + All rights granted under this License are granted for the term of +copyright on the Program, and are irrevocable provided the stated +conditions are met. This License explicitly affirms your unlimited +permission to run the unmodified Program. The output from running a +covered work is covered by this License only if the output, given its +content, constitutes a covered work. This License acknowledges your +rights of fair use or other equivalent, as provided by copyright law. + + You may make, run and propagate covered works that you do not +convey, without conditions so long as your license otherwise remains +in force. You may convey covered works to others for the sole purpose +of having them make modifications exclusively for you, or provide you +with facilities for running those works, provided that you comply with +the terms of this License in conveying all material for which you do +not control copyright. Those thus making or running the covered works +for you must do so exclusively on your behalf, under your direction +and control, on terms that prohibit them from making any copies of +your copyrighted material outside their relationship with you. + + Conveying under any other circumstances is permitted solely under +the conditions stated below. Sublicensing is not allowed; section 10 +makes it unnecessary. + + 3. Protecting Users' Legal Rights From Anti-Circumvention Law. + + No covered work shall be deemed part of an effective technological +measure under any applicable law fulfilling obligations under article +11 of the WIPO copyright treaty adopted on 20 December 1996, or +similar laws prohibiting or restricting circumvention of such +measures. + + When you convey a covered work, you waive any legal power to forbid +circumvention of technological measures to the extent such circumvention +is effected by exercising rights under this License with respect to +the covered work, and you disclaim any intention to limit operation or +modification of the work as a means of enforcing, against the work's +users, your or third parties' legal rights to forbid circumvention of +technological measures. + + 4. Conveying Verbatim Copies. + + You may convey verbatim copies of the Program's source code as you +receive it, in any medium, provided that you conspicuously and +appropriately publish on each copy an appropriate copyright notice; +keep intact all notices stating that this License and any +non-permissive terms added in accord with section 7 apply to the code; +keep intact all notices of the absence of any warranty; and give all +recipients a copy of this License along with the Program. + + You may charge any price or no price for each copy that you convey, +and you may offer support or warranty protection for a fee. + + 5. Conveying Modified Source Versions. + + You may convey a work based on the Program, or the modifications to +produce it from the Program, in the form of source code under the +terms of section 4, provided that you also meet all of these conditions: + + a) The work must carry prominent notices stating that you modified + it, and giving a relevant date. + + b) The work must carry prominent notices stating that it is + released under this License and any conditions added under section + 7. This requirement modifies the requirement in section 4 to + "keep intact all notices". + + c) You must license the entire work, as a whole, under this + License to anyone who comes into possession of a copy. This + License will therefore apply, along with any applicable section 7 + additional terms, to the whole of the work, and all its parts, + regardless of how they are packaged. This License gives no + permission to license the work in any other way, but it does not + invalidate such permission if you have separately received it. + + d) If the work has interactive user interfaces, each must display + Appropriate Legal Notices; however, if the Program has interactive + interfaces that do not display Appropriate Legal Notices, your + work need not make them do so. + + A compilation of a covered work with other separate and independent +works, which are not by their nature extensions of the covered work, +and which are not combined with it such as to form a larger program, +in or on a volume of a storage or distribution medium, is called an +"aggregate" if the compilation and its resulting copyright are not +used to limit the access or legal rights of the compilation's users +beyond what the individual works permit. Inclusion of a covered work +in an aggregate does not cause this License to apply to the other +parts of the aggregate. + + 6. Conveying Non-Source Forms. + + You may convey a covered work in object code form under the terms +of sections 4 and 5, provided that you also convey the +machine-readable Corresponding Source under the terms of this License, +in one of these ways: + + a) Convey the object code in, or embodied in, a physical product + (including a physical distribution medium), accompanied by the + Corresponding Source fixed on a durable physical medium + customarily used for software interchange. + + b) Convey the object code in, or embodied in, a physical product + (including a physical distribution medium), accompanied by a + written offer, valid for at least three years and valid for as + long as you offer spare parts or customer support for that product + model, to give anyone who possesses the object code either (1) a + copy of the Corresponding Source for all the software in the + product that is covered by this License, on a durable physical + medium customarily used for software interchange, for a price no + more than your reasonable cost of physically performing this + conveying of source, or (2) access to copy the + Corresponding Source from a network server at no charge. + + c) Convey individual copies of the object code with a copy of the + written offer to provide the Corresponding Source. This + alternative is allowed only occasionally and noncommercially, and + only if you received the object code with such an offer, in accord + with subsection 6b. + + d) Convey the object code by offering access from a designated + place (gratis or for a charge), and offer equivalent access to the + Corresponding Source in the same way through the same place at no + further charge. You need not require recipients to copy the + Corresponding Source along with the object code. If the place to + copy the object code is a network server, the Corresponding Source + may be on a different server (operated by you or a third party) + that supports equivalent copying facilities, provided you maintain + clear directions next to the object code saying where to find the + Corresponding Source. Regardless of what server hosts the + Corresponding Source, you remain obligated to ensure that it is + available for as long as needed to satisfy these requirements. + + e) Convey the object code using peer-to-peer transmission, provided + you inform other peers where the object code and Corresponding + Source of the work are being offered to the general public at no + charge under subsection 6d. + + A separable portion of the object code, whose source code is excluded +from the Corresponding Source as a System Library, need not be +included in conveying the object code work. + + A "User Product" is either (1) a "consumer product", which means any +tangible personal property which is normally used for personal, family, +or household purposes, or (2) anything designed or sold for incorporation +into a dwelling. In determining whether a product is a consumer product, +doubtful cases shall be resolved in favor of coverage. For a particular +product received by a particular user, "normally used" refers to a +typical or common use of that class of product, regardless of the status +of the particular user or of the way in which the particular user +actually uses, or expects or is expected to use, the product. A product +is a consumer product regardless of whether the product has substantial +commercial, industrial or non-consumer uses, unless such uses represent +the only significant mode of use of the product. + + "Installation Information" for a User Product means any methods, +procedures, authorization keys, or other information required to install +and execute modified versions of a covered work in that User Product from +a modified version of its Corresponding Source. The information must +suffice to ensure that the continued functioning of the modified object +code is in no case prevented or interfered with solely because +modification has been made. + + If you convey an object code work under this section in, or with, or +specifically for use in, a User Product, and the conveying occurs as +part of a transaction in which the right of possession and use of the +User Product is transferred to the recipient in perpetuity or for a +fixed term (regardless of how the transaction is characterized), the +Corresponding Source conveyed under this section must be accompanied +by the Installation Information. But this requirement does not apply +if neither you nor any third party retains the ability to install +modified object code on the User Product (for example, the work has +been installed in ROM). + + The requirement to provide Installation Information does not include a +requirement to continue to provide support service, warranty, or updates +for a work that has been modified or installed by the recipient, or for +the User Product in which it has been modified or installed. Access to a +network may be denied when the modification itself materially and +adversely affects the operation of the network or violates the rules and +protocols for communication across the network. + + Corresponding Source conveyed, and Installation Information provided, +in accord with this section must be in a format that is publicly +documented (and with an implementation available to the public in +source code form), and must require no special password or key for +unpacking, reading or copying. + + 7. Additional Terms. + + "Additional permissions" are terms that supplement the terms of this +License by making exceptions from one or more of its conditions. +Additional permissions that are applicable to the entire Program shall +be treated as though they were included in this License, to the extent +that they are valid under applicable law. If additional permissions +apply only to part of the Program, that part may be used separately +under those permissions, but the entire Program remains governed by +this License without regard to the additional permissions. + + When you convey a copy of a covered work, you may at your option +remove any additional permissions from that copy, or from any part of +it. (Additional permissions may be written to require their own +removal in certain cases when you modify the work.) You may place +additional permissions on material, added by you to a covered work, +for which you have or can give appropriate copyright permission. + + Notwithstanding any other provision of this License, for material you +add to a covered work, you may (if authorized by the copyright holders of +that material) supplement the terms of this License with terms: + + a) Disclaiming warranty or limiting liability differently from the + terms of sections 15 and 16 of this License; or + + b) Requiring preservation of specified reasonable legal notices or + author attributions in that material or in the Appropriate Legal + Notices displayed by works containing it; or + + c) Prohibiting misrepresentation of the origin of that material, or + requiring that modified versions of such material be marked in + reasonable ways as different from the original version; or + + d) Limiting the use for publicity purposes of names of licensors or + authors of the material; or + + e) Declining to grant rights under trademark law for use of some + trade names, trademarks, or service marks; or + + f) Requiring indemnification of licensors and authors of that + material by anyone who conveys the material (or modified versions of + it) with contractual assumptions of liability to the recipient, for + any liability that these contractual assumptions directly impose on + those licensors and authors. + + All other non-permissive additional terms are considered "further +restrictions" within the meaning of section 10. If the Program as you +received it, or any part of it, contains a notice stating that it is +governed by this License along with a term that is a further +restriction, you may remove that term. If a license document contains +a further restriction but permits relicensing or conveying under this +License, you may add to a covered work material governed by the terms +of that license document, provided that the further restriction does +not survive such relicensing or conveying. + + If you add terms to a covered work in accord with this section, you +must place, in the relevant source files, a statement of the +additional terms that apply to those files, or a notice indicating +where to find the applicable terms. + + Additional terms, permissive or non-permissive, may be stated in the +form of a separately written license, or stated as exceptions; +the above requirements apply either way. + + 8. Termination. + + You may not propagate or modify a covered work except as expressly +provided under this License. Any attempt otherwise to propagate or +modify it is void, and will automatically terminate your rights under +this License (including any patent licenses granted under the third +paragraph of section 11). + + However, if you cease all violation of this License, then your +license from a particular copyright holder is reinstated (a) +provisionally, unless and until the copyright holder explicitly and +finally terminates your license, and (b) permanently, if the copyright +holder fails to notify you of the violation by some reasonable means +prior to 60 days after the cessation. + + Moreover, your license from a particular copyright holder is +reinstated permanently if the copyright holder notifies you of the +violation by some reasonable means, this is the first time you have +received notice of violation of this License (for any work) from that +copyright holder, and you cure the violation prior to 30 days after +your receipt of the notice. + + Termination of your rights under this section does not terminate the +licenses of parties who have received copies or rights from you under +this License. If your rights have been terminated and not permanently +reinstated, you do not qualify to receive new licenses for the same +material under section 10. + + 9. Acceptance Not Required for Having Copies. + + You are not required to accept this License in order to receive or +run a copy of the Program. Ancillary propagation of a covered work +occurring solely as a consequence of using peer-to-peer transmission +to receive a copy likewise does not require acceptance. However, +nothing other than this License grants you permission to propagate or +modify any covered work. These actions infringe copyright if you do +not accept this License. Therefore, by modifying or propagating a +covered work, you indicate your acceptance of this License to do so. + + 10. Automatic Licensing of Downstream Recipients. + + Each time you convey a covered work, the recipient automatically +receives a license from the original licensors, to run, modify and +propagate that work, subject to this License. You are not responsible +for enforcing compliance by third parties with this License. + + An "entity transaction" is a transaction transferring control of an +organization, or substantially all assets of one, or subdividing an +organization, or merging organizations. If propagation of a covered +work results from an entity transaction, each party to that +transaction who receives a copy of the work also receives whatever +licenses to the work the party's predecessor in interest had or could +give under the previous paragraph, plus a right to possession of the +Corresponding Source of the work from the predecessor in interest, if +the predecessor has it or can get it with reasonable efforts. + + You may not impose any further restrictions on the exercise of the +rights granted or affirmed under this License. For example, you may +not impose a license fee, royalty, or other charge for exercise of +rights granted under this License, and you may not initiate litigation +(including a cross-claim or counterclaim in a lawsuit) alleging that +any patent claim is infringed by making, using, selling, offering for +sale, or importing the Program or any portion of it. + + 11. Patents. + + A "contributor" is a copyright holder who authorizes use under this +License of the Program or a work on which the Program is based. The +work thus licensed is called the contributor's "contributor version". + + A contributor's "essential patent claims" are all patent claims +owned or controlled by the contributor, whether already acquired or +hereafter acquired, that would be infringed by some manner, permitted +by this License, of making, using, or selling its contributor version, +but do not include claims that would be infringed only as a +consequence of further modification of the contributor version. For +purposes of this definition, "control" includes the right to grant +patent sublicenses in a manner consistent with the requirements of +this License. + + Each contributor grants you a non-exclusive, worldwide, royalty-free +patent license under the contributor's essential patent claims, to +make, use, sell, offer for sale, import and otherwise run, modify and +propagate the contents of its contributor version. + + In the following three paragraphs, a "patent license" is any express +agreement or commitment, however denominated, not to enforce a patent +(such as an express permission to practice a patent or covenant not to +sue for patent infringement). To "grant" such a patent license to a +party means to make such an agreement or commitment not to enforce a +patent against the party. + + If you convey a covered work, knowingly relying on a patent license, +and the Corresponding Source of the work is not available for anyone +to copy, free of charge and under the terms of this License, through a +publicly available network server or other readily accessible means, +then you must either (1) cause the Corresponding Source to be so +available, or (2) arrange to deprive yourself of the benefit of the +patent license for this particular work, or (3) arrange, in a manner +consistent with the requirements of this License, to extend the patent +license to downstream recipients. "Knowingly relying" means you have +actual knowledge that, but for the patent license, your conveying the +covered work in a country, or your recipient's use of the covered work +in a country, would infringe one or more identifiable patents in that +country that you have reason to believe are valid. + + If, pursuant to or in connection with a single transaction or +arrangement, you convey, or propagate by procuring conveyance of, a +covered work, and grant a patent license to some of the parties +receiving the covered work authorizing them to use, propagate, modify +or convey a specific copy of the covered work, then the patent license +you grant is automatically extended to all recipients of the covered +work and works based on it. + + A patent license is "discriminatory" if it does not include within +the scope of its coverage, prohibits the exercise of, or is +conditioned on the non-exercise of one or more of the rights that are +specifically granted under this License. You may not convey a covered +work if you are a party to an arrangement with a third party that is +in the business of distributing software, under which you make payment +to the third party based on the extent of your activity of conveying +the work, and under which the third party grants, to any of the +parties who would receive the covered work from you, a discriminatory +patent license (a) in connection with copies of the covered work +conveyed by you (or copies made from those copies), or (b) primarily +for and in connection with specific products or compilations that +contain the covered work, unless you entered into that arrangement, +or that patent license was granted, prior to 28 March 2007. + + Nothing in this License shall be construed as excluding or limiting +any implied license or other defenses to infringement that may +otherwise be available to you under applicable patent law. + + 12. No Surrender of Others' Freedom. + + If conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot convey a +covered work so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you may +not convey it at all. For example, if you agree to terms that obligate you +to collect a royalty for further conveying from those to whom you convey +the Program, the only way you could satisfy both those terms and this +License would be to refrain entirely from conveying the Program. + + 13. Use with the GNU Affero General Public License. + + Notwithstanding any other provision of this License, you have +permission to link or combine any covered work with a work licensed +under version 3 of the GNU Affero General Public License into a single +combined work, and to convey the resulting work. The terms of this +License will continue to apply to the part which is the covered work, +but the special requirements of the GNU Affero General Public License, +section 13, concerning interaction through a network will apply to the +combination as such. + + 14. Revised Versions of this License. + + The Free Software Foundation may publish revised and/or new versions of +the GNU General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + + Each version is given a distinguishing version number. If the +Program specifies that a certain numbered version of the GNU General +Public License "or any later version" applies to it, you have the +option of following the terms and conditions either of that numbered +version or of any later version published by the Free Software +Foundation. If the Program does not specify a version number of the +GNU General Public License, you may choose any version ever published +by the Free Software Foundation. + + If the Program specifies that a proxy can decide which future +versions of the GNU General Public License can be used, that proxy's +public statement of acceptance of a version permanently authorizes you +to choose that version for the Program. + + Later license versions may give you additional or different +permissions. However, no additional obligations are imposed on any +author or copyright holder as a result of your choosing to follow a +later version. + + 15. Disclaimer of Warranty. + + THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY +APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT +HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY +OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, +THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM +IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF +ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + + 16. Limitation of Liability. + + IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS +THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY +GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE +USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF +DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD +PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), +EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF +SUCH DAMAGES. + + 17. Interpretation of Sections 15 and 16. + + If the disclaimer of warranty and limitation of liability provided +above cannot be given local legal effect according to their terms, +reviewing courts shall apply local law that most closely approximates +an absolute waiver of all civil liability in connection with the +Program, unless a warranty or assumption of liability accompanies a +copy of the Program in return for a fee. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +state the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + <one line to give the program's name and a brief idea of what it does.> + Copyright (C) <year> <name of author> + + This program is free software: you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation, either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. + +Also add information on how to contact you by electronic and paper mail. + + If the program does terminal interaction, make it output a short +notice like this when it starts in an interactive mode: + + <program> Copyright (C) <year> <name of author> + This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, your program's commands +might be different; for a GUI interface, you would use an "about box". + + You should also get your employer (if you work as a programmer) or school, +if any, to sign a "copyright disclaimer" for the program, if necessary. +For more information on this, and how to apply and follow the GNU GPL, see +<http://www.gnu.org/licenses/>. + + The GNU General Public License does not permit incorporating your program +into proprietary programs. If your program is a subroutine library, you +may consider it more useful to permit linking proprietary applications with +the library. If this is what you want to do, use the GNU Lesser General +Public License instead of this License. But first, please read +<http://www.gnu.org/philosophy/why-not-lgpl.html>. diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..4ab14f5 --- /dev/null +++ b/Makefile @@ -0,0 +1,44 @@ +issues=$(shell printf '%s\n' [0-9]* | sort -nr) +out=.out +html_issues=$(patsubst %, $(out)/%/index.html, $(issues)) +any_issues=$(patsubst %, $(out)/%/.row.html, $(issues)) +open_issues=$(patsubst %, $(out)/%/.row.open.html, $(issues)) +css_input=src/style.css +css=$(out)/style.css + +all: $(css) $(html_issues) $(any_issues) $(open_issues) $(out)/index.html $(out)/any.html + @killall -USR1 dillo || true + +$(out)/issues: + printf '%d\n' $(issues) > $@ + +$(out)/%/index.html: %/index.md %/* src/mkissue.sh src/issue.awk + @mkdir -p $(out)/$* + src/mkissue.sh $*/index.md > $@ + +$(out)/%/.row.open.html: %/index.md src/mkrow.sh src/issue-entry.awk + @mkdir -p $(out)/$* + src/mkrow.sh $* $*/index.md open > $@ + +$(out)/%/.row.html: %/index.md src/mkrow.sh src/issue-entry.awk + @mkdir -p $(out)/$* + src/mkrow.sh $* $*/index.md > $@ + +$(out)/index.html: $(open_issues) src/mkindex.sh + @echo rebuild open index + @src/mkindex.sh $(open_issues) > $@ + +$(out)/any.html: $(any_issues) src/mkindex.sh + @echo rebuild any index + @src/mkindex.sh $(any_issues) > $@ + + +$(css): $(css_input) + @mkdir -p $(out)/ + @cp $^ $@ + +new: + @src/mknew.sh + +#fetch: +# @python src/export.py diff --git a/README.md b/README.md new file mode 100644 index 0000000..2eaaead --- /dev/null +++ b/README.md @@ -0,0 +1,33 @@ +# Dillo bug tracker + +This repository contains the issues for the Dillo web browser. Each issue is +contained in a directory named with the issue number. The text of the issue +is stored in the index.md markdown file and any extra attachments are placed +inside the issue directory. + +Issue metadata follows the email headers, example: + + Title: Indentation error on cgit diff + Author: Rodrigo Arias Mallo + Created: Sun, 28 Sep 2025 14:44:28 +0200 + State: open + + Indentation with tabs in cgit diff seems to be broken, elements don't get + aligned as expected. + +Comments are added in the same file by including the separator `--%--` and +additional headers: + + --%-- + From: rodarima + Date: 2025-08-23 13:33:46+00:00 + + So, there are two issues here: + +The format of the issues is barely restricted, so direct HTML can be included to +include HTML reproducers inline. + +To modify the issues, edit directly the index.md file and run `make` to render +the output before pushing the changes to upstream. + +To close an issue simply change the `State: open` line to `State: closed`. diff --git a/src/export.py b/src/export.py new file mode 100644 index 0000000..b453bc4 --- /dev/null +++ b/src/export.py @@ -0,0 +1,44 @@ +from github import Github +from github import Auth +import os + +token = None +with open(os.path.expanduser('~') + "/.config/github/token", "r") as f: + token = str(f.readline().strip()) + +auth = Auth.Token(token) + +g = Github(auth=auth) + +root = "." +datefmt = '%a, %d %b %Y %H:%M:%S %z' + +repo = g.get_repo("dillo-browser/dillo") +open_issues = repo.get_issues(state="all") +for issue in open_issues: + print(issue) + n = issue.number + title = issue.title + body = issue.body + os.makedirs("%s/%d" % (root, n), exist_ok=True) + issue_file = "%s/%d/index.md" % (root, n) + if body is None: + body = '' + + body = body.replace('\r\n', '\n') + + with open(issue_file, "w") as f: + f.write("Title: " + issue.title + '\n') + f.write("Author: " + issue.user.login + '\n') + f.write("Created: " + issue.created_at.strftime(datefmt) + '\n') + f.write("State: " + issue.state + '\n') + f.write('\n') + f.write(body) + for comment in issue.get_comments(): + f.write('\n\n--%--\n') + f.write('From: ' + comment.user.login + '\n') + f.write('Date: ' + comment.created_at.strftime(datefmt) + '\n') + f.write('\n') + f.write(comment.body.replace('\r\n', '\n')) + +g.close() diff --git a/src/issue-entry.awk b/src/issue-entry.awk new file mode 100644 index 0000000..bc0278d --- /dev/null +++ b/src/issue-entry.awk @@ -0,0 +1,21 @@ +BEGIN { FS=": "; c=0 } + +c == 0 && /^Title: / { sub("Title: ", ""); title=$0 } +c == 0 && /^Author: / { sub("Author: ", ""); author=$0 } +c == 0 && /^Created: / { sub("Created: ", ""); date=$0 } +c == 0 && /^State: / { sub("State: ", ""); state=$0 } +#/^--%--$/ { c++ } +/^--%--$/ { exit } +END { + if (s == "" || state == s) { + printf "<tr>\n" + printf " <td><a href='%d/'>#%d</a></td>\n", n, n + printf " <td>%s</td>\n", title + #printf " <td>%d</td>\n", c + printf " <td>%s</td>\n", modif + printf " <td><span class='issue-state state-%s'>%s</span></td>\n", state, state + printf "</tr>\n" + printf "\n" + } + exit +} diff --git a/src/issue.awk b/src/issue.awk new file mode 100644 index 0000000..69fb889 --- /dev/null +++ b/src/issue.awk @@ -0,0 +1,73 @@ +BEGIN { FS=": "; s=1; c=0 } + +s==1 && /^Title: / { sub("Title: ", ""); title=$0 } +s==1 && /^Author: / { sub("Author: ", ""); author=$0 } +s==1 && /^Created: / { sub("Created: ", ""); date=$0 } +s==1 && /^State: / { sub("State: ", ""); state=$0 } +s==1 && $0 == "" { + printf "<!doctype html>\n" + printf "<html>\n" + printf "<head>\n" + printf " <title>%s</title>\n", title + printf " <link rel='stylesheet' href='/style.css' type='text/css' />\n" + printf "</head>\n" + printf "<body>\n" + printf " <table class='issue-meta'>\n" + printf " <tr><th>Title</th><td>%s</td></tr>\n", title + printf " <tr><th>Author</th><td>%s</td></tr>\n", author + printf " <tr><th>Created</th><td>%s</td></tr>\n", date + printf " <tr><th>State</th>" + printf " <td><span class='issue-state state-%s'>%s</span></td>", state, state + printf " </tr>\n" + printf " </table>\n" + printf "\n" + s = 2 + next +} + +# Description +s==2 && $0 == "--%--" { + com_author = "" + com_date = "" + s = 3 + c++ + next +} +s==2 { print } + +# Comment header +s==3 && /^From: / { sub("From: ", ""); com_author=$0 } +s==3 && /^Date: / { sub("Date: ", ""); com_date=$0 } +s==3 && $0 == "" { + printf "\n" + printf "<div id='c%d' class='comment'>\n", c + printf " <a href='#c%d'>%s</a> on <i>%s</i>:<br>\n", c, com_author, com_date + printf "\n" + s = 4 + next +} + +# Comment body +s==4 && $0 == "--%--" { + # Close previous comment + printf "</div>\n\n" + com_author = "" + com_date = "" + s = 3 + c++ + next +} +s==4 { print } + +END { + if (s == 4) { + printf "</div>\n" + } + printf "\n\n" + printf "</body>" + printf "</html>" + +# printf "title=\"%s\"\n", title; +# printf "author=%s\n", author; +# printf "author=%s\n", author; +} diff --git a/src/mkindex.sh b/src/mkindex.sh new file mode 100755 index 0000000..a81e033 --- /dev/null +++ b/src/mkindex.sh @@ -0,0 +1,25 @@ +#!/bin/sh -e + +cat <<EOF +<!doctype html> +<head> + <title>Dillo Bug Tracker</title> + <link rel='stylesheet' href='/style.css' type='text/css' /> +</head> +<body> + <h1>Dillo Bug Tracker</h1> + <p>State: <a href="/">open</a> | <a href="/any.html">any</a></p> + <table class='issue-index'> + <tr> + <th>Bug</th> + <th style='width: 70%'>Title</th> + <th>Updated</th> + <th>State</th> + </tr> +EOF + +cat "$@" + +printf '\n' +printf ' </table>\n' +printf '</body>\n' diff --git a/src/mkissue.sh b/src/mkissue.sh new file mode 100755 index 0000000..cf03273 --- /dev/null +++ b/src/mkissue.sh @@ -0,0 +1,5 @@ +#!/bin/sh -e + +sed 's/ #\([0-9]\+\)/ [#\1](\/\1)/g' $1 | \ + awk -f src/issue.awk | \ + md2html --github diff --git a/src/mknew.sh b/src/mknew.sh new file mode 100755 index 0000000..880838b --- /dev/null +++ b/src/mknew.sh @@ -0,0 +1,18 @@ +#!/bin/sh + +n=$(printf '%s\n' [0-9]* | sort -nr | head -1) +if [ -z "$n" ]; then + n=1 +else + let n=n+1 +fi + +mkdir $n +p=$n/index.md + +echo "Title: " >> $p +echo "Author: $(git config get user.name)" >> $p +echo "Created: $(date -R)" >> $p +echo "State: open" >> $p + +echo "\$EDITOR $n/index.md" diff --git a/src/mkrow.sh b/src/mkrow.sh new file mode 100755 index 0000000..7581979 --- /dev/null +++ b/src/mkrow.sh @@ -0,0 +1,10 @@ +#!/bin/sh -e + +n=$1 +f=$2 +s=$3 + +title=$(head -1 $f | sed 's/^Title: //') +modif=$(stat -c %y $f | cut -d ' ' -f 1) + +awk -v n=$n -v s="$s" -v modif="$modif" -f src/issue-entry.awk < $f diff --git a/src/style.css b/src/style.css new file mode 100644 index 0000000..35a322d --- /dev/null +++ b/src/style.css @@ -0,0 +1,91 @@ +body { + background: white; + line-height: 1.5; + margin: 3em auto; + padding: 0 3em; /* Fix for Dillo */ + font-family: sans-serif; + max-width: 80ch; +} +h1 { + margin-top: 0.25em; + margin-bottom: 0.25em; + font-size: 22px; +} +img { + border: 0; + max-width: 100%; + margin-top: 1em; + margin-bottom: 1em; +} +figure { + text-align: center; + margin: 1em; +} +footer { + text-align: center; + margin-top: 2em; + clear: both; +} +pre { + padding: 0.25em; + background: #f7f7f7; + border-left: solid 2px #ccc; +} +.date { + font-style: italic; + float: right; +} + +/* Issue state label */ +span.issue-state { + display: inline-block; + text-align: center; + color: #000; + padding: 0px 0.25em; + border: solid 1px #777; +} +span.state-open { + background-color: #8f8; +} +span.state-closed { + background-color: #eee; +} + +/* Issue index view */ +table.issue-index { + width: 100%; + border-spacing: 0; +} +table.issue-index td { + border-collapse: collapse; + border-bottom: solid 1px #ddd; + border-top: solid 1px #ddd; + padding: 0.25em; +} +table.issue-index th { + text-align: left; + background-color: #eee; + padding: 0.25em; +} + +/* Issue view */ +table.issue-meta { + width: 100%; + padding: 0.25em; + border: solid 1px #777; + margin-bottom: 1em; +} +table.issue-meta th { + padding: 0.1em 0.25em; + text-align: left; + vertical-align: top; +} +table.issue-meta td { + width: 100%; + padding: 0.1em 0.25em; +} +div.comment { + margin: 0.5em 0; + padding: 0.5em; + border: solid 1px #777; +} |