When using TinyMCE (3.5.4.1) in IE9, if I place a DIV in my content, and if that DIV has either/both Height & Width specified, IE treats it, at least partially, as a contenteditable DIV.
This means when the user comes to edit such a document in TinyMCE the first time they click in the editor IE highlights the DIV in question, and allows the user to move it - which they often do by accident. They then have to click again to edit the content inside the DIV and while they do this the DIV is outlined on the page which is a distraction.
I have seen a number of posts (e.g. http://www.tinymce.com/forum/viewtopic.php?id=3939) saying that IE fires the "controlselect" event in this case and to place the cursor within the content and return false. I eventually managed to get this example to run, but while it suppresses the initial selection of the content it then seems to become random as to whether a given click inside the content places a cursor there or not.
Is there a reliable way to make IE handle this situation like the other browsers do i.e. with no unexpected side effects from adding height/width to a DIV?
I have got it mostly working as here http://www.tinymce.com/forum/viewtopic.php?pid=103272
And here http://www.tinymce.com/forum/viewtopic.php?id=29485
Its not perfect but seems as good as can get.
For this issue you could try to use object_resizing configuration parameter in your tinymce init
object_resizing: false,
Related
I am researching a problem where a user triggers a scroll event, we process it, and in the process of doing so are somehow triggering a second scroll event. Our code is similar to this. In real life, 'thead' is buried inside many levels of containers, etc.
$(window).on('scroll', function(){
$('thead').css('position','fixed');
})
The triggering action seems to be fixing the position of an element. This causes document.height to change, which makes sense, but such actions do not normally cause a scroll event to occur (from what I can tell).
I can reproduce this in our app (which is a mountain of jQuery) with very specific combinations of browser height and document height (I can't see a pattern to it, though; I just know values that work).
I can't reproduce it in a simple case, and I've been trying to all day.
I am confident that $.ScrollTop() or equivalent functions are not being called, and that the user is only making a single gesture.
The jQuery event object looks to me like it is a second user initiated event, eg. there is nothing to suggest that event #2 was caused by event #1.
This is happening on Chrome, haven't tried other browsers. Any suggestions appreciated.
When you make any element to be position:fixed/absolute, your document's height is changed because changed element become out-of-normal-flow and does not push next elements down (read CSS position property). It's the same as removing element from your page.
So, if you're at the bottom of the page and one of elements is gone, browser scrolls page up to compensate removed element's height (to leave you at the bottom of the page).
My application includes a typeahead feature when a user is typing into a comment box. In a similar fashion to Facebook's and google+'s it will perform a lookup of users and suggest them as tags on the fly.
When a user selects one of the offered tags it gets entered into the input area as an element.
I decided to use a conenteditable div for this, but have come across a few issues.
It turns out that firefox wont delete the inserted elements when they are set to contenteditable false whereas every other major browser does.
In order to work around this I have set the inserted 'user' tags as contenteditble=true and wrote a quick jquery workaround to solve this issue.
It works perfectly apart from one major issue. If there are multiple tags in the area and the first of them is not proceeded by any text, then when the user deletes the final one (assuming deletion with the backspace key from right to left) the caret gets positioned incorrectly following that final deletion.
Typing again appears to then return the position to normal.
This issue only occurs in Firefox
Here is a jsFiddle showing the issue:
http://jsfiddle.net/gordyr/PESky/
Place your cursor at the end of that last tag and then hold down the backspace key until all elements are removed. You will see that the cursor/caret moves up and out of position.
It is quite possible that this is actually a bug in firefox itself, however I am looking for a workaround of some kind as without this automatic element deletion with javascript, the don't get removed at all.
Many thanks
It appears that FF leaves some dirt behind, but you can clean it up by adding:
if (!$.trim(el.text())) {
el.empty();
}
This will check if the innerText of the contenteditable only contains spaces or newlines/breaks. If it does, just empty it. Seems to work in my test: http://jsfiddle.net/cBZ7k/
Side note: you should probably use keydown instead of keypress for webkit support. Also, e.which is enough to get the keyCode, jQuery normalizes this event property for you.
I have a blog that consists of consecutive entries, ie. divs. I have a separate background image for each entry. I want to change background image when a specific div gets visible in the client window. I couldn't figure out how to trigger it.
I think this is not about :visible or .show, all divs are alredy visible. However the page is long due to consecutive entries and I just want to change background image when the page is scrolled and a div get in sight.
Note: A javascript solution would be better by the way, if exists... rather than jQuery
I think you need to bind a function to the windows scroll event and validate the div's when the event is fired.
$j(document).bind("scroll", function() {
//check here
});
I found where someone is offering a plugin for this sort of thing too: http://remysharp.com/2009/01/26/element-in-view-event-plugin/
--edit--
here is a similar question and answer:
Check if element is visible after scrolling
I want to create a little WYSIWYG editor.
The idea:
First I want to add the feature to write and change text. So I add an onClick and onKeyBoard Listener to my div container. When I click the div I set a varaible named "focused" to true. When an key event is fired I check if focused is true. In case focus is false nothing will happen else the new charater will be added on the cursor's position.
My questions:
Is this the right way? I tried to check how other editors handle the text input but I wasnt able to get it.
In case this is the right way - how can I simulate a blinking cursor. In a textarea the cursor will blink but who about a div container? The cursor will hide immideatly after clicking.
I'm assuming you're doing this for fun/practice. If you're doing this for professional reason then I HIGHLY recommend you don't reinvent the wheel and use something like Ckeditor, tinyMCE or YUI.
That being said; you need to look into event handling. Specifically, for your question about focusing, you can look here. The way you're describing (setting a variable to true/false) seems like it is going to just run into problems. If you use the standard events attribute (as opposed to setting a "focus" variable onclick) you should define functions to execute and then set them as an onfocus/onblur attribute for the element you're listening to.
That is if you aren't using a javacript library like mootools, jquery, extJS, etc. If you're using one of those they likely have their own way of handling events, so you should search their respective documentation for how to implement event handlers.
One more note; you really should be using a textarea over a div (unless I'm misunderstanding and you just want to do something when a user focuses on your div). If you're using javascript only to completely reinvent a texteditor from a div; then your web page will not function without javascript. If you keep the text area; users could still type information in and you still get the benefit of grabbing text contents for form submits but using divs means your web page will just be rendered useless without javascript.
I'm using JQuery sortable list where I dyanmically I can modify the content inside each element (ie, textfield, color, etc). Either I indluce each element content as an iframe of div then this content is refreshed each time I move/drag and drop this element into another position. Which is weird is that it doesn't happend when I move another different element, so my question would be: is there anyway to avoid currentItem to be refreshed/reloaded after draggin it to another position?
Thanks in advance for your help (!)
This is a known bug. See: http://bugs.jqueryui.com/ticket/5575