Closed
Bug 363220
Opened 18 years ago
Closed 18 years ago
non-dotted non-1px borders sometimes drawn offset 1 pixel to the left (pixel snapping in FillPolygon?)
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
FIXED
People
(Reporter: ori, Unassigned)
References
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1
As seen in the test-case, the first div is displayed correctly but the second div has it's top and bottom borders shifted to the right.
The only difference between the left and right div, is that the first is inside a container div with width: 30% (rendered correctly), and the second one is inside a div with width: 70%
Reproducible: Always
Steps to Reproduce:
See testcase
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
The bug occurs in the trunk, but not in Firefox 2.0
Comment 3•18 years ago
|
||
Is this a recent regression?
Reporter | ||
Comment 4•18 years ago
|
||
I noticed that the yellow line on the right is clearly visible on the 2006-04-22 build and not visible on the 2006-04-21 build.
bug 328241 is probably at fault.
I also noticed that the 2006-04-21 build has other problems when displaying the testcase. To the right and the left of each of the 6 colored blocks there is a 1-pixel column of "faded" color.
Updated•18 years ago
|
Blocks: 328241
Status: UNCONFIRMED → NEW
Component: Layout → GFX: Thebes
Ever confirmed: true
QA Contact: layout → thebes
Comment 5•18 years ago
|
||
I'm guessing that there's something wrong with the pixel-snapping code for FillPolygon, actually. I have another testcase that I'll attach.
dotted borders, 1px solid borders, background colors, and tiled background images all seem consistent in how they pixel-snap, but wider solid borders don't match.
Summary: top, bottom borders drawn offset 1 pixel to the left of the element → non-dotted non-1px borders sometimes drawn offset 1 pixel to the left (pixel snapping in FillPolygon)
Comment 6•18 years ago
|
||
Updated•18 years ago
|
Flags: blocking1.9?
Summary: non-dotted non-1px borders sometimes drawn offset 1 pixel to the left (pixel snapping in FillPolygon) → non-dotted non-1px borders sometimes drawn offset 1 pixel to the left (pixel snapping in FillPolygon?)
Depends on: 368247
Comment 8•18 years ago
|
||
I tried making an equivalent testcase for top/bottom borders and couldn't find any problems.
Comment 9•18 years ago
|
||
For what it's worth, this doesn't happen on Windows, so it's probably actually a lower-level problem. It's hard to tell whether it happens on Mac given bug 361523.
Comment 10•18 years ago
|
||
Er, it does happen on Windows. I think I was testing in IE :-(.
OS: Linux → All
Hardware: PC → All
Comment 11•18 years ago
|
||
this looks a bit like bug 369864 to me, although that one is said to be a regression of bug 177805.
Will be fixed by bug 368247 (in my tree).
Flags: blocking1.9? → blocking1.9+
Fixed by patch for bug 368247.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Flags: in-testsuite?
Comment 15•18 years ago
|
||
I still see what looks like the same problem in the following build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070514 Minefield/3.0a5pre
but only inside a table having border-collapse: collapse.
I will attach a test case where varying windows width the border of a table cell is sometimes drawn 1px to the left.
Comment 16•18 years ago
|
||
shows the problem in Gecko/20070514 Minefield/3.0a5pre
Comment 17•18 years ago
|
||
(In reply to comment #15)
> I still see what looks like the same problem in the following build:
>
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070514
> Minefield/3.0a5pre
>
> but only inside a table having border-collapse: collapse.
> I will attach a test case where varying windows width the border of a table
> cell is sometimes drawn 1px to the left.
>
Please file a new bug.
You need to log in
before you can comment on or make changes to this bug.
Description
•