Closed Bug 1567987 Opened 2 months ago Closed 2 months ago

Image masks no longer working correctly since last Firefox software update!


(Core :: SVG, defect)

68 Branch
Not set



Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- affected
firefox68 --- wontfix
firefox69 --- affected
firefox70 --- affected


(Reporter: willsmith1, Unassigned)




(Keywords: regression)


(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Visited one of my websites -

Actual results:

All images have changed from their normal aspect ratio to 1:1 square on the page.

This has only started happening since the last Firefox update. All other browsers that support masks still work correctly, only the new version of Firefox is affected.

More information and a detailed description of the issue has been provided by Wesley Branton on your community forum here:

Expected results:

Images should be displayed with their correct aspect ratios. See attached screenshot for comparison.

I can vouch that this is an issue. It's not present in Firefox 67. It's present from Firefox 68 through Firefox Nightly.

Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → SVG
Ever confirmed: true
Product: Firefox → Core
Regressed by: 1524901
Flags: needinfo?(violet.bugreport)

I think our behavior here is correct, actually.

Briefly, the site is using two different masking techniques at once -- "mask-box" vs "mask-image" -- and the former CSS is active in Chrome whereas the latter CSS is active in Firefox. These two techniques should produce different renderings, as you can see if you selectively activate one or the other in Chrome (and add a -webkit prefixed version of the mask-image styling).

Firefox used to render the site's "mask-image" markup the same way that Chrome renders the site's "box" markup, which made Chrome and Firefox agree on the site's rendering as a whole -- but I suspect that that was a bug, which was fixed in 1524901. Now Firefox has adjusted its "mask-image" rendering such that we're consistent with Chrome's "-webkit-mask-image" rendering (which differs from Chrome's "mask-box" rendering)


The element in question is an <a> element with class="tm-mask-default", which applies these styles:

.tm-mask-default {
    -webkit-mask-box-image-source: url(../vendor/assets/uikit-themes/master-pinewood-lake/images/mask-default-image.svg);
    mask-border: url(../vendor/assets/uikit-themes/master-pinewood-lake/images/mask-default-image.svg);
    -webkit-mask-box-image-slice: 50 fill;
    mask-border-slice: 50;
    -webkit-mask-box-image-repeat: round;
    mask-border-repeat: round;
    mask-image: url(../vendor/assets/uikit-themes/master-pinewood-lake/images/mask-default-image.svg);
    mask-size: 100% 100%;

The interesting things about this CSS is:

  • Chrome only supports the top half of the CSS (specifically the webkit-prefixed parts) -- -webkit-mask-box-*. Firefox rejects this part of the CSS.
  • Firefox only supports the bottom 2 lines (mask-image and mask-size). Chrome rejects this CSS.
  • Neither browser supports the unprefixed mask-border-* properties.

So, completely different chunks of this CSS are active in Firefox vs. in Chrome, which means there's a different filtering technique being used in each browser -- -webkit-mask-box-image-source: vs. mask-image.

Interestingly, Chrome does actually support a webkit-prefixed version of the bottom two lines (the two lines that are active in Firefox), and if I adjust the site to use those prefixed features in Chrome (-webkit-mask-image and -webkit-mask-size instead of the -webkit-mask-box), then Chrome agrees with Firefox's square rendering here. So that suggests that Firefox is treating that styling correctly, and the only reason we disagree with Chrome on the site-as-a-whole is that the site uses a different masking technique for Chrome.

So, the "regression" here was actually us changing in the direction of correctness, and the reason we differ with Chrome is that Chrome is honoring the "-webkit-mask-box" properties (which Firefox doesn't support, see bug 877294 and bug 1244492), whereas Firefox is honoring the "mask-image" properties (which Chrome doesn't support except via a prefixed syntax that the site doesn't currently use).

Closed: 2 months ago
Resolution: --- → INVALID

So, Will: to get rendering as you'd like, I see two easy options:

(1) Probably best option: add preserveAspectRatio="none" to the outer <svg> element in your SVG mask. This allows that your square SVG mask-image file to be stretched to fit images with other aspect-ratios (instead of forcing itself to mask out an explicitly square area). I suspect this will restore the exact rendering that you were seeing from the current site in older Firefox versions, and my local testing indicates that this doesn't impact Chrome's rendering at all (i.e. it doesn't affect how the alternate -webkit-mask-box technique behaves when slicing out pieces of this SVG file.)

(2) Less-good option: you could also remove the mask-image/mask-size styling, if you want to just get rid of the masks altogether in Firefox (if option #1 doesn't work for some reason and the JPEG-aspect-ratio is more important to you than the masking).

If you wouldn't mind giving option #1 a try and letting us know if that works for you, I'd appreciate it - thanks!

Flags: needinfo?(violet.bugreport) → needinfo?(willsmith1)

Specifically, I'm suggesting that you adjust this first line of this file (the SVG mask):

Currently, it looks like:

<svg width="500" height="500" viewBox="0 0 500 500" xmlns="">

And to allow stretching to fit an arbitrary-aspect-ratio masked area, you want it instead to look like:

<svg width="500" height="500" viewBox="0 0 500 500" preserveAspectRatio="none" xmlns="">

Here's a screencast to illustrate comment 3.

In the screencast, I've got Chrome's devtools open, focused on one of the images with the CSS rule that I quoted in comment 3. As you can see, only the -webkit-mask-box declarations are accepted (and the bottom two, the ones that Firefox honors, are rejected by Chrome). If I turn off the -webkit-mask-box declarations, and add -webkit- prefixes to the bottom two decoarations so that Chrome will accept them, then Chrome changes its rendering to match Firefox, as shown at the end around 0:16 (which lends credence to the correctness of Firefox's handling/interoperability for those last two declarations.)

Here's a testcase which demonstrates that (a) Firefox and Chrome do really agree, when they're given versions of the same styles that they each understand (the upper part of the testcase), and (b) the hypothetical fix for this issue (adjust the SVG to add preserveAspectRatio="none", as in the lower part of the testcase):

(I accidentally posted the testcase as an attachment on the wrong bug -- on bug 1568054 -- but it's still perfectly valid & loadable, so I'll just link to it rather than reattaching it.)

Hi Daniel,

Thanks for your detailed explaination and the fix. I've applied preserveAspectRatio="none" to the SVG and the images are now displaying correctly. I have also notified the company that makes the templates so they can fix it at their end too.

Many thanks again!

Flags: needinfo?(willsmith1)

Sounds good -- thanks, Will!

You need to log in before you can comment on or make changes to this bug.