embed PDF content in xulrunner - pdf

On xulrunner 1.9.2 I could put the Adobe Reader plugin into /plugins of my xulrunner application and load content with:
<vbox minwidth="200">
<html xmlns = "http://www.w3.org/1999/xhtml" >
<div id="htmlDiv">
<embed
id = "pdfObject"
type = "application/pdf"
src = "chrome://manuals/content/test.pdf#toolbar=1&navpanes=1&scrollbar=1&page=1&view=FitH"
height = "850px"
width = "1100px"
/>
</div>
</html>
</vbox>
I am moving now to xulrunner 17.0.1 and I couldn't get it to work - the Adobe Reader gives an error witin its own popup.
I checked the versions to what is in the current Firefox installation and it is correct. I also deleted pluginsreg.dat from the application profile - no success.
Any ideas on how to get back that content into xulrunner based apps would be great.
xuldev

Never mind - a chrome path was missing a trailing slash in the chrome.manifest ;)
Paul

Related

Issue playing a video on Jenkins HTML Publisher

I am using Testcafe for my project tests and I am generating a HTML report with screenshot and video in my project.
When I am trying to publish the report using HTML publisher, the video is not playing.
When I open the generated HTML file in the Jenkins agent via browser, the video is playing fine. not sure, why it is not playing on the Jenkins HTML publisher plugin.
MY HTML video code looks like below
<div class="row">
<div class="column">
<img id="myImg" class="errImage" src="data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAABAAAA" style="width:100%;">
</div>
<div class="column">
<video autoplay muted loop controls id="errorVideo" style="width:99%">
<source src="C:\Program Files (x86)\Jenkins\workspace\Free style node test\e2e\artifacts\videos\Getting Started\My First Test\1.mp4" type="video/mp4">
</video>
</div>
</div>
I tried configuring following content security policy
System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "")
System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "sandbox; default-src '';")
not sure what policy is blocking the video from playing on the Jenkins publisher.
Can someone help to resolve this issue? Thanks in advance.
The policy which blocking your video from playing is media-src == "none", derived from default-src == 'none' (see https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy)
Take a look at the solution in https://github.com/jenkinsci/screenrecorder-plugin/blob/master/src/main/java/org/jenkinsci/plugins/screenrecorder/ScreenRecorderBuildWrapper.java, it could work for you:
String curCsp = System.getProperty("hudson.model.DirectoryBrowserSupport.CSP","");
if (!curCsp.contains("media-src"))
{
System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", curCsp + ";media-src 'self';");
}

PhantomJS rewriting URL in backgroundImage property to local file system

I am using PhantomJS to do some rewriting of HTML. I'm adding a background-image property to an element. But when I write out the resulting DOM, the URL has been rewritten to a local URL. I've boiled this down to the following test case:
JS
var page = require('webpage').create();
page.open("test.html",function(){
setTimeout(function(){
page.evaluate(function(){
document.getElementById("test").style.backgroundImage="url(test.png)";
});
console.log(page.content);
phantom.exit();
},1000);
});
HTML
<html>
<body>
<div id="test"></div>
</body>
</html>
Output
$ phantomjs test.js
<html><head></head><body>
<div id="test" style="background-image: url(file:///C:/cygwin/tmp/test.png); ">
</div>
</body></html>
UPDATE
The problem remains if you specify ./test.png or //test.png. However, http://example.com/test.png is left unchanged, as might be expected.
If this HTML document is opened in Chrome, and the background-image property added to the div element in the style inspector, the URL is unmodified, whether the document is inspected in the Elements tab in devtools, or via document.body.innerHTML displayed in the console, or copying the HTML.
UPDATE 2
I just found out that if the document is located in Chrome, and the command elt.style.backgroundImage="url(test.png"); is issued in the console, then the URL is rewritten. So at the end of the day it appears that this is not a PhantomJS issue, although I still don't understand this behavior.
Obviously, I don't want this URL to be rewritten in this fashion, and I don't understand why PhantomJS feels the need to do this. Ideas?

DOJO 1.8 /dojo/request/iframe is deleting <form></form> when uploading a file

I'm seeing a really strange behavior under DOJO 1.8.0. I'm trying to asynchronously upload a file. The file is uploading just fine and I'm getting the payload as expected, but when clicking the submit button the tags and everything in between is inexplicably deleted! It just vanishes. (NOTE: I've isolated this testing to a test page, so there's nothing else at play that would account for it. You're looking at the entirety of the code.)
require(['dojox/form/Uploader',
"dojo/request/iframe",'dojo/dom','dojo/on',
'dojox/form/uploader/plugins/IFrame', 'dojo/domReady!'],
function(Uploader,iframe,dom,on){
on(dom.byId("myButton"), "click", function(){
iframe.post("UploadFile.php",{
form: dom.byId("myForm"),
handleAs: "json"
}).then(function(data){
console.log(data);
}, function(err){}
);
});
<form method="post" id="myForm" enctype="multipart/form-data" >
<input name="uploadedfile" type="file" data-dojo-type="dojox.form.Uploader"
label="Select Some Files" id="uploader" />
<input id="myButton" type="button" value="Submit" />
</form>
Any ideas from anyone with DOJO 1.8 experience? I've been using /dojo/io/iframe just fine with versions 1.6 thru 1.7. This started happening only with 1.8 using the new /dojo/request/iframe code.
See http://jsfiddle.net/seeds/XD4Dc/1/
The form element is set to have target of dojo's injected iframe. Then form gets like, 'dijitHidden' with abs position -1000 top/left. Cant see why tbh.
There's a fix in the fiddle, add to your callback:
with(dom.byId("myForm").style) {
position = "";
left = "";
top = "";
}
I took this issue to the DOJO-Interest group and it was found to be bug with DOJO 1.8.0. It'll be fixed with the upcoming 1.8.1 release.
http://bugs.dojotoolkit.org/ticket/15939
From the bug report:
The form wasn't getting "eaten", but rather the position was getting set on it and moved out of the viewport because of some faulty logic to check if the form was in the DOM. This has been fixed and should be in 1.8.1.

How to load a pdf file in ipad using sencha?

How to load a pdf file in ipad using sencha?
I have tried the following methods:
html:'<div id="scroller" style="width:99%;overflow:scroll;">' +
'<img style="width:100%;overflow:scroll;"' +
'src="resources/pdfFiles/help.pdf">' +
'</img></div>'
and
html:'<div id="scroller" style="width:99%;overflow:scroll;">' +
'<iframe style="width:100%;overflow:scroll;"' +
'src="resources/pdfFiles/help.pdf">' +
'</iframe></div>'
and
html:'<div style="height:99%;width:99%;overflow:scroll;">' +
'<embed type="application/pdf" width="100%" height="100%" src="resources/pdfFiles/help.pdf" /></div>'
and
html:'<object data="resources/pdfFiles/help.pdf" TYPE="application/x-pdf" width="100%" height="100%" </object>'
iframe works fine in chrome browser and opens up the pdf. But in ipad it opens up blank. img tag opens up only the first page of the pdf in ipad. How to load the entire pdf in ipad on tap of a button? Any help appreciated.
As far as I know, Sencha Touch applications do NOT work well with iframe, especially when pdf is embedded in it.
You had better open up as a new link in browser and let the browser do the remaining tasks.
Here is a discussion on official forum: Displaying PDF and other non-HTML content in Sencha Touch 2

ABCpdf doesn't render images in an web application under IIS6

I'm trying to render a web page that contains images into a pdf document using ABCpdf. This is done from a web application.
When I run the application on my development machine in IIS5, everything is fine. When I deploy the application on IIS6, the images don't appear in the pdf.
To reproduce the problem, I made a simple web application to render a pdf file from a simple web page and I found out that the images which are not local are the ones that don't appear in the pdf.
The relevant code that interacts with ABCpdf is:
Doc theDoc = new Doc();
theDoc.Rect.Inset(18, 18);
theDoc.HtmlOptions.PageCacheEnabled = false;
theDoc.HtmlOptions.PageCacheClear();
theDoc.HtmlOptions.UseNoCache = true;
theDoc.HtmlOptions.Timeout = 60000;
int theID = theDoc.AddImageUrl(theUrl);
while (true)
{
if (!theDoc.Chainable(theID)) break;
theDoc.Page = theDoc.AddPage();
theID = theDoc.AddImageToChain(theID);
}
for (int i = 1; i <= theDoc.PageCount; i++)
{
theDoc.PageNumber = i;
theDoc.Flatten();
}
theDoc.Save(location);
theDoc.Clear();
The html page that I'm using for test is this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Test page</title></head>
<body>
<p>This is a local image</p>
<img src="http://myserver/test/images/testimage.gif" />
<p>This is a remote image</p>
<img src="http://l.yimg.com/a/i/ww/beta/y3.gif" />
</body>
</html>
So I'm trying to render the page at this url: http://myserver/test/testpage.html (the code above) into a pdf.
In IIS6, the second image (that is not local for the server) doesn't appear in the pdf.
It seems to be a problem with access rights, but I couldn't figure it out.
Thank you.
I know this is a little late, but hopefully will help someone else!
Just been experiencing a very similar problem (which is how I landed at this page..). The version of IIS was the same, but it was being run on a different server. Looks like the problem was more generation of the PDF before the image has finished downloading.
I got in touch with WebSuperGoo. The said under the hood it uses MSHTML (good chance that's the difference in your environments) and a couple of suggestions were to try:
theDoc.SetInfo(0, "CheckBgImages", "1");
and
theDoc.SetInfo(0, "RenderDelay", "5000"); // You can change this value, just an initial test.
The second will delay rendering the PDF, giving the image a chance to download.
I had a similar issue and found it was caused by the size of the image file being too large.