When you save a local copy of a web page with NetSurf you get an icon file
which is a tiny thumbnail view of the entire web page. I don't like these
very much - I find them untidy. Given that you can control whether or not
iconised windows use thumbnail images, it's a bit odd that one has no
control at all over the 'saved page icons'. I'd prefer a generic 'saved web
page' app icon, or nothing at all, giving the RISC OS default icon. If a web
page provided an .ico file, I guess many people might prefer to use
Is it possible to turn off the 'IconSprites' line in the mini !Run files
NetSurf provides you, which currently reads
Providing better control over this does seem like a legit use for a
configuration option. I'm a bit surprised that !Run file (and/or an
option Boot file) aren't available as editable resources.
At present I'm deleting the unwanted Sprites files and tweaking the !Run
files by hand, which is a chore.
Simon Smith | Once more unto now
| Is the winter to be or
| 'Tis the east (Exit.)
| -Wm. Shakespeare, abridged
seems to consistently crash NS (3.1 (Dev CI #1543)) without displaying a
Can anyone else get this site?
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
Screenshot not working for some reason - so changed to
"Are you the Prime Minister?" "No, but I've often been mistaken."
"What, for the Prime Minister?" "No. I've just often been mistaken..."
The NetSurf team are pleased to announce the availability of a new bug tracker 
The new tracker uses mantis  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.
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 
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  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  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
) 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  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  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
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
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.
 if the userid on sourceforge was kyllikki the email used was kyllikki(a)users.sourceforge.net
 Everyone knows that debugging is twice as hard as writing a program in the first place. - Brian Kernighan "The Elements of Programming Style", 2nd edition, chapter 2
Here is a brief list of the main changes made to NetSurf's core code since
the release of NetSurf 3.0:
+ Choices behaviour improvement
- Now only saves options which differ from the defaults.
+ about:config improved
- Visiting about:config shows which settings were modified by the user.
+ Textarea undo/redo
- Supports keyboard shortcuts to undo/redo changes made in textareas.
- The shortcut keys are platform dependent.
+ Rewritten treeviews [*]
- Faster (especially application startup time).
- Fixes rendering glitches.
- Improved new look.
- Nicer behaviour.
- Keyboard navigation.
- Treeview clients rewritten for new treeview:
- Global history
- Cookie manager
- SSL certificate viewer
- Several bugs fixed, e.g. cookie delete.
+ Hotlist has default folder [*]
- New additions go into the default folder, rather than into root.
- Default folder has different icon.
+ Directory listing of file: URLs
- Improved sort to fix "File1, File10, File2".
- Icons shown for folder/file differentiation.
+ Several leaks squashed
- Memory leaks in various places in NetSurf fixed.
- Reference counting leaks in LibDOM fixed.
+ URL bar hotlist indicator [*]
- Indicator shows whether current URL is in the Hotlist.
- Click to add/remove from hotlist.
+ LibCSS speedup
- Faster handling of CSS selection.
[*] Core change also requires front end updates which may or may not have
happened for any given platform.
I've left out all purely front end developments.
Please test the latest development builds and let us know how you get on.
Michael Drake (tlsa) http://www.netsurf-browser.org/