Running into problems with CKeditor 4.5.6 involving dragging content into ckeditor's editor.
To be more precise, When dragging and dropping content from outside of the current browser window the content is either stripped of formatting (from Word for example) or converted to other language symbols (if from a browser for example). For instance dragging the 'Similar Questions' title from the page I'm typing this question in produces:
Example of Firefox/CKeditor problem
However, dropping the url in the url bar for instance works correctly.
This issue only appears in Firefox. Chrome and IE work fine and I can drop formatted text from anywhere including Word and only my accepted tags (using CKeditors content filter) will correctly make it into the editor.
My page is using UTF-8, the pages I'm dragging from also use UTTF-8.
I've exhausted the forums looking for a solution and would greatly appreciate any help.
Thanks!
UPDATE:
After tinkering around in FF's console and exploring the drop event object I used the code:
CKEDITORSETTINGS.ckeditor.document.on('drop', function (evt) {
var data = evt.data.$.dataTransfer.getData('text/html');
console.log("paste data: " + data);
});
Which shows that the paste data is also incorrect. So this looks to be a Firefox issue unless I find any more leads.
Update #2:
Narrowed down further: this issue is ONLY when dropping data from OTHER browsers into FF
Update #3:
Updated FF to current version (45.0) and the issue is resolved.
What a wild goose-chase!
Related
I have an outlook-addin written in Angular framework, which communicates with the Outlook through the office-js.
My goal is to implement a service that opens any kind of URLs/links in any mainstream platforms where outlook is available, to be specific: in Google Chrome, Safari, Firefox, Opera, Internet Explorer, The MacOS desktop Outlook - old and new versions either, and most of the Windows desktop Outlook versions (2016, 2019, O365). But unfortunately I can not find a way that works in all of the platforms, and I want to avoid implementing it in a platform-dependent manner.
The first problem I encountered with, is that when I am trying to open links by a simple js function window.open(url) then the outlook versions that use Internet Explorer as an engine are failing to open URLs that contain the character #. That is because IE does not seem to be able to read this character and it cuts the URL in half by the # character and it completely removes the parts followed by the #.
https://en.wikipedia.org/wiki/County_Antrim#/media/File:Ballycastle_Harbour_-_geograph.org.uk_-_468327.jpg
window.open(
"https://en.wikipedia.org/wiki/County_Antrim#/media/File:Ballycastle_Harbour_-_geograph.org.uk_-_468327.jpg",
"_blank"
);
For example, if I try to open the URL above on Windows outlook 2019 which uses Internet Explorer as it's engine, then the url will look like this in the end:
https://en.wikipedia.org/wiki/County_Antrim
For a solution I've implemented a workaround that encodes the URL by a built-in function that comes with typescript which allows the IE to be able to open the link. By simply passing the encoded URL to the window.open() does not work because it concatenates the url with the host of my addin, which results in an invalid link.
window.open(
encodeURIComponent(
"https://en.wikipedia.org/wiki/County_Antrim#/media/File:Ballycastle_Harbour_-_geograph.org.uk_-_468327.jpg"
),
"_blank"
);
The host of my addin + the encoded URL:
https://localhost.eu.ngrok.io/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCounty_Antrim%23%2Fmedia%2FFile%3ABallycastle_Harbour_-_geograph.org.uk_-_468327.jpg
So I had to redirect manually with a simple html code as shown below:
redirect.html:
<html>
<head>
<script type="text/javascript">
window.onload = function (event) {
var regex = /\?url=(.*)/ig;
var match = regex.exec(location.search);
if (match && match[1] && match[1] !== "") {
location.href = decodeURIComponent(match[1]);
}
else {
document.body.innerHTML = "Redirect failed!";
}
};
</script>
</head>
</html>
typescript code:
url = "https://en.wikipedia.org/wiki/County_Antrim#/media/File:Ballycastle_Harbour_-_geograph.org.uk_-_468327.jpg"
window.open("./redirect.html?url=" + encodeURIComponent(url), "_blank");
Unfortunately, this method also has some flaws in the desktop outlook of MacOS. Redirecting makes the links open in a simple webviewer of the outlook application, and not in Safari as it is expected since the default browser is set to Safari in both of the system preferences and in the outlook browser preference. Despite the fact that it can open the links in this webviewer, I can not use it, because some of the webpages I want to navigate to does not support to be opened by the webviewer.
I was suspecting that this behaviour is caused by the relativity of the url ("./redirect..."). So I have tried building the URL by adding dynamically or even hardcoding the host of my addin to the beginning of the URL this way:
`${window.location.origin + window.location.pathname}/redirect.html?url=` + encodeURIComponent(url);
But there was no difference in the results by doing it, so I am guessing that referencing the host of the addin itself does not change quality or state of the URL, meaning that it is still managed as a relative link.
Since I had the opportunity to host the redirect.html from another server, I have tried referencing the redirect.html file from another host, and that way even the MacOS Outlook worked perfectly, proving my suspicion of the wrong management of relative links.
I have also tried using the function called openBrowserWindow provided by office-js the following way:
Office.context.ui.openBrowserWindow(url);
But this was also a dead-end, since this could neither handle the # character in IE nor it was supported in all of the platforms I need to use.
The last workaround I have tried is by completely reworking the service and instead of opening the links by using js or ts functions, I have tried binding the urls to the href attribute of <a></a> elements, however the application requirements exclude this method, as there are some links that are expected to be opened by double clicking, which can not be done with using an <a> tag as far as I know, at least not in an "hacky" way.
Which I would really like to know, what makes the links open in the webviewer of the MacOS outlook application instead of the default browser of the system? Is it a setting I am missing, or is there a way to force using the safari?
Did you try simply doing:
if (Office.context.ui.openBrowserWindow) {
Office.context.ui.openBrowserWindow("https://google.com");
} else
{
window.open("https://google.com");
}
Since openBrowserWindow is selectively not supported in OWA, window.open will automatically take over.
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'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 am writing a Firefox extension which creates a Java applet in the page.
function addApplet(aDocument,url,classfile,archive) {
if (navigator.javaEnabled()) {
var anApplet,body;
body = aDocument.getElementsByTagName('body')[0];
anApplet = aDocument.createElement('applet');
anApplet.setAttribute('CODEBASE',url);
anApplet.setAttribute('code',classfile);
anApplet.setAttribute('archive',archive);
anApplet.setAttribute('name',"Applet");
anApplet.setAttribute('width',"0");
anApplet.setAttribute('height',"0");
body.appendChild(anApplet);
}
}
The JAR file loaded from the applet is 500KB in size. I noticed that sometimes the extension causes Firefox's vertical scrollbar to freeze and the hot-keys to stop working. The scroll-bar and hot-keys work fine if I prevent the extension to append the applet to the page.
Another weird behavior is -- on the frozen page if I click inside any text/search box or even address bar the scroller and the hotkeys begin to work again. The same thing happens if I switch tabs or minimize the browser window.
I am using Firefox 3.6.12 on WindowsXP.
Please help me if you have an idea regarding this or if I should provide more information.
(Hey guys this problem is still not solved....please help me out with this......)
Thanks
See if something similar happens if you load the applet from an html page that includes the tag and its children as static content, rather than content added to the DOM.
I imagine it's a problem of Firefox and java, not your code.
Applets can be tricky. I would suggest creating a page of pure HTML that works, first.
As far as suggestions for change go, 1st thing to change is the width/height of the applet. An applet with 0 size can cause all sorts of problems. Instead, give it a WxH of 20 (then later hide it using CSS).
Ok this has worked:
Solution:
This behavior is the default since JDK 1.3. However you might need to prevent the applet from getting focus on startup, for example, if your applet is invisible and does not require focus at all. In this case, you can set to false the special parameter initial_focus in the HTML tag, as follows:
<applet code="MyApplet" width=50 height=50>
*<param name=initial_focus value="false">*</applet>
Cheers,
I've got this damn annoying bug (or wrong setting) that makes the player reload whenever it's clicked. It's set to play when you click, so when you click it, it reloads. The circle begins....
The reloading only happens in Firefox. In Safari (and I assume Chrome), the video opens in its own window. Not ideal, but it still plays.
Here's the code for the player: (I can't share the link unfortunately, NDAs etc etc.)
flashembed("player", "/flowplayer.commercial-3.0.7.swf", {
config: {
key: '##xxxxxx',
clip: {
autoPlay: false,
autoBuffering: true,
url: "http://myvid.com/url.mp4",
wmode: 'opaque'
}
}
});
This site is full of complete geniuses, I hope one of you can help me out!
The fact that this works as expected in Firefox 3.6 for Windows and Firefox 3.5.7 for Linux suggests its a Mac/Firefox issue.
Try comparing the generated output between different versions using Firebug and see if you can spot anything
I just had the exact same issue. I had Flowplayer in a content slider and the slider was cloning the player and the script. I fixed the problem by changing the video link to have a class of "player," instead of a unique ID, then changing the javascript call to Flowplayer to:
<script>flowplayer("a.player", "flowplayer-3.1.5.swf");</script>
and then moving the script out of the slider, so that the script itself wasn't cloned. I reinserted it just before the closing tag, but it could go anywhere.
I had the same issue using ajax to swap out the videos based on user action, e.g. clicking a link. I finally resolved it by removing the element and re-adding it prior to calling flowplayer:
$("#video #message-video").remove();
$("#video").html( $("<div>").attr("id","message-video") );
flowplayer("message-video", ...