clip: rect(...) property with bad values is inconsistent between platforms

NEW
Unassigned

Status

()

Core
Layout: View Rendering
18 years ago
8 years ago

People

(Reporter: Hixie (not reading bugmail), Unassigned)

Tracking

({css2, pp, testcase})

Trunk
css2, pp, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: relnote-devel [nsbeta3-] (py8ieh: work out which page caused me to file this bug, and fix it!))

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
Created attachment 14167 [details]
Simple and self explanatory testcase. Output should be green, not red.
(Reporter)

Updated

18 years ago
Keywords: 4xp, correctness, css1, dataloss, nsbeta3, pp, testcase
Priority: P3 → P2
QA Contact: petersen → py8ieh=bugzilla
(Reporter)

Comment 2

18 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

18 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
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).
Keywords: css1 → css2
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...
Created attachment 14610 [details]
Testcase: Correct use of CSS2 "rect" property as per the errata
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.

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

18 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
Added relnote keyword.
Keywords: relnote

Comment 12

18 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

18 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

18 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

17 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

17 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

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


 
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.
> 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?
.
Assignee: attinasi → roc+moz
Status: ASSIGNED → NEW
Component: Style System → Layout: View Rendering
Priority: P3 → --
Target Milestone: Future → ---

Updated

14 years ago

Comment 20

11 years ago
The behavior here should be consistent now.  Could someone test on Linux?
QA Contact: ian → layout.view-rendering
Assignee: roc → nobody
You need to log in before you can comment on or make changes to this bug.