Image goes in headings, Strip the WYSIWYG set block type from image on insert.

Why should this bug be related to wim instead to wysiwyg module?

Well actually iam relying on the WYSIWYG api for selection / inseration completely. Right now, i cannot control the selection at all, this is not possible yet.

There is also no need to clearfix an image, until you insert it into p tags, what should be the normal case in wysiwyg editors.

Wysiwyg module itself has no control over where things are inserted. That depends on the cursor position and type of selection (which may be 0 in length but still is a type text or HTML element). To some extent it also depends on what is inserted and which method is used.

Some background info:
Wysiwyg's own plugin API* all currently only supports insertion of arbitrary strings at the cursor position, so the user must position the cursor correctly depending on what's going to be inserted. Most editors end up doing something similar to object.queryCommandExec('inserthtml', contentString) when this method is used. Ie, the "context" of the selection/cursor position is not available for manipulation, and the actual insertion of the string is left up to the browser. The browser may or may not split/close tags to make the resulting HTML Elements fit properly in the DOM.

The second way of inserting things is to use the browser's selection/range objects and manipulate them as needed. The selection ranges know in which DOM elements they begin and end. We can examine and split the elements in a range to fit the inserted element(s) between them if needed - or before/after some specific element if that's what we need. Only the plugin doing the insertion knows exactly what needs to be done with the elements it wants to insert, so there's no way for Wysiwyg to know exacty what to do. other than provide the plugin with the selection/range objects.

That's where the major problems with this more flexible way of inserting things come in. All the major browsers have their own versions of selections/ranges, and all editors have wrapped these differences in different ways. Trying to sort this out by abstracting these objects even further in Wysiwyg will become a major mess, and it would be much better if we could bypass the editors with our own abstraction of the "native" browser objects (vs those of the editors).
This was discussed in another issue earlier and is not likely to get in before Wysiwyg 3.x as it would be a major API/structure change.

*The API for cross-editor plugins, which Wysiwyg Image Upload uses. None of the above applies to native editor plugins as they have direct access to - and should use - the selection API of the editor they were written for.

To get back on the original issue:
CKEditor is actually doing the correct thing here, given only the cursor position and the order by Wysiwyg to insert some arbitrary string there.
If you put the cursor right before/after the text in a heading, you're still inside the <h#> tag. It must be this way or it would be hard to prepend/append text to a header or paragraph. The header tags are block-level tags, just like paragraphs, and you need to press [enter] to create a new block after it (which should automatically become a paragraph) or put the cursor at the end of the paragraph above it and press [enter] there to get a new block before it.
Then you can insert your image properly. There's currently no other workaround as Wysiwyg Image Upload and other "Drupal plugins" don't have a cross-editor/browser way of accessing and manipulating the selection/range objects so they can decide what to do with elements close to or surrounding what they insert.

You can do that, but this just also creates a new special case where you might possible want an image in a header and it will be removed ( eventhough this is unlikely).

Thanks for the claryfication Twod.

Iam currently extending the API* for "replace", as this is often needed in update-tasks of a dialog. But i already see how the editors are messing arround with this.

CKeditor does not provide a node (the implementation of our abtraction does not) when your cursoter e.g. is above a link ( clicked into the middle ) but not selecting it. That results in an empty selection - update is not working. If you select the whole link, update will work AND the normal 'insert' will replace the element.

But in the case of the TinyMCE editor, you have a node eventhough you dont select the link (so kind of a fallback to correct user intention), and then you will need a "replace" action, otherwise the updated element will be inserted into the middle (at the cursor).

There are also some differences between data in tinyMCE and ckeditor. E.g if you select a element in CKEditor, data.content is undefined. If you do so in tinyMCE, content is an empty string.

More critical is the data.node object. Somehow, in CKeditor, $(data.node) is not the correct object, its broken. you will need to use $(data.node.$) .. in tinyMCE there is no data.node.$ at all and there $(data.node) works.

I most probably will open new bugs for this, e.g fixed that in my modules using :

    /* We need this due all the special cases in the editors */
    getRepresentitiveNode: function(node) {
      if(node.$) {
        // This case is for the CKeditor, where
        // $(node) != $(node.$)
        return $(node.$);
      }
      // else
      // This would be for the TinyMCE and hopefully others
      return $(node)
    },

any updates to this yet? ... bump

Right now, I don't have a solution for this. The selection part of the plugin api needs an overhaul, and until that's done there's not much we can do about this.

I also tend to postpone or even close this

I'm not sure if this is the same problem: the editor is stripping tags that the input format allows.

I have Wysiwyg with CEKditor, and I'm using Insert to put the uploaded image into the text. Using the image button and Image Resize Filter I have the text wrapping around the image when created, but after it's saved, the image goes below the text. And when I go back to edit, the text is correctly wrapped.

I checked with rich-text, and the only tags being used by CEKditor are

and with the style attributes in the tag and both tags are in the input format. And they get stripped.

Is this the same issue, or something different?

No, that's not the same issue. If you're using HTML Filter, that's where the styles are stripped. Disable it and try WYSiWYG Filter instead.