Closed Bug 422661 Opened 12 years ago Closed 11 years ago

Long border is rendered incompletely

Categories

(Core :: Layout: Tables, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: tim_tim2000, Assigned: vlad)

References

()

Details

(Keywords: regression)

Attachments

(5 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031205 Minefield/3.0b5pre

The problem was found by Forest from forum.mozilla-russia.org.
Searching for a bug to describe the problem, I have found the bug #228340, which is seemingly similar to this one.

Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 shows everything correctly.

Reproducible: Always

Steps to Reproduce:
1. Open the URL
2. Scroll down to the table's end

Actual Results:  
See no table border at the end of the table.

Expected Results:  
See the table border
Marking as a regression, asking for blocking1.9.
Flags: blocking1.9?
Keywords: regression
See example there: http://forum.mozilla-russia.org/uploaded/test4bug.xpi
If delete folder with images - this problem disappear!
Version: unspecified → Trunk
Bug also occurs on Mac. Probably a bug in the new border drawing code, possibly a gfx bug, but Vlad either way :-)
Assignee: nobody → vladimir
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Status: UNCONFIRMED → NEW
Ever confirmed: true
I create 2 new similar pages (publish it?) and don't reproduce this bug!
I don't find any rules.
Whoops!  This never got updated when we moved to 24.8 in cairo. (You'll notice in the testcase that the 5px border is actually rendered halfway down the test case -- at 16k pixels.)
Attachment #310060 - Flags: review?(roc)
I don't suppose there's a way to make the values actually depend on cairo's configuration?
Checked in.. can't do it at runtime (or even compile time), since the fixed point types are an internal implementation detail... even though they have a visible effect.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
I see the border fine on the Mac using the site in the URL with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008031904 Minefield/3.0b5pre. Using Win XP I can only see the table when I scroll the page, and when I get to the end I do not see a border.  
Depends on: 426933
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050810 Minefield/3.0pre

With this build on Windows Vista, the border is still rendered incompletely.  The top and bottom borders are not rendered.  To see the (incomplete) left and right borders, you should scroll down to the middle of the page.  It seems that the upper and lower parts of the vertical borders are not rendered correctly.  I'm reopening this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Given this is mostly working I'm taking off the blocker list..
Flags: blocking1.9+ → blocking1.9-
FWIW: Also does not work on Windows 2000.
(In reply to comment #10)
> Given this is mostly working I'm taking off the blocker list..

What is "mostly working"?
It fails on Windows at all (2000, XP, Vista) 

re-noming per comment 12.
Flags: blocking1.9- → blocking1.9?
I think Schrep meant that it's working for most testcases.
(In reply to comment #14)
> I think Schrep meant that it's working for most testcases.
> 

Yes - meant to say the impact of this bug doesn't seem to warrant blocking. 
Flags: blocking1.9? → blocking1.9-
Caused regression:

bug 434539
When border-style:solid(not 3D border) is set and border-right-color is additionally set, border-color issue is also observed(color is changed to black), in addition to partial border problem. And, if box height is taller, partially colored border is observed, and problem upon scrolling is also observed(length of colored part varies when scrolled. similar issue to bug 441900).

Case-0 : <table>, border-style:solid;
Case-1 : <table>, border-style:solid; + border-right-color
Case-2 : <p>,     border-style:solid; + border-right-color
Case-3 : <p>,     border-style:groove;

When border-style:solid(not 3D border), no problem occurs if additional border-(top/bottom/left/right)-(style/color) is not set.
(if border-(top/bottom/left/right)-width only, it works well)
"partial color and scroll related problem" was observed only when the test HTML was  held in local file. So "black color problem" only can be observed. Sorry for spam.
Note:
With test HTML attached to a bug of Bugzilla Japan(same test cases but slightly different HTML), "partial color and scroll related problem" was observed(10000 line case), with Fx trunk on MS Win-XP SP2, new profile.
> http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3814
I've opened Bug 443683 for problem of comment #17, because different phenomenon seems to be involved in "border-style:solid + border-right-color" case.
Attachment #328089 - Attachment mime type: text/html → text/html;charset="iso-8859-1"
Summary: Long table border is rendered incompletely → Long border is rendered incompletely
Duplicate of this bug: 433696
Duplicate of this bug: 429496
The test cases here and on the duplicates work for me on

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/2008072903 Minefield/3.1a2pre ID:2008072903

but still fail on

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 ID:2008070208

(Fixed by bug 368247 perhaps?)
Duplicate of this bug: 428910
1. This bug repros not only on tables, but also on all the elements, e.g. div, hr...
2. the exact repro condition is:
   a) element's width or height > 32767px
   b) the four borders have different styles
Albert, can you attach a testcase, that shows the bug in current trunk build?
Attached file testcase 2
testcase 2 works for me on current trunk (fx 3.0.1 fails)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080809033929 Minefield/3.1a2pre
Attachment #333412 - Attachment mime type: text/plain → text/html
testcase 2 fails in Fx 3.0.1 only locally, the uploaded file works... hmm
Duplicate of this bug: 450825
(In reply to comment #28)
> Albert, can you attach a testcase, that shows the bug in current trunk build?

I just tested on latest truck "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080817033619 Firefox/3.0.1"

It cannot repro .
Like bug 426933 this was fixed in starting in the 7-23 nightly on mozilla-central which looks like from bug 446323.
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → FIXED
Duplicate of this bug: 461508
Coming from bug 461508

Test-case there works for latest build minefield.

Attached is testcase where something very similar happens on latest build. Not sure if this is the same bug. I had to make the divs very tall indeed (about 8.4M pixels) to get the bug.

This time it's not just the div's borders that disappear, but the background-color as well. Workaround from that bug (shown in testcase) does not work.

I get the feeling I'm hitting some limit here on how tall a div can expect to get :)
Duplicate of this bug: 463025
Comment on attachment 349112 [details]
Partial Border Rendering on Tall DIV with Border on One Side

I see similar but different symptoms and I am curious if it is the same bug or a different one.

The DIVs are not exceptionally large in terms of the # of pixels, but they are tall. Borders on all 4 sides works, but on one side doesn't.
John, this Bug is fixed for Gecko 1.9.1 (Fx 3.1).
Don't expect it working in Fx 3.0.x
You need to log in before you can comment on or make changes to this bug.