Bug 120626 – [CSS Masking] -webkit-mask-origin should have an initial value of padding-box

• Status: RESOLVED
• Resolution: INVALID
• Component: CSS

[Andrei Parvu]

As the spec [1] says, the mask-origin property should have an initial value of padding-box.


[1] - https://dvcs.w3.org/hg/FXTF/raw-file/default/masking/index.html#the-mask-origin

[Andrei Parvu]

Created attachment 210349 [details]
Patch

[Build Bot]

Comment on attachment 210349 [details]
Patch

Attachment 210349 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/1693221

New failing tests:
editing/unsupported-content/table-delete-003.html
editing/unsupported-content/list-type-before.html
svg/css/getComputedStyle-basic.xhtml
fast/css/getComputedStyle/computed-style.html
editing/unsupported-content/table-type-before.html
editing/unsupported-content/table-delete-002.html
editing/unsupported-content/list-delete-001.html
fast/css/getComputedStyle/computed-style-without-renderer.html
editing/unsupported-content/list-type-after.html
editing/unsupported-content/list-delete-003.html
css3/calc/simple-composited-mask.html
editing/unsupported-content/table-type-after.html
editing/unsupported-content/table-delete-001.html

[Build Bot]

Created attachment 210350 [details]
Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-14  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.4

[Dirk Schulze]

Comment on attachment 210349 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=210349&action=review

> Source/WebCore/rendering/style/FillLayer.h:180
> -    static EFillBox initialFillOrigin(EFillLayerType type) { return type == BackgroundFillLayer ? PaddingFillBox : BorderFillBox; }
> +    static EFillBox initialFillOrigin(EFillLayerType) { return PaddingFillBox; }

Well, this code explicitly checked for BackgroundFillLayer. If it is background, then it sets padding-box. Obviously the type can be different and then it is BorderFillBox. I assume that the other case is -webkit-background, which must stay as it is. If it is incorrect for masking, you may add MaskFillLayer to the condition (does MaskFillLayer even exist?)

[Build Bot]

Comment on attachment 210349 [details]
Patch

Attachment 210349 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/1690274

New failing tests:
svg/css/getComputedStyle-basic.xhtml
fast/css/getComputedStyle/computed-style.html
css3/calc/simple-composited-mask.html
fast/css/getComputedStyle/computed-style-without-renderer.html

[Build Bot]

Created attachment 210378 [details]
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-07  Port: mac-mountainlion  Platform: Mac OS X 10.8.4

[Andrei Parvu]

(In reply to comment #4)
> (From update of attachment 210349 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=210349&action=review
> 
> > Source/WebCore/rendering/style/FillLayer.h:180
> > -    static EFillBox initialFillOrigin(EFillLayerType type) { return type == BackgroundFillLayer ? PaddingFillBox : BorderFillBox; }
> > +    static EFillBox initialFillOrigin(EFillLayerType) { return PaddingFillBox; }
> 
> Well, this code explicitly checked for BackgroundFillLayer. If it is background, then it sets padding-box. Obviously the type can be different and then it is BorderFillBox. I assume that the other case is -webkit-background, which must stay as it is. If it is incorrect for masking, you may add MaskFillLayer to the condition (does MaskFillLayer even exist?)

EFillLayerType can be only BackgroundFillLayer or MaskFillLayer. Some of those tests are failing because they are presuming that mask-origin will is defaulted to border-box.

[Dirk Schulze]

(In reply to comment #7)
> (In reply to comment #4)
> > (From update of attachment 210349 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=210349&action=review
> > 
> > > Source/WebCore/rendering/style/FillLayer.h:180
> > > -    static EFillBox initialFillOrigin(EFillLayerType type) { return type == BackgroundFillLayer ? PaddingFillBox : BorderFillBox; }
> > > +    static EFillBox initialFillOrigin(EFillLayerType) { return PaddingFillBox; }
> > 
> > Well, this code explicitly checked for BackgroundFillLayer. If it is background, then it sets padding-box. Obviously the type can be different and then it is BorderFillBox. I assume that the other case is -webkit-background, which must stay as it is. If it is incorrect for masking, you may add MaskFillLayer to the condition (does MaskFillLayer even exist?)
> 
> EFillLayerType can be only BackgroundFillLayer or MaskFillLayer. Some of those tests are failing because they are presuming that mask-origin will is defaulted to border-box.

Hmm. I am not sure if we should fix it now, or when unprefixing then.

David do you know if there is content that relies on -webkit-mask-origin: border-bx as initial value?

[Andrei Parvu]

Created attachment 211743 [details]
Patch

[Andrei Parvu]

(In reply to comment #9)
> Created an attachment (id=211743) [details]
> Patch

Just saw that the editor's draft of the spec has changed [1]: mask-origin now has an initial value border-box, so no need for this patch anymore.

[1] - http://dev.w3.org/fxtf/masking/#changes

[Dirk Schulze]

(In reply to comment #10)
> (In reply to comment #9)
> > Created an attachment (id=211743) [details] [details]
> > Patch
> 
> Just saw that the editor's draft of the spec has changed [1]: mask-origin now has an initial value border-box, so no need for this patch anymore.
> 
> [1] - http://dev.w3.org/fxtf/masking/#changes

Right, also changes like that should go into the unprefixed version on landing. Otherwise we break features that rely on the behavior.