Closed Bug 422661 Opened 15 years ago Closed 15 years ago
Long border is rendered incompletely
632 bytes, patch
|Details | Diff | Splinter Review|
4.55 KB, text/html;charset="iso-8859-1"
182 bytes, text/html
697 bytes, text/html
1.97 KB, text/html
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:18.104.22.168) Gecko/20080201 Firefox/22.214.171.124 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:126.96.36.199) Gecko/20080201 Firefox/188.8.131.52 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.
See example there: http://forum.mozilla-russia.org/uploaded/test4bug.xpi If delete folder with images - this problem disappear!
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.)
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: 15 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.
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
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:184.108.40.206) Gecko/2008070208 Firefox/3.0.1 ID:2008070208 (Fixed by bug 368247 perhaps?)
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?
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
testcase 2 fails in Fx 3.0.1 only locally, the uploaded file works... hmm
(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: 15 years ago → 15 years ago
Resolution: --- → FIXED
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 :)
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.