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
Created attachment 210349 [details] Patch
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
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
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?)
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
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
(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.
(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?
Created attachment 211743 [details] Patch
(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
(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.