I have a lot of data saved in XML files with XSLT to show the content properly in Firefox. But from today, Firefox doesn't interpret anymore the XSLT and shows a white page or the data in a block.
My current Firefox version is 68.0 (64-bit). Is there a bug with XSLT in the new version or is XSLT only disabled per default in Firefox 68.0?
As Tim C has pointed out in a comment, due to side effects of a security fix the use of <?xml-stylesheet href="foo.xsl" ..?> in XML documents loaded from the local file system is no longer working in Mozilla. The problem is reported as bug https://bugzilla.mozilla.org/show_bug.cgi?id=1565261 but it seems there is no intention to fix it as Chrome and other Chromium based browsers have stopped supporting XSLT referenced in XML documents loaded from the local file system long ago.
The discussions in the bug report, however, suggest that the setting privacy.file_unique_origin in about:config to false is a "workaround".
Keep in mind that it exposes you to the security problem whose fix disabled the use of XSLT referenced by xml-stylesheet processing instructions loaded from the local file system.
Related
I am creating a pdf document (via ColdFusion), but when I preview the rendered pdf in Firefox, I get the number "4" where my checkmarks are supposed to be (see photo below). When I preview the exact same pdf in Chrome or IE, I see the checkmark, and it all works perfectly!
I am pre-populating the pdf form fields (via ColdFusion session variables), and then rendering the pdf using the following markup:
<cfpdfform source="82040.pdf" action="populate">
<cfpdfformparam name="org" value="">
</cfpdfform>
Here is the resulting pdf form in Internet Explorer:
Note how the checkmark is rendered properly:
Here is the same form previewed in FireFox:
Note how the the checkbox has a "4" instead of a checkmark:
Any help would be greatly appreciated!
It is a bug with Firefox's PDF Viewer. Currently, there is no fix. As radiovisual's post points out, the bug in the underlying library (pdf.js) was supposedly fixed. However, there is still the issue of Mozilla updating the older version baked into Firefox (which is what most folks are using). Currently, that bug is still outstanding.
Probably the best you can do is to return the pdf as an "attachment", rather than "inline", so the browser prompts them to "open/save" the file. If the user opts to "open" the pdf, it should open with their default program instead. (Adobe Reader is the default for most users).
<cfheader name="Content-Disposition" value="attachment; filename=fileName.pdf">
<cfcontent type="application/pdf" .../>
Update:
This bug was apparently addressed already, as pointed out via the project's github repo: the bug was supposedly fixed during this commit. So if you are still experiencing problems, it either means:
You are using an outdated version of the pdf.js library,
Or, the problem has been re-introduced into the library.
So to start things off, you will want to make sure that you are using the most up-to-date version of the pdf.js library. If you are still experiencing problems, even with the most up-to-date version, then the problem is still within the embedded pdf document viewer, and there aren't too many things you can do to fix this until the project maintainer's finally fix the problem.
The issue you are experiencing (the reason why you are seeing a "4" where there should be a checkmark, is because the pdf.js library is using a special symbol font to render the checkmarks, but in problematic versions of firefox's embedded pdf-viewer the symbol font isn't rendering the checkmark correctly, so it shows a "4" instead of a checkmark -- because the checkmark symbol they are using in the custom font just so happens to be mapped to the number "4".
Similarly, for the same reasons cited above, if you assign the checkbox to render squares (instead of checks), the letter "N" will appear in the checkbox instead of a square, because the square shape symbol is mapped to the letter "N".
This problem only exists in the embedded pdf document viewer in Firefox but will look perfectly normal when viewed in Adobe Acrobat Reader, or other offline pdf readers (and other browser pdf readers, which is why it looks fine in Chrome and IE), so when users download the form, it will appear like you would expect it to.
Some workarounds / optimizations you could try:
Try one of these, or all of these, they are in no particular order (or guaranteed to work)
Don't rely on the built-in pdf.js browser extension in firefox, instead, make your own updated version based on the latest pdf.js source or target another pdf library and use it's browser-agnostic API to render and display your pdfs.
Create an HTML form for the user to fill and verify all the information, then render the pdf based on the data supplied by the HTML form, for download only (no previewing in the browser). This will force them to open the pdf in their default pdf viewer where the issue is not present, because, again, the problem you describe only happens in Firefox's embedded pdf viewer and not in other pdf viewers like Adobe Acrobat).
Make sure you have the ZapfDingBats Font installed on your server. I haven't confirmed this, but that commit that was supposed to have solved this issue seems to have added support for this font, so it is worth a try to make sure this font is accessible on your ColdFusion server, then try previewing the rendered pdf in Firefox.
Detect that the user is accessing your form via Firefox, and if so, warn the users of the issue, but assure them that downloading the form and viewing in their default pdf viewer will work as expected.
Convert the page to HTML5 (if you aren't already), then add in an HTML5 shiv (so HTML5 features can be used on older browsers), and a CSS normalizer, and test if the problem persists using these optimal settings. It's worth a shot to make sure that the problem is somehow treated differently under the HTML5 standard, since not everyone is having the same issues as you.
Lastly, make sure that your HTML is being rendered as valid markup via your ColdFusion output by using an HTML validator.
Other than that, there isn't a whole lot you can do until the mozilla team updates their embedded pdf viewer. But since the problem is only in the firefox viewer, and not in the pdf itself, it it up to you to decide if this is a deal-breaker or not, and search for alternatives.
Note: PDF.js is built into version 19+ of Firefox.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Update: You can use this pdf (which represents the character mapping of the ZapDingbats symbol font) as a way of testing your browser's interpretation of embedded fonts in the pdf rendered via pdf.js. Note that at the time of this writing, the above pdf does not display the Zapf Dingbats properly in Firefox (via pdf.js), but other browsers render them just fine (notice the "4" next to a20[x2714] in firefox, and the checkmark next to the same entry (a20[x2714]) in Chrome.
I tried to look through all the tutorials for RAML and I was pretty excited.
I found most of the online resources available but I could not understand why, when i set up everything and the flows are generated, then i run it locally as a mule application, when i point to localhost:8081/api/console/ i get a huuuuuuuge json response, but not the UI described for example here.
Yes i also faced the same issue with Any Point Studio. It is not at all displaying in the API KIT Console present in Any Point Studio. But to feel good and to see the output i have just tried it with Google Chrome Browser and i got the expected User Interface as i was expecting from API KIT Console. Hope this issue will be fixed from next release onwards.
Here is the URL i used to see it on Browser : http://localhost:8081/remote-vending/api/console/
Here is my output from Google Chrome browser for the API KIT Tutorial
My GUI didn't show in the Anytime studio tab: APIkit Consoles, one way to fix this:
make sure you have started your application
right click for the context menu
select encoding
click auto-select
I have had the same problem and resolved it by removing invalid whitespace. One of the example files I was including had an invalid trailing space.
The way I found out;
Open the Network panel in the Developer Toolbar in your browser
Go to http://localhost:8081/api/console/
Find the response for a request to '/api' with the request header 'Accept:application/raml+yaml'.
This response should contain the fully compiled RAML, where all include files have been included.
Copy this entire content into a new RAML-file in Anypoint Platform API Designer or some other YAML editor with error reporting.
It highlighted the invalid whitespace immediately for me.
It should work Out of the box.
It could be a bug of an earlier version.
Could you check the behaviour in more recent releases?
Changing my default browser from Firefox to Chrome resolved the issue for me.
I'm developing a firefox extension which has been working without any problems in firefox version 12.*.
Today I updated FF to version 13.0.1 and changed the install.rdf file accordingly:
<em:targetApplication>
<RDF:Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>1.0</em:minVersion>
<em:maxVersion>13.0.*</em:maxVersion>
</RDF:Description>
</em:targetApplication>
But since then the extension won't be installed. The message "-Extension name- could not be installed because it is not compatible with Firefox 13.0.1" is displayed.
I used Netbeans' foxbeans plug-in to create the first dummy version of my extension (I used to be -and still am- a beginner in Firefox extension development), so the install.rdf and install.js files are automatically generated. Feel free to ask for more code if you think it could help.
Is there anyone else who has the same problem? Any possible explanations?
SOLVED:
It seems like this is a rather weird Firefox bug. I discovered that the problem was caused by an ampersand I had placed on the extension's description:
<em:description>Demokritos Labeling & Filtering Client's Firefox Extension</em:description>
If I change the above to:
<em:description>Demokritos Labeling and Filtering Client's Firefox Extension</em:description>
the extension gets installed normally.
It's a minor but rather odd bug and I should probably report it.
Do you have an updateURL in your extension?
There is an open bug that if your updateURL is incorrect, you'll get a version error:
https://bugzilla.mozilla.org/show_bug.cgi?id=740378
I have downloaded WkHtmlToXSharp (which uses WkHtmlToPdf under the hood) and opened the solution.
When I run the test given with the project - CanConvertFromFile, it gives me a nicely formatted PDF output.
But as soon as I delete even a blank space from the source HTML file ( WkHtmlToXSharp.Tests\Resources\page.xhtml) it renders only text with no HTML structure in place i.e. all text on the page is rendered as a single line.
I am finding the same problem with my dev project using WkHtmlToXSharp.
I suspect this is due to change of character encoding of the source file. Do you know what the character encoding should be? Is this an issue with WkHtmlToPdf as well?
Note: Sorry for the slightly misleading tag (WkHtmlToPdf), the site did not allow me to create tag WkHtmlToXSharp.
Many Thanks!
wkhtmltopdf assumes UTF8 as default, but there's a property (WebSettings.DefaultEncoding) which can be used to override the encoding expected.
However, your problem looks more like you are re-using a disposed instance or something similar. May you describe a bit deeper your use case.. is it an ASP.NET application? a console project? are you running under visual studio's dev web server?
I believe the cause of this is in the issue tracker on Pablo's repo. Issue #7: Only works first time
datimson commented 25 days ago
Also, for the sake of helping anyone else who might have this problem, when debugging with WkHtmlToXSharp in ASP.NET you need to stop the ASP Development server before restarting or rebuilding the application - this is what was causing my text only PDF outputs.
It looks like IE7 doesn't reload the latest version of my stylesheet each time I upload a new version on the server.
This is annoying as I am debugging my .css file to make it work on IE...
Tried to empty the browser cache but still not working.
Thanks for your help.
Ctrl-F5 - forcible way to reload in IE
Include your version number in the file name. myfile_v1234.css
When testing, every time you do an update you can just wite "stylesheet.css?r=98123"
As long as the query string is different, it'll be downloaded again.
If you need, you can use javascript to append Math.random(), to get the random number. Not required on production though, when updates would be stable.
2 Questions:
Does IE eventually load with the newer stylesheet?
How are you saving the changes to the server (SSH, Web Interface, etc.)?
I ask because I ran into an issue with a web-based file management system a while back where one browser would show the CSS just fine, the other wouldn't, and we noticed the issue of which browser played nicely depended on which browser we used to upload the CSS.
The reason turned out to be that IE gave the CSS file a different MIME type than Firefox. If you continue to notice the issue even when you've cleared the cache, check the MIME type of the file using Firefox by going to Tools > Page Info.
Also, if it is simply a caching issue, consider turning caching off in IE. I believe this should be an Advanced Option under Internet Options.
Also, you may want to try creating a special developer environment for IE (if it comes down to it.) Perhaps have another machine with IE7 and no caching and any other features turned off (A kiosk mode, perhaps), and then previewing the page on that machine.
Thanks to you all!
I did manage to solve my problem with the "stupid" Ctrl+F5, and by changing the Internet Parameters of Windows to reload content every new visit.