NS_ERROR_FAILURE when other browsers work fine when setting font on a canvas context in a display:none iframe
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
Webcompat Priority | P2 |
People
(Reporter: manor.askenazi, Unassigned)
References
Details
(Keywords: webcompat:platform-bug)
Attachments
(4 files)
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
![]() |
||
Comment 3•11 years ago
|
||
![]() |
||
Comment 4•11 years ago
|
||
Comment 7•8 years ago
|
||
Comment 9•6 years ago
|
||
First of all, apologies for reviving such an old bug, but this has popped up as an issue for Flutter for web very recently:
https://github.com/flutter/flutter/issues/36341
We've confirmed the issue in Firefox 68.0.1 (64-bit) on Mac (and Firefox 60.8.0esr (64-bit) on Linux); here's a reduced repro case:
https://jsfiddle.net/ditman/Lmxoe574
(Crashes upon load, you may hit 'Reload' while the iframe is hidden to trigger the error again).
Comment 10•6 years ago
|
||
Still experiencing this issue in Firefox Quantum 69.0 (64-bit) on Linux.
Comment 11•6 years ago
|
||
Also stumbled upon this issue but we're not using display: none
. I could reproduce by just placing the iframe somewhere in one of the templates, on a place when it's never hidden.
Comment 12•6 years ago
|
||
(In reply to ale.garciaiglesias from comment #11)
Also stumbled upon this issue but we're not using
display: none
. I could reproduce by just placing the iframe somewhere in one of the templates, on a place when it's never hidden.
My mistake, it was being hidden.
Comment 13•5 years ago
|
||
This bug occurs within the current HTML document too on 71.0b8 (with Flot chart like the initial report from 6 yr ago). I don't experience it in Chrome.
Removing "hidden" in the following line prevents the error.
<div id="placeholder3" style="width: 100%; float: left;" hidden>
Comment 14•5 years ago
|
||
I experienced this same issue with an iframe that is hidden by default (ie. display:none).
SOLUTION:
I was able to avoid triggering the NS_ERROR_FAILURE error from Firefox by adding 'sandbox="allow-same-origin"' to the iframe attributes.
js.
Comment 15•5 years ago
|
||
(In reply to jsmoriss from comment #14)
SOLUTION:
I was able to avoid triggering the NS_ERROR_FAILURE error from Firefox by adding 'sandbox="allow-same-origin"' to the iframe attributes.
Never mind - false positive - the sandbox attribute does not fix the NS_ERROR_FAILURE error.
js.
Comment 16•5 years ago
|
||
I am seeing this error when I'm loading PDFs, as the iframe is hidden at first.
Comment 17•4 years ago
|
||
I seem to be running into this same error. It looks like it occurs with cross-origin iframes in my case. I noticed it on both Firefox 88.1.4 for Android and Firefox 88.0.1 for Ubuntu.
Here is a minimal (ish) repro: https://bl.ocks.org/nolanlawson/raw/950326e2d827dbfd2b78ea815c2b893b/
(Click "Result" after loading, notice that the canvas-derived text feature is undefined. The error is logged to the console.)
It seems inconsistent - on some page loads the error is there, on others it's not.
No repro in Chrome 89.0.4389.72 or GNOME Web 3.36.4 (WebKit 605.1.15)
More details: https://github.com/nolanlawson/emoji-picker-element/issues/132
![]() |
||
Comment 18•4 years ago
|
||
There is a suspicion that this might partly break an admin panel in wordpress (not confirmed yet)
https://core.trac.wordpress.org/ticket/53529
Comment hidden (off-topic) |
![]() |
||
Comment 20•3 years ago
|
||
Probably it would be good to have a test case as an attachment.
Comment 21•3 years ago
|
||
Comment 22•3 years ago
|
||
The minimal (modern) repro wold be like this:
<iframe style="display:none" srcdoc="
<script>
document.createElement('canvas').getContext('2d').font = '14px sans-serif';
console.log('OK')
</script>
"></iframe>
I.e. touching any font related stuff of a 2D canvas context inside an iframe with display: none
![]() |
||
Comment 23•3 years ago
|
||
Firefox Nightly 99.0a1 (2022-02-21) (64-bit)
returns
Uncaught
Exception { name: "NS_ERROR_FAILURE", message: "", result: 2147500037, filename: "about:srcdoc", lineNumber: 1, columnNumber: 0, data: null, stack: "@about:srcdoc:1:34\n" }
columnNumber: 0
<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
srcdoc:1
<anonymous> about:srcdoc:1
Safari Release 140 (Safari 15.4, WebKit 17614.1.1.5)
and Edge Version 100.0.1173.0 (Version officielle) Canary(x86_64)
returns OK
![]() |
||
Comment 24•3 years ago
|
||
Based on the fact that this is affecting real websites and creates pain for webdevs (see github issues above) and they are using workaround to solve it, I will set as Webcompat Priority P2 for now.
Comment 25•3 years ago
|
||
This issue is still present.
I am currently trying to render two charts generated by the chartjs node module within an iframe.
I am using:
Version: 98.0.2 (64-bit)
Mozilla Firefox for Ubuntu
canonical - 1.0
Comment 26•3 years ago
|
||
This is also hitting the latest Google doodle at https://www.google.com/search?client=firefox-b-d&q=halloween+google+doodle+
(clicking play doesn't work, and inspecting the error reveals they are setting the font on a canvas context in a non-displayed iframe).
Comment 27•3 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:lsalzman, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 28•2 years ago
|
||
For the record, it seems to be slightly intermittent but dependent on whether the iframe/canvas to be rendered is off-screen when initialized or not (assuming it won't have a PressShell yet at that time?). I'd suggest at least putting in the workaround so JS won't abort when it runs into this issue. Potentially wrong fonts is better than no graphs at all, right?
Comment hidden (advocacy) |
Comment 30•1 year ago
|
||
Not entirely sure why this hasn't been picked up yet. The workaround is very simple and we've had this in our code for over a year with no ill effects at this moment.
Comment 31•1 year ago
|
||
Hmm, just ignoring the setting sounds not-great, but yeah maybe fine instead of throwing.
Comment 32•11 months ago
|
||
It seems that I can not access the page even with VPN. Manor, is this still an issue?
Comment 33•10 months ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:lsalzman, since the bug has recent activity, could you have a look please?
For more information, please visit BugBot documentation.
Updated•10 months ago
|
Updated•8 months ago
|
Reporter | ||
Comment 34•7 months ago
|
||
(In reply to Raul Bucata from comment #32)
It seems that I can not access the page even with VPN. Manor, is this still an issue?
The website that triggered this error is long gone... Which isn't unexpected after 11 years :-)
Comment 35•7 months ago
|
||
If you need a PoC, we have some example code for this in our repo's issue for it:
https://repo.palemoon.org/MoonchildProductions/UXP/issues/2087
Comment 37•5 months ago
|
||
Using the testcase from comment 23, as well as looking at the code where the problem was identified, and the description of the problem, this seems to be fixed by bug 1779227 two years ago.
Description
•