I'm working with a contenteditable iframe that is being using for basic WYSIWYG editing. I've noticed a strange difference in the way that a Tab keypress event is handled between Chrome and Firefox.
When the document of the iframe has been configured using designMode = 'On', a tab pressed inside the document will skip to the next control in Firefox (expected) but create the following pre white-spaced span in Chrome
<span class="Apple-tab-span" style="white-space:pre"> </span>
Here's an example.
Interestingly, when the body of the iframe is setup instead using body.setAttribute("contenteditable", "true"), which I assumed was the same approach done in a different way, both browsers work as i would expect; moving the focus to the next tab index.
Can anyone explain why?
I'm afraid that the only answer is "just because". Don't expect that there's a reason behind how something works in contenteditable. I experienced hundreds of times that no one really cared or had time to care about that. When you've got bugs like https://code.google.com/p/chromium/issues/detail?id=226941 which make contenteditable totally irritating for users on Chrome & Opera and which hasn't been even confirmed by developers throughout entire year, then a small difference in Tab's behaviour is a detail which you have to fix and forget ;).
Use:
document.designMode = 'on';
Insted of
body.setAttribute("contenteditable", "true")
Related
I found that <input type=“search”> only works in Chrome and IE, but not in Firefox.
How can I make <input type=“search”> show the cancel button (x) in Firefox?
Webkit derived browsers put in an x to clear a value. Firefox does not. However firefox supports this feature, but it does nothing about it and you need to style it your self to show the X button in firefox.
Following link will help you to achieve the goal: HTML Textbox with a clear button in Pure CSS and without JavaScript
While the accepted answer is working as it can be seen in the codepen,
I feel the need to explain how this is working and what to be aware of.
As it took me quite some time to get it working as expected.
For anybody who was wondering how the clear is working type="reset" is causing this. Read more about it here
elements of type reset are rendered as buttons, with a default click event handler that resets all of the inputs in the form to their initial values.
This brings us to the second point of what to be aware of.
As the docs explains, the input or button of type reset will only work within a form. However, this creates a problem when having multiple inputs in a form, as all of them will be reset.
Another cavity would be the fact, that while fixing the clear button on firefox this will now produce multiple clear buttons in all the other browsers that do have support for it.
A little feature is that the css content also accepts a url(). This means that for instance custom svg's can be used as a clear icon.
On http://megsmoxie.com/2012/12/enter-to-win-a-fijit-friend-willa/ (or any single post) the search, subscribe, and comment forms do not work in Ineternet Explorer.
You can click in them and see the cursor for a second, then it seems to lose the focus, so I assume it's not an overlapping div issue. If you press a key as soon you click, you can enter one letter, but then it loses focus. It works fine in chrome and ff.
Oddly enough, the problem does not occur in ie on http://megsmoxie.com/contact/ or the homepage (sidebar forms work fine as well as contact form), the issue is only on single posts. Any help would be much appreciated.
You'll note that if you click and hold your mouse down, you can type into the field without interruption. It's only when you release your mouse button that the focus is stolen, and you can no longer type. With this behavioral observation, I took to Chrome to see what events are being handled:
I found that the document has a handler for the mouseup event, and that this code was coming from icx-ez-excerpt.js. Tracking this back through your document, you can find the relevant references below (removing these, sure enough, resolved the issue):
<script type="text/javascript">
var icx_publication_id = 10591;
var icx_copyright_notice = 'Copyright 2012 Meg's Moxie';
var icx_content_id = '30168';
</script>
<script type="text/javascript"
src="http://license.icopyright.net/rights/js/copyright-notice.js">
</script>
Remove that, and the code works as expected in IE. I'll dig a bit further to find out what, in their code, is breaking the experience for your users.
I looked over this page and found a lot going on. This is most likely due to some contention with the onfocus events being fired all over the place. IE is notoriously bad at handling the onfocus event in particular.
In addition there seems to be some third party scripts and controls that are firing. Its very possible that one of those is stealing focus from the text boxes in IE only.
Not much more I can tell you beyond that. If you are the developer of this site you are going to need to do some more in depth debugging. Try eliminating some of the stuff going on and adding it back one by one until it breaks again or debugging some of the javascript.
I've been asked to fix a few bugs on a website, and one of them is throwing me for a loop. Due to the style layout of this particular site, when a user selects and copies text from a specified area, they copy rich text data which if pasted into a rich text editor, results in a large black text on black-background blob.
Ideally, I would like to strip all style data, or somehow enable plain text copying on a particular set of data.
Is this possible? Or would I have to resort to something like a a Flash applet like what GitHub uses for Git URLs?
If you're happy with using JavaScript to solve the problem you can capture the "oncopy" events (credit to #FirstZero) on the elements you wish to restyle, and then restyle the element using JavaScript and style it back again after a timeout.
If you are okay using jQuery you can use JavaScript similar to the following:
$('p').bind(
'copy',
function(e) {
var copyElem= $(e.target);
var defaultColor = copyElem.css('color');
copyElem.css('color', 'pink'); // Change the color to pink for copy
window.setTimeout(
function() {copyElem.css('color', defaultColor);}, // Change it back
1
);
}
);
(Try it out in jsFiddle)
Note that this would be neater if there existed an onaftercopy event, but unfortunately there doesn't seem to.
I've only tested the above solution in Chrome, but it should work in Firefox (since 3.0), latest versions of Chrome and Safari, and in Internet Explorer. It will probably not work in Opera.
Many many years ago, I made a custom form that replicated the look of a menu on a video game. At the time, Firefox didn't allow many form UI widgets (Firefox 2.something?) to be styled with CSS. Apparently in the last few years that has changed.
What I wound up doing to resolve this problem was creating a very large input text-box with the content passed in via the value="" attribute. (<input type="text", not <textarea)
Despite the ability to style input boxes and their content, this information is not retained when copying the text itself. So I completely side-stepped the issue, and the fixes are live!
It was quite a bit simpler too, absolutely no-JS required.
this is insanely annoying problem:
AS3 full screen application based on ADOBE FLEX 4, text field. User types something in text field, and then starts clicking backspace many many times to remove what he just wrote, and for some reason, instead of removing characters from text field it tells browser to GO BACK and user navigates away. Why?! Please, please help, this is so terrible. My users are losing important unsaved this is data while using my application!
i am using safari browser
PLEASE HELP.
Wow, this is terrible, I am so irritated, it happens every single time
It is possible that the focus is lost from your text field when hitting the backspace multiple times (check if you are firing some events on the text field that may cause this), which causes the main window to take focus and trigger 'Back' on the browser.
The root of the problem is that the browser carries out keyboard shortcuts REGARDLESS of the flash app having the focus or not. From what I heard this problem does not exist on Safari's for Mac, only Safari for Windows.
I would check to see what browser you are in and then create a popup saying you this app does NOT work on Safari browser ON windows.
Scratching head*
Well maybe if HAD to solve this, I would use the ExternalInterface to interact with Safari or javascript to PREVENT the history back button from getting applied. So it won't go back to an old page. That is what I would look into.
On a page I have, I need to move TinyMCE editors in the DOM tree once in a while. However, for some reason, the editor doesn't like it: it clears itself completely and becomes unusable. As far as I can see, this behavior is consistent between Safari 4 and Firefox 3.6, but not Internet Explorer 7/8. Here's an example.
It truly is annoying to do something that works in Internet Explorer but not with more appreciable browsers. Is there something I missed in the docs about never trying to move an editor in the DOM tree? Is there some kind of workaround?
This is a browser bug/issue not a problem with TinyMCE. It's impossible to retain iframe contents in some browsers since once you remove the node from the dom the document/window unloads. I suggest first removing the editor instance then re-adding it instead of moving it in the DOM.
Had the same issue and here's how I resolved it...
Create the issue
I use jquery to move the dom element that contains the tinymce editor that causes it to lose all it's contents:
$('.form-group:last').after($('.form-group:first'))
After this point, the editor's iframe contents are removed.
The Solution
var textareaId = 'id_of_textarea';
tinyMCE.get(textareaId).remove();
tinyMCE.execCommand("mceAddEditor", false, textareaId);
There are times when the editor will add the iframe back, but not be visible. If that's the case, unhide the container:
$textarea = $('#' + textareaId)
$textarea.closest('.mce-tinymce.mce-container').show()
Note, this is using tinymce 4.x.