Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
Sometimes a server will send, say, 500 Internal Server Error with
a Content-Length of 0, and Dillo just happily shows the empty page
instead of the document that you thought you were going to get,
and it's confusing.
|
|
|
|
|
|
Occasionally, linebuf leaks have appeared in Jeremy's valgrind logs.
linebuf is used in Gif_literal() and Gif_sequence(). They are called
by Gif_process_code(), which is called by Gif_decode(). In
Gif_process_bytes(), you have to be in state 3 to call it.
linebuf is allocated inside Gif_do_img_desc(), which is called by
GIF_Block(). In Gif_process_bytes(), you have to be in state 2 to
call it.
After the allocation, there are a couple of cases where the code
can return while still in state 2, which would mean coming back to
Gif_do_img_desc() later and leaking the linebuf by allocating another.
Jeremy has kindly run on this patch for ten days or so without incident.
|
|
This leak had long made occasional appearances in Jeremy's valgrind
logs, and I supposed it was some complicated CCC interaction, and
didn't want to put a band-aid over the problem without knowing why
it's happening first. But now I finally dug into it, and I see it
coming from aborting in Cache_process_queue() (not viewable, for
instance), and then a_Cache_process_dbuf() never gets IOClose, which
makes a lot of sense!
|
|
|
|
|
|
Reported by: "Rob S." <mr_semantics@hotmail.com>
Submitted by: corvid <corvid@lavabit.com>
|
|
I saw a MSG with size 0x[something], and of course I thought it was
complaining that a size was given in hex notation.
|
|
In Html_write_raw() the current textblock can change while parsing HTML.
Instead of flushing the Textblock we started with, we now flush the
current one.
This fixes a long standing drawing bug where text was not positioned
initially.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The skipString() method of CssParser was eating one char too much in case
of a match. This caused e.g. empty comments (/**/) to be misinterpreted.
Noticed and tracked down by: Jeremy Henty <onepoint@starurchin.org>
|
|
|
|
|
|
The drawBorder{Top,Bottom,Left,Right} functions are similar. They
use a trapezium as draw polygon, or drawTypedLine() for dots and dashes.
Although the concept is simple, achieving pixel accuracy is laborious [1].
[1] http://www.dillo.org/css_compat/tests/border-style.html
|
|
|
|
thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-November/007801.html
|
|
|
|
|
|
http://www.weather.gov/ptwc/ doesn't work because it uses real numbers
rather than integers for coords. The 4.01 spec doesn't quite _rigorously_
state that real numbers are no good in that case, so far as I can see,
but it's pretty clearly the intention -- and html5 _does_ spell this out.
|
|
|
|
|
|
Bounds checking is already done by SimpleVector.
|
|
|
|
|
|
|
|
|
|
noticed by Johannes.
|
|
|
|
Testcase:
<div style="line-height: auto">
foo<br>foo<br>foo<br>
</div>
This only fixes the use of uninitialzed values in this case.
The real fix will be to drop the invalid declaration in the CSS parser.
This needs to be implemented with a later commit.
Reported-by: Jeremy Henty <onepoint@starurchin.org>
|
|
|
|
|