[Netsurf-develop] Rendering/saving problem
by Keith Hopper
Hi,
I have a PHP generated publicly accessible web document with which
Netsurf (29 March) reveals weird behaviour. The URL is
https://flame.cs.waikato.ac.nz/333/Private/login.php
It is only a 2kbyte document - plus style sheets and a few small graphics
- which validates against the W3C validation server.
Netsurf retrieves the document and, in the blink of an eye, states
'completed' (possibly because I am in the same building as the server of
course) - but 'completed' it reveals nothing visible - every other browser
(ten of them at least) handle the document happily - including all the RISC
OS ones I have (they don't of course find the style sheet though).
I can save the document to an html file and it contains what I would
have expected (exactly what the PHP should have generated). Try to 'full
save' the document and this appears to work - provided there is no space in
the name by which it is saved.
Unfortunately the full save produces a run and a sprite file - but
does not save the document in the directory.
Try to save as text or draw actually fail to happen!
In a sense, the full save/draw/text saves are consistent I suppose -
but now comes the weirdo. Having done the 'document only' save to a
suitable directory - it saves as an html file - double clicking on that
brings up a Netsurf window which produces a visible document - without
styles or graphics, of course.
If you have your browser set to check security certificates then try
the same URI as http:// ... - a different document with the same behaviour
in Netsurf.
Might this have something to do with the document being served
(correctly) as 'application/xhtml+xml'?? That could, I suppose, result in
the blank document, but surely the 'full save' should still have worked
irrespective of the media type when served?
Over to you!
Keith
--
City Desk
Waikato University
[PGP key available if desired]
18 years, 5 months
- 4
- 6
[Netsurf-develop] logging
by Stuart Halliday
In message <4d554d7a56lists-nospam(a)vigay.com>
pv <lists-nospam(a)vigay.com> wrote:
>
> In article <gemini.ie9r6w00b6a8i0194.druck(a)druck.org.uk>,
> David J. Ruck <druck(a)druck.org.uk> wrote:
>
> > In which case your upstream provider will be logging them all.
>
> Which is irrelevant because they have no way of knowing which user account
> the traffic corresponds to. All they would see is data going to aa63 (or
Surely you'd know which account had which IP address at a particular time?
> whatever) and there's no way I would divulge customer information to
> *anyone* irrespective of reason.
So if the police asked you to reveal the identiy of a possible child
molester. You'd go to prison rather than tell the police his/her account
details?
--
Stuart Halliday
http://mytriops.com/
Largest collection of Triops information on the Internet.
18 years, 5 months
- 2
- 1
[Netsurf-develop] crash during text input
by James Scholes
Netsurf has just crashed when inputting text on the drobe comments
system, and I *think* it may have something to do with the first
character on a new line being a space. I can repeat this in any box on
drobe. haven't tried any other sites though.
Fill the first line of the box with anything you like, so that pressing
space gets you onto a new line straight away. The next character causes
the crash.
It appears that the key number is over 100 or greater in every case.
I've tested this in various fonts, default size 14pt, minimum 12.
Here are the relevant bits of a stderr:
desktop/browser.c browser_window_textarea_callback 1269: key 97 at 37 in 'pages in the same window, you've got '
desktop/browser.c browser_window_textarea_callback 1269: key 32 at 38 in 'pages in the same window, you've got a'
desktop/browser.c browser_window_textarea_callback 1269: key 108 at 0 in ''
Error 0x80000200: Floating point exception: invalid operation
pc: 0x11e690
f0: 2147483648.000000 f1: 192.000000 f2: 140.000000 f3: 1072.000000
f4: 1100.000000 f5: 1.000000 f6: 1.000000 f7: 0.000000
fpsr: 1070010
Fatal signal received: Floating point exception
Stack backtrace:
( 24cfe4) pc: 107698 lr: 21a640 sp: 24cfe8 __unixlib_raise_signal()
( 24cff4) pc: 21a540 lr: 11f054 sp: 24a938 *** UnixLib error handler ***()
( 24a9c8) pc: 11e638 lr: 11f054 sp: 24a9cc ^html_redraw_box()
( 24aa5c) pc: 11e638 lr: 11f054 sp: 24aa60 ^html_redraw_box()
( 24aaf0) pc: 11e638 lr: 11f054 sp: 24aaf4 ^html_redraw_box()
( 24ab84) pc: 11e638 lr: 11f054 sp: 24ab88 ^html_redraw_box()
( 24ac18) pc: 11e638 lr: 11f054 sp: 24ac1c ^html_redraw_box()
( 24acac) pc: 11e638 lr: 11f054 sp: 24acb0 ^html_redraw_box()
( 24ad40) pc: 11e638 lr: 11f054 sp: 24ad44 ^html_redraw_box()
( 24add4) pc: 11e638 lr: 11f054 sp: 24add8 ^html_redraw_box()
( 24ae68) pc: 11e638 lr: 11f054 sp: 24ae6c ^html_redraw_box()
( 24aefc) pc: 11e638 lr: 11f054 sp: 24af00 ^html_redraw_box()
( 24af90) pc: 11e638 lr: 11f054 sp: 24af94 ^html_redraw_box()
( 24b1e8) pc: 11e638 lr: 947c sp: 24b1ec ^html_redraw_box()
( 24b27c) pc: 11e638 lr: 11f054 sp: 24b280 ^html_redraw_box()
( 24b310) pc: 11e638 lr: 11f054 sp: 24b314 ^html_redraw_box()
( 24b3a4) pc: 11e638 lr: 11f054 sp: 24b3a8 ^html_redraw_box()
( 24b438) pc: 11e638 lr: 11f054 sp: 24b43c ^html_redraw_box()
( 24b4cc) pc: 11e638 lr: 11f054 sp: 24b4d0 ^html_redraw_box()
( 24b560) pc: 11e638 lr: 11f054 sp: 24b564 ^html_redraw_box()
( 24b5f4) pc: 11e638 lr: 11f054 sp: 24b5f8 ^html_redraw_box()
( 24b688) pc: 11e638 lr: 11f054 sp: 24b68c ^html_redraw_box()
( 24b71c) pc: 11e638 lr: 11f054 sp: 24b720 ^html_redraw_box()
( 24b7b0) pc: 11e638 lr: 11f054 sp: 24b7b4 ^html_redraw_box()
( 24b844) pc: 11e638 lr: 11f054 sp: 24b848 ^html_redraw_box()
( 24b8d8) pc: 11e638 lr: 11f054 sp: 24b8dc ^html_redraw_box()
( 24b96c) pc: 11e638 lr: 11f054 sp: 24b970 ^html_redraw_box()
( 24ba00) pc: 11e638 lr: 90910 sp: 24ba04 ^html_redraw_box()
( 24ba34) pc: 90884 lr: 640c4 sp: 24ba38 html_redraw()
( 24ba68) pc: 64020 lr: 1be86c sp: 24ba6c content_redraw()
( 24bb14) pc: 1be558 lr: 168cb8 sp: 24bb18 gui_window_update_box()
( 24bc64) pc: 168910 lr: 7798c sp: 24bc68 ^browser_window_callback()
( 24bcb4) pc: 77900 lr: 679bc sp: 24bcc0 content_broadcast()
( 24bd24) pc: 678ec lr: 731a8 sp: 24bd28 ^browser_redraw_box()
( 24bd70) pc: 72b3c lr: 7a118 sp: 24bd74 ^browser_window_textarea_callback()
( 24bd80) pc: 7a0f0 lr: 10df3c sp: 24bd84 browser_window_key_press()
( 24bdec) pc: 10de18 lr: 73430 sp: 24bdf0 ro_gui_window_keypress()
( 24be04) pc: 733a8 lr: 1bcc08 sp: 24be08 ^ro_gui_keypress()
( 24be14) pc: 1bcb40 lr: 1bcad8 sp: 24be18 ^ro_gui_handle_event()
( 24bf30) pc: 1bc95c lr: 121f14 sp: 24bf34 gui_poll()
( 24bf40) pc: 121efc lr: 934b4 sp: 24bf44 ^netsurf_poll()
( 24bf58) pc: 9346c lr: 15db54 sp: 24bf5c main()
( 24bf70) pc: 15dadc lr: 8e54 sp: 24bf74 _main()
--
18 years, 5 months
- 2
- 1
[Netsurf-develop] Re: Accesskeys
by Mark Syder
In message <20050330041425.2B264135DE(a)sc8-sf-spam2.sourceforge.net> you wrote:
> Today's Topics:
>
> 1. UK government websites "access keys" (Martin Angove)
>
> I've never heard of this before, but on perusing this website:
>
> http://www.digitaltelevision.gov.uk/access_keys_home.html
>
> I found the following:
>
> <p>This website uses the UK government access keys system. To navigate
> using your keyboard, please hold down your <strong>'Alt'</strong> key
> (Windows) or '<strong>Ctrl'</strong> Key (Apple Machintosh) and press
> the relevant key from the following list. If you are using an Internet
> Explorer browser, you will then need to press
> <strong>'Enter'</strong></p>
> <p><a href="/index.html" accesskey="1">1 - Home</a><br>
> <a href="/press/press_home.html" accesskey="2">2 - Press
> Notices</a><br>
>
> I can find no supporting Javascript, so the thing seems to simply be
> part of the <a href> tag. Is there any chance of this being supported
> under Netsurf?
As a webdesigner who always uses accesskeys I find it disappointing that no RISC OS browsers support it. It is part of HTML, so I hope it wouldn't be hard to support it in Netsurf.
--
Mark Syder (like the drink but spelt different)
www.onlinegenie.net
18 years, 5 months
- 1
- 0