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)

x86
All
defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: shashi, Assigned: karnaze)

References

()

Details

(Keywords: css2, testcase, Whiteboard: [TESTCASE] shashi@narain.com)

Attachments

(1 file)

Detailed comments and testcases to follow in a few minutes.
Whiteboard: [TESTCASE] shashi@narain.com
Target Milestone: M11
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).
Assignee: troy → karnaze
Component: Layout → HTMLTables
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>&nbsp;</p></td> Remove them and the gray lines go away.
Attached file reduced test case (deleted) —
QA Contact: petersen → chrisd
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
Adding CSS 2 to summary.
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
mass move to m14.
Keywords: css2
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...
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Target Milestone: M14 → M16
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.
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).
Summary: {css2} Dynamic adjustment of the CSS2 clip property is causing rendering problems → Dynamic adjustment of the CSS2 clip property is causing rendering problems
Moving to M18.
Target Milestone: M16 → M18
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
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."
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.
FIXED
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Since this bug is fixed, I am removing the testcase from my server.
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
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.
Verified fixed per reporter comments
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: