Bug: iframe not full width when multiple instances?

[q2apro]

Note: The links stated below do not trigger the bug anymore. I have programmed a workaround via PHP. The bug, however, still exists!

Former Headline: "Appending an Image resizes SCeditor's iframe" Update: Behaviour not only on upload, see below.

Situation: I have multiple instances of SCEditor on my page. Example: http://www.q2apro.com/forum/74/sceditor-with-mobiles-test-post-q2a

If you click on comment and then on button Browse (to upload an image), jquery will upload the image immediately after the file has been chosen.

Problem now, after the successful uploaded, SCEditor resizes not only the image but also the iframe:

The web inspector shows me before the upload:

<iframe tabindex="0" style="width: 524px; height: 307px;" frameborder="0"></iframe>

and after the image upload:

<iframe tabindex="0" style="width: 90px; height: 339px;" frameborder="0"></iframe>

So something must be resing the editor's iframe.

---

Update: Just now I realized that the hidden iframe is already resized when clicking on the "comment" button in my forum to fade in the editor.

You can try it here, click on the comment button and insert text and you will notice it: http://www.q2apro.com/forum/74/sceditor-with-mobiles-test-post-q2a

What could be the bug?

Thanks, Kai

PS: When resizing the entire browser window, the iframe seems to get updated and displays correctly.

[q2apro]

I found out that if I remove:

emoticonsRoot: '../mypath/',
emoticonsEnabled: false,

from:

$('textarea[name="a_content"]').sceditor({
    plugins: 'xhtml',
    style: '../minified/jquery.sceditor.default.min.css',
    locale: 'lt',
    toolbar: 'bold,italic,underline|color|orderedlist,bulletlist|link,table',
    fonts: 'Arial,Arial Black,Comic Sans MS,Courier New,Georgia,Impact,Sans-serif,Serif,Times New Roman,Trebuchet MS,Verdana',
    colors: '#000|#F00|#11C11D|#00F|#B700B7|#FF8C00|#008080|#808080|#D3D3D3',
    resizeEnabled: true,
    autoExpand: false,
    width: '100%',
    height: 350,
    emoticonsRoot: '../emoticons',
    emoticonsEnabled: false,
});

everything works fine!

However, I don't need the emoticons and to save server load I have to prevent them to be loaded. So I need emoticonsEnabled: false

Edit: I also tried the latest 1.4.6-dev but the same problem occurs.

[q2apro]

Another update on this issue. It might not be the emoticons. I enabled them, and the issue still appears on certain editor fields:

1. Go to http://www.q2apro.com/forum/91/home-page-breaks-bit-android-does-happen-other-devices-also and click on "reply" for one of the comments.
2. Enter text and you see the line breaking after about 200 px.

Very weird. Obviously sceditor is setting the width of the iframe incorrectly.

But as soon as you resize the browser window, the size is updated to the correct values.

[q2apro]

One more information, maybe the essential one:

I have used width: '100%' all the time.

Now I have changed the width to a fixed value: width: 600 and the problem disappeared. So this might be the buggy part...

Problem: I need to set the width to 100% so that the editor is displayed correctly on mobiles (not too wide). I cannot use the fixed value.

[brunoais]

can you try exchanging between those 2 in order to force the browser to recalculate the sizes? It might be related to the order that each element's size is calculated.

[q2apro]

between those 2

What do you mean exactly? I tried the 100% and the 600 px, the 100% causes the problem.

[brunoais]

Use javascript to change the CSS rules that are applied to it while the user is viewing the page. See if, by doing that, it seems to solve your issue.

[use]

I was having the same problem when integrating with json-editor. By using your fix, I was able to get it more-or-less working.

To be specific, this line fixes the issue:

width: 600

This line doesn't:

width: "600px"

[sphaero]

Similar problem here. Multiple instances inside the @jdorn/json-editor render a 92px wide iframe from the second on.

[samclarke]

I can reproduce this is if the editor is created on a hidden textarea and CSS is used to force the width (e.g.: https://jsfiddle.net/2bvjmywc/1/) or if it's created on a hidden textarea with a width of 100% set (e.g.: https://jsfiddle.net/2bvjmywc/2/). I think that's what's happening here.

If it is then it's caused by the editor is trying to stay within the same bounds as the original textarea by measuring the width and height of the textarea and toolbar. Unfortunately it fails horribly if the textarea is hidden.

The toolbar height can vary so, to stay within the bounds of the original textarea, the height of the iframe needs to exclude the toolbar height. It's easy to do using flexbox (just 3 lines of CSS) but without flexbox the only solution is CSS tables. Unfortunately IE handles them slightly differently to other browsers and I couldn't find a way to make it work in IE.

The only solutions I can think of are:

1. Break backward compatibility and not include the toolbar in the editor height. That would mean the editor will take up more space than the original textarea.
2. Use flexbox and drop all browsers that don't support it (according to Can I Use... that means dropping IE <= 9). I'm not sure I want to drop IE 9 support plus it looks like flexbox is buggy in IE.
3. Do nothing and leave this bug

None of which are ideal. If anyone can think of a better solution I'm happy to try it.

[brunoais]

My suggestion: Document it breaks (give a link to this issue too) and... ... let it break in IE<=9. OR ... make a behavior (worked for me in the past).

There's no viable way of solving it in IE<=9. Also, I've tried behaviors and... although they are a hack all in itself, they actually work to solve these issues. Do note they are specific to IE and they were discontinued in IE10. Also, I don't think IE10 has any bugs in flexbox that affects this.

[samclarke]

An IE behavior sounds like a great solution! I can only find an ancient page on MSDN describing them. Do you know if they can they detect when the visibility or height of a node has changed? If they can then we can switch to flexbox and use a behavior for IE9 compatibility.

Also, I don't think IE10 has any bugs in flexbox that affects this.

I've just tested it and it seems to works without a problem so just depends on IE 9 now.

[brunoais]

It's a behavior not an expression Height/width change, yes. Gaining and losing visibility, no. Calculating original size at creation, yes. It is basically javascript and you can make your own event listeners, anyway. Just be careful to avoid attaching repeated event listeners to the same thing.

[samclarke]

Gaining and losing visibility, no.

That might be a problem. Won't it will suffer from the same issue as above if it's hidden when created?

If it does then it would mean having to drop IE 9 support to fix this issue or find another solution.

[brunoais]

@samclarke If there's anything that requires a recalculation of a CSS rule, the behavior will be called for its own calculation on the subject. Just try it anyway. It's easy to do a poc for IE behaviors. What isn't is to make the robust for production.

[samclarke]

I've tried it seems to have the same issue as above. Could be down to my poor implementation though. On the plus side I have discovered the propertychange event gets triggered on style changes so we could add an propertychange event listener to all the parents elements and if the changed property is style.display then recalculate.

Only issues are that it might not work well with resizing (that's easy to check) and it's going to be a lot of work to get right and debug. So I guess the question now is how important is IE 9 support? Is it worth all that effort or would it be better to just fix other bugs and either leave this one or dump IE 9 support.

[brunoais]

For resizing, just listen to to the resize event on the parent element.

[samclarke]

Yeah thinking about it, the editor already handles resizing and I can't see there being a conflict with the propertychange event so that should be OK. Just leaves the question of whether it's worth it.

The current IE 9 usage stats are:

Wikimedia: IE 8 - 1.28% & 1.31% IE 9 - 1.37% & 1.28%

Statcounter IE 8 - 1.57% IE 9 - 1.19%

data.gov.uk IE 8 - 0.56% IE 9 - 1.04%

Netmarketshare IE 8 - 3.65% Netmarketshare IE 9 - 4.83% (seems to be going up?)

If all the code can go in a behavior (I'm assuming they can add event listeners to parents?) then at least it won't increase the code size or cause issues for other browsers.

[brunoais]

I can't answer you that, unfortunately. You can leave it to someone else to implement if they require it for their website. It is only 1% of the users on most websites and it only happens if the replacing textarea was hidden.

[samclarke]

The IE behavior seems to work surprisingly well. I was expecting that to take a huge amount of debugging.

Did hit an IE flexbox bug though. IE doesn't expand the iframe to fill the full width so have to use calc() to fix that but looks like it works well apart from that.