When I set response content type as Excel, the Open/Save dialog is shown twice , just on IE8. It works fine on other browsers (tested on Chrome/Firefox/Opera).
The code for setting response content type is:
response.setContentType("application/vnd.ms-excel");
response.setHeader("Content-disposition","attachment;filename=abc.xls");
I searched for solutions/workarounds. Turning off Smartscreen didn't help.
Also, another suggestion was to wait for 5-10 sec before clicking Save/Open. That too didn't work.
What's the cause of this? Are there any IE specific workarounds?
It's a pain but IE8 is still widely used by the users.
This is just a guess, but it could have something to do with the way Office (used to) embed itself in IE with plugins.
A workaround might be putting it in a zip file before sending it over to the user.
Related
I need to embed PDF files in an xpage application. We are using IE11 x64 and this cannot be changed. Eventually, I'll also need to embed MS Office files (Word, Excel, Power Point).
I have looked at a lot of pages and couldn't get a working solution for this... I have some code that works if I force IE11 in IE10 mode, but then Dojo starts acting weird (cannot close dialog boxes, ...).
The code I have right now in my computed field looks like this:
var id:string = pageDocument.getDocument().getUniversalID();
var attNames = #AttachmentNames();
var url = getAttachmentURL(id,attNames);
'<object data="' + url + '#view=Fit&pagemode=none&statusbar=0&messages=0"' +
'type="application/pdf" width="100%" height="100%" > ' +
'<p>It appears your Web browser is not configured to display PDF files. ' +
'No worries, just click here to download the file.</p>'+
'</object>'
I need a free solution.
IBM, This should be made easy if we want to compete with SharePoint, no???
Short answer: don't bother.
Long answer: While you might get it to work for PDF in IE11, your boss won't be happy, because it will not show on her iPad, so you need to have a plan B.... and there is another gotcha down the road (read below). This is what I would do:
Use Apache PDFBbox to extract text from the PDF and show that in the XPage.
Add a link to the page to open the whole PDF
Do the same thing for office documents using Apache POI eventually using OpenNTF POI4XPages
The download link should make use of WebDAV for Domino to allow round-trip editing
Why all this fuzz:
Your users will use mobile at some point of time and NO mobile browser does support embedding (nor do any browsers on a Mac)
Even if you successfully get embedding working, users will start to edit the embedded document and get really really upset since you don't save back the changes
On a side note: asking IBM to support a technology that is vendor proprietary working in one browser (that has been EOL for future updates - see project Spartan) - ain't going to happen.
I got this working nicely in IE11 for PDF files with this very simple line:
<embed src="MyPDFFile.pdf" width="640px" height="755px" alt="pdf" />
I'll go along with Stephen's answer: I won't bothe rtrying to mak ethis work with Office files. It will give our "Notes is bad" users some munitions to move to SharePoint, but we do have other advantages!
I tried using Bumpbox, and pdf.js and while I could get them working, iframes seemed to work best for me with using normal Domino attachment urls in xpages
I am not sure if this solution is right or not, but it works well for an app I have that only has PDFs. It does work on mobile too, at least on iOS.
<iframe
src="#{javascript:
var url = 'https://app.nsf/';
var doc = sessionScope.docID;
var atname = #RightBack(sessionScope.aname,'Body');
var end = '/$file'+atname;
return url+doc+end}"
width="800" height="1000">
</iframe>
Probably the best approach is to use a pure HTML5/JavaScript renderer
for PDF documents without any third-party plugins (e.g. PDF.js)
For further discussion take a look at the following stackoverflow
entry recommended way to embed pdf in html
In my opinion, it's the best way to use a commercial product (e.g. crocodoc) for other documents like MS Office (Word, Excel, etc.).
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?
I have been working on this site for some time and just launched it for a client.
People have actually had trouble beleiving I had done it on WordPress, though I don't see why...
Anyway, I suddenly see that the form fields of one of the forms on the site (Newsletter Registration) disappear while on IE, you get to see them for a second and puff, they're gone. I did check this previously on IE and it worked, I especially used CSS3 PIE to get the rounded effect for the fields on IE...
Link to website: http://www.doritsivan.com (hope this isn't considered promotion, not my intention)
site is based on WordPress and jQuery.
resolved the issue, thank you all. it was a bad case of relative vs. absolute positioning and the fields decided to go away (literaly)
A bunch of debugging with firebug-lite (btw was real to get it to work on my IE, kept on crashing or refusing to load altogether combined with IE popup and security issues) and I understoid that this was the issue, then some pixel fiddling and all was good. rechecked in Chrome, saw that result was exactly the same. job done
Export This
The above is a Data URI containing a base 64 encoded csv data export. On my app's report page, I embed the export within each page view so that an export doesn't require another trip to the database.
In Firefox 3, clicking this link opens a save-as download dialog box. Clicking it in Chrome 9 does nothing. I can right-click-save-as in Chrome, and it will write the decoded csv to a file. Clicking it in Safari opens the decoded CSV data in the browser window, which I can then save manually.
In IE... who cares, am I right?
You can reproduce this to test for yourself by copying that <a> tag in it's entirety into a blank file called test.html and open it in each browser. It acts exactly the same way as it does in the context of my app.
Question: Is there a way to force a Save As dialog to pop up, as in Firefox, when the user clicks the Data URI link? Or some other way to get around this inconsistency?
In theory, Firefox, Chrome and Safari all support Data URIs. In practice.......
Unfortunately, application/octet-stream doesn't work too well in Safari (at least Safari 6). It just saves the file as "unknown" with no Save dialog box. To my knowledge, there's no cross-browser way to do what you're trying to do except to bounce the content off a server.
For some reason my site displays a "Cannot display this message" error in those browsers while working correctly in Firefox, Opera, Safari and IE8.
It looks like this: http://www.reviewsaurus.com/images/pagedisplay.png
This document was successfully checked as XHTML 1.0 Transitional!
It doesn't have anything to do with HTML errors. The worst that can do is show a garbled or blank page.
There is some sort of server misconfiguration going on of WordPress and the gzip Content-Encoding.
Your website doesn't work in IE, but /index.php loads just fine. Inspecting the raw HTTP Response (using Fiddler2), the difference between the two responses is that on the request to /, WordPress (presumably) adds the following text to the gzipped HTTP response body:
<!-- Page not cached by WP Super Cache. No closing HTML tag. Check your theme. -->
Because of that addition to the gzipped content, it's no longer a proper gzip stream, and IE6/7 can't ungzip it.
Other browsers probably have better error handling, so they can handle the error just fine.
I don't know how you can fix that problem, but a Google search for that piece of text turns up a few hits on wordpress.org at least.
It's not valid XHTML. If IE6/7 is actually interpreting it as XML, this will cause it to stop parsing. Can you give a screenshot to show what the failure looks like?
UPDATE: Now that it is XHTML Transitional, it's validating, and I'm out of suggestions until I get someplace I can run IE.
UPDATE 2: Just ran IE7 against the site, and the page loaded fine.
It's displaying fine, albeit slowly, in IE7 for me. I would still recommend fixing the two errors and validate as Strict, but they don't seem to me to be the cause of your problem. IE6 and IE7 are intepreting them as text/html.
This document was successfully checked as XHTML 1.0 Transitional!
It still doesn't work though...
Found the problem:
Was using the following procedures to remove unnecessary characters, seems to be wrong though.
<?php
function callback($buffer)
{
$holdit=$buffer;
$holdit=str_replace(" ", " ", $holdit); // tab
$holdit=str_replace(" ", " ", $holdit); // double space
$holdit=str_replace("\n", " ", $holdit); // new line
$holdit=str_replace("\r", " ", $holdit); // new line
$holdit = eregi_replace("<!--[^>]*-->"," ",$holdit); // comment
return $holdit;
}
ob_start("ob_gzhandler");
ob_start("callback");
?>
Seems I don't need that function either, it is faster without it.
(I should probably have opted for a single eregi_replace too)