188957 - CSS 1px dotted border gap appearing in Mozilla even with validated CSS style sheet

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P4)

Description

[Bernie Zimmermann]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

In the page at http://www.pleasureunit.com/bernie I have set up a DIV element
for displaying posts.  The DIV element's style is controlled via a validated
external stylesheet (validated at w3c) that assigns a 1px dotted border to the div:

/* division elements */
.box {
 width: 100%;
 background-color: #E8E6FD;
 color: #6B66A3;
 padding: 10px;
 margin-bottom: 5px;
 border: 1px dotted #514C86
}

The border shows up as usual in IE (but with dashes instead of dots, due to IE
bug) without the gaps and in Opera 7 as well.

The gap in Mozilla only appears on the upper border at the very right and the
lower border at the very right (for roughly 15 pixels or so).

Reproducible: Always

Steps to Reproduce:
1. Go to www.pleasureunit.com/bernie
2. View the dotted border in the main content of the page.
3. See how the gaps appear to the right.

Actual Results:  
Gaps appeared in the dotted border that shouldn't be there.

Expected Results:  
Made the dotted border continuous around the entire edge of the DIV.

Comment 1

[Ruslan Ismailov]

Attachment: Border gap. Simplify testcase

I see this gap in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b)
Gecko/20030112 under WinXP.

Comment 2

[Ruslan Ismailov]

Seems to be a strange bug with dotted and dashed borders -- top and lower
segments draw not in 100% width, but only on width without padding.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase that makes this very clear....

Comment 4

[Boris Zbarsky [:bzbarsky]]

So the problem is the combination of "width:100%" and padding on something
inside a table cell (which cannot overflow).  The situation is overconstrained.
 It looks like we decide we got to the end of the frame rect and stop when we
hit the cell edge while painting the borders....

I see nothing obvious in DrawDashedSides (is that what we call?  Why do we have
all this dead code in nsCSSRendering?) that would do that incorrectly, though....

Comment 5

[Ruslan Ismailov]

Attachment: dotted border inside cell toubled with percentile width

I realy thing that it is table resing trouble. div inside div work ok,
but div with paddign inside table cell produce nasty effect and report
incorrect sizing on big percentiles.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Ruslan, see comment 4, the part about overflow.  <div> can overflow.

Comment 7

[Ruslan Ismailov]

Attachment: Overflowing div cause dotted border to gap

Look at this testcase. I could not understand, why div with width 100%, padding
60px become 120 pixel overflowed (and in 500px div not overflowed).

This overflow is source of trouble, of cource. But I could not find where it
could apply :-(.

Comment 8

[Boris Zbarsky [:bzbarsky]]

You are trying to solve the following equations for the width of the div (d) and
the table (t):

d = 100%*t    (width: 100%)
t = d + 40    (40px of padding)

No solutions exist.  The rest follows.

Comment 9

[Ruslan Ismailov]

Sorry, I could not understand what I see in nsCSSRendering

There is 2 differentc DrawDashedSides!

521 void nsCSSRendering::DrawDashedSides(PRIntn startSide,
755 void nsCSSRendering::DrawDashedSides(PRIntn startSide,

Which one used?

And similar function 

984 void nsCSSRendering::DrawDashedSegments(nsIRenderingContext& aContext,

Comment 10

[Boris Zbarsky [:bzbarsky]]

You can trace the code from nsCSSRendering::PaintBorder().  Looks like the one
on line 755 is called (and the other one is dead code, possibly).

I looked some more... the code on line 787 that does:

  // find the x and y width
  nscoord xwidth = aDirtyRect.XMost();
  nscoord ywidth = aDirtyRect.YMost();

looked suspect.  If I  borderInside instead of aDirtyRect things work just dandy.

So this sounds like a dup of one of roc's bugs on invalidation being screwy in
this situation?  Or is this code just wrong?

Comment 11

[Ruslan Ismailov]

Boris, I think this code wrong! look two line up:

782   // XXX Unused variables
783   nscoord xstart = PR_MAX(aDirtyRect.x, borderInside.x);
784   nscoord ystart = PR_MAX(aDirtyRect.y, borderInside.y);
785 
786   // find the x and y width
787   nscoord xwidth = aDirtyRect.XMost();
788   nscoord ywidth = aDirtyRect.YMost();

So in xstart is borderInside.x, than xwidth is meaningless.

Comment 12

[Ruslan Ismailov]

More precisely, there is (xstart is not use, but...)

923           temp = borderOutside.XMost();
<adjust code>
945           if( temp > xwidth)
946             temp = xwidth;

so if border could not go thorough aDirty size.

BTW. height 100% is not good to.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yeah, well... as I understand it, things are not supposed to paint outside of
the dirty rect.  So either I understand correctly and the dirty rect is wrong,
or I understand incorrectly and this code is wrong.  Since roc is the guy who'd
know, I'd like to see what he says.

Comment 14

[Ruslan Ismailov]

Attachment: heigh: 100% problem with border

I want to ask, is this example linker with this bug, or it is different one and
I should made another one? I realy think that this one linked, but I not sure.

Comment 15

[Mike Cowperthwaite]

What sort of 'qawanted' is desired for this bug?

http://bugzilla.mozilla.org/attachment.cgi?id=111485&action=view
  Appears to display OK in 1.3 final and 1.4a.

http://bugzilla.mozilla.org/attachment.cgi?id=111491&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=111537&action=view

  These both display OK in 1.3 final and 1.4a, ASSUMING the padding is added
to the declared size of the DIV, rather than providing a minimum spacing
between the DIV's edges and the inner content's text box (which is how Opera 7
is handling them, incorrectly IMO).

I don't see *any* dotted borders at Bernie's site, so I guess the page design
has changed.

Comment 16

[Boris Zbarsky [:bzbarsky]]

I think in this case the QA that is wanted is to find the bug it's a dup of, if
any.... ;)

Comment 17

[Bernie Zimmermann]

Looks like simplicity sometimes just makes things harder.  This is still a bug
in 1.3 final.  You may not see any dotted 1px divs on my site anymore, but the
problem is clearly evident.  I am using validated CSS and you can see how the
outer-right edge of my website (which should be flush with the content and
header image) is jagged thanks to the incorrect widths of the divs that contain
"Here," "There," "Everywhere," etc.

Also notice that the inner-right edge (of the divs containing the post dates)
expand too far to the right as well.  They should be flush with the main post
content.

Take a look at http://www.pleasureunit.com/bernie/ in Internet Explorer and
Opera 7 and you'll see how flush and symmetrical the site is.  Then look at the
page in Mozilla 1.3 or Phoenix and you'll clearly see the problem.

Basically the way I've got it setup is you've got an outer div (torso) that is
set to 65% of the window in width.  Then you've got two divs inside that div,
body and arm, set to 75% and 23% widths respectively (on the assumption that
they have 100% of the torso div to work with).  I started with 25% instead of
23%, but tried to compensate a bit since Mozilla was rendering the widths like
they were set to 80% and 30%.  Obviously this doesn't add up, and is why the
page gets skewed.

Comment 18

[Boris Zbarsky [:bzbarsky]]

> you can see how the outer-right edge of my website (which should be flush with
> the content and header image) is jagged thanks to the incorrect widths of the
> divs that contain "Here," "There," "Everywhere," etc.

I just loaded the site... it looks straight.  I laid a ruler along the right
edges of the divs to make sure -- they all line up (linux build 2003-03-26-08).

Comment 19

[Bernie Zimmermann]

I sure hope you're right, Boris.  I'll get a more recent build than the one I
have now [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3)
Gecko/20030312] and I'll respond back here with what I find out.

Comment 20

[Bernie Zimmermann]

Attachment: Screenshot of incorrect DIV behavior in Mozilla 1.4a (Win32)

This is what I am seeing in Mozilla 1.4a

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

The right ends of these divs are extending beyond what their right bound should
be.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Oh, is that what you mean?  You have:

div.title {
 width: 100%;
 border-bottom: 1px solid #8292D4;
 background: #3D4A98;
 padding: 5px;
 font: bold 8pt Verdana, Arial;
}

This means: "Make this 100% of the parent width.  Give it 5px padding".  That
means that it will overflow the parent by 10px horizontally.  Similar issue for
the titlebox class.

IE/Windows has a bug in its box model -- see
http://www.tantek.com/CSS/Examples/boxmodelhack.html (authored by the technical
lead of the MacIE team, btw).  Opera 7 copies that bug in quirks mode (which
your page triggers, being HTML 4.01 transitional with no doctype URI).

The original problem with this bug was that overflowing borders were not
painting correctly.  Bernd fixed that some time ago, however.  I never imagined
that you thought the layout incorrect; I assumed it was what you wanted, since
your CSS clearly specified it.

Comment 22

[Bernie Zimmermann]

Boris, thanks for bringing this to my attention.  I wasn't aware that the W3C 
had set forth such an illogical use of the box model.  Fortunately it sounds 
like in CSS3 we'll be able to specify which one we more heavily believe in 
(border-box or content-box).  Until then, at least I know I need to research 
some hacks to *try* and take care of the problem.

I think we've drifted off the topic of this bug anyway, as it sounds like the 
border gap problem has been fixed.  That's good news!  Thanks again.