Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TinyMCE does not initialize properly when composing an email using the classic skin and Firefox #4788

Closed
rcubetrac opened this issue Mar 10, 2015 · 6 comments

Comments

Projects
None yet
1 participant
@rcubetrac
Copy link

commented Mar 10, 2015

Reported by hobbyist on 10 Mar 2015 08:42 UTC as Trac ticket #1490310

Beginning with Roundcube 1.1.0 I watched some problems that, under some circumstances, prevent TinyMCE to initialize properly when composing an email using the classic skin.
When the editor has been loaded, the pane in which normally the textfield appears, remains empty, but TinyMCE's buttonbar above is loaded correctly. If you move the slicer between composing- and attachment-area, the textfield will be shown and you can compose your mail. Next time composing a mail within the same session the editor initializes at once, but if you restart the browser the phenomenon will appear again.

First time I had supposed that this issue was caused by the low resolution of my netbook, but some more of our users confirmed this behaviour on their desktops with higher resolutions. I observed that all users use Firefox about version 35 or higher. It doesn't matter if you use Windows or Linux as operating system. Some systems work at once, others behave as described.

Maybe it is offtopic, but when having this behaviour the followin css error occurs: "downloadable font: OS/2: bad linegap: -32 {font-fmaily:"tinymce-small" [http://www.tinymce.com/develop/bugtracker_view.php?id=7422](...]"
compare:[)

What I tried yet, but the problem remains:

  • Removing all plugins, especially the legacy_browser plugin, I accused wrongly
  • Using the original skin without adaptions
  • Replacing the woff font files because of the error message
  • Replacing some more files of TinyMCE

Can somebody solve this issue or at least confirm it? By now, I suppose it is a caching or runtime problem of Firefox when loading the page.

Keywords: Tinymce, Firefox, initialisation
Migrated-From: http://trac.roundcube.net/ticket/1490310

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 10, 2015

Comment by @alecpl on 10 Mar 2015 08:51 UTC

The font issue is probably unrelated and fixed in git with update to TinyMCE 4.1.8.

What I suspect is that it might be the issue described here http://www.roundcubeforum.net/index.php/topic,22159.msg59704.html#msg59704. Could you check and confirm the solution proposed there?

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 10, 2015

Milestone changed by @alecpl on 10 Mar 2015 08:51 UTC

later => 1.1.1

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 10, 2015

Comment by hobbyist on 10 Mar 2015 09:05 UTC

Thanks for that quick crosspost, I haven't found yet. The problem description sounds different, but maybe it's another expression of the same error.

I will try the patch later, because (luckily) I can't reproduce it on this machine. I will also try the nightly build of tinyMCE, if the patch you refered fails.

Again thanks in advance.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 10, 2015

Comment by hobbyist on 10 Mar 2015 20:25 UTC

Hey Alec,
thanks for the hint. It works for me. I can't reproduce the behaviour after integrating the code. I asked some users for further confirmations.

I merely had problems to use the patch command for inserting the changes from the board's post, so I did it manually. And of course afterwards you must remember to use bin/jsshrink.sh to minimize the modified jsfile ;-)

BTW: Great Work!

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 11, 2015

Comment by @alecpl on 11 Mar 2015 18:35 UTC

Fixed in a172f39.

@rcubetrac

This comment has been minimized.

Copy link
Author

commented Mar 11, 2015

Status changed by @alecpl on 11 Mar 2015 18:35 UTC

new => closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.