Closed
Bug 14350
Opened 25 years ago
Closed 24 years ago
Dynamic adjustment of the CSS2 clip property is causing rendering problems
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: shashi, Assigned: karnaze)
References
()
Details
(Keywords: css2, testcase, Whiteboard: [TESTCASE] shashi@narain.com)
Attachments
(1 file)
(deleted),
text/html
|
Details |
Detailed comments and testcases to follow in a few minutes.
Reporter | ||
Updated•25 years ago
|
Whiteboard: [TESTCASE] shashi@narain.com
Target Milestone: M11
Reporter | ||
Comment 1•25 years ago
|
||
The following comments are based on the 09-18 build for Linux and Win32.
Testcase 1 (http://www.narain.com/gecko/testcases/test10.html)
With this testcase, the page renders correctly. This page should be used to
compare to what happens in testcase 2.
Testcase 2 (http://www.narain.com/gecko/testcases/test11.html)
The code used in this testcase is identical to the one used in testcase 1
without the exception of two things. Firstly, the CSS section contains
clip: rect(0px, 300px, 0px, 300px) and overflow: hidden This effectively hides
the object when the page is first loaded. Secondly, I have added a JS function
that performs a DHTML pseudo-transition that manipulates the clip property to
make the object visible via the onLoad handler contained within the <body> tag.
The table that appears in this testcase renders a gray border around all the
cells in Win32. In Linux, the border appears as a ridge. These extra borders
should not appear (as compared to testcase 1).
Chris, I narrowed the test case down and determined a few things:
1. it has nothing to do with absolute positioning (my reduced case doesn't use
it)
2. it's not an incremental painting problem. Notice that covering up the window
doesn't fix it, and neither does resizing the window
3. it seems that the gray vertical lines are because of the two table cells that
are defined like this:
<td width="25"><p> </p></td>
Remove them and the gray lines go away.
Updated•25 years ago
|
QA Contact: petersen → chrisd
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Summary: Dynamic adjustment of the CSS2 clip property is causing rendering problems → [CSS 2] Dynamic adjustment of the CSS2 clip property is causing rendering problems
Target Milestone: M11 → M12
Assignee | ||
Comment 4•25 years ago
|
||
Adding CSS 2 to summary.
Updated•25 years ago
|
Summary: [CSS 2] Dynamic adjustment of the CSS2 clip property is causing rendering problems → {css2} Dynamic adjustment of the CSS2 clip property is causing rendering problems
Assignee | ||
Comment 5•25 years ago
|
||
mass move to m14.
Comment 6•25 years ago
|
||
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Comment 7•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14 → M16
Reporter | ||
Comment 8•25 years ago
|
||
These comments are based on the 02-03-08-M14 build for Linux...
Using this build I saw that the gray borders have disappeared :-) I am very
curious to know if this bug has been fixed since Bugzilla informed me that the
target had been moved from M14 to M16.
I am going to give this bug a spin using the same build on a Win98 box to see if
it has been fixed on that end.
Reporter | ||
Comment 9•25 years ago
|
||
These comments are based on the 02-03-10-M14 build for Win32...
Just run this bug through my Win98 box and saw that the gray borders are no
longer showing up (just like Mozilla's Linux counterpart).
Updated•25 years ago
|
Summary: {css2} Dynamic adjustment of the CSS2 clip property is causing rendering problems → Dynamic adjustment of the CSS2 clip property is causing rendering problems
Assignee | ||
Comment 11•24 years ago
|
||
This bug has been marked "future" because we have determined that it is not
critical for netscape 6.0. If you feel this is an error, or if it blocks your
work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M18 → Future
Reporter | ||
Comment 12•24 years ago
|
||
karnaze@netscape.com wrote:
>This bug has been marked "future" because we have determined that it is not
>critical for netscape 6.0.
Taken at face value, this is a very disturbing statement. Putting the actual bug
aside, I find it rather insulting that a bug marked against Mozilla is now
equated to be against Netscape 6.0. I am not here for the benefit of Netscape's
branded distribution of Mozilla (and if I were I would expect to get paid for
it).
Take a look at Bugzilla's home page: "This is not the place to report bugs about
commercial Netscape products. For that, try Netscape's own bug reporting form
instead."
Comment 13•24 years ago
|
||
If you wish to fix the bug, you are welcome to -- all Chris Karnaze is saying is
that Netscape have decided that they are not going to be spending their own
resources fixing this bug before they release their Netscape 6.0 product which
will be based on Mozilla.
Reporter | ||
Comment 14•24 years ago
|
||
FIXED
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 15•24 years ago
|
||
Since this bug is fixed, I am removing the testcase from my server.
Comment 16•24 years ago
|
||
Shasai, is it possible you can attach your testcases to this bug? It's
unfortunate you removed them from your server as we could really use them to
verify this bug is indeed fixed. :-) Thanks! -ckritzer
Reporter | ||
Comment 17•24 years ago
|
||
I removed the testcases because 1) this bug has not re-appeared since I
commented on it on Feb 4. It is very safe to say that this bug has been fixed
(if it ever comes back I can always re-open this bug) 2) Troy has attached a
much better testcase that simplies the problem. No point keeping dups around on
my machine.
You need to log in
before you can comment on or make changes to this bug.
Description
•