Re: r5444 joty - /trunk/netsurf/riscos/gui.c
by John-Mark Bell
On Sat, 27 Sep 2008 netsurf(a)semichrome.net wrote:
> Author: joty
> Date: Sat Sep 27 11:19:08 2008
> New Revision: 5444
>
> URL: http://source.netsurf-browser.org?rev=5444&view=rev
> Log:
> Remove include of an internal UnixLib header (which btw no longer exists in gccsdk4)
[...]
> -#include <unixlib/sigstate.h>
22:43:39 <@jmb> http://source.netsurf-browser.org/?view=rev&revision=4068
22:44:02 <@jmb> and, the reason that got reverted is because
unixlib/sigstate.h defines __write_backtrace, which we
depend on
22:44:22 <@jmb> can we *please* get unixlib sorted in that area
22:44:37 <@jmb> or do we get to reinvent the backtracing wheel
In addition to this, if we assume that NS 2.0 must build correctly with
-Werror enabled, the above change blocks any 2.0 release as it introduces
a build warning.
I would rather not have to reinvent backtrace emission in NS itself.
It's beyond me quite why write_backtrace isn't public UnixLib API
already as it's hugely useful, especially given the dearth of decent
debug tools on RO.
J.
14 years, 8 months
Text selection with text field box active
by Chris Young
When clicking and dragging the mouse over and outside a text input
field (while it is active), usually it works fine, but occasionally it
causes NetSurf to crash. This assertion appears in the log:
assertion "s->root->gadget->caret_text_box != NULL" failed: file "desktop/selection.c", line 737
Not sure if this is just me or if it is reproduceable on other
platforms.
Chris
14 years, 8 months
libnsbmp test cases
by M Joonas Pihlaja
Hi netsurf-dev,
I've had a look at the recently broken off BMP loading library
libnsbmp from the point of view of robustness against malformed
images, and today finally created some test images to exercise
the issues I've found. Mostly the library seems okay, except
perhaps a bit too trusting of the input. As to its design, I
really like the approach of shuffling off the image allocation to
the client, as that puts the client in control of the main
resource usage. Could do with some bounds checked arithmetic and
array access primitives though.
Most of the potential out of bounds data writes in the code were
cunningly foiled by a restriction to 16 bits of width/height in
the library's bmp struct, so whoever thought of that deserves
kudos. :) Still, a few potential overflows remain, and even more
if the client is careless about how they allocate the image
bitmap, so to avoid them all I suggest restricting acceptable
widths and heights to be less than 16k.
I've gathered single examples of the problems I've found in the
bmp_<foo>() functions. There's some code and logic duplication
between different parts of libnsbmp, so the same problem
sometimes appears in multiple places, but I haven't gone and made
tests cases for each of those as they look all the same of
course.
The images themselves along with source, memcheck reports and
some further explanations are here:
http://www.discontinuity.info/~rowan/libnsbmp-tests.tar.gz
Those don't cover any of the ico/image collection parsing code,
but there seemed to be some issues there as well. Things like
trusting bitmap offset and such, but I haven't made tests for
those.
Finally, and totally tangentially to the test images, could I
make a feature request regarding the client callbacks? The
current set of callbacks includes a function
bmp_bitmap_cb_get_bpp bitmap_get_bpp; /**< Find the width of a pixel row in bytes. */
which seems quite odd since libnsbmp treats the return value as a
bytes_per_pixel value (which always *must* be four or bad things
will happen) instead of row stride / pitch like the comment
suggests. It would be useful if there was actually a callback
for the row stride.
Cheers,
Joonas Pihlaja
14 years, 8 months
Re: r5340 tlsa - /trunk/netsurf/Makefile.config
by Philip Boulain
(Apparently managed to miss the list with my reply. Whoops.)
On Wed, 2008-09-17 at 07:35 -0500, James Bursa wrote:
> On Wednesday 17 September 2008, you wrote:
> > On Tue, 2008-09-16 at 19:26 -0500, James Bursa wrote:
> > > In summary I don't see where the enthusiasm for disabling a fully working
> > > and useful feature is coming from.
> > Because MNG is obsolete in favour of APNG, which has actually been
> > implemented in browsers that more than a rounding error's worth of
> > people use?
> >
> > There's no legacy base of websites that'd stop working if it were
> > removed, as nobody used it in the first place, so it's a great
> > candidate for culling. (Ergo: not actually a "useful feature".)
> It is not that simple, for example:
> http://article.gmane.org/gmane.comp.graphics.png.general/1688/
I'm aware of that, but it ultimately doesn't matter. Mildly popular
browsers have implemented APNG, and not MNG (to the extent of removing
it from Mozilla), so APNG stands infinitely more chance of being used
than MNG.
It may also avoid MNG's stillbirth by degrading gracefully in IE.
> Please don't call NetSurf a rounding error.
My point is that the sum of MNG-supporting browser share is < 1%,
without pegging any actual number on it, thus nobody is ever going to
use it. This makes it dead weight, which is bad for the reasons Rob
highlights. As for libpng vs libmng, AFAIK, libpng has patches for APNG
support; libmng does not.
--
| Philip Boulain PhD student | The world can only really be changed |
| IAM, ECS, Uni of Southampton | one piece at a time. The art is |
| http://zepler.net/~lionsphil | picking that piece. --Tim Berners-Lee |
14 years, 8 months
Fwd: Dutch translation of NetSurf
by Michael Drake
Simon Voortman contacted me about translating the web site to Dutch. At
the moment we have the same problem as with the old site; it's not easy to
keep the translations in sync.
He's proposing a Messages like system for making master web pages with
tokens for each bit of content which are replaced by the relevant
translation of the associated text to build the web pages.
See his message below.
Any ideas / comments?
Michael
------ Forwarded message ------
From: Simon Voortman <svoortman(a)thecoast.tmfweb.nl>
Date: 11 Sep 2008 0205
Subject: Dutch translation of NetSurf
Hi Michael,
Summer's over, NetSurf 2.0 is (slowly) coming along, so it's probably time
to
move along with the Dutch translation, to be ready before NS 2.0.
It's been a while that you haven't heard of us.
Partly that's due to the summer: Gerard lives on a boat, and I haven't
seen or
spoken him since around June.
Another reason was the restructuring of the HTML-pages (which you guys did
before the summer).
Gerard was very disappointed by that, because it wasn't obvious what parts
had
changed and what not. It seemed like he had to do all his work over again!
I, too, must say translating HTML pages is not one of my favourite
activities,
because you have to wade through the HTML code to find the parts which
must
be translated, and it's all too easy to change the layout of the resulting
page by accident. Plus, you cannot easily do a diff against an older
version
and expect a sensible result.
So, why don't you guys separate the HTML pages into pure HTML with some
placeholders to insert the translated text into? Something like RISC OS
uses
when you translate applications with a Messages file?
Then, you could just make one (master) HTML page and, by using different
language files, produce the translated HTML page. Like:
HTML + placeholders --\
+ (build proces) ---> translated HTML
language files -------/
So, instead of:
<html>
<head>
<title>NetSurf | RISC OS Development Builds</title>
</head>
<body>
<li><a href="/about/">About NetSurf</a></li>
<li><a href="/downloads/">Downloads</a>
Make it like:
<html>
<head>
<title>NSRODEVBUILDS</title>
</head>
<body>
<li><a href="/about/">ABOUT</a></li>
<li><a href="/downloads/">DOWNLOADS</a>
Then, make Messages files with the following content:
English:
NSRODEVBUILDS: NetSurf | RISC OS Development Builds
ABOUT: About NetSurf
DOWNLOADS: Downloads
Dutch:
NSRODEVBUILDS: NetSurf | RISC OS ontwikkel versies
ABOUT: Over NetSurf
DOWNLOADS: Bestanden ophalen
When building a new version of NetSurfs translated pages, have the tokens
like 'NSRODEVBUILDS' replaced by their translation to make the translated
HTML pages.
Please note: This should be a separate usable tool, as it's also
invaluable
for us translators to make and test new translations!
Now, you can run diffs between Message file versions and get a sensible
result!
Another advantage is: You can restructure the master HTML page to your
heart's
content, without worrying about the translated pages layout lagging behind
(or doing that [the restructuring on the translated pages] yourself), as
that's automatic then - the translated parts remain translated, and new
strings (should) show up in English.
And, since a Messages file is not position-dependent, you can make a
distinction between already and yet-to-be-translated parts (by moving the
latter to e.g. the top or the end of the file), making translation easier.
Well, I'm eager to hear your thoughts about the above!
In case that the above is not going to happen (fast), I would like to hear
what files we should begin to translate to get the Dutch translation
underway.
Cheers,
Simon.
------ End forwarded message ------
--
Michael Drake (tlsa)
http://www.smoothartist.com/
14 years, 8 months
Re: r5225 chris_y - /trunk/netsurf/!NetSurf/Resources/en/Messages
by John-Mark Bell
It's just occurred to me that I didn't comment on this.
On Sun, 31 Aug 2008 netsurf(a)semichrome.net wrote:
> Author: chris_y
> Date: Sun Aug 31 06:22:59 2008
> New Revision: 5225
>
> URL: http://source.netsurf-browser.org?rev=5225&view=rev
> Log:
> Addition of strings used by the Amiga UI.
>
> Modified:
> trunk/netsurf/!NetSurf/Resources/en/Messages
>
> Modified: trunk/netsurf/!NetSurf/Resources/en/Messages
> URL: http://source.netsurf-browser.org/trunk/netsurf/%21NetSurf/Resources/en/M...
> ==============================================================================
> --- trunk/netsurf/!NetSurf/Resources/en/Messages (original)
> +++ trunk/netsurf/!NetSurf/Resources/en/Messages Sun Aug 31 06:22:59 2008
> @@ -215,6 +215,36 @@
> ImgStyle2:Dithered
> ImgStyle3:Error diffused
>
> +Copy:Copy
> -Copy:Copy to clipboard ^C
Was this intentional? I suspect it'll break the relevant menu entry in the
RISC OS front end.
>
> +# Tree export
> +#
> +TreeHotlist:NetSurf hotlist
> +
Why has this been moved?
As a general note. If you add stuff to Messages files, please do so for
_all_ languages, not just English.
J.
14 years, 8 months
Re: Crash on BBC News site
by John-Mark Bell
On Sat, 13 Sep 2008, Chris Young wrote:
> Crashlog attached (not sure how much use it is, probably not
> much), from this page: http://news.bbc.co.uk/1/hi/uk/7613458.stm
>
> This wasn't happening until recently, so I suspect it has been caused
> by recent changes in render code.
schedule_run()+0x10C (section 1 @ 0xdab4)
ami_handle_msg()+0xC5C (section 1 @ 0x3d64)
gui_multitask()+0x18 (section 1 @ 0x46f0)
There's your problem. You're running scheduled callbacks from somewhere
other than gui_poll. This is guaranteed to break things, as the core is
not reentrant.
c.f. http://source.netsurf-browser.org/?view=rev&revision=3366
John.
14 years, 8 months
Crash on BBC News site
by Chris Young
This appears to be in the core code as far as I can tell, so I thought
I'd flag it up here. Most (if not all, it has certainly happened on
both I tried) articles on the BBC News website are causing a crash,
occuring on line 524 of render/box.c - the end of a for statement:
fallback = fallback->next)
Crashlog attached (not sure how much use it is, probably not
much), from this page: http://news.bbc.co.uk/1/hi/uk/7613458.stm
This wasn't happening until recently, so I suspect it has been caused
by recent changes in render code.
Chris
14 years, 8 months
Re: GSoC code submissions
by John-Mark Bell
On Thu, 4 Sep 2008, John-Mark Bell wrote:
> I'm expecting each of the GSoC students to submit their own changes to the
> project on Google code.
This has now been done. Thanks to all of you for a great summer's work. We
look forward to any further contributions you wish to make to NetSurf :)
J.
14 years, 8 months
