Right or bottom borders sporadically disappear or lose a pixel of width in some cases

RESOLVED WONTFIX

Status

P1
normal
RESOLVED WONTFIX
16 years ago
4 years ago

People

(Reporter: emeyer, Assigned: kmcclusk)

Tracking

({testcase})

Trunk
Future
testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P1])

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 103856 [details]
Testcase showing a missing border (at least on my machine)

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...

Comment 4

16 years ago
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
Keywords: testcase
OS: Mac System 9.x → All
Priority: -- → P3
Hardware: Macintosh → All
(Reporter)

Comment 5

16 years ago
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.)

Comment 6

16 years ago
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.
Summary: Right borders sporadically disappear on relatively positioned inline elements → Right or bottom borders sporadically disappear in some cases
Whiteboard: [Hixie-P1]

Comment 9

16 years ago
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.
Assignee: position → kmcclusk
Component: Layout: R & A Pos → GFX Compositor
QA Contact: madhur → petersen
(Assignee)

Updated

16 years ago
Priority: P3 → P1
Target Milestone: --- → Future
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. ***

Comment 18

16 years ago
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. ***

Comment 20

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

Comment 21

16 years ago
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. ***
Summary: Right or bottom borders sporadically disappear in some cases → Right or bottom borders sporadically disappear or lose a pixel of width in some cases
*** Bug 221007 has been marked as a duplicate of this bug. ***

Comment 26

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

Comment 27

15 years ago
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. ***

Comment 33

14 years ago
Created attachment 168047 [details]
A simple XUL testcase displaying the problem


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.

Comment 36

12 years ago
WFM on reflow branch build. Somebody please add "[reflow-refactor]" to status whiteboard.
A particular testcase may be, but the underlying cause isn't.
Depends on: 287624

Comment 38

11 years ago
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.

Comment 40

11 years ago
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?
Product: Core → Core Graveyard
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]
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX

Comment 43

4 years ago
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
Flags: needinfo?(gphemsley)
Flags: needinfo?(gphemsley)

Comment 44

4 years ago
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
Flags: needinfo?(gphemsley)

Comment 45

4 years ago
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
Flags: needinfo?(gphemsley)
You need to log in before you can comment on or make changes to this bug.