Open
Bug 51678
Opened 24 years ago
Updated 2 years ago
clip: rect(...) property with bad values is inconsistent between platforms
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
NEW
People
(Reporter: ian, Unassigned)
Details
(Keywords: css2, platform-parity, testcase, Whiteboard: relnote-devel [nsbeta3-] (py8ieh: work out which page caused me to file this bug, and fix it!))
Attachments
(2 files)
The 'clip' property seems to work fine on Windows 2000, but on Linux and Macs it just hides everything when set. Tested with the 2000090608 comm builds. See testcase. Nominating for nsbeta3 as this is a *major* bug with our clip support (it basically kills the clip property in fact), and it works fine on one third of our tier 1 platforms.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Updated•24 years ago
|
Priority: P3 → P2
QA Contact: petersen → py8ieh=bugzilla
Reporter | ||
Comment 2•24 years ago
|
||
cc'ing beard, kevin, robert -- this is a major platform parity bug with clip. Do we know about it? Is it a problem with the GFX layer? Can we fix it? ;-)
Comment 3•24 years ago
|
||
I'm getting the following assertions on WinNT and Linux when viewing the testcase: ###!!! ASSERTION: bad clip values: 'aLeft <= aRight && aTop <= aBottom', file s:\mozilla\view\src\nsView.cpp, line 654 ###!!! ASSERTION: bad clip values: 'aLeft <= aRight && aTop <= aBottom', file s:\mozilla\view\src\nsView.cpp, line 654 After, the rendering is correct on NT and wrong on Linux. Sending to Kevin to check out - it seems like a platform-specific clipping problem to me...
Assignee: clayton → kmcclusk
Comment 4•24 years ago
|
||
The clip: property does not appear until css2. Changing css1 keyword to css2 The current implementation on WIN32 is working but the interpretation of the rect values appears to be incorrect. The spec indicates that the rect specifies offsets from the outside of the box. The WIN32 implementation is interpreting the rect values as rect(left, top, width, height).
The behavior has been changed. Check the CSS2 errata. I think Mozilla's interpretation is now correct WRT the errata, and it's "rect(top, right, bottom, left)". That's was a rather dumb move if you ask me, but no-one did :-).
I believe that, in fact, this testcase is invalid. I'll attach another testcase...
Comment 8•24 years ago
|
||
Thanks Robert: I see that we DO match the CSS2 errata, and the original test case is incorrect. With your new test case it works correctly on both WIN32 and Linux.
Comment 9•24 years ago
|
||
Changing summary from: clip: rect(...) hides everything on Linux and Macs to: clip: rect(...) property with bad values is inconsistent between platforms I could condition the rect in nsView::SetChildClip so it behaves consistently between platforms, but attinasi@netscape.com wants to look at the possibility of catching the bad values when the property is parsed (This would allow us to provide feedback to the author) Changed component to Style System. Marking nsbeta3-. Reassigning to attinasi@netscape.com
Assignee: kmcclusk → attinasi
Component: Layout → Style System
Summary: clip: rect(...) hides everything on Linux and Macs → clip: rect(...) property with bad values is inconsistent between platforms
Whiteboard: [nsbeta3-]
Comment 10•24 years ago
|
||
I need to look at the CSS requirements on parsing a rect - namely, can we enforce that the rect never has a negative height or width, or does each property have its own independent restrictions? In either case, the CSSParser can deal with illegal rect values (per property if required) and can throw the rule away.
Status: NEW → ASSIGNED
Comment 12•24 years ago
|
||
Cleaning up the keywords, priority, severity, and platforms. In particular, I removed the dataloss keyword because we don't lose data if the rect is valid.
Severity: major → normal
Keywords: dataloss
OS: Linux → All
Priority: P2 → P3
Hardware: PC → All
Target Milestone: --- → M19
Reporter | ||
Comment 13•24 years ago
|
||
bah, the spec changes so often that I got all confused!!! Sorry about that.
Whiteboard: [nsbeta3-] → [nsbeta3-] (py8ieh: work out which page caused me to file this bug, and fix it!)
Comment 14•24 years ago
|
||
Moving out to future: still need to investigate to see if this is INVALID or not, but later.
Target Milestone: M19 → Future
Updated•24 years ago
|
Whiteboard: [nsbeta3-] (py8ieh: work out which page caused me to file this bug, and fix it!) → relnote-devel [nsbeta3-] (py8ieh: work out which page caused me to file this bug, and fix it!)
Comment 15•24 years ago
|
||
Adding myself to cc. Since that in all platforms I have tested since and including Netscape 6, Mozilla clip:rect property is not working. All becomes invisible. Not tested with Win2000. But all pages with style="clip:rect(,,,,)" are not working. My note is here because I am investigating workaround, if you know some workaround please e-mail me. Working on a document to help web developers make pages with clipping in Netscape 6 and Mozillas.
Comment 16•23 years ago
|
||
Thanks Robert and sorry to all, my last comments I was not updated with the Errata and right now I am tuned and also saw Robert's notes about the CSS errata. I am updating all demostrations that are published at http://www.mozilla.org/docs/dom/samples/ that are using CSS clip, because it looks like there is a problem with clip. I'll be evangelizing at geckonnection.com also about the correct way to use clip.
Comment 17•23 years ago
|
||
IIUC, the content author workaround for this bug is simply to avoid using incorrect values, yes? Not nominating for nsbeta1 based on this assumption; please nominate for nsbeta1 if I've misunderstood this.
Comment 18•21 years ago
|
||
> but attinasi@netscape.com wants to look at the possibility of catching the bad
> values when the property is parsed
That's impossible to do since the rect validity depends on things like the
computed font size if relative size units are used.
Perhaps the layout code that actually sets the clip rect could look at the
computed values and set the rect's size to 0 if rect.IsEmpty() tests true?
Comment 19•21 years ago
|
||
.
Assignee: attinasi → roc+moz
Status: ASSIGNED → NEW
Component: Style System → Layout: View Rendering
Priority: P3 → --
Target Milestone: Future → ---
Comment 20•17 years ago
|
||
The behavior here should be consistent now. Could someone test on Linux?
Updated•15 years ago
|
QA Contact: ian → layout.view-rendering
Assignee: roc → nobody
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•