I think this was filed as security in mozilla because of https://bugzilla.mozilla.org/show_bug.cgi?id=950000 - but I'm not sure our font code has the same codepath. Can you explain how exactly this issue would pose a security risk to Chrome users? Thanks!

Actually I'm not really sure about this bug and I'm not familiar with fonts, I filed this bug because in comment 1 said: "Chrome also appears to get this wrong" and I tested the test case on Chrome and I didn't get the same result on Firefox. Please you can close this bug if is it an invalid bug :-)

no this seems like a valid bug (thanks for reporting) but I don't think it has the same security implications. I'll transmogrify this into a feature bug and see if blink team can look at it.

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 14.04 using chrome reported version #66.0.3353.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

This would be very simple to fix, but I believe the current behavior is spec compliant:

https://html.spec.whatwg.org/multipage/canvas.html#dom-context-2d-font

Basically: fonts get resolved when the 'font' attribute is set.

If we think there is a fundamental problem with this way of doing things, then we should first discuss amending the spec.