941146 - NS_ERROR_FAILURE when other browsers work fine when setting font on a canvas context in a display:none iframe

Status: RESOLVED DUPLICATE of bug 1779227

(Core :: Graphics: Canvas2D, defect)

Description

[Manor Askenazi]

Attachment: bug.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36

Steps to reproduce:

Example of the bug can be generated here: http://slice.med.nyu.edu/cptac/dice/static/replicate.html 

if you click on any of the boxes at the top of the graph (e.g. the green square in the upper left part of the graph, see image called "click_here.png") -- the resulting divs open up with empty screens.

The relevant error (there are currently others that do not appear to be relevant to the bug at hand) is: 


Actual results:


NS_ERROR_FAILURE: Failure on line 1675 of jquery.flot.js

which causes graphs to appear empty (i.e. no data, clicking on the screen icon in the resulting graphs yields a similar plot that does contain data), see image called "bug.png".



Expected results:

An example of the correct output (Safari, Chrome and IE deal OK with this code, both on Windows and MacOS) can be seen in the image called "correct.png"...

Comment 1

[Manor Askenazi]

Attachment: correct.png

Comment 2

[Manor Askenazi]

Attachment: click_here.png

Comment 3

[Alice0775 White]

Error in the error console:

Timestamp: 2013/11/21 15:40:46
Error: ReferenceError: viewer is not defined
Source File: http://slice.med.nyu.edu/cptac/dice/static/replicate.html
Line: 1

Timestamp: 2013/11/21 15:40:58
Error: NS_ERROR_FAILURE: 
Source File: http://slice.med.nyu.edu/cptac/dice/static/js/jquery.flot.js
Line: 1675

Timestamp: 2013/11/21 15:40:59
Error: NS_ERROR_FAILURE: 
Source File: http://slice.med.nyu.edu/cptac/dice/static/js/jquery.flot.js
Line: 1675

Comment 4

[Boris Zbarsky [:bzbarsky]]

The relevant code looks like this:

   ctx.font = '14px Arial';

where ctx is a canvas 2d context whose canvas element is in a document with no presshell (probably a display:none iframe).

What we do in that situation is:

2104   nsIPresShell* presShell = GetPresShell();
2105   if (!presShell) {
2106     error.Throw(NS_ERROR_FAILURE);
2107     return;
2108   }

presumably because of all the styleset/inheritance stuff we have to do here.

We should either silently no-op the call in this case or skip the inheritance bits or something instead of throwing.

Or alternately, decouple the CSS inheritance machinery from having a presshell.

Comment 5

[alex]

This bug seems to be a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=733698

Comment 7

[Miklos Maroti]

This bug is still unresolved, but works in all other browsers. If you have a hidden iframe that contains a canvas, then all operations on the context of that canvas will fail. I can provide a testcase if needed.

Comment 8

[eflanagan]

I think I am seeing this behavior when running Firefox 56.0.2 headlessly in a Travis CI environment.

Miklos, do you have that testcase? I can try to run it in the same environment

Comment 9

[David Iglesias]

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

[niekvb]

Still experiencing this issue in Firefox Quantum 69.0 (64-bit) on Linux.

Comment 11

[ale.garciaiglesias]

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

[ale.garciaiglesias]

(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

[kb]

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

[jsmoriss]

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

[jsmoriss]

(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

[jesse.sierks]

I am seeing this error when I'm loading PDFs, as the iframe is hidden at first.

Comment 17

[Nolan Lawson]

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

[Karl Dubost💡 :karlcow]

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 19

[subzey]

It's been a decade since this bug was introduced in Firefox 10 🥂🎆

Comment 20

[Karl Dubost💡 :karlcow]

Probably it would be good to have a test case as an attachment.

Comment 21

[Nolan Lawson]

FWIW the repro I posted doesn't seem to repro anymore in Firefox 97 on Ubuntu. My attempts at a local reduced repro are also not successful.

The repro posted by ditman, however, does seem to show an NS_ERROR_FAILURE in the console.

Comment 22

[subzey]

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

[Karl Dubost💡 :karlcow]

Attachment: test showing the issue

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

[Karl Dubost💡 :karlcow]

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

[Carter Stanton]

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

[Thomas Wisniewski [:twisniewski]]

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

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 28

[Mark Straver]

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 29

[Peter]

+1

Comment 30

[Mark Straver]

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

[Emilio Cobos Álvarez (:emilio)]

Hmm, just ignoring the setting sounds not-great, but yeah maybe fine instead of throwing.

Comment 32

[Raul Bucata]

It seems that I can not access the page even with VPN. Manor, is this still an issue?

Comment 33

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 34

[Manor Askenazi]

(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

[Mark Straver]

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 36

[Lee Salzman [:lsalzman]]

Timothy, can you look into this?

Comment 37

[Timothy Nikkel (:tnikkel)]

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.