Closed
Bug 176237
Opened 22 years ago
Closed 10 years ago
Right or bottom borders sporadically disappear or lose a pixel of width in some cases
Categories
(Core Graveyard :: GFX, defect, P1)
Core Graveyard
GFX
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: emeyer, Assigned: kmcclusk)
References
Details
(Keywords: testcase, Whiteboard: [Hixie-P1])
Attachments
(2 files)
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•22 years ago
|
||
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•22 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
Reporter | ||
Comment 5•22 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•22 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
Updated•22 years ago
|
Whiteboard: [Hixie-P1]
Comment 9•22 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•22 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. ***
Blocks: 188468
*** Bug 193697 has been marked as a duplicate of this bug. ***
*** Bug 164832 has been marked as a duplicate of this bug. ***
Comment 18•22 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. ***
Depends on: 63336
Comment 20•22 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•22 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•21 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•21 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/).
Comment 28•21 years ago
|
||
*** Bug 215043 has been marked as a duplicate of this bug. ***
Comment 29•21 years ago
|
||
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•20 years ago
|
||
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•18 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•17 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•17 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?
No.
Updated•16 years ago
|
Product: Core → Core Graveyard
Comment 42•10 years ago
|
||
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
Closed: 10 years ago
Resolution: --- → WONTFIX
Comment 43•10 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)
Updated•10 years ago
|
Flags: needinfo?(gphemsley)
Comment 44•10 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•10 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.
Description
•