(Documentation?) bug in libCSS css_computed_style_compose?
by James Montgomerie
Hello,
I'm working on libCSS just now, implementing support for some of the 'page' properties (page-break-before, page-break-after etc). I've noticed what I think is a bug in css_computed_style_compose, and I wanted to run it past the experts before trying to fix it, in case I've got the wrong end of the stick.
The symptoms are that properties that should by default /not/ inherit are inheriting.
The cause, I think, is in css_computed_style_compose. It happens when 'child' and 'result' point to the same object, and parent has 'page' group properties set (I think this will apply equally to the current 'uncommon' group), but the child does not. In the loop, when we get to the first set property in a group, it is composed (because the group in parent is not NULL), which causes the group to be allocated in the result object (the setters allocate the group if it doesn't already exist), and memset to 0. This meant that, because 'child' and 'result' are the same, all the other properties in 'child' are now set to 0 (by the memset when the group is set up). 0 is 'inherit'. Properties that /should/ have a non-inherit initial value are now set to inherit erroneously.
The solution is either to call initial_... for all the properties in the group when it's set up (in the "ENSURE_PAGE" macro, or equivalent), or maybe to change the docs to state that child and result may NOT be the same object.
Does this sound like a plausible diagnosis?
Thanks,
Jamie.
11 years, 11 months
Re: Atari Screenshots / BBC
by Chris Young
On Sun, 27 Feb 2011 21:49:53 +0100, m0n0 wrote:
> > That makes my cyan squares on Wikipedia even more interesting. I
> > take
> > it you're using the latest trunk versions of everything?
>
> Yes... but I made the screenshot with 16 bit color depth, maybe that is
> of any importance? On the other side, I think the Atari plotter code is
> very different to the one that the amiga uses, so you can't just think
> the result should be the same. As far as I remember there was one change
> of the Color format within libcss...
Right, next question :)
Are you building with NETSURF_USE_PNG, NETSURF_USE_MNG or both?
@Michael
Fixed screenshot:
http://homepage.ntlworld.com/cdyoung/tmp/ns-screenshots/wiki.png
Chris
12 years
Re: Atari Screenshots / BBC
by Chris Young
On Sun, 27 Feb 2011 21:49:53 +0100, m0n0 wrote:
>
> Am Sonntag, den 27.02.2011, 21:06 +0100 schrieb "Chris Young"
> <chris(a)unsatisfactorysoftware.co.uk>:
>
>
> > That makes my cyan squares on Wikipedia even more interesting. I
> > take
> > it you're using the latest trunk versions of everything?
>
> Yes... but I made the screenshot with 16 bit color depth, maybe that is
> of any importance? On the other side, I think the Atari plotter code is
> very different to the one that the amiga uses, so you can't just think
> the result should be the same.
I know, that was the point - to figure out whether the problem was
endianness in the core or something in the frontend. As it works for
you, the problem must be in the frontend somewhere. I compiled my
port with full Cairo plotters (code is pretty much identical to the
gtk plotters) and it still does it, so I'm tending towards something
in the bitmap plotters not being quite right.
A nose through the mess of CSS on Wikipedia shows that those tabs have
PNG background images from a data: URI like the following:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAABkAQAAAABvV2fNAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAABVJREFUeF7dwQEBAAAAQCDTTfdD4WOJ5TIB3ib9EgAAAABJRU5ErkJggg==
I pasted that into the NetSurf URL bar and got the following assert:
assertion "!c->locked" failed: file "content/content.c", line 746
So I suppose that needs fixing before I can figure out what's going on
here.
I did try it in another browser and that data: is a white line, which
is pretty much what I'd expect.
Chris
12 years
More API for history_core
by Sven Weidauer
I need to enumerate all entries in the local history to correctly
display tool tips in the local history view. And to implement menus on
the back and forward buttons I also need to enumerate the history
entries in the order history_back() and history_forward() go and I
need access to the history_go() function.
Here are my proposed changes to history_core.{c,h}. My new
enumeration API uses a callback, but I could use as well a different
approach using history_entry_first_child() and history_entry_next().
From 6658ace3866e725ceef115c6beb754ea27349851 Mon Sep 17 00:00:00 2001
From: Sven Weidauer <sven.weidauer(a)gmail.com>
Date: Sat, 26 Feb 2011 13:25:35 +0100
Subject: [PATCH] Added function to enumerate entries in the history
tree.
---
desktop/history_core.c | 54 +++++++++++++++++++++++++++++++++++++++
+++++++++
desktop/history_core.h | 10 ++++++++
2 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/desktop/history_core.c b/desktop/history_core.c
index 0449a3d..fc9f292 100644
--- a/desktop/history_core.c
+++ b/desktop/history_core.c
@@ -94,6 +94,8 @@ static bool history_redraw_entry(struct history
*history,
int x, int y, bool clip);
static struct history_entry *history_find_position(struct
history_entry *entry,
int x, int y);
+static bool history_enumerate_entry( struct history *history, struct
history_entry *entry,
+ history_enumerate_cb cb, void *ud );
/**
@@ -766,3 +768,55 @@ struct history_entry
*history_find_position(struct history_entry *entry,
return 0;
}
+
+
+/**
+ * Enumerate all entries in the history.
+ *
+ * \param history history to enumerate
+ * \param cb callback function
+ * \param user_data context pointer passed to cb
+ */
+void history_enumerate( struct history *history, history_enumerate_cb
cb, void *user_data )
+{
+ history_enumerate_entry( history, history->start, cb, user_data );
+}
+
+/**
+ * Enumerate subentries in history
+ *
+ * \param history history to enumerate
+ * \param entry entry to start enumeration at
+ * \param cb callback function
+ * \param ud context pointer passed to cb
+ */
+static bool history_enumerate_entry( struct history *history, struct
history_entry *entry,
+ history_enumerate_cb cb, void *ud )
+{
+ struct history_entry *child;
+
+ if (!cb( history, entry->x, entry->y, entry->x + WIDTH, entry->y +
HEIGHT,
+ entry, ud )) return false;
+
+ for (child = entry->forward; child; child = child->next) {
+ if (!history_enumerate_entry( history, child, cb, ud ))
+ return false;
+ }
+
+ return true;
+}
+
+const char *history_entry_get_url( const struct history_entry *entry )
+{
+ return entry->page.url;
+}
+
+const char *history_entry_get_fragment_id( const struct history_entry
*entry )
+{
+ return entry->page.frag_id;
+}
+
+const char *history_entry_get_title( const struct history_entry
*entry )
+{
+ return entry->page.title;
+}
\ No newline at end of file
diff --git a/desktop/history_core.h b/desktop/history_core.h
index 55b4e0b..50b4172 100644
--- a/desktop/history_core.h
+++ b/desktop/history_core.h
@@ -28,6 +28,7 @@
struct hlcache_handle;
struct history;
struct browser_window;
+struct history_entry;
struct history *history_create(void);
struct history *history_clone(struct history *history);
@@ -47,4 +48,13 @@ bool history_click(struct browser_window *bw,
struct history *history,
int x, int y, bool new_window);
const char *history_position_url(struct history *history, int x, int
y);
+typedef bool (*history_enumerate_cb)( struct history *history, int
x0, int y0, int x1, int y1,
+ const struct history_entry *entry, void *user_data );
+
+void history_enumerate( struct history *history, history_enumerate_cb
cb, void *user_data );
+
+const char *history_entry_get_url( const struct history_entry *entry );
+const char *history_entry_get_fragment_id( const struct history_entry
*entry );
+const char *history_entry_get_title( const struct history_entry
*entry );
+
#endif
--
1.6.5.1+GitX
From f28906a8bc8d7db56a38be66fe27677d7413da53 Mon Sep 17 00:00:00 2001
From: Sven Weidauer <sven.weidauer(a)gmail.com>
Date: Sun, 27 Feb 2011 12:25:44 +0100
Subject: [PATCH] Publishing 'history_go' function and creating API to
enumerate all history items reachable by the forward or back buttons.
---
desktop/history_core.c | 41 +++++++++++++++++++++++++++++++++++++
+---
desktop/history_core.h | 5 +++++
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/desktop/history_core.c b/desktop/history_core.c
index fc9f292..ac34f5c 100644
--- a/desktop/history_core.c
+++ b/desktop/history_core.c
@@ -83,8 +83,6 @@ struct history {
static struct history_entry *history_clone_entry(struct history
*history,
struct history_entry *entry);
static void history_free_entry(struct history_entry *entry);
-static void history_go(struct browser_window *bw, struct history
*history,
- struct history_entry *entry, bool new_window);
static void history_layout(struct history *history);
static int history_layout_subtree(struct history *history,
struct history_entry *entry, int x, int y, bool shuffle);
@@ -769,6 +767,43 @@ struct history_entry
*history_find_position(struct history_entry *entry,
return 0;
}
+/**
+ * Enumerate all entries that will be reached by the 'forward' button
+ *
+ * \param history The history object to enumerate in
+ * \param cb The callback function
+ * \param user_data Data passed to the callback
+ */
+void history_enumerate_forward( struct history *history,
history_enumerate_cb cb, void *user_data )
+{
+ struct history_entry *entry;
+
+ if (history == nil || history->current == nil) return;
+
+ for (entry = history->current->forward_pref; entry != NULL; entry =
entry->forward_pref) {
+ if (!cb( history, entry->x, entry->y, entry->x + WIDTH, entry->y +
HEIGHT, entry, user_data))
+ break;
+ }
+}
+
+/**
+ * Enumerate all entries that will be reached by the 'back' button
+ *
+ * \param history The history object to enumerate in
+ * \param cb The callback function
+ * \param user_data Data passed to the callback
+ */
+void history_enumerate_back( struct history *history,
history_enumerate_cb cb, void *user_data )
+{
+ struct history_entry *entry;
+
+ if (history == nil || history->current == nil) return;
+
+ for (entry = history->current->back; entry != NULL; entry = entry-
>back) {
+ if (!cb( history, entry->x, entry->y, entry->x + WIDTH, entry->y +
HEIGHT, entry, user_data))
+ break;
+ }
+}
/**
* Enumerate all entries in the history.
@@ -819,4 +854,4 @@ const char *history_entry_get_fragment_id( const
struct history_entry *entry )
const char *history_entry_get_title( const struct history_entry
*entry )
{
return entry->page.title;
-}
\ No newline at end of file
+}
diff --git a/desktop/history_core.h b/desktop/history_core.h
index 50b4172..552d39b 100644
--- a/desktop/history_core.h
+++ b/desktop/history_core.h
@@ -52,9 +52,14 @@ typedef bool (*history_enumerate_cb)( struct
history *history, int x0, int y0, i
const struct history_entry *entry, void *user_data );
void history_enumerate( struct history *history,
history_enumerate_cb cb, void *user_data );
+void history_enumerate_forward( struct history *history,
history_enumerate_cb cb, void *user_data );
+void history_enumerate_back( struct history *history,
history_enumerate_cb cb, void *user_data );
const char *history_entry_get_url( const struct history_entry
*entry );
const char *history_entry_get_fragment_id( const struct
history_entry *entry );
const char *history_entry_get_title( const struct history_entry
*entry );
+void history_go(struct browser_window *bw, struct history *history,
+ struct history_entry *entry, bool new_window);
+
#endif
--
1.6.5.1+GitX
12 years
Re: Atari Screenshots / BBC
by Chris Young
On Sun, 27 Feb 2011 20:15:56 +0100, m0n0 wrote:
> > Is that running on a big endian CPU?
>
> Yes (68040)
That makes my cyan squares on Wikipedia even more interesting. I take
it you're using the latest trunk versions of everything?
Chris
12 years
Re: Atari Screenshots / BBC
by Chris Young
On Sun, 27 Feb 2011 19:39:32 +0100, m0n0 wrote:
> Screen shots attached.
Is that running on a big endian CPU?
I was going to try the GTK version under Debian PPC but my install is
broken to the extent it won't boot.
Chris
12 years
Re: Screenshots page / BBC
by Michael Drake
m0n0 <ole(a)monochrom.net> wrote:
> But why isn't the gradient renderer? Because the image shall be drawn
> completely outside of the clipping rectangle ( clipping is from x: 0, y:
> 0, x1: window_width, y1: 40) - the plot function is called with 250 as y
> coord - that's not within the clipping rectangle... so the image will
> never be drawn.
Ah, right, this is expected behaviour.
Consider the following css:
div.example {
background: url(bg.png) bottom right;
width: 1000px;
height: 1000px;}
A box generated for <div class="example"></div> will have the background
image bg.png tiled over the 1000x1000 area of the box. The "bottom right"
part says that the image is explicitly placed at the bottom right, so if
the image is 3px by 3px, then the image is positioned at a position 997
from the top of the box, and 997 from the left of the box. It is tiled
such that one of the tiles is exactly at that coordinate.
If you only need to redraw the top half of the box, because the rest is
outside the viewport, then that coordinate is outside the clipping
rectangle. You still have to draw the visible area with the tiled
background, and the tiles must still be positioned to coincide with the
explicitly given tile coordinate, whether it's inside the clipping
rectangle or not.
I fixed this in the framebuffer front end. See framebuffer/framebuffer.c,
where it gets the left most tile position, and the top most tile position,
and then tiles to the extents of the clip region.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
12 years
