3:38 p.m.
On Tue, 12 Feb 2013 15:40:13 +0000 (GMT), Michael Drake wrote:
In article <531c85f3cdtlsa(a)netsurf-browser.org>,
Michael Drake <tlsa(a)netsurf-browser.org> wrote:
> New features:
> - The textarea is auto scrolled as you drag a selection.
More new features:
- Double click in a textarea selects a word.
- Triple click in a textarea selects a paragraph.
Note that this depends on the front end passing the double and triple
click events to the core. I have updated the GTK, Framebuffer and RISC OS
front ends to do so.
The AmigaOS frontend already sent double-clicks. I've added
triple-click support.
The new textarea is working well here. I'm getting strange effects on
the last line of multi-line areas on occasion (maybe when the last
line is the first line of a line which extends onto the next line? -
if that makes sense!), but I haven't been able to reproduce it on
demand.
What happens is that NetSurf displays the correct thing, but the caret
stops before the end of the line, as if something different is there.
I'm also getting a serious memory leak during usage, but I'm not sure
if that is related to the new textareas, JavaScript or something else
- all I know is that it appears to have started within the last week
(and it isn't my box redraw queue - I've checked that), and typing
things into textareas eventually grinds to a halt (due to lack of
memory - although it might not be the typing into textareas which is
the cause)
I'll run with JavaScript disabled for a bit in case it is related to
that.
Chris
4:16 p.m.
New subject: New textareas and text inputs
In article
<OUT-511BF9C7.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
On Tue, 12 Feb 2013 15:40:13 +0000 (GMT), Michael Drake wrote:
The AmigaOS frontend already sent double-clicks. I've added
triple-click support.
Cool, thanks.
The new textarea is working well here.
Good. :)
I'm getting strange effects on the last line of multi-line areas
on
occasion (maybe when the last line is the first line of a line which
extends onto the next line? - if that makes sense!), but I haven't been
able to reproduce it on demand.
I've not seen that. Do you mean a textarea line which is soft-wrapped to a
line out of sight below the visible display? I've not seen that here.
What happens is that NetSurf displays the correct thing, but the
caret
stops before the end of the line, as if something different is there.
So if you move the caret with cursor-right key, it doesn't reach the end
of the displayed text?
The last character on a soft-wrapped line is a space, but you can't put
the caret to the right of it, a caret after the space is on the start of
the next line.
I'm also getting a serious memory leak during usage, but I'm
not sure
if that is related to the new textareas, JavaScript or something else
- all I know is that it appears to have started within the last week
(and it isn't my box redraw queue - I've checked that), and typing
things into textareas eventually grinds to a halt (due to lack of
memory - although it might not be the typing into textareas which is
the cause)
This is concerning. I'll have a look.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
6:35 p.m.
New subject: New textareas and text inputs
On Wed, 13 Feb 2013 21:16:45 +0000 (GMT), Michael Drake wrote:
> I'm getting strange effects on the last line of multi-line
areas on
> occasion (maybe when the last line is the first line of a line which
> extends onto the next line? - if that makes sense!), but I haven't been
> able to reproduce it on demand.
I've not seen that. Do you mean a textarea line which is soft-wrapped to a
line out of sight below the visible display? I've not seen that here.
Yes.
> What happens is that NetSurf displays the correct thing, but the
caret
> stops before the end of the line, as if something different is there.
So if you move the caret with cursor-right key, it doesn't reach the end
of the displayed text?
The last character on a soft-wrapped line is a space, but you can't put
the caret to the right of it, a caret after the space is on the start of
the next line.
It gets as far as the length of the line below it, it looks like it is
confused as to which line it is actually on. Pressing enter appears
to act as if it is on the line below too (and then refreshes it and
everything works as it should). If I can get it to do it again, I'll
save a copy of my text.
> I'm also getting a serious memory leak during usage, but
I'm not sure
> if that is related to the new textareas, JavaScript or something else
> - all I know is that it appears to have started within the last week
> (and it isn't my box redraw queue - I've checked that), and typing
> things into textareas eventually grinds to a halt (due to lack of
> memory - although it might not be the typing into textareas which is
> the cause)
This is concerning. I'll have a look.
I start with about 400MB, it disappears to nothing during use, and
when I quit NetSurf it only frees up less than 100MB. It looks like
something isn't getting freed.
I've just been playing around with it trying to reproduce the "last
line" bug (I couldn't), and I'm down to 150MB - after quitting NetSurf
- from a starting point of 400MB. That's with JavaScript disabled, so
we can eliminate that.
Chris
1:57 p.m.
New subject: New textareas and text inputs
On Wed, 13 Feb 2013 21:16:45 +0000 (GMT), Michael Drake wrote:
> I'm also getting a serious memory leak during usage, but
I'm not sure
> if that is related to the new textareas, JavaScript or something else
> - all I know is that it appears to have started within the last week
> (and it isn't my box redraw queue - I've checked that), and typing
> things into textareas eventually grinds to a halt (due to lack of
> memory - although it might not be the typing into textareas which is
> the cause)
This is concerning. I'll have a look.
I think I've tracked this down to a bug (or "implementation feature",
perhaps) in OS4's newlib realloc() function.
If I allocate 10MB of memory in 64 byte chunks using realloc(), around
400MB of RAM gets eaten up, rather than the expected 10MB. I've tried
the same test with clib2, and - aside from the fact it takes forever
and I can't be bothered to wait for it to complete - it seems to work
correctly (in that it isn't allocating vast amounts of memory beyond
what was requested)
However I can't (nor do I want to) build NetSurf against clib2.
I toyed with the idea of addng my own malloc/realloc/free
implementations to NetSurf, until I realised that I'd need to also add
them to all of NetSurf's dependencies, because some things might be
allocated by one library and freed using free() (or vice versa).
Any suggestions on how to work around this bug would be appreciated,
as I have no idea how long it will take for a fix to be released.
Chris
4:29 p.m.
New subject: New textareas and text inputs
In message <OUT-512279AE.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>
"Chris Young" <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
Any suggestions on how to work around this bug would be appreciated,
as I have no idea how long it will take for a fix to be released.
UnixLib, the C (and more) runtime library used in the RISC OS NS build,
uses Doug Lea's malloc implementation (cfr. http://g.oswego.edu/dl/).
Perhaps that's an option for you.
John.
--
John Tytgat
joty(a)netsurf-browser.org
1:39 p.m.
New subject: New textareas and text inputs
On Mon, 18 Feb 2013 22:29:33 +0100, John Tytgat wrote:
In message
<OUT-512279AE.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>
"Chris Young" <chris.young(a)unsatisfactorysoftware.co.uk>
wrote:
> Any suggestions on how to work around this bug would be appreciated,
> as I have no idea how long it will take for a fix to be released.
UnixLib, the C (and more) runtime library used in the RISC OS NS build,
uses Doug Lea's malloc implementation (cfr. http://g.oswego.edu/dl/).
Perhaps that's an option for you.
That's what I was trying to link in as a replacement, but some
libraries still seemed to be using the newlib one, hence freeing
within NetSurf was crashing. I'm wondering whether that is due to the
lib in question being dynamically linked. I'll have a play with my
buildsystem and try again.
Chris
6:39 p.m.
New subject: New textareas and text inputs
On 19 Feb 2013 18:39:40 +0000, Chris Young wrote:
> > Any suggestions on how to work around this bug would be
appreciated,
> > as I have no idea how long it will take for a fix to be released.
>
> UnixLib, the C (and more) runtime library used in the RISC OS NS build,
> uses Doug Lea's malloc implementation (cfr. http://g.oswego.edu/dl/).
> Perhaps that's an option for you.
That's what I was trying to link in as a replacement, but some
libraries still seemed to be using the newlib one, hence freeing
within NetSurf was crashing. I'm wondering whether that is due to the
lib in question being dynamically linked. I'll have a play with my
buildsystem and try again.
Actualy dlmalloc needs some work to actually allocate memory, which is
beyond my understanding, so I wrote something a bit simpler.
However, same problem. It works fine if I replace all the textarea
internal malloc/realloc/free calls to use my functions, but a global
replacement of them isn't working for some reason.
I suspect crazy #ifdeffing of that file won't go down well, but I do
at least have a buildable version here that doesn't exhibit problems
after using a few textareas.
I'm toying with the idea of patching newlib.library, as convincing
either developers or betatesters that it has a problem is proving more
difficult than anticipated. Might be a _very_ bad idea though - I'd
rather work around it in NetSurf as that has less wide-ranging
consequences.
Chris
11:30 a.m.
New subject: New textareas and text inputs
In article
<OUT-512279AE.MD-1.4.17.chris.young(a)unsatisfactorysoftware.co.uk>,
Chris Young <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
I think I've tracked this down to a bug (or "implementation
feature",
perhaps) in OS4's newlib realloc() function.
If I allocate 10MB of memory in 64 byte chunks using realloc(),
around
400MB of RAM gets eaten up, rather than the expected 10MB.
Does it behave any better now? I've increased the step size.
In other news, the Amiga ami_file_save_req() behaviour needs attention,
because browser_window_get_selection() now returns a pointer to a char *
string that the client must free, rather than the old textplain/html
struct selection object.
I've already fixed up the obvious stuff.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
3:39 p.m.
New subject: New textareas and text inputs
On Fri, 22 Feb 2013 16:30:25 +0000 (GMT), Michael Drake wrote:
> I think I've tracked this down to a bug (or
"implementation feature",
> perhaps) in OS4's newlib realloc() function.
> If I allocate 10MB of memory in 64 byte chunks using realloc(), around
> 400MB of RAM gets eaten up, rather than the expected 10MB.
Does it behave any better now? I've increased the step size.
Doesn't seem to have made an awful lot of difference, unfortunately.
I do seem to have finally convinced the PTB that there is a problem
though.
In other news, the Amiga ami_file_save_req() behaviour needs
attention,
because browser_window_get_selection() now returns a pointer to a char *
string that the client must free, rather than the old textplain/html
struct selection object.
I think I've obliterated struct selection* from the frontend now.
Chris
3748
days inactive
3760
days old
netsurf-dev@netsurf-browser.org
9 comments
3 participants
participants (3)
-
Chris Young -
John Tytgat -
Michael Drake