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: web page is blank with new vwersion on NeSurf
John Williams wrote Fred Bambrough nets...@ypical-daemon.co.uk 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. John -- John Rickman - http://rickman.orpheusweb.co.uk/lynx No sé nada, y no estoy seguro de éso
Re: BoxConvert?
On Sat, 07 Jun 2014 16:50:01 +0100, Richard Torrens (lists) wrote: What does the message BoxConvert mean? It's obscure to say the least! It means NetSurf wasn't able to convert a box :) I don't fully understand how it works, but it is to do with layouting. 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 I wouldn't have thought so. The SSI portion is an HTML comment if it isn't getting parsed by the server, so it should be getting ignored. a) When did this start? b) Can you post one of the faulty pages here, or upload it in a way in which it can be downloaded without the SSI being parsed? Chris
Re: BoxConvert?
On 7 Jun 2014 17:32:35 +0100, Chris Young wrote: On Sat, 07 Jun 2014 16:50:01 +0100, Richard Torrens (lists) wrote: 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. a) When did this start? b) Can you post one of the faulty pages here, or upload it in a way in which it can be downloaded without the SSI being parsed? c) Log file? Somehow missed (c). Chris
Re: BoxConvert?
In article out-53934cb3.md-1.4.17.chris.yo...@unsatisfactorysoftware.co.uk, Chris Young chris.yo...@unsatisfactorysoftware.co.uk wrote: a) When did this start? I haven't updated NS for a while so don't know when it started! b) Can you post one of the faulty pages here, or upload it in a way in which it can be downloaded without the SSI being parsed? After a bit more experimenting, it is caused by the line: Pa href=http://!--#echo var=HTTP_HOST --!--#echo var=DOCUMENT_URI --Top of page/a Two pages in the attached archive: one contains the line, one does not. NS clearly isn't going to do anything sensible with this - but at present it causes the page not to load at all. -- Richard Torrens. http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats and more! new.zip,A91 Description: application/riscos
Re: BoxConvert?
On Sat, 07 Jun 2014 19:58:41 +0100, Richard Torrens (lists) wrote: After a bit more experimenting, it is caused by the line: Pa href=http://!--#echo var=HTTP_HOST --!--#echo var=DOCUMENT_URI --Top of page/a Ah, right. I know exactly what the problem is and what causes it. NetSurf now rejects invalid URLs. By invalid I mean, anything containing characters that are not permitted either in old-style ASCII names, or in IDNA, plus some other validity checking mostly related to IDNs. Previously NetSurf would percent-encode the host and return that, so you'd end up with a garbage URL. Now it rejects the URL outright. However, it appears the layouting can't cope with that. I did some extensive searching when I made this change initially and was unable to track down why this was causing the layouting to fail - ideally, a broken URL shouldn't cause termination of the layouting process, it should only make the problem link go nowhere. I considered this low risk at the time as it is incredibly rare to encounter a link to a URL which doesn't conform to the rules. However, obviously it does need to be fixed, so if you can raise it on the bugtracker that'd be grand. Chris
