Jump to content

Problem with TinyMCE in Chrome


mindplay.dk
 Share

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...

Link to comment
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?

Link to comment
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/

Link to comment
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
Link to comment
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.

Link to comment
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.

Link to comment
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...

Link to comment
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
Link to comment
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.

Link to comment
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
Link to comment
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! :)

Link to comment
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 :)

Link to comment
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.

Link to comment
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
Link to comment
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.)

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...