Jump to content
mindplay.dk

Problem with TinyMCE in Chrome

Recommended Posts

I'm having some bad problems with the TinyMCE input-field under Chrome.

Basically, I'm seeing this (thought not in Finnish, heh.)

This is a known bug in TinyMCE, apparently - but it seems to only affect a few people. It only occurs when you have enough content to make the vertical scroll-bar appear, and only when you scroll upwards.

The bug has been recorded in the TinyMCE bug tracker, but they don't seem to be doing anything about it - looks like they have 1,200 or so other bugs to attend to.

It has also been mentioned in this post on StackOverflow. Using that, I came up with this (horrible) work-around:

$('iframe').get(0).contentwindow.onscroll = function() { var el = this.document.body; el.style.backgroundColor = '#fffffe'; this.setTimeout(function(){ el.style.backgroundColor='#ffffff' }, 1); };

No solution, just demonstrates a possible work-around - it basically just forces Chrome to repaint.

Obviously, this bad, bad, terrible work-around will only work if your body background is white.

I would be really grateful if others could help find a better solution to this problem, since I can't really throw this at our customers - it's unusable as-is...

Share this post


Link to post
Share on other sites

Yeah, it's been broken since few latest Chrome versions. It's horrible and terrible. Thinking about getting rid of the tinyMCE all together.

What parts of the editor need to be tied into PW? Images and links, but is there any others?

Share this post


Link to post
Share on other sites

But what's the alternative?

WYSIWYG's all suck - we're probably just going to end up with a different set of problems...

Share this post


Link to post
Share on other sites

You might be right. I always try to find all possible ways to keep RTE in minimum, but it is just impossible to avoid situations where client needs a little table there and some images just here etc...

But since Aloha Editor dropped the ExtJS dependency and is now implemented in JqueryUI it might be a good candidate. It's also GPLv2 licensed now: http://aloha-editor.org/blog/2012/07/aloha-editor-goes-jquery-and-gplv2/

Share this post


Link to post
Share on other sites

I would think twice before using anything that new - other WYSIWYG's have had years and years to learn (and work around) all the endless cross-browser issues, and problems with editable HTML in general, the list is endless...

Share this post


Link to post
Share on other sites

CKeditor has a version for jquery that doesn't seem hard to implement. I did a very quick adaptation to the pw tinyMCE module, and got it working. Lot's of work ahead is still missing of course...

the new skin look pretty nice http://ckeditor.com/...ckeditor_4_skin

post-88-0-92675700-1352399934_thumb.png

post-88-0-35875900-1352400277_thumb.png

  • Like 2

Share this post


Link to post
Share on other sites

Table editor on CKeditor is much better than the one on TinyMCE - other than that I'm not sure how much they differ? Hard to say though before testing more thoroughly.

Biggest problems with our clients so far has been:

  • Images, choosing them, setting width/height and positioning them inside text
  • Tables and their attributes

Share this post


Link to post
Share on other sites

I also noticed this recently, but checking now on my local install it's gone. I have updated and am now on 23.0.1271.64.

I also think it is more an issue with Browser than Tinymce. So maybe Chrome already fixed the render bug. It appeared suddenly, and since automatic updates you get new updates almost daily. Not sure about IE9 and others but usually such render bug are Browser issues that can happen, it's a dirty business so you get dirty things happening not only in tinymce. :)

I agree Wywiwyg sucks and there's tons of problem, but I learned to deal with it, although never really happy. Mostly we have hard time teaching users to enter paragraphs and heading instead of breaks and bolds.

Share this post


Link to post
Share on other sites

Edit: Ok, I found that if I open the developer tools in chrome the render bug is appearing. When I close the dev tool it's gone.

Share this post


Link to post
Share on other sites
WYSIWYG's all suck - we're probably just going to end up with a different set of problems...

Quite possibly :/

But what's the alternative?

This other WYSIWYG editor has been bouncing about in another thread for a little while. It looks (to me) like use of it is likely not viable with the current version (licensing) but as Ryan suggested

One possibility is that we could use an older version

perhaps an earlier version would still be a big step up over TinyMCE* (if using an earlier version did not bring other problems)?

*So far, TinyMCE has been kind to me and I have not used Redactor so I'm not bad-mouthing one or promoting the other, just seemed these two threads shared some interest.

Share this post


Link to post
Share on other sites

I also noticed this recently, but checking now on my local install it's gone. I have updated and am now on 23.0.1271.64.

I'm on 22 and it's not gone. Chrome is updating currently so interesting to test soon.

Share this post


Link to post
Share on other sites

Still doing it, without dev tools opened. Versio 23.0.1271.64 m

Share this post


Link to post
Share on other sites

Okay, it looks like this is a bug in Chrome - I don't think this is specific to TinyMCE at all. I became suspicious of this today, when I experienced the same problem with an iframe on a page that was not using TinyMCE at all.

This bug was first reported on the Chromium bug tracker on August 17:

http://code.google.c...etail?id=143354

So hopefully they're working on a remedy - please go and vote for this bug, and don't start integrating another WYSIWYG port for this reason, because it'll most likely just suffer from the same problems...

Share this post


Link to post
Share on other sites
and don't start integrating another WYSIWYG port for this reason, because it'll most likely just suffer from the same problems...

I did it very quickly, and mostly because I was curious if it would be an easy task. It's not an easy task, but it's less difficult than I expected... lesson learned: we really don't have to be stuck to a editor if we don't want. Truth is that CKeditor future versions got me really curious. Just have a look at these examples: inline editor, placeholder, div replace all taken from here http://nightly-v4.ckeditor.com/3783/samples/

Would be also interesting to make a module for markItUp integration.

  • Like 1

Share this post


Link to post
Share on other sites

Those editors impress me diogo (coming from a background where in my previous CMS I used Textile in the Admin i/f and nothing else).

As long as an editors output is clean and ensures no copy-pasted cruft (like <font> etc) gets in then it's an exciting proposition.

I suppose one 'problem' is which editor; while support for several could be added (and perhaps that's inevitably what will happen) it seems like it would be good if one were standardized on, that would likely deliver the best implementation and ongoing support and enhancement. Arguably that's where we are now with TinyMCE (which as I've noted I don't dislike), except it looks from demos of other editors to my un-trained eye as if TinyMCE is a bit out of date.

I've not yet seen the Chrome error, but I'm running Canary now and if I see it there I'll also report it.

Share this post


Link to post
Share on other sites

This is turning into a different discussion, but I don't really care which WYSIWYG editor I use - they all suck, they just suck in different ways.

At the end of the day, WYSIWYG (for most clients) is just not a good idea in the first place - clients are notorious for messing up designs, pasting bad markup, pasting from Word, picking colors that don't fit the design, and so on and so forth. Most WYSIWYG editors go to great extents to try to suppress and clean bad/faulty markup, and succeed to varying degrees, with varying degrees of negative impact on those of us who do know HTML.

I have long been thinking about a new kind of WYSIWYG editor based on structured snippets, rather than raw markup. I believe it is possible to provide a WYSIWYG experience, giving the client the freedom they need, without giving them the power to mess things up - while at the same time, actually providing them with something that is faster, easier and more comfortable to work with. I have been coming back to this idea now and then for at least five years.

Anyway, I'm going completely off-topic here... :)

  • Like 3

Share this post


Link to post
Share on other sites

I've too little exposure to todays WYSIWYG editors to know their failings but I'm saddened and not overly surprised to read

they all suck, they just suck in different ways.

Good luck with progressing your idea mindplay.dk.

And here's to going off-topic when it's called for! :)

Share this post


Link to post
Share on other sites

Like you, I also hate them, and tend to prefer solutions like textile, but for telling the truth, clients are always more comfortable with wysiwyg, So I just try to build my websites in a way that I can have as much raw text areas as I can (I love ilimited custom fields!), and prepare my css to prevent any playful things with the wysiwyg.

I have long been thinking about a new kind of WYSIWYG editor based on structured snippets, rather than raw markup. I believe it is possible to provide a WYSIWYG experience, giving the client the freedom they need, without giving them the power to mess things up - while at the same time, actually providing them with something that is faster, easier and more comfortable to work with. I have been coming back to this idea now and then for at least five years.

I am very interested in knowing more details about this :)

Share this post


Link to post
Share on other sites

One useful solution to RTE madness is to handling image/text-positioning outside the actual editor controls. You add "image&text" blocks and position images in relation that single block text. Madmimi has nice implementation and can be quickly seen on their home page video: https://madmimi.com/

In my opinion most work for client comes from

A) Image positioning

B) Tables

C) Pasting word document which isn't cleaned properly, has some styles that aren't even removable from editor etc.

I think A and B can be solved with good editor (images like mad mimi, good table editor like CKEditor or Aloha). C can be solved with "clean all styles" methods.

Share this post


Link to post
Share on other sites

The way Madmimi relates image and text we can already do with repeatables :)

Share this post


Link to post
Share on other sites

Yep.. kind of. No visual preview, no drag and drop, no clean ui, no resizing of images etc.. It takes much more to create nice and simple UI for that use case.

Share this post


Link to post
Share on other sites

hm... would be a good ImputField module

Share this post


Link to post
Share on other sites

It would. Just not too simple. I find it amazing that there isn't a single open source editor that takes different approach - but there are many editors that are tied to single commercial app (like mad mimi etc). Something like mindplay was talking about here: http://processwire.com/talk/topic/2103-problem-with-tinymce-in-chrome/#entry19695

I'm all in to help contributing in a such module, if there will be a community effort. I believe it is much more JS than it is PW or PHP, so it would be wise to open source it as independent software. Then it would be tied deeply to PW to provide unique and top notch editor. It could also integrate some other editor for basic editing options (links, headings, tables, lists etc).

  • Like 1

Share this post


Link to post
Share on other sites

There was a short wave of WYSIWYM (what you see if what you mean) editors at one point - one of which survived:

http://www.wymeditor.org/

This does not address the visual disconnect that most normal users experience though - it probably makes it worse.

I thought about using Twig templates as these micro-snippets - as there is a JS port of the PHP template engine, this would make it possible to render the templates in real time on the client-side, as well as storing the structured document/data and rendering it on the server-side.

The other approach, is to render purely on the client-side, and send the document/data and rendered result back to the server, but this has one major drawback: if a template changes for some reason, you can't updated the rendered content. (same issue with buggy WYSIWYG's now, for that matter.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...