Item4895: Large help text displayed by default with Opera

A very large WYSIWYG help text is displayed above the main text box when using opera 9.24 on Linux on ~twiki4 site. Presumably this is meant to be un-expanded? It's so large that it hides the text box further down the page. It would be good if the TMCE/WYSIWYG setup, which I guess is involved here, fails safe so that the basic edit approach works with non-IE/Firefox browsers. Or just make the main help text shorter, I think it's really too long if it fills the whole vertical part of 22" flat screen, even when it's explicitly expanded by the user clicking the twisty. Surely we can have a shorter help text without all the screenshots, as the main help, and maybe have the larger help text in a pop-up window? (But beware TWiki:Codev.BackFromPreviewLosesText - this loss of latest edits bug was also caused by pop-up help on IE.) It would be good if the TMCE/WYSIWYG setup, which I guesss is involved here, fails safe so that the basic edit approach works with non-IE/Firefox browsers.

-- TWiki:Main/RichardDonkin - 27 Oct 2007

UPDATE: Tested with Firefox 2.0.0.8 and this problem did not happen.

However, WYSIWYG mode on ~twiki4, on this topic, crashed Firefox on Linux - hung for a while downloading page and did not show text cursor in textbox. This is clearly a FF bug but this probably means TMCE is not really ready for release, until it avoids stepping on browser crash bugs, IMO. The version of Firefox was 2.0.0.8, latest version from the Ubuntu repositories on Ubuntu Feisty 7.04, fully updated.

---

You are reporting several problems here, in the same report.

The expanded help. This is a problem with Twisty Contrib, I think (or maybe pattern skin). I see the same effect with Safari 3 on Windows. I'm glad someone else sees this, I thought I was the only one :-(. Confirmed.

The length of the help. Yes, I'm sure we could have a shorter help, if someone who was any good at writing help information was prepared to pitch in and help write some. This support has been promised several times, but never delivered, so we are stuck with what we have.

FYI the editor does have a validation step to block navigate away if data loss is risked, and does fail safe if certain agent strings are seen (see TinyMCEPlugin).

I'm sorry, "but "crashed Firefox" is nothing like enough information. However I will note that TinyMCE has been in use on this site for several months now, from a wide variety of browsers. I use it daily from Firefox 2.0.0.8 and have never seen a browser crash that could be attributed to TMCE. Further, TMCE has been in use of a large number of CMSes for a lot longer than we have been using it. So, it might not be ready for primetime, but it's at least as ready as Firefox. If you can reproduce this crash, please open a fresh report.

CC

Sorry about the two reports in one, but this does sometimes happen when I report WYSIWYG bugs, i.e. I get another bug when reporting the first one..

The expanded help is the main issue, but really it's best if we whitelist the user agents that work, and only use the twisty then if that makes sense, i.e. simply omit the help for browsers that we do not explicitly support with TMCE.

"Crashed Firefox" is exactly what happens, I don't see how I could say any more about that i.e. process died. However, it isn't reproducible (lost in the conflict checks though otherwise they worked well) so can probably ignore it for now.

-- TWiki:Main.RichardDonkin - 27 Oct 2007

I looked at whitelisting the agents that work, but rapidly ran into the usual issues when interpreting user agent strings. I decided it was unreliable and, since the set of non-working browsers seems to be quite a bit smaller than the set of working browsers, I decided to blacklist rather than whitelist.

CC