Re: r2680 jmb - /trunk/netsurf/render/layout.c
by James Bursa
> Author: jmb
> Date: Fri Jun 30 00:30:06 2006
> New Revision: 2680
>
> URL: http://svn.semichrome.net?rev=2680&view=rev
> Log:
> Ensure containing block has valid height for positioning absolute children
>
> Modified:
> trunk/netsurf/render/layout.c
>
> Modified: trunk/netsurf/render/layout.c
> URL:
> http://svn.semichrome.net/trunk/netsurf/render/layout.c?rev=2680&r1=2679&...
> ==============================================================================
> --- trunk/netsurf/render/layout.c (original)
> +++ trunk/netsurf/render/layout.c Fri Jun 30 00:30:06 2006
> @@ -158,6 +158,7 @@
> int max_pos_margin = 0;
> int max_neg_margin = 0;
> int y;
> + int old_height;
> struct box *margin_box;
>
> assert(block->type == BOX_BLOCK ||
> @@ -296,9 +297,18 @@
> cy = y;
> }
>
> + /* Before positioning absolute children, ensure box has a
> + * valid height. */
> + old_height = box->height;
> + if (box->height == AUTO)
> + box->height = 0;
> +
> /* Absolutely positioned children. */
> if (!layout_absolute_children(box, content))
> return false;
> +
> + /* And restore height for normal layout */
> + box->height = old_height;
>
> /* Advance to next box. */
> if (box->type == BOX_BLOCK && !box->object && box->children) {
This is strange. What case did you find where this was a problem? The
height of a box should never be AUTO when layout is complete.
17 years, 1 month
Cookies: security
by John-Mark Bell
The current cookie implementation errs on the side of caution wrt
accepting incoming cookies and choosing outgoing cookies. We currently
implement all of RFC2109:$4.3.2. Unfortunately, this means that a number
of sites will break (I'm currently aware of 2 - yahoo.com and
sourceforge.net).
I certainly don't like the idea of relaxing our handling of cookie
validation. In the specific case of yahoo, they try to set a domain cookie
for .yahoo.com from a host edit.europe.yahoo.com. This contravenes the 4th
item in the list of reasons to reject an incoming cookie. Sourceforge,
otoh, tries to set a domain cookie for .sourceforge.net from a host
sourceforge.net. By my reading of the spec, this contradicts the 3rd item
of the list.
Obviously, it's the intention to provide a cookie acceptance UI (along
with some form of cookie management UI) so it could be reasonable to
simply defer this decision to the user. I suspect, however, that most
users will simply turn off any popup query dialog at the first
opportunity, thus rendering any attempt at not leaking the user's cookie
details in this way pretty redundant.
Is there a better way of dealing with this?
John.
17 years, 2 months
Cookies: unverifiable transactions
by John-Mark Bell
The next thing the cookie implementation requires is support for
unverifiable transactions (RFC2109:$4.3.5). This is somewhat difficult
given the way fetches are currently handled; ideally, the cookie stuff
would know:
a) what spawned the fetch (simple enough - it already gets the referer)
b) what cookies (if any) the parent fetch set.
The second of these is rather difficult to provide. Has anyone got any
thoughts on how this might be handled?
John.
17 years, 2 months
Absolute positioning
by James Bursa
I've started working on absolute positioning.
My plan is to add struct box *absolute_children to struct box. Absolute
boxes will be a linked list attached to the absolute_children pointer of
their containing block (see CSS 2.1 10.1), and not appear in the children
list at all.
The other possibility would be to make a new box type BOX_ABSOLUTE,
similar to the way floats are implemented. I think that would make
layout_block_context() much more complicated though.
Any comments?
James
17 years, 2 months
Absolute positioning patch
by John-Mark Bell
Hi,
I've produced the following patch for a couple of issues in the absolute
positioning code. In summary:
* Fix use of margin[RIGHT] in calculation of right margin
* Fix available_width initialisation for shrink-to-fit widthing
This appears to fix the lack of text wrapping on CSS Zen Garden but
appears to lose the links panel that should be on the right hand side.
I've not investigated whether that's a side effect of my changes or
something else, so haven't committed the change. James; if this patch is
fine with you, I'll commit it.
John.
---
Index: render/layout.c
===================================================================
--- render/layout.c (revision 2648)
+++ render/layout.c (working copy)
@@ -368,7 +368,7 @@
/* Absolutely positioned children. */
if (!layout_absolute_children(block, content))
return false;
-
+
return true;
}
@@ -2364,7 +2364,7 @@
box->style->position == CSS_POSITION_RELATIVE);
layout_compute_offsets(box, box->parent, &top, &right, &bottom, &left);
-
+
if (left == AUTO && right == AUTO)
left = right = 0;
else if (left == AUTO)
@@ -2501,9 +2501,9 @@
} else if (margin[RIGHT] == AUTO) {
margin[RIGHT] = containing_block->width -
left -
- border[LEFT] - padding[LEFT] -
+ margin[LEFT] - border[LEFT] - padding[LEFT] -
width -
- padding[RIGHT] - border[RIGHT] - margin[RIGHT] -
+ padding[RIGHT] - border[RIGHT] -
right;
} else {
right = containing_block->width -
@@ -2517,7 +2517,14 @@
margin[LEFT] = 0;
if (margin[RIGHT] == AUTO)
margin[RIGHT] = 0;
+
+ available_width = containing_block->width -
+ margin[LEFT] - border[LEFT] - padding[LEFT] -
+ padding[RIGHT] - border[RIGHT] - margin[RIGHT];
+
if (left == AUTO && width == AUTO && right != AUTO) {
+ available_width -= right;
+
width = min(max(box->min_width, available_width), box->max_width);
left = containing_block->width -
margin[LEFT] - border[LEFT] - padding[LEFT] -
@@ -2532,6 +2539,8 @@
width -
padding[RIGHT] - border[RIGHT] - margin[RIGHT];
} else if (left != AUTO && width == AUTO && right == AUTO) {
+ available_width -= left;
+
width = min(max(box->min_width, available_width), box->max_width);
right = containing_block->width -
left -
@@ -2566,7 +2575,7 @@
box->x = left;
box->width = width;
box->height = height;
-
+
if (box->type == BOX_BLOCK || box->object) {
if (!layout_block_context(box, content))
return false;
17 years, 2 months
