Open Bug 941146 Opened 9 years ago Updated 16 days ago

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

Categories

(Core :: Canvas: 2D, defect)

x86
macOS
defect
Not set
normal

Tracking

()

Webcompat Priority P2

People

(Reporter: manor.askenazi, Unassigned, NeedInfo)

References

Details

Attachments

(4 files)

Attached image 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"...
Attached image correct.png
Attached image click_here.png
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
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.
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → Canvas: 2D
Ever confirmed: true
Flags: needinfo?(dbaron)
Summary: NS_ERROR_FAILURE when other browsers work fine! → NS_ERROR_FAILURE when other browsers work fine when setting font on a canvas context in a display:none iframe
This bug seems to be a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=733698
Duplicate of this bug: 733698
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.
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

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).

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

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.

(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.

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>

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.

(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.

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

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

There is a suspicion that this might partly break an admin panel in wordpress (not confirmed yet)
https://core.trac.wordpress.org/ticket/53529

Webcompat Priority: --- → ?

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

Webcompat Priority: ? → P2

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.

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

Attached file 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

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.

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

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).

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