Im using CKeditor version 4.5.8 in 'inline' mode (so directly in the content with the 'contenteditable' html attribute). This all works fine, except for one thing. I've added the 'Image upload' plugin, to add support for uploading an image while it's drag/dropped in the editor. This all works pretty good, except for one thing I can't get to work:
when dropping the image in the editor there should be a 'uploading' progressbar (tested in Chrome and in Firefox). But instead I almost directly see the message 'Upload complete'. But, at that time the upload is not completed (I've added a debugger breakpoint I my code to assure this is the case) and the 'success' response is not yet received (I see it as 'Pending' in the developer tools 'Network Tab'.).
However, when I 'throttle' the connection via Chrome dev tools, I do see a progressbar, however it's not showing the upload progress, but a 'Internal progress' of the browser of somekind? See screenshot:
Any ideas how to fix this?
The progress CKEditor 4 provide is taken from the XHR2 progress event. Note that it may not work properly on the localhost when the upload works immediately. Also I see your images are taken from cache ("from cache" in the 5th column in the Network Debugger). Try to disable cache and check does it helps.
Additionally I see your arrows next to data:image/jpeg. CKEditor, before uploading images, loads them locally as BASE 64 data to show user the preview. Then these images are uploaded and the source of the image is replaced. These data is not a real network data, it is the content JavaScript loaded locally.
Related
I'm building a series of web pages. Some have images on them. I need to update the images and view the result. BUT in the moment Chrome takes the images from some kind of cache or other mechanism. I did a test and created some html with the image. Here's the original image:
<p class="Regular"><img class="img-responsive" max-width="40%" height="auto"
src="/jpg/image30.jpg" ><br/><br/>
That image is old. I uploaded (via WinSCP) a new image30.jpg, but the old one continues to display. I went to what I think the Chrome cache in
C:\Users\username\AppData\Local\Google\Chrome\User Data\Default\Cache
And deleted all files except for data_1, _2, etc.
I went into Chrome's settings and deleted browsing data.
If I change the image name in the Html to some other name, even one which doesn't exist, an image does display, usually an older one.
This also happens with Firefox and Opera.
You can press CTRL + F5 to reload the page without cache. Under google chrome develop tool, we have an option to disable the cache:
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.
A website I have will absolutely not work on Facebook's Debugger. I constantly get Error parsing input URL, no data was scraped (that's it). It's a WordPress 3.5 installation running Yoast's SEO plugin with OG data enabled.
I run many WordPress 3.5 sites from the same host (Dreamhost), with the SAME plugin that works perfectly on Debugger. If you checked the source code on the page not working, you can see the correct og: data.
All no-indexes have been unchecked, maintenance mode is off. I can't imagine a wordpress theme causing it to fail (I switched the theme to double check).
http://www.pompeya.com
I even tried the fbrefresh using http://www.pompeya.com?fbrefresh=CAN_BE_ANYTHING
When I go to facebook, it IS pulling the text og data, but not the 200x200px PNG pic that I've included. Again, I'm operating the same tactics as all my other wordpress sites, which are working.
Need help why Debugger can't even see the site!
I'm using CKEditor for my site.
Now I found the plugin called "MediaEmbed". I need it for embedding YouTube videos.
I installed it and the integration worked fine, but embedding won't work.
When you paste the code into the text area in the embedding dialog and then click on OK in IE and Chrome nothing happens and in Firefox it just adds a image as a flash-content-placeholder.
Let's say the flash-content-placeholder image would be just in the wysiwyg interface, but then i should get the embed code when I click on "view source" - but no, there you just see the source of the placeholder image div and img tag.
Then let's say the embed code is saved internally, so I save the file I create with CKEditor, and the out I get is just what I entered without the stuff the MediaEmbed plugin has generated at all.
How to fix this?
Please help!
Yours Joern.
use firebug and see, it'll be giving a cross domain error. the plugin has a bug. use try catch in the place where is accesses the windows.name property for a workaround.
Try istead ckeditor youtube plugin
I've created a couple of Office plugins. The plugin shows a set of html files installed on the clients computer. The plugin uses a COM-accessible assembly which shows a WinForm with a WebBrowser on it. The plugin makes the WebBrowser navigate to a file on the clients computer. The assembly is also used in other programs to show the same information.
When showing the local html files using a 'normal' browser (e.g. double clicking a file in Windows Explorer) the browser popup a security warning about running active content. This is because we have some javascript in it. This warning is supressed by setting the 'Allow active content to run in files on My Computer' in the Internet Explorer settings. This solves the issue using a 'normal' browser.
Funny enough the 'active content' warning is not shown when getting the same file using a Word/Excel/PowerPoint plugin. It calls the same assembly, using the same WinForm and using the same content. Despite the setting 'Allow active content to run from My Computer' being false, the content is shown without a warning and the javascript is executed.
Now, the problem and the real question is that Outlook does the reverse. No matter what I use for 'Allow active content to run from My Computer' the browser warning about the active content in the html file is shown. When I confirm the message and allow the scripts to continue, the javascript runs fine. So, even when I set the 'Allow active content to run from My Computer' to true, the warning is given.
I've gone through all (sort of) relevant settings in Outlook, but nothing helps.
I assume that Outlook is using some kind of private context for a webbrowser (probably because it is using a webbrowser object internally).
The real question is: how can I make the Outlook plugin respect the IE settings?
(I understand this is a long story and maybe not clear enough. Please let me know if I have to elaborate more).
I couldn't get rid of the security warning without lowering the security setting. And that is not an option: we are talking about a project that will be installed on millions of computers.
I decided to go another route. Let's see if we can make the browser trust the html pages. So, what to do to get rid of the 'Active content' warning.
First I investigated what exactly triggers the warning. That was easy: any tag in your html file will do. And I need script, so removing that isn't an option. But, when hosted from a website, the scripts run fine and don't suffer from a warning. So, I investigated if it is possible to run my files in the Internet-context.
I found out there is a way, at least for IE (which in my case is sufficient). If you save a webpage as a complete HTML file from IE, the browser adds a comment to the html to signal its origin. Something like: . If you later open that stored html file, the file is shown in the Internet context.
So, I tried adding to the html file. And, voila, the file is opened in the Internet context. The security warning about active content is gone and the scripts are executed fine.
But, that raised another problem. We have a couple of window.open statements in the scripts and using that causes he cross domain browsing problems that in recent IE versions are blocked. Even if you use a relative path in the window.open call, if fails and you end up with a blank window.
In our case, we can (probably) decide to get rid of the window.open calls. But, if a reader ever finds a solution for using window.open in this scenario, I would be very happy if you let me know.
So, for now: case closed...
Internet explorer use Mark of web in such cases
<!-- saved from url=(0014)about:internet -->
<!doctype html>
<!-- saved from url=(0023)http://www.contoso.com/ -->
<html>
<head>
<title>A Mark of the Web Example.</title>
</head>
<body>
<p>Hello, World</p>
</body>
</html>
More info from here
https://msdn.microsoft.com/en-us/library/ms537628(v=vs.85).aspx