See the forthcoming testcase for an example. What I'm seeing is that relatively positioned inline elements can lose their right border, depending on the padding and margins of inlines within the relatively positioned inline. It also seems like the margins of the relative inline can affect whether or not a border disappears. If you fiddle with values, borders can come and go. I have seen this in several builds, including 2002102208-trunk/Mac.

Changing the font and font size in the CSS doesn't seem to affect the presence of absence of a right border. I can supply a screenshot if other people don't see the same problem.

I see the problem on cl2 instead of cl1. In any case, does this seem like it could be some rounding problem with view sizes? (If you use a 2px border, does the whole thing not show up, or just one pixel of it?)

It seems like it is just one pixel cut off, but I can't get it to seem like a rounding problem by testing various 'width' numbers on blocks...

on win2k and redhat linux 7.2 :- i see the missing right border on 'c11' on macOS 10.1 :- i see the missing right border on 'c12' adding KW : testcase

Interesting, I saw the missing right border on 'cl1' in MacOS9.1. It may be font-related after all; I set my default font to Times New Roman/16 in the Preferences, which I think is different than the shipping defaults. (Or maybe not.)

Seeing it on cl1. Zooming, and I see it on cl2. I have a similar problem on http://www.student.lu.se/~kin02ndo/, where a complicated 1px border would sometimes vanish. With 2px, it either shows as 1px or 2px. It also depends on the size of the window, as resizing changes the conditions. Definitely a round-off thing. In a calculus with a total of x em + y px + z %, the px values must be preserved at all cost.

*** Bug 176632 has been marked as a duplicate of this bug. ***

Retitling bug to reflect the duplicate and the uncertainty of the conditions that actually cause the problem.

I see the problem with the test in both Mozilla 1.1 as well as on the trunk. I'm seeing what looks like this bug in my blog (http://www.pavlov.net/blog/) in the sidebar which is floated.

->Compositor.

This is probably a duplicate of bug 63336, but I'm not sure.

*** Bug 179551 has been marked as a duplicate of this bug. ***

*** Bug 171571 has been marked as a duplicate of this bug. ***

*** Bug 184709 has been marked as a duplicate of this bug. ***

*** Bug 187262 has been marked as a duplicate of this bug. ***

*** Bug 193697 has been marked as a duplicate of this bug. ***

*** Bug 164832 has been marked as a duplicate of this bug. ***

2003-03-26-04trunk build on winXP 2003-03-24-08trunk build on macos10.1 tested attachment 103856 [details] .... all the bottom borders are visible. fixed ?

*** Bug 199935 has been marked as a duplicate of this bug. ***

I've also seen some table borders not print when scaled to less than 100%. (FizzillaMach/2003032808, maps.yahoo.com "Printable Version.")

The testcase is no longer causing problems for me (Camino Build ID: 2003040705), but the bug still does exist. I have this problem when visiting http://www.toomuchsexy.org/

*** Bug 211701 has been marked as a duplicate of this bug. ***

*** Bug 215022 has been marked as a duplicate of this bug. ***

*** Bug 216295 has been marked as a duplicate of this bug. ***

*** Bug 221007 has been marked as a duplicate of this bug. ***

Still open. Try http://tranchant.plus.com/ and press Ctrl-minus. Bottom border on menu box disappears for me (Firebird 0.7, Win2k).

An ugly demonstration of (perhaps) this bug appears when resizing a "Week View" (the default) in Mozilla calendar. At certain window heights some of the horizontal grid lines disappear. The vertical lines seem OK though. I'm running Mozilla 1.6 on Win32 with the Jan 9th calendar XPI installed (http://www.mozilla.org/projects/calendar/).

*** Bug 215043 has been marked as a duplicate of this bug. ***

I don't see this issue in the given testcase, but in the testcase from bug 215043 which I duped against this bug. There the borders are painted wrong with 100% and 90% text-size, but correctly when using 75% or 120% text-size.

*** Bug 234407 has been marked as a duplicate of this bug. ***

*** Bug 256697 has been marked as a duplicate of this bug. ***

*** Bug 261964 has been marked as a duplicate of this bug. ***

Open the attached dialog using openDialog('chrome://foobar/content/test.xul', '','chrome,centerscreen,resizable'); A dialog with 4 rectangles appears. All the inner borders should be 2 pixels wide. Resize the dialog. Sometimes the inner borders are only 1 pixel wide, sometimes the two adjacent rectangles' borders are separated by a 1 pixel wide white space.

*** Bug 287233 has been marked as a duplicate of this bug. ***

This may be significantly improved on the trunk due to the changes in bug 173051.

WFM on reflow branch build. Somebody please add "[reflow-refactor]" to status whiteboard.

A particular testcase may be, but the underlying cause isn't.

is this still a problem? going by comment 33 I don't see anomalies Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007101605 Minefield/3.0a9pre

This should have been fixed by the patch to round border widths to the nearest pixel, I think.

oddly similar to bug 339673 - except it's the top border (In reply to comment #39) > This should have been fixed by the patch to round border widths to the nearest > pixel, I think. bug 63336?

No.

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]

This bug still happens, is relatively serious and ought to be reopened. I reported a bug for it that was marked as duplicate here: https://bugzilla.mozilla.org/show_bug.cgi?id=216295 . Just because there wasn't any activity, does not mean it does not exist. I feel strongly against the RESOLVED / WONT_FIX attitude - see: http://www.shlomifish.org/humour/fortunes/show.cgi?id=sharp-perl-resolved-wont-fix Regards, -- Shlomi Fish

Dear Mr. Hemsley, why did you remove my needinfo? note silently? This bug is real, still exists, and should be reopened. I realise people like me have a hard time motivating people, but I am kept being disappointed by the apathy that the Mozilla developers and the admins of bugzilla.mozilla.org show towards people who report bugs here, and the amount of helplessness people like me feel when reporting bugs here. Here are some cases for proper dialogues and for providing good customer service: * http://www.joelonsoftware.com/articles/customerservice.html * https://www.youtube.com/watch?v=uGDA0Hecw1k - Mike & The Mechanics - The Living Years. If you want people to continue to use Mozilla products and recommend it to their friends, please spend more time on communicating with them and closing their bugs. Otherwise, you're going to materialise Shaikeh Ofir’s English teacher's definition of monologue as "One person talking to himself" and dialogue as "Two persons talking to themselves" - see https://www.youtube.com/watch?v=2bpVrKm9QCc . Best regards, -- Shlomi Fish

Shlomi, sorry you are having trouble. I don't understand gphemsley's reasons for closing the bugs such as this because this is in the graveyard which means either the component or the type of issue related to this bug is "dead", as in the code is no longer supported or no longer exist in a current shipping product, but I don't think gphemsley is the person to address your problem. I suggest you undup your original bug (which is not in graveyard) from this one, unless other users speak up in this bug that they still see a problem