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.
Related
I'm running into something really weird with my HTML/CSS.
When I reload the page sometimes one of my elements ends up positioned where it's supposed to be (centered vertically) and sometimes it ends up out of the viewport (something like 700px above the top of the page).
That the page acts differently on different page loads is only half of the weirdness. If I remove body's height: 100% property and re-add it in the web inspector everything magically fixes itself. (body is this element's direct parent.)
My instinct tells me that the answer to the first part of the weirdness is that there's some race condition going on causing things to happen in a different order randomly. But I'm not sure what that might be or why it's affecting things.
What could cause removing and re-adding an identical CSS attribute from an element to cause the page layout to change?
I can't reproduce in a jsfiddle unfortunately but here's a gif of this in action:
Edit: A new piece of the puzzle. I've discovered that this only happens in Chrome and appears to happen only if the page is loaded with an empty hash on the URL.
http://myurl.com works
http://myurl.com/#foo works
http://myurl.com/# intermittently has issues
There was a workaround to trigger a re-flow posted by #Huangism below but there are some caveats (some complications with timing when exactly to trigger a re-flow and also triggering a re-flow on a working page causes a flash of the content).
I think this is a weird bug with chrome, try this
After the content is shown, using jquery - hide the div that contains that content, check it's height and show it
Assuming $el is your jquery div element
$el.hide().height();
$el.show();
Try it and see if it fixes the issue or not
Try setting the height using js or jquery.
It looks like when you reload the page your CSS attributes are set to your body tag via style="" and then quickly removed. Its likely something in your js
Good grief this is hacky. Would still love an explanation for exactly what's going on and the proper way to deal with it but...
After figuring out that somehow an empty hash being appended to the URL was part of the issue an acceptable workaround seems to be completely removing an empty hash if present by using the html5 history API.
My code looks something like this:
// when the page is ready...
$(function() {
// if the url ends with a "#" (and the browser supports it...)
if(window.location.href && window.location.href.indexOf('#') == window.location.href.length - 1 && window.history) {
// clear the darn empty hash using the html5 history API
window.history.replaceState({}, '', './');
}
});
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")
A recurring problem with modern web design can be summed up as "too much sh** all over the place". There're two problems with this: one, it takes up memory and takes longer to load, and two, it visually clutters the webpage.
If I just wanted to solve the second problem, I wouldn't need help. JavaScript can delete DOM nodes and CSS can hide them, so there're already a few visible ways to simply hide parts of a webpage. What I want to do is solve the first problem - make a webpage load faster by not loading certain elements.
I'm pretty sure it's impossible to selectively download certain parts of an HTML file. But once the source is downloaded, the browser doesn't have to actually parse and display all of it, does it?
Of course, if this is done after it's already been parsed and displayed, it would be pointless. So I need a way to tell Chrome what to do before it begins parsing the HTML. Is this possible, and do you think it would significantly reduce load time/memory usage?
Yeah, unfortunately Ive never seen a way of changing the html before Chrome renders it.
But as far as blocking things that that page gets to display then Id recommend just using AdBlock https://chrome.google.com/webstore/detail/gighmmpiobklfepjocnamgkkbiglidom
AdBlock can be used to stop resources (js,images,css,xmlhttprequest) from ever being downloaded (it blocks them in the background using the webRequest api) and can also hide elements using css...its rather effective (just remember to select advanced options in its option page and then when you click the AdBlock button you get "Show the resource list"). Also installing Flashblock can help...or disable plugins in Chromes settings, doing this will make them not load but will still show on the page and then you can make them load.
Totally possible! Meet the newest Chrome API: webRequest, finalized in the current version of Chrome - 17.
Docs for webRequest: http://code.google.com/chrome/extensions/webRequest.html#event-onBeforeRequest
I'm trying to think of a solid way to do this... one suggestion I have is using the 'sub_frame' filter, and watching if it's a like/tweet/social button url
You could also block known analytics stuff... and the list goes on! Have fun! Do you have an email list I can sub to for when you launch? If not, get one and drop me a comment!
(From the comments, here is how a innerHTML hack could work)
//This modLoop constantly peers into and modifies the innerHTML in attempt to modify the html before it's fully processed.
var modLoop = function modLoop(){
var html = document.documentElement.innerHTML
//modify the page html before it's processed!
//like: html = html.replace('//google'sCDN.com/jquery/1.7.1/', chrome.extension.getURL('localjQuery.1.7.1.js'));
//I just pulled that ^ out of nowhere, you'll want to put careful thought into it.
//Then, mod the innerHTML:
document.documentElement.innerHTML = html;
setTimeout(modLoop, 1);
};
var starter = function starter(){
if (document.documentElement.innerHTML && document.documentElement.innerHTML.lengh > 0) {
modLoop();
} else {
setTimeout(starter, 1);
}
};
starter();
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.
HELP, this is a very unique problem and I can't for the life of me figure it out.
My flash content is overlapping the HTML above it.
This only happens if I've just launched IE after being restarted and goes away once I refresh the page. I even added a jQuery $(document).ready function that sets a margin between the html and the flash content to add 1px of space when the page is loaded. It's so hard to figure out, because once I refresh the page, it goes away.
Any input GREATLY appreciated.
Here is the site.
http://www.californiaremodels.com
(This only happens in IE)
here is a screen shot of the problem.
########### SOLVED ###################### SOLVED
I set the flash output as a javascript var (actually json_encoded PHP output) and on document load inserted the object into the "flashContent" div with the jQuery.(document).ready event.
Thank you to Andy Shellam!!
Have you tried loading your flash content using jQuery? I.e. set your div width/height in your HTML with a "this requires javascript/flash" placeholder, then have jQuery load the OBJECT into the div on page load. This way cures IE7's annoying "click here to activate this control" issue - may be a similar issue.
It may be due to the fact that you're floating that DIV that holds the flash content. It shouldn't matter, but sometimes IE gets hinky about such things. Try taking off the float and see if that cures the problem. If it does, create a non-floating workaround.
looks like it is the -4px of margin top you have that is creating the problem