443683 - Border is not rendered properly(rendered in black, partial border, position/color changes upon scroll), if border-right(top/bottom/left)-color is additionally specified for block of large hight with border-style:solid

Status: RESOLVED DUPLICATE of bug 422661

(Core :: Layout, defect)

Description

[WADA:World Anti-bad-Duping Agency]

Attachment: Test casse(HTML) with border-style:solid + border-right-color for <P>

This is spin-off of phenomenon/issue of Bug 422661 Comment #17.

Border is not rendered properly, if border-right(top/bottom/left)-color is additionally specified for block of large hight with border-style:solid.
1. Rendered in black. But in some cases, partially rendered in expected color.
2. Partial border is rendered(problem of Bug 422661).
3. Multiple partial borders(short vertical borders in black) when large hight.
   (probably problem of Bug 441900) 
4. When the "short vertical border in black" is placed at bottom of the block,
   and border-bottom is rendered properly in expected color,
   rendering at top position of the block becomes funny.
   (Example in Case-1, 1640 lines case)
   (4-1) When top part of the block is displayed in window :
         (A) Black virtial border appears when down-arrow kei is pressed
         (B) When window width is changed, Black vertical border appears
         (C) (A) & (B) repeats until line 2 is placed at top of window
   (4-2) When top part of the block is not displayed in window(line 2 is top) :
         (D) When window width is changed, black vertical border appears
         (E) When scrolled to top, black vertical border from line 2 is seen
   Similar phenomenon is seen in case-4 to 7, with colored border at top part.

Comment 1

[WADA:World Anti-bad-Duping Agency]

I forgot to add <meta ...charset> in HTML, so different charset such as utf-8 may be used. And, test result depends on charset/font/font-size because test result depends on "hight of paragraph".
(4-1)/(4-2) with Case-1 was observed when iso-8859-1/Times New Roman/16. When utf-8/arial(probably), (4-1)/(4-2) may be seen with Case-5/6 only.
Sorry for confusing test case.

Comment 2

[Simon Montagu :smontagu]

(In reply to comment #1)
> I forgot to add <meta ...charset> in HTML, so different charset such as utf-8
> may be used.

For future reference: by default bugzilla.mozilla.org serves HTML attachments with charset=UTF-8 specified in the HTTP Content-Type header, so <meta ... charset> doesn't make any difference on its own anyway. You can specify a different charset in the MIME Type field, either when creating the attachment or by editing the field after upload.

In this case the attachment seems to be pure ASCII anyway, so UTF-8 is a fine charset for it :)

Comment 3

[WADA:World Anti-bad-Duping Agency]

Thanks for guidance. I added charset=iso-8859-1 to the attachment, because font choice when utf-8 seems to depend on environment. (On Japanese MS Win, font set in "Japanese" is used by Firefox when utf-8, instead of one in "Western".)
(A) Western,Serif/Times New Roman/16: (4-1)/(4-2) is observed with Case-2/4/5/6/7 
(B) Western,Sans-serif/Arial/16     : (4-1)/(4-2) is observed with Case-5/6/8

Comment 4

[WADA:World Anti-bad-Duping Agency]

Attachment: Test case(HTML), with changeable line number in <P>

This new test case executes;
  Inserts N,N+1,...,N+7 "nnnn<BR>" in eight <P>'s by p_obj.innerHTML,
  for which border-style:solid + border-right-color is specified.
It's to see following phenomenon.
  Border color issue(rendered in black) starts to occur at different box hight
  from (larger box height than) box hight where "partial border/border
  position/border length" issue (upon initial rendering and upon scrolling)
  starts to occur.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Following is test result with Fx latest trunk on MS Win XP SP2. 
(A) 1614 is specified (font setting : Western,Serif,Times New Roman/16)
    1699 is specified (font-setting : Western,Sans-Serif,Arial/16)
   A-1) Change num of lines => border is not rendered at top part of box
   A-2) Scroll to bottom by Ctrl+End
        => Bottom part of box is rendered in expected color.
           No problem in scroll by up/down arrow or page up/page down at bottom.
   A-3) Scroll to top by Ctrl+Home
        => Border at top part of box is not rendered
        => Border is rendered when scrolled by up/down arrow
   A-4) When A-2)/A-3 is repeated, same phenomenon can be observed
(B) 1638 is specified (font setting : Western,Serif,Times New Roman/16)
    1724 is specified (font-setting : Western,Sans-Serif,Arial/16)
   B-1) Change num of lines => border is not rendered at top part of box
   B-2) Scroll to bottom by Ctrl+End
        => Bottom part of box is rendered in black(left/right) or red(bottom)
        => Scroll by up/down arrow key
           => black border is cut-off, border-bottom is not rendered
   B-3) Scroll to top by Ctrl+Home
        => Border at top part of box is not rendered
        => Border is rendered in black when scrolled by page up/page/down
        => Border is rendered in black when scrolled by up/down arrow,
           but border starts from different position form page up/page down
   B-4) When B-2)/B-3 is repeated, same phenomenon can be observed

Comment 6

[WADA:World Anti-bad-Duping Agency]

(C) 3276 is specified (font setting : Western,Serif,Times New Roman/16)
    3448 is specified (font-setting : Western,Sans-Serif,Arial/16)
   C-1) Change num of lines => border is partially rendered at top part of box
        (It's for 3276(3448)+1 to 3276(3448)+7 lines cases.)
        (When 3276/3448 line case, none of border is rendered.)
        (Possibly rendered in "White".)
   C-2) Scroll to bottom by Ctrl+End
        => Bottom part of box is partially rendered in proper color
        => Scroll by up/down arrow key or page up/down key
           => nothing happens
   C-3) Scroll to top by Ctrl+Home
        => Border at top part of box is partially rendered in proper color
        => Border is rendered in black partailly when scrolled by up/down arrow,
           or page up/dow key. Rendered part length is nor changed in this case.
   C-4) When C-2)/C-3) is repeated, same phenomenon can be observed

In this case, it looks to be rendered as ;
 - (1.partial at top) + (2.fixed length "White" border) + (3.partial at bottom)
 - Length/position of (1.partial at top)/(3.partial at bottom) is not changed
   upon scroll
 - Length of black portion in (1.partial at top) varies upon scroll.

Several different limitations/corruptions seem to become visible by border-right-color change. 

Comment 7

[WADA:World Anti-bad-Duping Agency]

I've met Bug 424423 today. Bug 424423 Comment #4 says following, although the bug is mainly for performance issue in border rendering.
> A lot of people will see this problem (of slow and jerky scrolling) ...
Setting dependency.

Comment 8

[WADA:World Anti-bad-Duping Agency]

FYI.
I met Bug 378217 also, which is for issues in "css3 'border-image'" support.
It possibly has relation to this bug's problem.