Re: logging
On Tue, Mar 22, 2011 at 09:00:17AM +, Brian Bailey wrote: > In article <20110321163550.gg4...@rjek.com>, >Rob Kendrick wrote: > > [snip] > > > > > > >I am intrigued by the successive improvement and development of > > > >Netsurf. Periodically I load a personal favourite page in Wikepedia, > > > >just to see what changes are apparent in performance. It would seem > > > >that loading and rendering of that page does indeed vary. > > > > > > > >To what extent can one expect verbose logging to slow things down (I > > > >use a rather slow machine, which I am not going to change this side > > > >of Christmas). Is it possible to turn verbose logging on/off. > > > > > > Not tested, but in the !Run file near the bottom is the following line: > > > > > > Run .!RunImage -v %*0 2>.WWW.NetSurf.Log > > > > > > If you put a | before the .WWW.NetSurf.Log that should > > > disable the logging. > > With a copy of r12120, I put a | before -v in the expectation that logging > would be completely turned off. Three lines only were recorded in the log > file, related to fonts, in this case. > > > > > > Unless their is anything in the Netsurf code itself that expects to > > > write to the log it should work, but I'm offering no guarantees. > > > Remove the -v flag. That is what enables verbose logging. Note that > > this simply stops NetSurf formatting and emitting the log data. It will > > still involve checking "do I need to log this?" > > Thanks, Rob. I also removed the -v flag, without putting an | anywhere. > > NetSurf seemed to be entirely stable in both cases. As far as I could > tell, there was no discernible, subjective change in time in loading and > rendering files, in either case. > > I guess that I must accept that my machine /is/ rather slow. But, as I am > retired I can make endless cups of tea whilst things happen. 8-) Out of interest what speed do you get if you set "incremental_reflow:0" in the Choices file? It may be a case your hardware really is simply too slow to support that feature and is spending so long redrawing that it is not spending long enough fetching.. -- Regards Vincent http://www.kyllikki.org/
Re: setting size and position of window
On Wed, Mar 30, 2011 at 02:04:12AM +0100, Jim Nagel wrote: > can anybody suggest a trick whereby i could make a Netsurf window open > at a certain size and position on screen, to display a local file? Well the other frontends use the Choices values window_x, window_y, window_width, window_height for their initial window placement. These values overridden on the command line combined with the url to open should do what you need? For example: ./nsgtk --window_x 100 --window_y 200 --window_width 200 --window_height 200 http://news.bbc.co.uk opens a 200x200 pixel window at 100,200 on the screen at news.bbc.co.uk in the gtk version. If the RISC OS frontend does not support this I have no better idea, sorry. > > the page in mind is the control panel for my networked monsterprinter. > it's useful to have it handy during a print job without taking up too > much screen space. > > -- > Jim Nagelwww.archivemag.co.uk > > -- Regards Vincent http://www.kyllikki.org/
Re: WG: Compiling on Fedora 13
On Wed, Apr 27, 2011 at 11:44:49AM +0200, David Sandberg wrote:
>
>
> -Ursprüngliche Nachricht-
> Von: David Sandberg [mailto:david_sandb...@alice-dsl.net]
> Gesendet: Dienstag, 26. April 2011 22:25
> An: ''
> Betreff: Compiling on Fedora 13
>
> I'd try to build netsurf like the documentation for Fedora with all the
> Dependencies build.
> It was not possible to compile the Source without Errors:
>
> This is the result:
>
> [root@Acer1 netsurf]# PKG_CONFIG_PATH=/usr/local/lib/pkgconfig make
> TARGET=gtk
> M.CONFIG: JPEG (libjpeg)enabled (NETSURF_USE_JPEG := YES)
> M.CONFIG: JNG/MNG/PNG (libmng) disabled (NETSURF_USE_MNG := NO)
> M.CONFIG: PDF export (haru) enabled (NETSURF_USE_HARU_PDF := YES)
> M.CONFIG: glibc internal iconv enabled (NETSURF_USE_LIBICONV_PLUG :=
> YES)
> M.CONFIG: SVG (librsvg-2.0) disabled (NETSURF_USE_RSVG := NO)
> M.CONFIG: SVG (libsvgtiny) disabled (NETSURF_USE_NSSVG := NO)
> M.CONFIG: Sprite (librosprite) auto-enabled (NETSURF_USE_ROSPRITE :=
> AUTO)
> M.CONFIG: BMP (libnsbmp)enabled (NETSURF_USE_BMP := YES)
> M.CONFIG: GIF (libnsgif)enabled (NETSURF_USE_GIF := YES)
> M.CONFIG: PNG (libpng)enabled (NETSURF_USE_PNG := YES)
> M.CONFIG: WebP (libwebp)disabled (NETSURF_USE_WEBP := NO)
> Use of uninitialized value $svninfo{"repositoryroot"} in length at
> utils/svn-testament.pl line 111.
> TESTMENT: unchanged
> LINK: nsgtk
> /usr/bin/ld: build-Linux-gtk/gtk_dialogs_options.o: undefined reference to
> symbol 'lround@@GLIBC_2.1'
> /usr/bin/ld: note: 'lround@@GLIBC_2.1' is defined in DSO /lib/libm.so.6 so
> try adding it to the linker command line
> /lib/libm.so.6: could not read symbols: Invalid operation
> collect2: ld backs 1 as End-Status
> make: *** [nsgtk] Error 1
>
>
>
> Can someone help me. Probably a linker problem. Pleas give the syntax for
> the linker command line.
This is because glibc no longer automatically links teh math library
(libm) with the toolchain you are using. Very easy fix:
In the main Makefile around line 345
You will see:
# common libraries without pkg-config support
LDFLAGS += -lz
change the LDFLAGS line to
LDFLAGS += -lz -lm
That should sort the link for you
The formal diff is
Index: Makefile
===
--- Makefile(revision 12242)
+++ Makefile(working copy)
@@ -343,7 +343,7 @@
$(eval $(call feature_enabled,LIBICONV_PLUG,-DLIBICONV_PLUG,,glibc internal
iconv))
# common libraries without pkg-config support
-LDFLAGS += -lz
+LDFLAGS += -lz -lm
CFLAGS += -DNETSURF_UA_FORMAT_STRING=\"$(NETSURF_UA_FORMAT_STRING)\"
CFLAGS += -DNETSURF_HOMEPAGE=\"$(NETSURF_HOMEPAGE)\"
--
Regards Vincent
http://www.kyllikki.org/
Re: puzzling email
On Mon, Oct 17, 2011 at 04:10:32PM +0100, Brian Bailey wrote: > John > > > > I just got an email from i4imaging which included a file oleO.bmp which > > > NetSurf didn't like very much declaring BadType as it was fetching and > > > processing. Said file didn't seem to render. Are bmp file a no go area, > > > perhaps? > > > A BMP file made with DPIngScan loads fine, so your file is probably > > faulty - or, as sometimes happens, has the wrong file extension perhaps > > (?). > > > My BMP file starts with the characters 'BM' as viewed in a text editor. > > Thanks for that. It does indeed start with 'BM' but I'm mostly sure that > it wasn't generated with DPIngScan. Bound to be from the dark side, > really, but it does beg the question how many other BadFile types might > there be lurking out there? > > I've had something similar happen before but ignored it! > > Brian > It is most likely that your application has saved the bitmap with a data filetype. NetSurf (correctly) converts the RO data filetype to the application/octet-stream MIME type which will not be considered as anything beyond binary data that cannot be interpreted. Additionally if the bitmap is small you might try opening a bug on the bugtracker and placing it there to be examined as without it no-one can make any sensible determination. And *not* specific to this report, just using it as an opportunity: Please, PLEASE, there are only a very small number of use working on NetSurf. Can users read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html and follow its advice. Also http://catb.org/~esr/faqs/smart-questions.html is worth a read but be aware of the offensive language in that one. We welcome bug reports, however, hand-wavy reports take a disproportionately large amount of time to answer so you run the risk of simply never receiving a reply. -- Regards Vincent
Re: User feedback requested
I fixed one double free bug that was showing up when this page was run on gtk frontend but it may be unrelated, can you try the latest build to be see? -- Regards Vincent http://www.kyllikki.org/
Re: User feedback requested (esp. RISC OS)
On Mon, Oct 01, 2012 at 08:15:00PM +0100, David H Wild wrote: > In article , >Bryn Evans wrote: > > Tried the second Sept 30th release and seems ok - > > RiscPC, StrongArm, RO4·02, 130Mb memory. > > In my case using RO 6.20. > > I have had no crashes but there is a silly with Flickr which doesn't > produce the individual images - although it does show the images on the > index page. With the March version I could see the pictures but there was a > message telling me to use Javascript for the best results. This message has > now disappeared, but I'd rather have the pictures. > > The readme file needs replacing, as it applies to the older system and > tells you how to install the boot and system files which are not supplied > with the new version. > Although this message is a reply to Mr Wild *everyone* should read it and understand what I am saying. I will endeavour to be as clear as I can be. If that comes across as overly abrupt I apologise but before any additional misunderstanding occurs I wish to make these points clear. * The Continuous Integration (CI) builds are produced for the NetSurf Developers. * We have chosen to make them publicly available *only* as a courtesy to our users. * The prominent and clear warning in the big orange box [1] is there for a reason, please read what it says. If you disagree its not open for discussion, simply do not use the builds! * The CI builds are *NOT* in any way, whatsoever, at all (can I make this more emphatic?) to be considered a usable release or something stable. If a build happens to work and not explode you are fortunate. * We are happy to accept reports of issues on these builds as long as full and concise information is provided in the report. A patch to fix the problem is more than welcome (do discuss it with the developers first - we may have already fixed it). * Opinion on what steps we "should" or "ought" to take to resolve an issue is best kept to yourself, especially if you have not understood the above points. * If these simple guidelines are ignored or argued over we will have to reconsider the open access policy FOR CI BUILDS (before anyone misquotes me). In summary: These builds are a debugging tool for the NetSurf developers which you can choose to use if you wish, as long as you understand they are in no way a release. If you find a bug reporting it clearly and concisely is fine patches very welcome and opinion is not useful. In this case: A report that the additional resources mentioned in the readme were missing (which is now fixed BTW) would have been fine. The exact version used and other information would have been nice to have. That was where it should have been left and now I have clarified the purpose of these builds I assume that in future the issue will not arise again. [1] http://ci.netsurf-browser.org/builds/ -- Regards Vincent
NetSurf Developer Workshop
We held our latest developer workshop this weekend, I have written about it on my blog[1] for those who might be interested in what we got up to. [1]http://vincentsanders.blogspot.co.uk/2012/11/another-netsurf-developer-workshop.html -- Regards Vincent http://www.kyllikki.org/
Re: Serious error on riscoscode site
On Thu, Nov 22, 2012 at 03:22:27PM +, David Pitt wrote: > Using Netsurf 2.9 or #665 on an ARMini or Netsurf 2.9 on VRPC. > > On this site http://www.riscoscode.com > > Clicking menu on the top section, the shaded grey box, results in a serious > error and Netsurf terminates. A log is at:- > fixed in #667 -- Regards Vincent http://www.kyllikki.org/
RISC OS Javascript support
Thanks to Rob Kendrik, Chris Gransden and myself we now have NSPR and Spidermonkey libraries building in the NetSurf toolchain[1]. The CI system[1] has built the toolchain successfully and a copy of NetSurf for RISC OS with Javascript enabled[3]. I would be grateful if any interested users could test this build. The javascript support is still *very* limited and the performance is unlikely to be awe inspiring, please do not expect a great experience. I still have a *lot* of interfaces remaining to implement and we are a small development team lacking an active RISC OS maintainer. *** Please Note *** All the usual caveats of using a CI build apply, additionally, this is the first successful *experimental* build with these libraries. I have been personally unable to test on RISC OS. It might fail in all sorts of interesting (Chinese proverb style) ways and I cannot offer support if it does. [1] http://git.netsurf-browser.org/toolchains.git/ [2] http://ci.netsurf-browser.org/ [3] http://ci.netsurf-browser.org/builds/riscos/NetSurf-gcc-json-727.zip -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS Javascript support
Thankyou for all your feedback. As some of you discovered there was no user interface to enable javascript so you would need to add: enable_javascript:1 to your configuration manually. It seems that the RISC OS edition of spidermonkey is failing to even initialise as can be seen within the log as: javascript/jsapi.c js_initialise 39: New runtime handle 0x0 which effectively means the javascript support is disabled and will not be able to use any script code on this platform (many of your examples work fine on the Linux platforms being used for development). If time permits I may look into this further but as I have limited access to RISC OS systems myself and the platform maintainer is currently not active I cannot promise progress in the immediate future. Sorry this was not more useful at this time but I do feel progress is being made albeit slowly. -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS Javascript support
Hi Chris, thanks for your ongoing help with this. On Sat, Dec 15, 2012 at 01:53:03PM +, Chris Gransden wrote: > In article <20121214122314.gg15...@kyllikki.org>, >Vincent Sanders wrote: > > Thankyou for all your feedback. > > > As some of you discovered there was no user interface to enable > > javascript so you would need to add: > > > enable_javascript:1 > > > to your configuration manually. > > While testing the various spidermonkey versions I added the user interface > to enable javascript. Here's a screen dump www.cgransden.co.uk/screen.png. Please can you send a patch? even if its just the files you changed I can work up a suitable patch from those, whatevers easiest. > > > It seems that the RISC OS edition of spidermonkey is failing to even > > initialise as can be seen within the log as: > > > javascript/jsapi.c js_initialise 39: New runtime handle 0x0 > > With 1.85 on RISC OS this happens with the JIT turned on. If the JIT is > disabled it gets a bit further then gets stuck in a loop. How do we disable JIT? I used your recipie to build spidermonkey as a template. Even with --disable-tracejit passed to configure METHOD JIT is still enabled (toolchain build has the patches and Makefile used[1] (in the sdk directory)). If I turn that off too (--disable-methodjit) the library fails to build, perhaps I am missing something? I would like to try and debug where the later version of spidermonkey fails as it is such a huge improvement in functionality going forwards. > > > which effectively means the javascript support is disabled and will not > > be able to use any script code on this platform (many of your examples > > work fine on the Linux platforms being used for development). > > > If time permits I may look into this further but as I have limited > > access to RISC OS systems myself and the platform maintainer is > > currently not active I cannot promise progress in the immediate > > future. > > > Sorry this was not more useful at this time but I do feel progress is > > being made albeit slowly. > > Would it be an option to use Spidermonkey 1.7 on RISC OS temporarily? This > version seems stable and all the javascript tests work ok. They give the > same results as the gtk version which uses 1.85. I can build 1.7 temporarily, but this is not really solving the issue at all and will (from past experience) almost certianly lead to RISC OS being stuck there forever. In future I do wish to move onto editions of spidermonkey past 1.8.5 (3 years old) which provide improved perfomance and functionality so limiting myself to version 1.7 (which is over five years old now, think firefox 2 era) seems counterproductive. > > Chris. > > > [1] http://git.netsurf-browser.org/toolchains.git/tree/ -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS Javascript support
On Sat, Dec 15, 2012 at 06:41:14PM +, Chris Gransden wrote: > In article <20121215171742.gh15...@kyllikki.org>, >Vincent Sanders wrote: > > > Please can you send a patch? even if its just the files you changed I > > can work up a suitable patch from those, whatevers easiest. > > Steve already beat me to it. Those changes are working. good to know > > > How do we disable JIT? I used your recipie to build spidermonkey as a > > template. Even with --disable-tracejit passed to configure METHOD JIT > > is still enabled (toolchain build has the patches and Makefile used[1] > > (in the sdk directory)). If I turn that off too (--disable-methodjit) > > the library fails to build, perhaps I am missing something? > > > I would like to try and debug where the later version of spidermonkey > > fails as it is such a huge improvement in functionality going > > forwards. > > I think the JIT is built if ARM is detected. Setting > WTF_CPU_ARM_TRADITIONAL 0 in Platform.h and '-DENABLE_ASSEMBLER=0 > -DENABLE_JIT=0' stops it building the JIT. > might try this today though I have run out of time for messing with toolchain stuff right now. > > I can build 1.7 temporarily, but this is not really solving the issue > > at all and will (from past experience) almost certianly lead to RISC > > OS being stuck there forever. > > > In future I do wish to move onto editions of spidermonkey past 1.8.5 > > (3 years old) which provide improved perfomance and functionality so > > limiting myself to version 1.7 (which is over five years old now, think > > firefox 2 era) seems counterproductive. > > I thought it would be useful for getting people to test stuff now. I spent a few hours on this yestarday. The 1.7.0 download [1] is not autoconf and I was unable to persuade it to cross compile with our toolchain let alone with the nspr. If you have a recipie that would be great... > > Chris. > > > [1] http://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS Javascript support
On Sun, Dec 16, 2012 at 01:18:52PM +, Chris Young wrote: > On Sun, 16 Dec 2012 11:44:53 +0000, Vincent Sanders wrote: > > > I spent a few hours on this yestarday. The 1.7.0 download [1] is not > > autoconf and I was unable to persuade it to cross compile with our > > toolchain let alone with the nspr. If you have a recipie that would be > > great... > > 1.7 doesn't need NSPR, that's one of the advantages of using it (I'm > still watching a couple of Bugzillas for NSPR to be removed from newer > Spidermonkey, it should be easier to get that to work then). I must have misunderstood what teh DIST variable points at then? but thats perfectly possible ;-) > > I have an archive with a hand-crafted makefile, although I have a > feeling there are a couple of executables that it has to build in > order to build the library, that I ended up having to build manually, > so it'll need some tweaking. I can send it to you if you want it (it > has all the AmigaOS changes too, but they are all #ifdef'd XP_AMIGA so > won't affect RISC OS) > well I would be very interested in a diff against the distribution archive anyway. If I can get the NetSurf toolchain package building spidermonkey for your platform we can get the CI builds (and by extension future release builds) to generate output with JavaScript support for your platform > Chris > > -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS Javascript support
OK, the CI system just built #740 with a spidermonkey 1.8.5 library with the JIT disabled as suggested by Chris Gransden. Can this be tried by someone with access to RISC OS? and please be aware this may well behave very badly indeed. If this fails I have now successfully built 1.7.0 for RISC OS (though not run tested) so the possibility of using an older known working version exists. Please remember to enable javascript via the nice shiny new configuration interface Steve Fryatt has provided. -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS Javascript support
On Sun, Dec 16, 2012 at 04:07:25PM +, Chris Gransden wrote: > In article <20121216154023.gl15...@kyllikki.org>, >Vincent Sanders wrote: > > OK, the CI system just built #740 with a spidermonkey 1.8.5 library > > with the JIT disabled as suggested by Chris Gransden. Can this be > > tried by someone with access to RISC OS? and please be aware this may > > well behave very badly indeed. > > It get stuck in a infinite loop as soon as a web page is opened. Alt-break > is the only way to quit. > bother, oh well. any posibility of a log to maybe debug it? anyway I will sort out switching to the 1.7.0 build for now. > Chris. > > > -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS Javascript support
ok last try for now, ci #744 is built with spidermonkey 1.7.0 maybe it works maybe it doesn't. Please also remember to use the json tagged downloads if you want to try with javascript as the jsoff ones do not even have teh interpreter linked. -- Regards Vincent http://www.kyllikki.org/
Re: On line passport application
On Sun, Jan 13, 2013 at 11:32:14PM +, Tim Hill wrote: > In article > <56966.82.153.33.53.1358117198.squir...@email.orpheusnet.co.uk>, Gerald > Dodson wrote: > > > In message > > > <55612.82.153.33.53.1358077313.squir...@email.orpheusnet.co .uk> > > > "Gerald Dodson" wrote: > > > > > >> Trouble with this on the UK gov site: goes to an error 404 screen. > > >> Has anyone had success with this? > > > > > > Hi Gerald > > > > > > Can you give the URL? I'll have a go. > > > > > > Chris. > > > > > > > It is: > > > https://passports.ips.gov.uk/epa1r1a/ctl04 On Suirrel it does not show > > distinction between lower case 'l' and number 1. The string "epa" is > > followed by number 1r1: the 'ct' by lower case 'l'. > > Perhaps you should use a better font. (What's Suirrel?) > > As usual, this seems to be a NetSurf+Javascript issue. On 'another > platform' with a modern browser, the page linked to from > passports.ips.gov.uk is > https://passports.ips.gov.uk/epa1r1a/Rich/Formpage.aspx and not what > Netsurf comes up with that you quote; it uses a javascript link. Even > NetSurf's partial javascript is obviously not catered for. Actually the *correct* analysis is: https://passports.ips.gov.uk/ ->302 redirect -> https://passports.ips.gov.uk/epa1r1a/index.html All the links use old style javascript: URI scheme links (instead on onclick) calling __doPostBack(); unfortunately because out User-Agent reply is truthful and not a pack of lies. The site is not serving any of the javascript code to provide the actual implementation for __doPostBack which, unsurprisingly, results in bad page navigation. I will open the discussion with the other developers on our UA string again...trouble is I agree with the principle of not lieing so this is a difficult issue to think about. > > Whether you can get any further with NetSurf is not something I would > bother to try. I long ago gave up using RISC OS for 'serious' surfing. > Even a £28 Android tablet is more capable, unfortunately. This is not a helpful statement, especialy not on the NetSurf users mailing list, you are of course entitled to express your opinion...elsewhere. > > -- > Tim Hill > .. -- Regards Vincent http://www.kyllikki.org/
Re: Upper character truncation - CSS handling
On Sun, Apr 14, 2013 at 10:04:10PM +0100, John Williams wrote:
>
> I see at:
>
> http://www.pets4homes.co.uk/sale/dogs/bedlington-terrier/wakefield/
>
> an illustration of the subject line which may be related to the problem
> (which I have lost track of) reported by me, and, I think, Dave Higton some
> years ago which was not actioned.
>
> The problem is that the top few lines of the characters in the headines are
> not displayed.
>
If you want this fixed please submit it to our issue tracker,
otherwise it is liable to be ignored.
Some brief analysis shows this is due to the css rule:
.curvedboxcontainer h1 {
font-family: Passion One, Helvetica, san-serif;
font-size: 36px;
color: #b66222;
line-height: 90%;
}
It appears the bounding box height is scaled by 90% but not the text
itself. I also note NetSurf falls back to the sans-serif font choice
which should not be a factor.
--
Regards Vincent
http://www.kyllikki.org/
Re: downloading older development versions
On Mon, Apr 22, 2013 at 01:12:08PM +, Tony Moore wrote: > Between NetSurf #417 (9 Oct 2012) and #461 (13 Oct 2012), it became > impossilbe to log-in to Yahoo webmail because, apparently, redirection > failed. I reported the problem > https://sourceforge.net/tracker/?func=detail&aid=3579166&group_id=51719&atid=464312 > but it persists, as of today, in #1083. > > I would like to determine the version in which the problem first occurs > but I cannot find any way of downloading versions prior to those listed > at http://ci.netsurf-browser.org/builds/riscos/ > > Could someone please suggest how this may be done? It cannot, the CI service only keeps the last 25 builds However: build #417 was at commit 38a9c374a4685c6b06625e63c3e305101e531d81 build #461 was at commit 61a2b8ddc452b915925793f4f538dbb2ca9b5ba5 and git log 38a9c374a4685c6b06625e63c3e305101e531d81..61a2b8ddc452b915925793f4f538dbb2ca9b5ba5 shows all changes between them I have added teh list to the bug > > Tony > > > > > -- Regards Vincent http://www.kyllikki.org/
Internationalisation
I recently had opportunity to integrate a translation platform into the NetSurf workflow[1]. This integration has been performed on the transifex platform, is complete, and does work reasonably. However without real actual translations it is not useful. I would like to invite anyone with translation skills to improve the netsurf project by using this web interface to enter translations[2]. I am especially interested in any of our current developers providing translatiopns who wish to become translation reviewers to ensure we maintain a high quality. The current number of translated/reviewed strings by language is: English: 100%/100% French: 93%/93% Dutch: 92%/92% German: 92%/92% Italian: 92%/92% Spanish: 87%/0% Chinese: 0%/0% The review status is purely based on the existing corpus (i.e. if it is in the current set of translations it is considered reviwed) The spanish translation is currently a pure machine translation althouh we already have some volunteers from the translation community to whom I am grateful for their input. [1] http://vincentsanders.blogspot.co.uk/2013/05/true-art-selects-and-paraphrases-but.html [2] https://www.transifex.com/projects/p/netsurf/ -- Regards Vincent http://www.kyllikki.org/
Mac OS X
We continue to compile for the Mac OS X cocoa frontend on both PowerPC (OS 10.5 leopard) and x86 (OS 10.6 snow leopard). The Continuous Integration (CI) system uses two real mac mini computers[1] as build slaves as Mac OS X cannot currently be reliably cross compiled for. Recently the PPC CI system build slave (chimera) had a catastrophic hard drive failure and required a complete OS and development tools reinstall. This re-install took an extended period of time as the PPC system is somewhat slow compared to other targets. Generally we use SSD in our build slaves, however I was unwilling to bear the cost of a 2.5inch PATA SSD for this system so its been reinstalled with a reconditioned Seagate 5200 RPM drive. The cocoa frontend currently has no maintainer and I am interested in hearing from any actual users to give an indication as to whether it is worth investing any additional resources on this platform. So any actual users or developers, please speak up now! Note I am not asking for opinion about other considerations such as diversity and how nice it is to have a wide range of platforms supported, purely if there are any actual users. If there are none I shall simply remove these targets from the CI system on the next occasion this rather old and *very* slow hardware fails. [1] http://www.flickr.com/photos/29254252@N06/8519229958/in/set-72157626712232414 -- Regards Vincent http://www.kyllikki.org/
Options/Choices refactor
I have finally completed and merged my refactor of the NetSurf user option code. This means that user options files will now only contain the options which differ from the defaults. This will alow us to alter the defaults in future and have everyones choices actually update instead of being overidden by old saved default values that might not be useful. There may be a small but annoying side effect to this chnage in that many people will have bad default settings saved in their Choices files already which will now be faithfully applied even if they are unwanted. The principle place this will be observed is with system colours. These are the colours exposed as specifically named css properties [1] and can be seen on test pages [2] NetSurf also uses these colour settings throughout the UI for several platforms. Each platform sets its own defaults and the users configuration is available to override these settings. Up to this point the system colour configuration and setup has been somewhat flawed and will probably have resulted in most users saved Choices containing a set of overrides setting all these colours to black! (0) If you experience such behaviour with CI builds after #1212 please edit your Choices file to remove all the entries beginning with "sys_colour_" they should not reappear subsequently (unless you would like black controls, labelled in black on a black background, with a little black light that lights up black to let you know you have done it.) [1] http://www.w3.org/TR/css3-color/#css-system [2] http://www.iangraham.org/books/xhtml1/appd/update-23feb2000.html -- Regards Vincent http://www.kyllikki.org/
Choices change, or avoiding the all black
As this seems to be a stumbling block for so many and I can see complaints from users upgrading stretching into my future. The choices validation will (from CI build #1223), when the system colour options are all configured to black, simply reset them back to defaults. This does mean that in future noone will be able to set all system colours to black intentionaly, but as that seems a daft thing to do anyway... -- Regards Vincent http://www.kyllikki.org/
Re: Colours
On Wed, May 29, 2013 at 02:53:18PM +0100, Gerald Dodson wrote: > Following the recent changes and my deletion of ..Choices the colours have > obviously changed - in the Hotlist in particular. I have looked at the > User document but not found any way of changing the colours. How can this > be done? The default colours can now be configured by each frontend maintainer as they see fit. I beleive on RISC OS the defaults are derived from the wimp colours and on GTK they are the css spec defined defaults (which are a bit ugly truth be told). However there are user settings to override all these. you can see all configuration values on the about:Choices page and see the pretty version on about:config The numbers are hexidecimal values in the format OOBBGGRR Where O is opacity 0x00 is opaque 0xff is transparent BB is blue GG is green RR is red For reference the default values are: sys_colour_ActiveBorder:d3d3d3 sys_colour_ActiveCaption:f1f1f1 sys_colour_AppWorkspace:f1f1f1 sys_colour_Background:6e6e6e sys_colour_ButtonFace:f9f9f9 sys_colour_ButtonHighlight:ff sys_colour_ButtonShadow:aeaeae sys_colour_ButtonText:4c4c4c sys_colour_CaptionText:4c4c4c sys_colour_GrayText:505050 sys_colour_Highlight:0008c0 sys_colour_HighlightText:ff sys_colour_InactiveBorder:f1f1f1 sys_colour_InactiveCaption:e6e6e6 sys_colour_InactiveCaptionText:a6a6a6 sys_colour_InfoBackground:efdf8f sys_colour_InfoText:00 sys_colour_Menu:f1f1f1 sys_colour_MenuText:4e4e4e sys_colour_Scrollbar:cc sys_colour_ThreeDDarkShadow:aeaeae sys_colour_ThreeDFace:f9f9f9 sys_colour_ThreeDHighlight:ff sys_colour_ThreeDLightShadow:ff sys_colour_ThreeDShadow:d5d5d5 sys_colour_Window:f1f1f1 sys_colour_WindowFrame:4e4e4e sys_colour_WindowText:00 -- Regards Vincent http://www.kyllikki.org/
Bugs, their care and stomping
The NetSurf team are pleased to announce the availability of a new bug tracker [1] The new tracker uses mantis [2] software which is usable from NetSurf This move has been necessitated because of several issues, principally: - The SourceForge issue tracking system has been upgraded and is now unusable from NetSurf - The advertisements on the site have become aggressively invasive - The reliability of the site has come into question. We have imported the bugs from SourceForge although this has resulted in a renumbering of identifiers (bug numbers). We have been able to put a link back to the old sourceforge bug numbers in the "Additional Information" of every imported bug. Please do not use the SourceForge tracker for any new bugs or update any old ones there as they will be ignored. Accounts We have created users within the new system for everyone who has reported a bug. For most imported users the email address used was their sourceforge contact address [3] The new system does not allow for anonymous issue reporting, if this is a problem for you we thank you for your opinion but this decision is not negotiable. To login please use the lost password interface [4] to update your details if you wish. If a user needs the address associated with their account altering and cannot access it through sourceforge please contact us [5] giving as much information as possible (including the user id and some reasonable argument that the account is yours - we will set the address to where you send the mail from) Accounts have been created manually for the many users who usefully put their contact details within their reports, additionally their email details have been removed from the publicly visible reports which should reduce spam harvesting. We assure all users we will never use the email addresses given to the system other than to reply to their bug reports. New and existing bugs - Updates to bugs will (by default! this is configurable for each user [6]) result in the reporter receiving an email. If you wish to update a bug please use the web interface, replying to the emails means a developer has to manually copy the reply to the bug. We may reconsider changing the reply address to refuse mail if this becomes a burden. New reports should contain as much information as the reporter can provide we give some guidence [7] but ultimately the more information you provide the more likely we can reproduce the issue and the more likely it is to get resolved. Debugging is hard [8] please do not have unreasonably high expectations, we did *not* intend to have the bug that you found, please do not take it personally. I have currently triaged just over 10% of the open bugs and will make my way through those that remain over the forthcoming weeks. Please understand that there are very few active developers and many open bugs so this work goes slow. I have to be pretty harsh in my triage and will close incomplete bugs (especially anonymous ones) without a detailed examination. These may be reopened by the reporter but I request that as much information is provided as you can. What things mean I know some reporters are already misunderstanding what the various fields in a report are for, especially the severity and status fields. Severity refers to how severe the impact is on the project overall i.e. if the bug causes a crash in normal operation (crash severity) and is *not* a reflection on how important the bug is (we specifically do not have a priority field for that). To be clear the *default* of minor means, in this context, that the bug does not make the browser unusable for *everyone* Status is related to the bug work flow within the netsurf team. It starts at new when the bug is reported, gets set to feedback when we need more information from the user or a user reopens an unresolved issue. The acknowledged status means a developer has at least looked at the report but not reproduced the issue whereas confirmed shows they have reproduced it (not the reporter, we know they managed it!). The assigned status means that one of the developers has decided they are the best person to fix the issue and are actively examining the problem. We are also using the assignment to the import user as a flag that basic triage has not yet been performed on the bug. Finally the resolved status implies that the resolution field should be looked at to see how the issue was resolved and the closed status implies the developer has finished with the report and no additional activity will be made on the issue. [1] http://http://bugs.netsurf-browser.org [2] http://www.mantisbt.org/ [3] if the userid on sourceforge was kyllikki the email used was kylli...@users.sourceforge.net [4] http://bugs.netsurf-browser.org/mantis/lost_pwd_page.php [5] h...@netsurf-browser.org [6] http://bugs.netsurf-browser.org/mantis/account_prefs_page.php [7] http://bugs.netsurf-browser.org/ [
Re: Bugs, their care and stomping
On Wed, Dec 18, 2013 at 02:29:06AM +, Harriet Bazley wrote: > On 17 Dec 2013 as I do recall, > Vincent Sanders wrote: > > [snip] > > > > We have created users within the new system for everyone who has > > reported a bug. For most imported users the email address used was > > their sourceforge contact address [3] > > > > > Oh -- oops, there's two of me now, then... Only one now, I moved all 59 of your old reports to your new user > -- > Harriet Bazley == Loyaulte me lie == > > It is better to wear out than to rust. > > -- Regards Vincent http://www.kyllikki.org/
NetSurf Developer workshop
The write up of our recent developer weekend is now available [1] for those interested in what we achived. [1] http://vincentsanders.blogspot.co.uk/2014/01/netsurf-developer-workshop-redux.html -- Regards Vincent
Re: Bad archive
On Mon, Feb 03, 2014 at 11:44:03PM +, cj wrote: > In article <803664d453.wra...@wra1th.plus.com>, >Gavin Wraith wrote: > > NetSurf 3.1 (Dev CI #1681-9) all give "bad archive" when I try to > > unzip. The relevant files appear to be !Help, !Run and !RunImage. > > Is this just me? > > There does seem to have been a problem with the jsoff builds > recently. The zips arrive as zero length files. The json version The CI system is no longer generating jsoff builds at all for any target that supports a build with javascript. The ability to disable javascript as an option remains. This was a decision made at the developer workshop (it is on the whiteboard) http://vincentsanders.blogspot.co.uk/2014/01/netsurf-developer-workshop-redux.html > seems fine. It is screwing up my auto download and updater, though, > because the extraction of Netsurf from the zero length zip obviously > fails. In fact its not you are downloading zero length archives, it is more that you are trying to fetch non-existant archives. > > -- > Chris Johnson > > -- Regards Vincent http://www.kyllikki.org/
Re: Sockets
On Tue, Feb 04, 2014 at 11:08:33AM +, Geoffrey Baxendale wrote: > Hi, > > Is it just me, or is Netsurf's sockets system awry. After a modest > browsing session Internet access freezes up due, I think, > to sockets being used up. Qitting Netsurf restores order. It seems to > have started about a couple of weeks ago. Not sure of the exact time. > > Risc Os 6.2 NS R1681. (JSoff) are you reporting a duplicate of http://bugs.netsurf-browser.org/mantis/view.php?id=2064 if so can you please add your observations to the bug as a note > > TTFN > -- > Geoff. > Using Acorn StrongARM Kinetic RiscPC. > Oxymoron of the day: "Little Monster" > > -- Regards Vincent http://www.kyllikki.org/
Re: MousAxess
> Yes. And I can't log in either (FF, Windows - at work). I can't remember > my credentials. > > I haven't logged in since the bug tracker changed to Mantis. I've also > changed email address some months ago; I can't remember whether I > updated them in the previous bug tracker. So I don't know whether my > credentials have been ported; and even if they have; I can't remember > them :-( As mentioned in previous mails to the list about the new bug system, yes almost everything got imported from the old system, including their accounts etc. however sourceforge "sanitised" the data they made available to us so the import is a bit incomplete in places. Imported users will need to use the "forgotten password" interface to re-verify their account. Once verified they can login and change the email address to something more suitable. If (as in your case) they have lost everything, please contact h...@netsurf-browser.org with a request to change details. On this occasion I have reset your account (davehigton) email to d...@davehigton.me.uk. you now need to retrieve your password and login. -- Regards Vincent http://www.kyllikki.org/
Your bugs in the tracker
Can anyone who has an open bugs in our tracker [1] please go and review your reports. We have almost 200 outstanding bugs and it is very hard keeping on top of them. An number of older bugs are awaiting feedback from the reporter or no longer apply to current versions. If you have a bug like this please, please assist us by replying with requested feedback or adding a note that simply says if the issue is still reproducible. We are trying to get on top of the bugs for the next release bug your assistance is appreciated. As previously mentioned all old accounts and bugs have been imported from sourceforge but if you no longer remember your user name, have access to your sourceforge email or other issues logging in just contact us [2] (please no direct email as it will just add work for us forwarding it to the role address). [1] http://bugs.netsurf-browser.org/mantis/my_view_page.php (select "Reported by Me" link) [2] h...@netsurf-browser.org -- Regards Vincent http://www.kyllikki.org/
Re: Allrecipes website
On Fri, May 02, 2014 at 08:16:10PM +, Peter Slegg wrote: > > I am using the Atari build No. 1841 (m68k) and this allrecipes page just > displays blank. That build is a little behind but it does not seem to matter, current HEAD on gtk on Linux builds is also empty. Please can you submit a bug report to the tracker [1] > > It is probably just the JS but I can't test that here. I tried editing > the page source to remove the JS but still blank. There is a lot of JS on that page but its failing to display the noscript with it turned off so something else is wrong. > > Can someone else confirm the behaviour and if it is the JS ? > > > > Peter > > > > > [1] http://bugs.netsurf-browser.org/mantis/ -- Regards Vincent http://www.kyllikki.org/
Re: mantis not updated for 3.1
On Mon, Apr 28, 2014 at 10:01:13AM +, Tony Moore wrote: > On http://bugs.netsurf-browser.org/mantis/bug_report_page.php the drop- > down menu, attached to the 'Product Version' field, needs to be updated > to include 3.1 I updated this a week ago but only just noticed this message, all ok now I presume? > > Tony > -- Regards Vincent http://www.kyllikki.org/
Persistant disc cache
I am pleased to be able to announce that I have enabled the persistent source object cache on the RISC OS build. This means that RISC OS CI builds from #1956 onwards have the capability to store cacheable objects fetched from from the web to disc. I would appreciate any feedback on this feature though bugs should be logged through the usual means of the bug tracker. This cache will reduce the amount of data downloaded for many web pages (in some cases dramatically) and should improve the overall user experience. The tradeoff here is using disc space (and some memory for book keeping) in return for a reduction in bandwidth usage and latency. If your system has limited disc or memory you may wish to disable this feature. The amount of disc used for this cache is selected using the disc_cache_size option. The RISC OS frontend does not currently have a user interface to set this value. The cache value is number of bytes to use on disc and a value of 0 will disable the cache completely. The default value is set to a gigabyte. To set this value you need to quit NetSurf, edit the Choices file manually and restart NetSurf. This feature uses the !Cache resource from Adam Richardson which is distributed as part of the !Boot resources in every CI release build. The !Boot should be merged to get this installed. If !Cache is not available the cache will be disabled. -- Regards Vincent http://www.kyllikki.org/
Re: Persistant disc cache
On Thu, Jun 05, 2014 at 08:34:08PM +, Tony Moore wrote: > On 5 Jun 2014, Vincent Sanders wrote: > > > I am pleased to be able to announce that I have enabled the persistent > > source object cache on the RISC OS build. > > That's good news. Many thanks. > > [snip] > > > The amount of disc used for this cache is selected using the > > disc_cache_size option. The RISC OS frontend does not currently have a > > user interface to set this value. The cache value is number of bytes > > to use on disc and a value of 0 will disable the cache completely. The > > default value is set to a gigabyte. > > Does that mean disc_cache_size:1073741824 ? yes thats the default setting, as usual if the setting is the default value it will not appear in the user Choices file. > > The disc cache now seems to be named 'Misc'? Is there any way of moving > it out of !Scrap? I have no idea to what you are referring, as I said in the previous mail we are using !Cache (shipped in the !Boot of the CI builds ready for merge) to store this persistent data. This is because !Scrap is for transient data and many users do not store it on persistent storage. The cache must be persistent between runs of the browser to be useful. > > Tony > -- Regards Vincent http://www.kyllikki.org/
Re: web page is blank with new vwersion on NeSurf
On Fri, Jun 06, 2014 at 10:40:48PM +0100, John Rickman Iyonix wrote: > Since moving to #1959 the following page is blank. It should show > three columns of text. > http://rickman.orpheusweb.co.uk/lynx/lynxweb.html > > It works as expected with #1785 and all earlier versions. Hove you reported a bug? When you do please note that this issue is a layout issue caused by teh recent improvement of the overflow css rules. In the css on the referenced page .col3 has an overflow:hidden; which, if removed, restores the page layout. > > Would someone please check that this problem is reproducible on a > machine other that my Iyonix. > I have updated Boot with the Boot that came with the disc cache > version and Java script is enabled. > > John > > -- > John Rickman - http://rickman.orpheusweb.co.uk/lynx > > -- Regards Vincent http://www.kyllikki.org/
Re: BoxConvert?
On Sat, Jun 07, 2014 at 04:50:01PM +0100, Richard Torrens (lists) wrote: > What does the message BoxConvert mean? It's obscure to say the least! It is, and it is a implementation detail from some code that requires improvment in its error reporting. It efectively means "it went badly wrong" and was caused as a side effect from ChrisY nice work supporting IDNA hostname format. Any URL where the hostname was invalid for the IDNA parser caused the new code to report that error, unfortunately as I mentioned the higher level code delt with this poorly. I have commited a possible fix which is available from the CI system as build #1962 Hopefully this fix will fare better than Ranger 3 did in 1962. > > I now (3.2 (Dev CI #1959)) get it on every local www page I run. Which is > a pain - as I cannot then check a www page before uploading. > > I suspect it may be because I use SSI on my www pages: they contain, for > example > > and > Page Information > Document URL: > Page first published 30th July 2005 > Last modified: > > © 2005- 4QD > > -- > Richard Torrens. > http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, > cats > and more! > > -- Regards Vincent http://www.kyllikki.org/
Re: web page is blank with new vwersion on NeSurf
On Tue, Jun 10, 2014 at 11:27:46PM +0100, Harriet Bazley wrote: > On 7 Jun 2014 as I do recall, > John Rickman Iyonix wrote: > > > John Williams wrote > > > > >Fred Bambrough wrote: > > >> Ah, having seen what it's supposed to be on my Mac... yes, it's blank. > > > > > It broke between 1932 and 1935. > > > > Thanks to all who tested and confirmed the problem. > > I will report it as a bug. > > > I wonder if this is the same as the behaviour I was seeing in bug > http://bugs.netsurf-browser.org/mantis/view.php?id=2143 ... > (had to revert to version 1932 due to the segfault part of the report!) As I already said, this is caused by the overflow css changes, needs a bug creating and tlsa to fix it. > > -- > Harriet Bazley == Loyaulte me lie == > > I mean to live forever - or die trying! > > -- Regards Vincent http://www.kyllikki.org/
Re: Disc cache worth it?
Although this reply is to Peter it applies to all the subsequent discussion. Firstly, as I did memntion in my original mail this feature is new and not tuned yet so may have adverse behaviour on some systems. Please do not draw any conclusions about the usefulness or otherwise of this feature from *development* snapshots. If you want stable behaviour the 3.1 release should be used. It may well turn out that this feature is simply unsuitable for RISC OS but we are at the beginning of a long road. As we have seen with the issues around !Cache and now with general perfomance, the challenges of building a cache suitable for use across many systems are not inconsiderable On Mon, Jun 23, 2014 at 05:58:52PM +0100, Peter Young wrote: > I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to > have found some downsides to it, and I wonder if (a) I'm doing it > correctly and (b) if it's worth the occasional faster opening of some > sites. Subsequent mails indicate you were using this correctly, as to the "worth it" that is what we need to evaluate. I prevoiusly mentioned it, but I shall re-iterate: The persistant cache is purely a trade, in this case it is trading disc resource for network resources. I use the term disc resource carefully, it includes both storage space *and* the time to store and retrieve the files. Similarly network resource is the data downloaded *and* the latency getting that data. > > If I load, for instance, http://www.bbc.co.uk/news/ as the first site > of a session, it loads maybe a little faster, but then I get > intermittent hourglass activity for sometimes up to thirty seconds, > during which I can't do anything else. There are several other sites, > for instance Wikipedia home page, which do the same. And the next day > the same happens. What is happening here is that when your browser has gone idle after retrieving the website you have numerous objects (images html files etc.) which are eligible to be written out to the persistent cache. Given the front page of the BBC news site is (right now) 1.1 Megabytes in 187 files which can rise to in the region of 2 Megabytes or more if there are a image heavy news stories, that represents a great deal of data to be written out. The write out task then starts writing these to disc limited by a bandwidth cap. In the current implementation this is hard wired to a maximum write bandwidth of 512K/second. It had not occurred to me that such a rate would not be achievable. Because the code does not moderate its write rate you have to watch the hourglass as it saves those files to disc. This is made much worse, as as I understand it from knowlageable RISC OS people, because disc writes are not performed in the background. In your example if we assume you managed to get four megabytes of cached data to be written and it took 30 seconds to achive that, we get a write rate of around 130K/second or roughly a Megabit/second. Your network connection does not have to be very good at all to outrun the disc and hence the disc cache is making a horrible trade in your case. > > Looking in !Cache, which is in !Boot.!Resources, I find that in the > Caches.Default.NetSurf directory there are currently 1933 files, > totalling 22449384 bytes. Is this to be expected, as I don't use > NetSurf a huge amount? I've already excluded this directory from my > daily backup, which has been taking a lot longer since I started using > !Cache. The web is huge these days, 22 Megabytes is literally only 20 pages on most sites, even if the site shares those objects between multiple pages, just visiting all the heading sections of BBC news requires 10Megabytes of persistant storage and over 1000 files. For example google chrome by default uses 16Megabyte blocks to store sub 16k sized objects and creates four of those to start with It is not uncommon for a well used browser to have several gigabytes of disc used for web caches. In most current systems using a gigabyte of RAM let alone Disc is not uncommon. In summary, the cache: - Is still in development. - Is not a panacea and will not benefit everyone. - Is a compromise trade, and it seems for some systems with slow disc it is literally faster to retrieve from network than from local storage. - Is likely to be very large to be effective as the source web pages are large. - Can be disabled by setting its size to zero. I will look into adding a heuristic to disable or at least tune the cache writeout if it detects it is exceeding the available disc bandwidth. -- Regards Vincent http://www.kyllikki.org/
Re: Bug reporting
On Mon, Jul 07, 2014 at 11:15:09PM -0800, Dave Higton wrote: > The first thing the bug tracker asks is Category, which is a > list of platforms from which I have to choose one, indicating > that the bug is specific to a platform. > > But, since I only have one platform, how do I know if what I'm > reporting is specific to that platform? > It is intended to give us more information. All bug fixing runs through the basic stages of replicate, isolate and ameliorate. In order to replicate a bug to start this process we require as much information as possible. > How to the developers react to it? Now that RISC OS is a > minority platform for Netsurf, does it make the developers > take less notice of the report? makes no difference response wise > > Or do the developers take it as simply the platform on which > it was first observed, and find if it's common to other > platforms? pretty much, might also let us decide it is frontend specific and assign it to the appropriate frontend maintainer. If the issue is not specific often we will just change the catagory to suit. The main issue with bugs right now is we have more of them being reported than we are managing to fix (gaining about one a day currently) but its more useful to have them reported than not. > > Dave > > > FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! > Check it out at http://www.inbox.com/earth > > -- Regards Vincent http://www.kyllikki.org/
Re: Bug reporting
On Wed, Jul 09, 2014 at 03:48:11AM -0800, Dave Higton wrote: > On Wed, 09 Jul 2014 11:51:10 +0100 Richard Porter wrote: > > > On 8 Jul 2014 Dave Higton wrote: > > > >> The first thing the bug tracker asks is Category, which is a > >> list of platforms from which I have to choose one, indicating > >> that the bug is specific to a platform. > > > >> But, since I only have one platform, how do I know if what I'm > >> reporting is specific to that platform? > > > > You don't but the developers may need to know what platform you are > > running on. I take it to mean hardware platform since the OS and > > version are asked for separately. > > OK, but that's not what it actually says. The options under > "Category" are: > > ABEND > Amiga-specific > Atari-specific > BeOS-specific > Cocoa-sepcific > Framebuffer-specific > GTK-specific > Javascript > Layout > RISC OS-specific > Win32-specific > [All Projects] General If you are in any doubt of the category to use then use the General category (it is a universal default category for all projects). For you as a risc os user your options are limited to: Javascript - issues obviously related to javascript. Layout - Issues where the layout of the page is incorrect. RISC OS-specific - Issues related to the RISC OS UI specifically, like errors in the toolbar or configuration windows etc. [All Projects] General - As already mentioned this is the default, if you are unsure at all, just use this. > > I, as a user of a single OS, cannot tell whether the problem is > specific to that OS, yet the field is required input from me. > The catagory is intended for issues specific to those OS frontends, if you are not using them it cannot possibly be relevant to you. As I outlined above, you (currently) have a choice of four. > I don't want to make a big deal out of it, but it does look to > be a misnomer, and I was just looking for some clarification of > its significance to the developers. I've got it. > > AAMOI: what is the ABEND option about? ABnormal END is a special classification for reported issues where the program terminated abnormally with invalid state, literally the program termination was abnormal. Generally these are aborts not caused by assert() debug macros or our code dereferencing bad pointers those are "normal" aborts. This class is only useful to developers triaging bugs and I would hide it from normal users if mantis allowed it. > > Dave > > > Protect your computer files with professional cloud backup. > Get PCRx Backup and upload unlimited files automatically. > Learn more at http://backup.pcrx.com/mail > > -- Regards Vincent http://www.kyllikki.org/
Re: 2000 plus behaviour
On Wed, Jul 09, 2014 at 10:12:45AM +0100, Brian wrote: > So far as I can tell, every version since 2000 goes into some kind of loop > when downloading and rendering pages. Though a page may appear to have > been completely rendered the 'eggtimer' continues to scroll and obstructs > other activities like quitting NetSurf. > > -- > bbai...@argonet.co.uk > > Try 2011 or later -- Regards Vincent http://www.kyllikki.org/
Re: dropzone on a web page
On Thu, Sep 11, 2014 at 02:25:52PM +0100, Jim Nagel wrote: > It's good to see the World Out There starting to adopt drag-and-drop > in some situations where Acornuts have taken it for granted for 30 > years. > > For instance http://onlinemd5.com is a service that calculates the MD5 > checksum for any file without having to upload it: you just drag the > file out of its directory to the dropzone on the web page. This works > a treat in Windows on my laptop. > > Unfortunately, though, not in RiscOS Netsurf: if the file is a Jpeg > or text, Netsurf displays the picture or text rather than feeding the > file to the MD5 calculator. This "dropzone" tenchniqe relies upon adding a div element with a "special" class around a form with an input of the file type (which we support and actually you can drag and drop to such widgets already). The surronding div elemnt has a javascript "drop" event added to it which gets the filename dropped and updates the form file widget. At this time the NetSurf javascript implementation supports very few events, this support does not include any of the "drag and drop" events. > > Of course, it could be that the calculation is performed by Javascript > so Netsurf couldn't handle the job anyway. > > But I'm curious about the technique involved in registering a file's > pathname by this "dropzone" method. Can Netsurf cope with this in > principle? > > -- > Jim Nagelwww.archivemag.co.uk > > -- Regards Vincent http://www.kyllikki.org/
Re: My wish: To be able to save just the HTML file
On Sat, Sep 20, 2014 at 03:35:43PM +0300, Vesa Paatero wrote: > Hi, > > My wish for Netsurf developers is a simple one: To be able to save > just the HTML file of a web page with link references intact. > Currently, Netsurf always saves the whole web page, i.e. the HTML > file with links changed to point to the associated files saved into > a directory automatically created for them. I imagine it would be > relatively easy to enable saving just the HTML page, yet it > currently can't be done ... or if it can be done, please let me > know. You did not specify which toolkit you are using. In RISCOS you can just use the menu or F3 to save the page source. With GTK you simply have to use Tools->Developer->Page Source (Ctrl+U) and then save the file from there. Other frontends depend upon their native implementations and I do not know the specifics. Perhaps we need to take a look at the user guide again it does seem to be a little out of date in places. > > Thanks for considering it! > > Vesa > > -- Regards Vincent http://www.kyllikki.org/
Re: Atari test builds
On Tue, Sep 23, 2014 at 06:28:44PM +, Peter Slegg wrote: > The Atari build folder is empty: > > http://ci.netsurf-browser.org/builds/atari/ > Unfortunately the CI system master ran itself out of disc and I had to clean out some corrupted builds including the gtk,monkey and atari directories. I have rectified the disc issue and we now have plenty of space so this should not happen again. sorry for any inconvenience. -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS Save-as PDF file
On Mon, Nov 10, 2014 at 08:04:02PM +, John Williams wrote: > > I noticed recently (from another posting) that (some) other platforms seem > to still have Save as PDF which was implemented under RISC OS and later > removed. The export as PDF was implemented as a core feature using a library called libharu. unfortunately the library has not had a new release since version 2.2 (several years ago) and NetSurf requires fixes that have never been released. This issue combined with the original author abandoning the work and the feature becoming broken has resulted in PDF export being configured off for some time now. Making it work once again would require a great deal of work which no one has yet committed to doing. > > I was wondering about the status of this, as it seemed like a miracle at > the time. > > I know we can still use the Drawfile export and print to a PDF file, but > the direct option seemed so much more elegant! Unless someone fixes it this feature is unlikely to ever return. > > John > > -- > | John Williams > | joh...@ukgateway.net > > Names for Soul Band:- Soul Proprietor(s) * > > -- Regards Vincent http://www.kyllikki.org/
Disc cache updates
The disc cache has recently been updated to track the speed of write operations. The implementation of this briefly introduced a bug generating excessive logging (seen as heavy disc writing and cpu load) which has been squished and CI build #2413 should not have the problem. As a result of this performance tracking The browser will now detect if a system cannot sustain a write speed of one Megabit (120kilobytes / second) the cache will disable itself and display a warning. If this continues to occur the cache is simply not useful on that system and should be configured off (by setting the cache size to 0) The Megabit limit is a practical value derived from experimentation. It in envisaged that the lower disc bandwidth may be tuneable in future based on the users network connection but this needs investigation and careful checking. -- Regards Vincent http://www.kyllikki.org/
CI updates
I have recently had the opportunity to greatly improve the NetSurf CI build infrastructure both in terms of hardware and software. On the hardware side I would like to thank Mythic Beasts [1] for once again generously donating a 1u rack server. This is a 8 core Xeon with 24G of memory which replaces their previous donation of a 4 core 8G system. This server is the projects primary VM host for CI build slaves and the bug tracker. It continues to be hosted by Collabora [2] in Cambridge. Other services the project uses, like the website, remain hosted by Pepperfish [3] for which I would also like to extend my appreciation. The new hardware has reduced the NetSurf CI rebuild time under 150seconds (down from 300) on all ten currently built operating systems and allowed the addition of more build combinations improving the utility to the developers. The additional memory has allowed us to add more build slaves and hence extend the number of OS built for. Also the number of checks performed in analysis jobs[4] was extended. The CI software has been upgraded to the latest version of jenkins along with all the other plugins. I used the opportunity to complete the improvements to the development build process which was started at the developer weekend. This has resulted in the job history and rss feed data for many CI jobs (including the main NetSurf job) being reset, apologies if this adversely affects anyone but as new builds are performed the history backlog will build up again. As a note builds are only performed if commits to the git repository[5] occur, we do not perform periodic (daily) builds in general. As there have not been many commits recently there have been very few builds, this is correct and expected behaviour. [1] https://www.mythic-beasts.com/ [2] https://www.collabora.com/ [3] http://www.pepperfish.net/ [4] http://ci.netsurf-browser.org/jenkins/job/scan-build-netsurf/ [5] http://git.netsurf-browser.org/ -- Regards Vincent http://www.kyllikki.org/
Re: Malformed site (partly OT).
On Sat, Feb 21, 2015 at 11:47:48PM +, Peter Young wrote: > On 21 Feb 2015 Peter Slegg wrote: > > >> Date: Fri, 20 Feb 2015 12:49:38 GMT > >> From: Peter Young > >> Subject: Re: Malformed site (partly OT). > >> > >> That's interesting, and indeed the site is misbehaving today. Loading > >> those three files and then refreshing the site corrects it, so it does > >> indeed seem that NetSurf is tripping over itself and failing to get > >> the CSS files. > >> > >> Is this worth a bug report? > >> > >> Best wishes, > >> > >> Peter. > >> > > > I have also seen pages rendered without the css but I sometimes see this > > on Firefox with my much faster office PC. > > So far the site has always worked for me with Windows Chrome. A bug > report has been sent, and the feedback so far is "Timed out fetching > the CSS file." Sorry if this seems a bit short but its really a note for the developers to remind ourselves what is going on. The "missing" CSS files in your case are failing to download. The curl library we use to actually do all the http/https network access is reporting an error code that tells us the fetch of the CSS file timed out. This points to a network issue, now that may be an issue with the RISC OS network stack interacting with the remote server or simply a transient error where the connection could not be established. Debugging networking issues like this is very challenging, especially on unmaintained niche networking stacks like RISC OS. TCP/IP is an evolving protocol and sometimes implementations are not completely backward compatible. To properly debug this it would be necessary to put a network protocol analyser on your local network (like wireshark) and perform a full session analysis which might take a great deal of time to decode. As NetSurf developers cannot practically do this at best all we can do is ensure our usage of libcurl is correct and deal with the missing resources. The browser itself is correctly handling the missing resource and showing the page without styling so technically there is no bug within NetSurf. I am leaving the issue open for now as I think Michael wants to use it as an excuse to improve our internal error reporting. > > Best wishes, > > Peter. > > -- > Peter Young (zfc Re) and family > Prestbury, Cheltenham, Glos. GL52, England > http://pnyoung.orpheusweb.co.uk > pnyo...@ormail.co.uk > > -- Regards Vincent http://www.kyllikki.org/
Re: Submit buttons don't send the button name
On Mon, Mar 09, 2015 at 08:21:29PM +, Dave Higton wrote: > In message <9458d4a054.davem...@my.inbox.com> > Dave Higton wrote: > > >While writing a web server for my heating controller, I've realised > >that Netsurf doesn't send the name of a submit button that has been > >clicked in a form, unlike other browsers. > > > >For example, when the form is called "view_specials" and the button > >is called "next", other browsers return a string including: > > > >view_specials?button=next > > > >Whereas Netsurf returns just: > > > >view_specials? > > > >Is this an expected deficiency? If not, it's clearly wrong, so I'll > >extract a suitable fragment of HTML and post a bug report. > > No-one has responded, so I've raised a bug report. Apologies, I was juggling the release with trying to squash a series of nasty crashing bugs and missed the mail. However, yes submitting a bug is almost always the correct answer, we can always triage it and close it if necessary but we miss stuff if it is not there. I might take a look but dunno if it will make 3.3 or not. > > Dave > > > Can't remember your password? Do you need a strong and secure password? > Use Password manager! It stores your passwords & protects your account. > Check it out at http://mysecurelogon.com/manager > > -- Regards Vincent http://www.kyllikki.org/
Open Bugs
We have a large number of open bugs [1] related to various OS, some of which are very old and some are even awaiting feedback [2]. It would be really helpful if anyone with the appropriate platform and some inclination (especially RISC OS users) to have a look through at least the bugs needing feedback and see if we have fixed the issues or not. The acknowledged [3] (but not yet confirmed) RISC OS buglist is also rather larger than I would like and if anyone can reproduce (or not!) any of those bugs and add a comment that would be very helpful. Just to restate it, please do annotate the bugs rather than reply here (unless you have no bug account where here is better than nothing) so we can keep track of your valuable contribution [1] http://bugs.netsurf-browser.org/mantis/view_all_bug_page.php [2] http://bugs.netsurf-browser.org/mantis/search.php?project_id=1&status_id=20&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90&match_type=0 [3] http://bugs.netsurf-browser.org/mantis/search.php?project_id=1&category=RISC%20OS-specific&status_id=30&sticky_issues=on&sortby=date_submitted&dir=ASC&hide_status_id=90&match_type=0 -- Regards Vincent http://www.kyllikki.org/
Re: #2654
On Wed, Mar 18, 2015 at 08:28:45AM +, John Williams wrote: > > NetSurf changes page says, re #2654: Had you actually read the commit message in its entirity [1] you would have discovered that the text clearly explains why this was done. It fixes bug #1970 [2] by causing the datestamp of the !RunImage file to be used for the application creation date instead of the directory whose metadata is easily changed by filesystem operations. At least thats what the bug said and it was either implement it or close it. So I implemented it. > > > 1. Create an empty !RunImage file in RISC OS page save apps > > I have racked what few brains I have, but can see no reason for this. > > Creation of a zero length dummy file of a totally inappropriate filetype > (text) and which is not even referred to in the Inventory file. > > I suppose there must _be_ a reason. > > John > > -- > | John Williams > | joh...@ukgateway.net > > Names for Soul Band:- Soul Expression * > > [1] http://git.netsurf-browser.org/netsurf.git/commit/?id=e7f1ad318f85d54bee0bd3e18e8a86cb6688622c [2] http://bugs.netsurf-browser.org/mantis/view.php?id=1970 -- Regards Vincent http://www.kyllikki.org/
Re: netsurf and gtk+ build error
On Thu, Mar 19, 2015 at 01:26:34AM +0400, ny wrote: > Hi guys! > > I try to build netsurf in the distribution PCLinuxOS, but get the > following error: > > --cut--- > PKG.CNFG: Curl (libcurl)enabled > PKG.CNFG: GTK-2 (gtk+-2.0)failed > gtk/Makefile.target:62: *** Unable to find library for: GTK-2 (gtk+-2.0). > Stop. > --cut--- please can we have the output of "make Q=" which should make the build noisy and give us some more information to work with. > > I extremely wondering! Because GTK library is installed, this is > evidenced by the following commands: > > $ pkg-config --modversion gtk+-2.0 > 2.24.22 > > $ ls /usr/lib64/pkgconfig/gtk+-2.0.pc > /usr/lib64/pkgconfig/gtk+-2.0.pc > > Sources of netsurf took here: > http://download.netsurf-browser.org/netsurf/releases/source-full/netsurf-all-3.3.tar.gz > > > What to do? Please help. > > -- Regards Vincent http://www.kyllikki.org/
Re: Fwd: netsurf and gtk+ build error
On Thu, Mar 19, 2015 at 12:30:17PM +0400, ny wrote: > Vincent, I don't understand what the option "Q=", but I ran the > command as you pointed out, and that's what I got: > > CFLAGS="-Wno-error" make Q= > That was correct, except there was a bug in the Makefile and it does not pass the Q value to the otehr builds. I have fixed this. Can you replace the top level Makefile with http://git.netsurf-browser.org/netsurf-all.git/plain/Makefile and try again please. -- Regards Vincent http://www.kyllikki.org/
Re: unreadably narrow column in rendering of page
On Tue, Mar 31, 2015 at 03:44:06PM +0100, Jim Nagel wrote: > These pages from local newspaper takes ages in the fetching-processing > stage, and then finally displays its text in a pane that is too narrow > to read. > http://www.centralsomersetgazette.co.uk/Just-doctor-ordered/story-26229361-detail/story.html > http://www.centralsomersetgazette.co.uk/Street-schoolgirl-gains-place-national-theatre/story-26181050-detail/story.html > > Dunno if the fault is Netsurf or the designer of the page. > > The wife (voice teacher for pupils in stories) is not impressed. > > Netsurf #2644 on Iyonix (RiscOS 5.18). > > -- > Jim Nagelwww.archivemag.co.uk > > I reported that in the bug database for you as bug number 2303. -- Regards Vincent http://www.kyllikki.org/
Updated disc cache
I know several RISC OS users regularly use the CI builds and have had issues with the disc cache. This is partly a request for assistance and partly a warning. I have recently changed the disc based caching to use fewer small files. This change is not backwards compatible and will leave the old cache files behind. I would suggest that any of you using the disc cache to delete it before running a NetSurf CI version after #2696 NetSurf will continue to run just fine if you do not but all the old cache files will be left behind and never cleaned up. The upside of this change is that it *may* help with performance for those of you that were seeing repeated warnings about insufficient disc bandwidth. As I have explained previously on several occasions the RISC OS filesystem performance appears to be very poor when using several small files, the new system uses a handful of large files as well to remove this as an issue. If you have previously disabled the cache please can I ask you to retry with the newer versions and see if the performance has improved? If you are feeling very adventurous you can report the bandwidth achieved. This is a line in the debug Log file held in scrap *after* the browser has been quit. The last line of the Log will read something like: (2298.806358) desktop/netsurf.c netsurf_exit 294: Exited successfully The bandwidth line will be about 20 lines from the end of the log and look like (2298.804881) content/llcache.c llcache_finalise 3352: Backing store average bandwidth 128324035 bytes/second -- Regards Vincent http://www.kyllikki.org/
Re: Updated disc cache
On Fri, Apr 03, 2015 at 12:48:39PM +0100, Jim Nagel wrote: > Vincent Sanders wrote on 3 Apr: > > If you are feeling very adventurous you can report the bandwidth > > achieved. This is a line in the debug Log file held in scrap *after* > > the browser has been quit. The last line of the Log will read > > something like: > > > (2298.806358) desktop/netsurf.c netsurf_exit 294: Exited successfully > > > The bandwidth line will be about 20 lines from the end of the log and > > look like > > > (2298.804881) content/llcache.c llcache_finalise 3352: Backing store > > average bandwidth 128324035 bytes/second > > Thanks for the work. > > Where do we report it TO? Can you give a quicklink, please? this is an informal poll, so to the list is fine. > > > -- > Jim Nagelwww.archivemag.co.uk > > -- Regards Vincent http://www.kyllikki.org/
Re: Updated disc cache
On Fri, Apr 03, 2015 at 02:39:05PM +0100, cj wrote: > In article , >David Pitt wrote: > > Hmm! My Iyonix did over three time better than that, and there was > > no "too slow" message. My test piece was http://www.dailymail.co.uk > > because that is a particularly heavy duty site. > > OK. A lot of random browsing around that site led to: > > (5743.13) content/llcache.c llcache_finalise 3352: Backing store > average bandwidth 531777 bytes/second > > which is over 5 times faster. However, I thought we would be talking > drive speed, which shouldn't be affected by the download speed of any > particular site, or am I completely up the wrong alley? That value is *purely* the total amount *written* to disc divided by how long the write operations took. The write time includes all directory creation/seek operations etc. rather than just the raw disc write performance. Anything above a megabit a second (125000 bytes/second) will not trigger the warning about low write speed. I set it there because below that value the overheads of disc caching exceed the benefit of simply fetching data from the network. > > -- > Chris Johnson > > -- Regards Vincent http://www.kyllikki.org/
Re: Updated disc cache
> > > > > > I suspect much of the delay for small files is due to checking, > > > creating, and traversing directories! > > > The depth was chosen so it would work on poor-quality file systems that > > only allow a handful of entries in a directory, such as FileCore :) > > It is a shame that there is no simple way to discover if 'big > directories' are being used with no such limitations, as they have been > here for many many years. > A bit technical for this list but http://git.netsurf-browser.org/netsurf.git/tree/content/fs_backing_store.c#n326 explains all the constraints from all the different systems the cache must deal with, the result is lowest common denominator. Beleive me when I say working out that limit set from a many dimensional dataset like that was not easy With the changes I have just made however more than 90% of metadata and 70% of actual data ends up in the large block files and causes far fewer directories to be created substantially reducing overheads. -- Regards Vincent http://www.kyllikki.org/
Updated disc cache summary
Just to summarise the outcome of all the observations on the improved disc cache. The improvements make the cache viable on many more supported systems, including more RISC OS systems. On PC with modern OS it made no great improvement as their OS could already cope with the directory layout and had a plentiful write speed already. No test I ran on PC saw the write rate, before or after the changes, drop below 30 megabytes a second. Although the updated cache does use less processor time to achieve its results. On RISC OS the benefit is stark and very clear. Most tests show a five fold or more improvement in write performace using the new code and many fewer directories created. The sumamry of results from all the data points I have access to: ++--+ | System | Rate K/s | ++--+ | Rpi|7 | | ARM mini | 33 | | Iyonix [1] | 300 | | a9 | 500 | | vrpc | 570 | | ARMX6 | 2700 | ++--+ This shows that the disc cache is now useful on RISC OS for most non SD based systems. The Raspberry Pi running RISC OS and the ARM mini both appear to react very poorly indeed to the write pattern used by the disc cache. Users on such systems should ensure the cache is disabled by setting it to 0 size in the options. The Iyonix is a bit of a difficult one to call, its disc write speed appears to be very volatile. Though on average it is beneficial to enable the cache on this hardware. The standout here is the ARMX6 which is managing a very respectable (for RISC OS) 2.7 megabytes per second with the new code some 8 times better than before the changes. [1] The Iyonix write rate seems highly variable and ranges between 90 and 400 K/s -- Regards Vincent http://www.kyllikki.org/
Re: Small, but old bug
On Thu, Apr 09, 2015 at 05:20:52PM +0200, David Feugey wrote: > When I made a page with accents, all is OK with Unicode. > For example "élément" > > But if I use HTML codes, (éléments), NetSurf considers that > there are 3 words "é"+"lé"+"memts". A cut after each special characters. > > And so carriage return is sometimes applied at the wrong place. > Will this bug be corrected? > > Bye, David This is in the tracker already as bugs #467 [1], #408 [2] and #476 [3] It is caused because our text reflow and word breaking algorithm does not meet the standard and breaks words where it really ought not to. For an explanation of the complexity involved in reflowing text efficiently on constrained system computerphile did a couple of excellent videos. [4][5] While these specifically talk about e-readers, a browser faces similar challenges (and more) Fixing this is earmarked for our 4.0 series and needs a re-written render engine. The new engine is a job comparable in size to the entire project to date and has not yet been started. [1] http://bugs.netsurf-browser.org/mantis/view.php?id=467 [2] http://bugs.netsurf-browser.org/mantis/view.php?id=408 [3] http://bugs.netsurf-browser.org/mantis/view.php?id=476 [4] https://www.youtube.com/watch?v=kzdugwr4Fgk [5] https://www.youtube.com/watch?v=CdbvgRqyC-0 -- Regards Vincent http://www.kyllikki.org/
More disc cache improvements
Further to my previous efforts I have made an attempt to improve the disc cache performance even more. I would again be grateful if suitably interested users could try test CI build 2771 or later. The previous changes switched to using a small number of large files to hold all the "small" entries within the cache instead of them using individual files. This drastically improved the cache performance on several RISC OS machines. The new update extended this approach so that these block files get created with their maximum size instead of being grown every time a new cache entry is added. This change should be beneficial to RISC OS users as filecore is (apparently) dreadful at this kind of usage pattern. I have also adjusted how the computation of low bandwidth is made to try and make it more stable and less "trigger happy". I would be interested in getting the details from using the updated test release in the same way as previously detailed. (The overall bandwidth message from the log) I am especially interested in testing from the Iyonix as this was right on the edge of usefulness previously. It is probably not worth bothering with the RPi and ARM mini platforms as their reported bandwidth last time was awful and I do not envisage an improvement of that many orders of magnitude. -- Regards Vincent http://www.kyllikki.org/
Re: Google
On Fri, May 08, 2015 at 01:26:32PM +0100, Richard Torrens (lists) wrote: > Yesterday Google stopped working with Netsurf. > > Has anyone any cures or suggestions? > It has been reported in the tracker as bug number 2314. Google have changed the non javascript portion of their reply (the noscript entry) to comtain completely broken html that simply causes the browser to refresh and fail to work usefully. We cannot do anything about this in NetSurf itself and need Google to unbreak their noscript, If you can get anyone there to listen that would be good as I have been unable to find someone to contact. This affects all non javascript browser (or those with it turned off) and cannot be worked around. > -- > Richard Torrens. > http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, > cats > and more! > > -- Regards Vincent http://www.kyllikki.org/
Re: More disc cache improvements
OK perhaps I needed to be more explicit in what I wanted to achieve from this testing. I am interested in the persistent disc cache write performance on different platforms, especially RISC OS, to see if my recent changes improve the situation there.. This means the browser must be used to retrieve numerous web pages with lots of cacehable content (images, html, css etc.) and given time to write that data to disc. This usually happens in the background while the user is reading the page they just loaded. It is not useful (or sufficient) to simply load the browser, visit a page and exit. This is explicitly why I asked for help from real users because developers usage data is not representative. So if you participate please do run the browser for a while for your usual browsing session and return the information at the end. The pages you visit, the speed of your connection and the sites you visit have no bearing on the results I am after. As long as the sites data is cacehable in some way it should be sufficient. The information I want is contained in the log file at exit as most of you have discovered. I have improved whats reported with build CI 2774 and would appreciate two lines of output which appear all together near the end of the log. An example is: content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 2620/240/2380/0 (100%/9%/90%/0%) content/llcache.c llcache_finalise 3361: Backing store wrote 96531600 bytes in 6617 ms average 14626000 bytes/second This example shows 96 Megabytes of data written in 6.6 seconds yielding the 14 Megabytes a second rate from a long browsing session Note that data was written over a couple of hours the time here refers to the actual the browser had to wait for the OS to complete the write operation. I would like these two lines from the logfile along with the OS and hardware spec of the system. E.g. "RISC OS 5 on Iyonix with FAT formatted hard drive" or "ROOL beta on Raspberry Pi 2 with FAT formatted SD card" If your cache is being effective you may notice that subsequent runs of the browser have quite varying write rates which can be caused by not writing enough data to get a sensible average. Unless the cache has written at least 250 kilobytes of data the results are not useful. For example if your cache has only written a hundred bytes of data the time it takes to do that will hugely affect the write rate. This is the cause of several "false positives" on the "write rate too slow" previously because a write of a hundred bytes that took a millisecond was considered as "too slow" instead of a rounding error! -- Regards Vincent http://www.kyllikki.org/
Re: noscroll
On Wed, Aug 26, 2015 at 11:04:57PM +0100, Jim Nagel wrote: > Although this reply is to Jim its intended to address the wider audience here explaining why so many sites now fail to render adequately. > http://www.allaboutcircuits.com/technical-articles/fritzing-takes-your-design-from-breadboard-to-pcb/ > > If you make the window bigger, you see more of the text. But the > scrollbars don't change in response. Once the window fills the whole > screen, there's no way to view the remaining text. The cursor keys or > pagedown have no effect; nor does the scrollwheel. > > Never seen this phenomenon before. What's going on in the coding? > > If it's something in the site's CSS, is there any way of tweaking it > in Netsurf? Many of the sites you refer to are based on Jquery [1] or similar. The web has fundamentally changed in the last decade from declarative HTML for content and CSS for styling to almost pure code driven generation, including styling. As you are discovering this *requires* extensive, performant and correct JavaScript operation to display anything, let alone good output. Coupled to this we need a layout engine that can cope with dynamic updates and layered ordering. All the specifications for this technology is continuously changing and differs from day to day (yes seriously) In an attempt to improve the situation we are in the process of changing JavaScript engine and providing implementations for the massive DOM (207 classes and in excess of 3500 methods). However with only a few of us working on it part time progress is excruciatingly slow. For comparison the team size at Google, Mozilla and Microsoft working on this area number in the tens of full time engineers. I am aiming for a 3.4 release before the end of October with the updated Javascript engine and the multitude of other fixes that have happened since 3.3 [2] This release should hopefully be better for all supported architectures. However as repeatedly stated previously RISC OS will *NOT* be a release target for 3.4 unless someone can come forward who will be responsible for that OS. At best the CI master builds will be available but we offer no guarantee about the stability of those. > > First noticed this using Netsurf #2789 on Armini 5.22; same behaviour > now in Netsurf #2935 on Iyonix 5.18. > > -- > Jim Nagelwww.archivemag.co.uk > > [1] https://jquery.com/ [2] http://bugs.netsurf-browser.org/mantis/changelog_page.php?version_id=16 -- Regards Vincent http://www.kyllikki.org/
Re: even Wikipedia times out now
On Thu, Oct 01, 2015 at 10:03:56PM +0100, Jim Nagel wrote: > It seems that Netsurf now times out even for Wikipedia. > Try this page: https://en.wikipedia.org/wiki/Fritzing > > Hourglass goes on forever, though it least it does not tie up the > whole machine. > > Go to Netsurf iconbar choices, Content, Disable Javascript, > and try the Wikipedia page again. Now it loads no problem. > > (Netsurf #2964 on Iyonix with Ro 5.18) > > Anybody else see the same behaviour? The bugtracker is always available, please feel free to report issues in development builds. Please do not be offended if we close them with "we know" but in the same breath we do apreciate you taking the time. In this case you managed to give me an easy to reproduce testcase and I found and slaughtered the bug, fix is in #2968 The issue was to do with asyncronous javascript script completion handling. Basically javascript handling is mad and you found a case I had not covered. > > I notice that the Choices file (which results from changing something > in the Netsurf configuration) no longer stores the Javascript setting > -- it's on by default, and that's that. I'm pretty sure that in the > past, the Choices file contained a line enable_javascript:1 (or 0). > If I'm right, when did this change take place? What's the reasoning? > > It would sure be handy to have a keyboard shortcut to switch > Javascript on and off! > > -- > Jim Nagelwww.archivemag.co.uk > || See you at the show? www.riscoslondonshow.co.uk October 24 > > > -- Regards Vincent http://www.kyllikki.org/
Re: Google crash
On Mon, Nov 09, 2015 at 03:31:58PM +, David Pitt wrote: > Geoffrey Baxendale, on 9 Nov, wrote: > > > Hi, > > > > I find that clicking in the search box on Google UK with JS enabled > > crashes Netsurf CI 3055. It's OK with JS off. (RISC OS 6.2 on Kinetic) > > > > Has anyone else seen this or is it just me? > > Same here on two instances of OS4.39 VRPC on Windows 7, but not on my > Raspberry Pi OS5.23 (09-Nov-15) where it is OK. > > It is already on the bug tracker. > > http://bugs.netsurf-browser.org/mantis/view.php?id=2385 I think i fixed this, can people try and let me know? > > -- > David Pitt > > -- Regards Vincent http://www.kyllikki.org/
Re: simple html pages slow to render
On Sat, Nov 07, 2015 at 11:35:26AM +, John Rickman Iyonix wrote: > > The Gaydon online parish magazine is a single HTML file which > references a common CSS file. > > http://www.gaydon.org.uk/mags.html > > It takes on average 31 seconds to load and display a magazine using > NetSurf #3055 on an Iyonix. Javascript on or off makes no difference. > > Using NetSurf 3.2 the page load is instantaneous. > > Not sure if this counts as a bug but I have submitted a report to the > tracker. > this is in the tracker as http://bugs.netsurf-browser.org/mantis/view.php?id=2384 I have added a debug build of NetSurf to the tracker for this issue only if someone could download and run this development version and upload the log of it failing that would be great. For me the issue never occurs using my emulated RISC OS. -- Regards Vincent http://www.kyllikki.org/
Re: simple html pages slow to render
On Tue, Nov 10, 2015 at 08:12:18AM +, David Pitt wrote: > Vincent Sanders, on 10 Nov, wrote: > > > On Sat, Nov 07, 2015 at 11:35:26AM +, John Rickman Iyonix wrote: > > > > > > The Gaydon online parish magazine is a single HTML file which references > > > a common CSS file. > > > > > > http://www.gaydon.org.uk/mags.html > > > > > > It takes on average 31 seconds to load and display a magazine using > > > NetSurf #3055 on an Iyonix. Javascript on or off makes no difference. > > > > > > Using NetSurf 3.2 the page load is instantaneous. > > > > > > Not sure if this counts as a bug but I have submitted a report to the > > > tracker. > > > > > > > this is in the tracker as > > http://bugs.netsurf-browser.org/mantis/view.php?id=2384 > > > > I have added a debug build of NetSurf to the tracker for this issue only > > > > if someone could download and run this development version and upload the > > log of it failing that would be great. For me the issue never occurs using > > my emulated RISC OS. > > I have to admit to an element of failure in that I can't find that > development build on the tracker. I attached it to the 2384 bug report as netsurf-fetch-log.zip > > -- > David Pitt > > -- Regards Vincent http://www.kyllikki.org/
Re: Builds as reflected on changes page under Build History
On Mon, Jan 18, 2016 at 11:39:23AM +, John Williams wrote: > > I have noticed a few times, including as I write this, that sometimes the > progress of a build seems to get stuck as shown at: > > http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes > > Today the progress is still stuck from Jan 15, 2016 7:37 on #3269 at, say, > 95% completion, and a build #3270 remains "pending". > > RISC OS #3269 has downloaded fine, but presumably something has stuck at a > later point for another OS. > > Why/how does this happen? The CI system is built around the concepts of jobs, each job represents a task the system needs to perform such as building NetSurf binaries or packages etc. Each job requires some resources usually provided by one or more worker systems. So for example the master branch NetSurf build requires a worker (we are transitioning to using the controller/worker naming from master/slave after some very spirited complaints) for each compiled architecture (e.g. cislave4 compiles for arm-unknown-riscos). What you are seeing in your example is where a resources is no longer unavailable to the CI system (specifically cislave3 running the haiku OS). The failure means the in progress job cannot complete and new jobs that require that resource cannot commence. It requires an administrator (me) to come along and reboot the failed system and restart the CI worker software to make the resources available again and allow the job to complete. > > Also, sometimes there is nothing listed under Changes for versions - not > even a build reference. > Builds can be manually started by developers if there has been an issue during a build, these will have no code changes and be anonymous > Just curious! > > John > > -- > | John Williams > | joh...@ukgateway.net > > I think, therefore I am unsure - I think! * > > -- Regards Vincent http://www.kyllikki.org/
Bug tracker
There has been an issue with the bug system sending emails which has now been fixed. The mails affected include account maintenance and creation as well as issue notification. The issue was caused by a configuration error exposed during the recent spate of issues with our infrastructure (I have previously sent notification to the list) Apologies for any inconvenience caused. I would like to take this opportunity to mention a few things: - The bug tracker address is http://bugs.netsurf-browser.org/ and the cover page there provides brief instructions on bug reporting. - Issues can be viewed anonymously - Reporting a new bug requires an account - If you have any issues with the bug tracker please mention them either on these lists or to h...@netsurf-browser.org iff they contain personal information. -- Regards Vincent
Re: Netsurf Cache
On Tue, Apr 12, 2016 at 02:49:39PM +0100, nets...@avisoft.f9.co.uk wrote: > There was much discussion about a year ago about the cache performance on > RISC OS, and there were some code changes, but I would like to add the > results of some investigations of the Netsurf v3.4 cache on my Iyonix, > running RISC OS 5.23 (11 Oct 2015). I am beginning to think this feature should never have been enabled for hoplessly legacy operating systems such as RISC OS. I will go over how this feature works once again. This is in response to this message but is, as usual, aimed at all users. To be clear a cache in any computer program trades one resource for another. Generally a web browser will have numerous caches for different uses. In NetSurf we have three main caches: 1. one held in RAM for decoded images This cache trades processor time (used to decode images from compressed source formats like jpegs) for memory (to hold the decoded images). Without this cache scrolling a page would be glacial as every time an image needs to be plotted, even if it is only a single pixel of it, we would need to decode the entire source image 2. a cache for source objects (the stuff downloaded from web servers) held in memory This cache trades memory for network bandwidth used downloading source objects. Without this every time a page navigation happens within a website all the css, images, javascript etc that did not chnage must be downloaded again which would quickly make browsing unusable. 3. a cache of source objects held on disc. This cache trades disc space and bandwidth for memory. Although not immediately obvious the memory is that from the previous cache and indirectly could be seen as network bandwidth used. This is known as a cache hierachy where one cache backs another. The memory cache size setting deals with the first two of these caches and the disc cache settings the third. > > In the past I had problems with the cache taking large amounts of disc > space, and the resulting long backup times for !Boot, so my current > settings are 10MB space, expiring after 2 days. The average web page is now well over 2 megabytes [1] and is growing rapidly all the time. You would be much better served having no persistant storage (disc) cache enabled at all by setting its size to zero than by a small one like this. As I keep emphasising again and again the cache is a trade of one resource for another in an attempt to reduce the oveall time to perform the action of visiting a web page. If you are not able to make that trade a net profitable transaction you are better off not doing it at all. The RAM, CPU and disc overhead for enabling the cache greatly exceeds your settings which probably require a minimum of a few hundred megabytes and several weeks to make the trade worthwile on RISC OS. In fact I will add a feature request to the tracker to have a minimum viable size for the cache size options. I fear your expectations around sizes of resources are a little out of date. The default cache sizes on PC platforms is 128 megabytes of memory and a gigabyte of disc. Even these are pretty restrained, for example: my desktop has a recently started copy of chrome with a handful of tabs open and thats reporting well over a gigabyte of memory used and several gigabytes of disc. It is not uncommon for standard PCs to have 8 gigabytes of memory and a terrabyte of hard drive space accessed at rates measured in hundreds of megabytes a second. I know RISC OS has no hope of getting anywhere near such resources but it must be understood that the modern web is orientated around systems of this magnitude of capability. [1] http://www.soasta.com/blog/page-bloat-average-web-page-2-mb/ > > However, the actual space usage was 45MB (as measured by Filer Count), > and it contained 210 files. What was more difficult to find was that > there were 7,298 directories with 8 levels, which occupied another 14MB, > of which 6,412 contained no files at any lower level. So only 886 > directories actually contained the 210 files of cached data. Enumeration > of the cache took about 2 minutes. > It is possible you had a cache left over from an earlier version of NetSurf where small files were stored in separate files. Cache improvements merge all smaller files into a few large index files and only use the directories for larger files. Regardless the directories are not accounted for as on most OS they are a very low cost resource and are never enumerated. There is a well known "cache" indicator file created which on most systems is used to indicate to other software that the contents of the directory are not at all "valuble" and may be discarded at will and should not be enumerated. > I decided to delete all 6,412 directories that contained no data, saving > about 12MB of disc space. More importantly, counting or
Re: Text drag & drop
On Wed, Apr 27, 2016 at 06:13:18PM +0100, Chris Young wrote: > On Wed, 27 Apr 2016 16:47:15 +0100, Richard Torrens (lists) wrote: > > > Somewhere between 3492 and 3507 the ability to mark text, drag and drop > > elsewhere has been lost. Also the find text does not mark the finds. > > > > This was very useful! I hope it's temporary thing? > > Marking text isn't working correctly on the Amiga version either. Put > it on the bugtracker if you haven't already. > Apologies for this Chris. I have been making some core changes improving the font layout API and messed up converting some frontends. I fixed the others but you got to Amiga before I had chance. Thanks for that I have also recently changed the warn_user API. The core have very, very few usages of this left and mostly returns nserror from API letting the frontends report errors as they see fit. However this means frontends now provide the warning API through the miscellaneous operations table. Frontend code that should generate user warnings (amiga_warn_user for the amiga frontend) should be called directly To avoid breakage I kept the old warn_user() API in utils/utils.[ch] while I carefully remove usages. Rather than risk me breaking your frontend again might it be possible for you to remove the use of this API? > Chris > > -- Regards Vincent http://www.kyllikki.org/
Re: Slow ?
As I have mentioned previously, the Atari port has no active maintainer and therefore only receives the absolute minimum of changes to keep it compiling in the CI system. This is also why it is not a release candidate frontend. Given the general lack of developer time at present I cannot guarantee there will be resources to examine this issue. On Tue, May 10, 2016 at 09:27:54PM +, Peter Slegg wrote: > > In the past few weeks I've noticed that the download and > rendering speed of the (Atari) test builds seems quite a > bit slower than with earlier versions. As far as I know there have been no core changes recently that would affect the browsers speed. Generally all recent changes have been code cleanups in preparation for larger planned updates. Please can I ask you to check that you have not made any other changes to your system that might have caused this. There have been several reports recently which have turned out to be related to updates completely unrelated to NetSurf. > > Some pages are taking over 20 mins and more are timing out. Perhaps you can provide the CI build numbers of "working" and "slow" versions? the closer these values are together the easier it will be for a developer to attempt to diagnose the issue. > > > Peter > > > > > > -- Regards Vincent http://www.kyllikki.org/
Re: how to make Netsurf forget its logged-in state
On Thu, May 12, 2016 at 01:21:43AM +0100, Jim Nagel wrote: > I'm tinkering with something on my own website, an area that requires > the viewer to provide a username and password. > > I successfully get in with my own username and password. Now I want > to test those of another user. > > So I click the link that takes me to the subsite -- and I'm straight > in; I don't see any box asking for username and password. > > Tried Ctrl-F5, menu Reload, tried deleting from the History file, > tried quitting and relaunching Netsurf. Still never see the login box > again. > > How do I "log out"? (If that's the correct term in this situation. > Maybe it's more like changing the "state".) > > -- > Jim Nagelwww.archivemag.co.uk > > You appear to be using basic authentication login. In which case you can get all the gory details [1] on stack overflow. Efectively basic auth has no way of logging out! NetSurf implements basic auth by simply keeping the details in the memory based url database untill the browser is quit (inline with every other browser) and short of a load of javascript messing about (which I doubt we get right) there is nothing to be done and we work as specified. [1] http://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication -- Regards Vincent http://www.kyllikki.org/
Re: Failure when receiving data from the peer
On Sat, Jul 09, 2016 at 03:45:08PM +, Peter Slegg wrote: > > When I try to open a link to this page: > > http://www.ccrexplorers.com/forumdisplay.php?f=17 > I have retrived this page with and without javascript on gtk and framebuffer frontends without problem so i must conclude the issue lies with the Atari frontend. As you know there has not been an atari frontend maintainer for some time so it it unlikely anyone will be able to address this issue directly. > it starts to Fetch and then fails with the error: > > Failure when receiving data from the peer > > > Atari build 3591 > > > Peter > Thankyou for the clear report even if I cannot assist with the issue. -- Regards Vincent http://www.kyllikki.org/
Re: Site crasher NS
On Tue, Sep 20, 2016 at 04:49:54PM +0100, Richard Torrens (lists) wrote: > http://nosher.net > > Twice gives a window to accept certificate. On accepting second one, NS > dies. > > > 3.6 (Dev CI #3714) and a few prevous. Does thisa happen to others? This is a similar issue to a GTK bug that had already been reported. I have split that bug and created http://bugs.netsurf-browser.org/mantis/view.php?id=2471 for the RISC OS version. This stems from the RISC OS frontend attempting to display multiple SSL warnings for the site and because it is using a deprecated and broken piece of compatibility code (treeview vs corewindow interfaces) we get a crash. I have fixed the GTK frontend which no longer crashes but as there is no active RISC OS maintainer the work there has not been done. -- Regards Vincent http://www.kyllikki.org/
Re: CSS and "media query" -- smartphone vs desktop
On Tue, Oct 25, 2016 at 10:47:45AM +0100, Jim Nagel wrote: > Any chance of Netsurf's CSS handling being extended a bit to support > "media query"? It has been on our list of "important" things to do for some considerable time now. We know what needs to be done and how [1] but as usual development time is limited and noone has yet had time to work on the feature. > > Reason I ask is that I want to rejig my various websites (including > Archive's) so that (among other things) they will be readable on > smartphone screens as well as desktop screens. > > I gather that the "media query" in CSS would make it possible to have > a single design to which the end-browser will respond accordingly -- > this would be much more elegant than having separate code for each > target possibility. it affects an increasingly large number of websites so its importance as a feature is rising. > > My son Bart (now a pro web developer in Vancouver, but brought up on > RiscOS so knows the scene) is helping on this. We're not aiming to do > anything elaborate, but elegance yes please. > > There's probably a narticle for Archive magazine in all this! > > -- > Jim Nagelwww.archivemag.co.uk > > [1] note this has some bad language http://wiki.netsurf-browser.org/Css_media_queries -- Regards Vincent http://www.kyllikki.org/
Frontend maintainership
At the recent NetSurf developer weekend[1] we discussed many topics one of which was our regular review of the frontends. Except for Amiga and GTK none of the frontends have a active maintainer. The cocoa and atari frontends are however causing a great deal of concern. cocoa - Unless a maintainer can be found (or at least someone willing to fix it) before 11th Febuarary 2017 the CI for this target will be disabled. The code will be removed during the next developer weekend on the 10th June. This decision has been made because the effort to keep this frontend building is large and we have many reports that the resulting binary simply crashes when started. atari - The atari frontend is built for m68k and coldfire variants using a variant of the netsurf cross compliation toolchain/sdk. No serious updates have been made to this toolchain in some time and it has become a burden. Unless this is addressed before the next developer weekend the frontend will be disabled in the CI and subsequently code removed. riscos - Still lacks a full time maintainer but due to its userbase the team keeps it working. Gets a reprieve again and will be reconsidered next time. windows - Lacks a full maintainer but has been fixed up to be at least useful. A maintainer for this frontend would be welcome. amiga - Chris Young continues to provide excellent maintainership no problems noted. monkey - test frontend is useful and we envisage expanding the scope of its usage. beos - The Beos port is generally only tested on Haiku at this point. The frontend is kept useful by mmu man and pulkomandy. Main issues revolve around the CI slave and its crashy java port. gtk - Vince looks after this and despite gtk+ changing API a lot it remains useful. framebuffer - generally good shape but the Linux framebuffer and input need attention. It has been agreed we will look into using libinput to improve this area. [1] http://wiki.netsurf-browser.org/developer-weekend/feb-2017/ -- Regards Vincent http://www.kyllikki.org/
cocoa frontend
As previously stated the cocoa frontend has been disabled in the CI and any build errors in this frontend are no longer considered to "break the build" Unless a maintainer for cocoa comes forward and fixes it so it compiles and runs before the next developer weekend in June this frontend will be removed from the source at that time. -- Regards Vincent http://www.kyllikki.org/
Re: Codethink sponsored work on NetSurf
On Tue, May 02, 2017 at 09:16:25AM +0100, Michael Drake wrote: > > Over the past few weeks I've been able to spend time > contributing to open-source projects at work. > > Codethink [1] values open-source software, and so I > was approved to work on NetSurf and related components > while I was between projects. I'd like to thank > Codethink for this opportunity, which I very much > value and appreciate. I would like to publicly thank Codethink for allowing you this time and acknowledge that it represents several thousand pounds worth of developer time which has benefited NetSurf and by extension your fellow developers. > > > Cheers, > > Michael > > > -- Regards Vincent http://www.kyllikki.org/
Re: Codethink sponsored work on NetSurf
On Wed, May 03, 2017 at 12:51:54PM +0100, Kevin Wells wrote: > In message <20170502143538.ge12...@kyllikki.org> > Vincent Sanders wrote: > > >On Tue, May 02, 2017 at 09:16:25AM +0100, Michael Drake wrote: > >> > >> Over the past few weeks I've been able to spend time > >> contributing to open-source projects at work. > >> > >> Codethink [1] values open-source software, and so I > >> was approved to work on NetSurf and related components > >> while I was between projects. I'd like to thank > >> Codethink for this opportunity, which I very much > >> value and appreciate. > > > >I would like to publicly thank Codethink for allowing you this time > >and acknowledge that it represents several thousand pounds worth of > >developer time which has benefited NetSurf and by extension your > >fellow developers. > > It has fixed a bug I submitted. :) > > I tried to inform the bug tracker, but it appears to be done. Thanks for reporting this, It was due to a configuration error after last weeks upgrades, fixed now I hope. Please let me know if there are any additional issues with the bug tracker. > > > > > > > >> > >> > >> Cheers, > >> > >> Michael > >> > >> > >> > > > > > -- > Kev Wells > http://kevsoft.co.uk/ > Yes, makin' mock o' uniforms that guard you while you sleep > > -- Regards Vincent http://www.kyllikki.org/
Re: Logging of Changes
On Sat, Jan 27, 2018 at 09:50:28AM +, John Williams wrote: > > Why are there often series of changes which are not specifically logged at: > > http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes > > like in the last 13 builds. Does the information appear somewhere else? The "gap" builds are simply those triggered by other components (libraries). There are no code changes in NetSurf itself so no entry on this list. Most of the 13 you identify stem from recent fixes and improvements to librufl, libcss and toolchain updates. Though you may also see builds triggered from the CI system itself because I have been ensuring the system can successfully perform repeat builds. > > John > > -- > | John Williams > | joh...@ukgateway.net > > -- Regards Vincent http://www.kyllikki.org/
NetSurf web sites
All the NetSurf web services [1] are now securely accessible. This has been made possible by the lets encrypt service [2] providing no cost certificates and pepperfish proving the infrastructure to manage them. We are making this change to ensure our users privacy is protected. The NetSurf project collects no personally identifying data about users of our web services except that required to provide the service [3] and we do not believe third parties should be able to intercept such information either. Daniel Silverstone and myself have now updated all the NetSurf infrastructure to make https available. It is intended that after a short stabilisation period that web server and wiki will have HSTS [4] enabled. Once this occurs only encrypted connections will be available to NetSurf services. Please ensure there are no issues with the secure sites (let us know if there are!) and update any links you may have in external documents. [1] https://www.netsurf-browser.org/ https://wiki.netsurf-browser.org/ https://bugs.netsurf-browser.org/ https://ci.netsurf-browser.org/ [2] https://letsencrypt.org/ [3] The bugs interface requires a user identifier and email address which are required to use the service and we do not use that data for any other purpose than tracking bugs. [4] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security -- Regards Vincent http://www.kyllikki.org/
Re: Missing images
On Thu, Aug 09, 2018 at 11:41:24PM +0100, Richard Porter wrote: > On 9 Aug 2018 Tim Hill wrote: > > > In article , Richard Porter > > wrote: > >> Hi all, I've got a strange problem on one of my sites. On > >> http://www.mmpa.org.uk/ all of the gif images are missing, including > >> the yellow navigation buttons at the top. If you go to other pages the > >> "home" and "News" buttons are present. > > > [Snip] > > > Whenever images don't show, I always suspect the Content option 'hide > > advertisements' and you do have all those GIFs in a sub directory called > > 'images'. Try the option off if it's on and if that works, use a more > > cryptic directory name than 'images'. > > Thanks for all the replies. > I've tried unticking "Hide advertisements" but it makes no difference. > Yes, the gifs are in directory called "images". > > I suspect it's a cacheing problem. I'll see if it clears after 24 hours. you have bugs open about NetSurf having a "caching" issue or failure to display images etc. none of which have logs attached and are explicitly awaiting feedback. It would be helpful if you could respond to these so we can get enough information to attempt to fix them. On RISC OS I have determined that disc caching is generally a waste of time as the filesystems performance is dreadful. The default *disc* cache size on RISC OS is 0 (i.e. off) and is probably the correct value for such low performance systems. > > Richard > -- > Richard Porter http://www.minijem.plus.com/ > t: @westernexplorer mailto:r...@minijem.plus.com > I don't want a "user experience" - I just want stuff that works. > > -- Regards Vincent http://www.kyllikki.org/
3.9 Release
A lot of features and bug fixes have happened since the 3.8 release so I am considering producing a 3.9 soon. The merging of the work to add css media queries has resulted in much improved rendering on many web sites including making our handling of CSS length [1] calculations much more sensible especially useful on higher DPI displays. The completion of the monkey test frontend harness and associated infrastructure has resulted in numerous issues being discovered and resolved especially making the javascript support more robust. Additional testing also means our handling of some core things like HTTP headers and basic web authentication has improved and should not regress in future. There have also been a great number of resource leaks fixed improving the browsers overall memory usage. I had intended to release before now but testing kept revealing issues, however I now believe that we are ready for a 3.9 release candidate on Sunday June 16th with the actual release on Saturday June 22nd unless critical bugs are discovered. If anyone has a reasonable objection to this please let me know as soon as possible and I will reconsider. [1] https://hacks.mozilla.org/2013/09/css-length-explained/ -- Regards Vincent
Re: 3.9 Release
On Sat, Jun 22, 2019 at 05:36:39PM +0100, Richard Torrens (lists) wrote: > In article <20190615175934.gh14...@kyllikki.org>, >Vincent Sanders wrote: > > A lot of features and bug fixes have happened since the 3.8 release so > > I am considering producing a 3.9 soon. > > A (hopefully small) point: for some time now Netsurf seems to be picking > up only the first css link. Please could you create an issue on the tracker with some actual details? or this simply will never be looked at Futher if you are refering to http://www.torrens.org/ (btw please consider https, https://letsencrypt.org/ is a brilliant idea) you have two stylesheet links in the head element http://css.torrens.org/main"; type="text/css"> http://css.torrens.org/navbar.css"; type="text/css"> the first is garbage relative link and all browsers i tried it with treat it as such and ignore it. > > On all my www pages I have two css links - the second one defines the > header and is ignored. on other pages (i picked cats for an example) the link elements are: http://css.torrens.org/styles1.css"; type="text/css"> http://css.torrens.org/navbar.css"; type="text/css"> and the styles from both are used in NetSurf causing the header bar contact, home and search backgrounds to be coloured (for example) > > But great work what has been done. Thanks for that. > > -- > Richard Torrens. > http://www.Torrens.org for genealogy, natural history, wild food, walks, cats > and more! > > -- Regards Vincent http://www.kyllikki.org/
Re: 3.9 Release
> I had intended to release before now but testing kept revealing > issues, however I now believe that we are ready for a 3.9 release > candidate on Sunday June 16th with the actual release on Saturday June > 22nd unless critical bugs are discovered. > Well it seems a lot of bugs decided to make themselves known right at the last moment and despite some hard work from John-Mark, Daniel, Michael and myself we have simply not managed to get the browser as stable as I wanted for a release. I will try again to release sometime this week but again I ask for some *feedback* . I have had literally two replies (one should have been a bug report but at least it was activity) and I hope there are more than two people other than the developers using the CI builds! -- Regards Vincent
The 3.9 Release
I am pleased to announce the latest release of NetSurf is now available. NetSurf 3.9 features support for CSS Media Queries (level 4) and improvements to JavaScript handling. Also included are many bug fixes and improvements. We recommend all users upgrade to NetSurf 3.9. -- Regards Vincent http://www.kyllikki.org/
Re: The 3.9 Release / documentation for Media Queries etc
On Mon, Jul 22, 2019 at 11:00:25AM +0100, Jim Nagel wrote: > Vincent Sanders wrote on 21 Jul: > > NetSurf 3.9 features support for CSS Media Queries (level 4) and > > improvements to JavaScript handling. > > Also included are many bug fixes and improvements. > > > Good work: thanks to the whole Netsurf team. > > I'd like to know more about Media Queries vis-a-vis Netsurf. Will the > documentation (link from Netsurf welcome page) be updated soon? Michael already answered but i thought i would add that the mozilla developer network is always a good reference to learn about generic web features. Specificaly https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries might be helpful to you. > > As I understand it from the bottom of my learning curve, Media Queries has > to do with designing a website so that it automatically adapts according > to whether the user is viewing it on a large or small screen. > > In the site I have been working on, I have treated Netsurf as the default. > Realizing that Windows users habitually view a page the full size of their > wide monitor, and thus get unreadably wide lines of text, I inserted a > workaround to constrain page to 800px (about A5 width). This works fine > on A5 Android tablet too. > > The problem of sensibly adapting the layout for a small screen on a > smartphone has so far eluded me, hence my interest in Media Queries. > > > -- > Jim Nagelwww.archivemag.co.uk > > > > -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS NetSurf no longer responding to URI files
On Sun, Aug 04, 2019 at 02:17:36PM +0100, Peter Young wrote: > I would have reported this on the bug tracker, but I've found it > impossible to access this, even after a change of password. I just tried this myself from RISC OS build and I can log into mantis > > This is currently with 3.10 (Dev CI#4729) on RISC OS 5.25, RiscOS version > (24 Aug 18). > This build is no longer available to us in the CI. please can you navigate to about:testament and report the big hex number shown there > I have been using URI files so=red in Paul Vigay's NeXTBar app to launch > favourite files. I'm lazy, and this is easier than finding them from the > icon bar's Hot List. Fot the last three or so development builds this has > stopped working, and even if I save the location in a RISC OS URI file and > double-click on this it still doesn't work. Also, double-clicking on a URL > in a MPro email doesn't work. We have not changed handling of such files in the RISC OS version of NetSurf only improvements to (scale) zoom handling (if you notice any issues there I probbaly made a mistake.) Perhaps you have another application responding to URI files and preventing NetSurf from handling them. Apologies I cannot be of more assistance here as RISC OS is not a platform I use often. > > I've just discovered that if I save a location as an ANT URL file and > double-click on this, it does work. However, this is the format NeXTBar > uses to store URLs, so I am not totally puzzled. > > Does anyone know why this should happen? > > Best wishes, > > Peter. > > -- > Peter Young (zfc Hg) and family > Prestbury, Cheltenham, Glos. GL52, England > http://pnyoung.orpheusweb.co.uk > pnyo...@ormail.co.uk > > -- Regards Vincent http://www.kyllikki.org/
Re: "Warning from Netsurf: Unknown"
On Mon, Oct 21, 2019 at 10:40:17PM +0100, Richard Porter wrote: > On 21 Oct 2019 Jim Nagel wrote: > > > I downloaded Netsurf #4874 today, replacing #4850. > > > Upon trying to load various websites I get a mysterious error message that > > says only "Warning from Netsurf: Unknown". The status line at the bottom > > of the Netsurf page also says "Unknown". > > > Example: http://www.dalsemi.com/datasheets/appindex.html > > > I would like to know what this means! I don't recall getting this message > > in previous versions of Netsurf. But maybe it's just a bad day today. > > > Using ArmX6 with Ro 5.25 (Rcomp 2018-apr-25). > > I have been getting this with 4834 if not earlier. I don't think it's > easily repeatable. next time either of you see this issue please can you open an issue in our tracker (preferably with a log attached) so we can attempt to diagnose it. -- Regards Vincent
Re: "Warning from Netsurf: Unknown"
On Tue, Oct 22, 2019 at 01:21:26PM +0100, Richard Porter wrote: > On 22 Oct 2019 David Pitt wrote: > > > It is on the bug tracker now. The example above is a very broken site, > > neither Safari or Firefox get anywhere with it. > > I get the same response after a long wait. > I have changed how all network errors are reported to be a proper error page instead of a popup. please can those affected (using CI builds) confirm that the new behaviour is more informative and works for them. -- Regards Vincent http://www.kyllikki.org/
Re: RISC OS CI#4886 - can't type reply
On Thu, Nov 07, 2019 at 02:43:09PM +, David Higton wrote: > Something appears to have gone wrong betweem the RISC OS CI versions 4885 > and 4886. I tried typing a reply in the ROOL site, but no keyboard input > appeared. The same is true for for 4886 and 4887, but 4885 is OK for me. > > Can someone else please try this and let me know if you can reproduce it > - if so, I will report it. > > I did update !Boot and !System. > > David > > This was reported as issue https://bugs.netsurf-browser.org/mantis/view.php?id=2715 I resolved the issue and should be fixed in 4890 and onwards -- Regards Vincent http://www.kyllikki.org/
Re: Atari build 5032: cache folder
On Sat, Feb 29, 2020 at 10:33:10PM +, Peter Slegg wrote: > > I have just installed the Atari test build 5032 and it throws an error. > > NetSurf failed to initialise > > > I switched the binary back to a previous build but that failed as > well. Investigation showed that the cache folder had gone. > > I re-created it and the older version runs again but 5032 deletes it. > > > Peter I beleive I have fixed this now. The code for atari_mkdir_all() was using the wrong directory separator (i.e. / instead of \) Let me know if that fixes the problem as I cannot test myself -- Regards Vincent http://www.kyllikki.org/
Re: OL handling
On Mon, Jan 25, 2021 at 03:29:30PM +, Harriet Bazley wrote: > Netsurf doesn't seem to support HTML of the form > > > > but always defaults to a sequential numerical list, whatever type/value > the source specifies - are we all supposed to be styling list entries > with CSS nowadays? Depends on the intended usage. The MDN page is a good reference https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ol Netsurf has never supported anything other than plain decimal numbering for list markers/counters I have added a basic implementation of the CSS 2.1 styles https://www.w3.org/TR/CSS2/generate.html#propdef-list-style-type Michael Drake fixed the HTML hinting so the type on the OL can be used (note its on the OL *not* the LI element) I cannot close a bug as noone opened one but please do so if there are issues in this area. > > -- > Harriet Bazley == Loyaulte me lie == > > It is better to be deceived by a friend, than to suspect him. > ___ > netsurf-users mailing list -- netsurf-users@netsurf-browser.org > To unsubscribe send an email to netsurf-users-le...@netsurf-browser.org > -- Regards Vincent http://www.kyllikki.org/ ___ netsurf-users mailing list -- netsurf-users@netsurf-browser.org To unsubscribe send an email to netsurf-users-le...@netsurf-browser.org
