Item9424: Wysiwyg editor resize broken in IE8
Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
You need trunk and you need IE8 to test this
Try and edit (wysiwyg) a topic.
Now resize the edit windows by mouse clicking the lower right corner.
The resize should be in effect as long as you keep the left mouse key clicked. But it continues to resize even when you let go of the button.
You have to click again on the left mouse button to release the resize mode.
Very confusing and a clear release blocker bug
--
KennethLavrsen - 01 Aug 2010
Will not be able to get to this until after 14 Aug. Maybe a beta release is doable with this left unfixed if it's mentioned in the known issues.
--
PaulHarvey - 03 Aug 2010
I don't agree this should be a release blocker.
- It's irritating, but it's fairly obvious how to work round it and doesn't actually prevent you from doing anything.
- It is highly likely to be a TMCE bug requiring reporting upstream. The resizing is a standard TMCE plugin that we just enable.
- Given that it works perfectly on Mozilla, the alternative may be it's an IE8 bug, with even less chance of an upstream report being acted on.
We should not be holding up a release for something like this - if we did, we'd have to hold it up forever.
--
CrawfordCurrie - 09 Aug 2010
This feature works fine in Foswiki 1.0.9
This bug will be experienced by normal end users. Most of them will see it. IE is still the most common browser in business environments. And IE8 is even the most recent of IE.
The bug is not visible on the Moxi demo site. So it is the way we use the plugin that causes the problem.
This bug is very serious. Admins upgrading from 1.0.9 to a 1.1 beta would be flooded with end user reactions against this and the performance bug.
We cannot sacrifize qualiity on such important end user interface. We have raised urgent bugs - we still have urgent bugs that only builders of advanced wiki apps will experience.
This is visible by anyone editing. Resizing the window is not an expert thing. It is daily use. It has to work.
I would never even consider installing a
--
KennethLavrsen - 09 Aug 2010
This is caused by jquery 1.3.2.
Marking for Micha's attention to consider shipping 1.4.2 as default jquery lib.
To-do:
- Test that 1.3.3 fixes the problem. In this case, let's upgrade JQueryPlugin to ship with 1.3.3 instead of 1.3.2
Options:
- Ship stand-alone instead of jquery build of TinyMCE. AFAICT the Moxie guys are slowly re-writing TinyMCE to abstract all their sizzle functionality to be plugged in with jquery. They do seem to be picking jquery as their long-term strategy. But AFAICT there is no real loss in us switching to the non-jquery build. I have used some jquery in foswikibuttons and friends but this should continue to work as long as JQueryPlugin is enabled.
- Upgrade Foswiki 1.1 to ship with 1.4.2 by default. This breaks chili, among other things.
--
PaulHarvey - 10 Aug 2010
Since when is 1.3.3 released? Can't find it at
http://docs.jquery.com/Downloading_jQuery#Past_Releases
Can we disable the resize plugin? I'd recommend that with
NatEditPlugin anyway.
--
MichaelDaum - 10 Aug 2010
Yikes, where did I read that.. Ok. Give me a couple of weeks. Should have time next week to think this through
--
PaulHarvey - 10 Aug 2010
I think this is fixed. Use non-jquery build of TinyMCE. I think it's madness that we have users manually resizing the editor every time. I will take the
NatEditPlugin autosize work I did and make it a generic plugin that should work on
PatternSkin as well. Or should we wait for until after Foswiki 1.1.0. I can do it is a separate
TinyMCEAutoSizePlugin perhaps. Kenneth?
--
PaulHarvey - 16 Aug 2010
We can close this. I will add new MCE plugin in a different task to autosize editor. It will not be enabled by default for Foswiki 1.1.0
--
PaulHarvey - 16 Aug 2010