Steps to reproduce: 1. Disable hardware acceleration. 2. Restart Firefox. 3. Go to https://dl.dropboxusercontent.com/u/95157096/85f61cf7/2gedjoqbn0.htm. Actual results: The text does not appear inside the button. Screenshot https://dl.dropboxusercontent.com/u/95157096/85f61cf7/wnaqb0tiwd.png

Bug 1234485 fixed this issue when hardware acceleration is enabled.

Good: Windows 10 & macOS 10.12 - nightly 53/aurora 52/beta 51/release 51. Bad: Windows 10 (parallel VM) - nightly 53. aurora 52 is good. I guess there is a case that probably not handled correctly whenever acceleration is disabled on particular Windows and graphics configuration. CJ, could you take a look whether it's about bug 1234485?

Phew! I can repro this issue on my notebook

To repro this bug 1. Set "layers.acceleration.disabled" as true 2. Enable e10s.

(In reply to Astley Chen [:astley] UTC+8 from comment #2) > Good: Windows 10 & macOS 10.12 - nightly 53/aurora 52/beta 51/release 51. > Bad: Windows 10 (parallel VM) - nightly 53. aurora 52 is good. > > I guess there is a case that probably not handled correctly whenever > acceleration is disabled on particular Windows and graphics configuration. > > CJ, could you take a look whether it's about bug 1234485? There are two ways to draw a mask after bug 1234485 landed 1. Indirect paint(nsSVGIntegrationUtils::CreateAndPaintMask) The path exists before bug 1234485 landed. That text element can not be rendered correctly on this path. 2. Paint on mask layer(need HWA) This path is introduced by the patches in bug 1234485, that text can be rendered correctly on this path Disable HWA means turn off #2 and always draw mask by #1

Milan - can you prioritize? Regression in 53

(In reply to C.J. Ku[:cjku](UTC+8) from comment #7) > There are two ways to draw a mask after bug 1234485 landed > 1. Indirect paint(nsSVGIntegrationUtils::CreateAndPaintMask) > The path exists before bug 1234485 landed. That text element can not be > rendered correctly on this path. I'm not sure how that's the case if this is a regression in 53. That is, it would never have rendered even before bug 1234485 landed? > 2. Paint on mask layer(need HWA) > This path is introduced by the patches in bug 1234485, that text can be > rendered correctly on this path > > Disable HWA means turn off #2 and always draw mask by #1 Again, it seems that changes to enable #2 have modified #1 so that what used to render no longer does. Was there a #3 that now no longer exists after bug 1234485 landed?

(In reply to Jet Villegas (:jet) from comment #9) > (In reply to C.J. Ku[:cjku](UTC+8) from comment #7) > > There are two ways to draw a mask after bug 1234485 landed > > 1. Indirect paint(nsSVGIntegrationUtils::CreateAndPaintMask) > > The path exists before bug 1234485 landed. That text element can not be > > rendered correctly on this path. > > I'm not sure how that's the case if this is a regression in 53. That is, it > would never have rendered even before bug 1234485 landed? Before bug 1234485 landed, the test page in comment 1 always fails. From this perspective, this bug should not be a regression. > > 2. Paint on mask layer(need HWA) > > This path is introduced by the patches in bug 1234485, that text can be > > rendered correctly on this path > > > > Disable HWA means turn off #2 and always draw mask by #1 > > Again, it seems that changes to enable #2 have modified #1 so that what used > to render no longer does. Was there a #3 that now no longer exists after bug > 1234485 landed? #1 can not render that page correctly even before bug 1234485. Bug 1234485 did not change the behavior of #1, it only provided another way to generate position-mask. We switch to this new path,#2, only if certain situations fit, such HWA is enable. If the conditions that required by #2 is not fit(e.g. turn off HWA), we still go back to #1. Regarding to your question, I do not think we have a #3.

I can not reproduce this bug. Pushlog for fix range: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0112e92d67d3c90a82ed7f2a6d8e5454b492df74&tochange=337ed61025fe7b9ca0dc2f7c729177f24850fa7f This bug has been fixed in bug 1369910.

Botond, is bug 1369910 suitable for uplift? Or should we let this ride to 56?

(In reply to Julien Cristau [:jcristau] from comment #12) > Botond, is bug 1369910 suitable for uplift? Or should we let this ride to > 56? I spoke to :mstange about it. It would be good to understand why bug 1369910 fixed this bug, in case the real bug here is something else, and the changes in bug 1369910 just covered it up somehow.