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

Status: NEW

(Core :: Web Painting, defect)

Description

[Hixie (not reading bugmail)]

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.

Comment 1

[Hixie (not reading bugmail)]

Attachment: Simple and self explanatory testcase. Output should be green, not red.

Comment 2

[Hixie (not reading bugmail)]

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

[Marc Attinasi]

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

Comment 4

[Kevin McCluskey (gone)]

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

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 :-).

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I believe that, in fact, this testcase is invalid.

I'll attach another testcase...

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Testcase: Correct use of CSS2 "rect" property as per the errata

Comment 8

[Kevin McCluskey (gone)]

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

[Kevin McCluskey (gone)]

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 [e-mail] 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 [e-mail]

Comment 10

[Marc Attinasi]

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.

Comment 11

[Kevin McCluskey (gone)]

Added relnote keyword.

Comment 12

[Marc Attinasi]

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.

Comment 13

[Hixie (not reading bugmail)]

bah, the spec changes so often that I got all confused!!! Sorry about that.

Comment 14

[Marc Attinasi]

Moving out to future: still need to investigate to see if this is INVALID or 
not, but later.

Comment 15

[/\/\arcio Galli]

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

[/\/\arcio Galli]

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

[ekrock's old account (dead)]

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

[Boris Zbarsky [:bzbarsky]]

> but [e-mail] 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

[Boris Zbarsky [:bzbarsky]]

.

Comment 20

[Eli Friedman]

The behavior here should be consistent now.  Could someone test on Linux?