Make a new table in WYSIWYG
Start writing in a cell
Hit RETURN to start a new line.
Note that the first line you wrote jumps down a little bit.
Write some text in the 2nd line you just wrote
Save the topic.
View the TML
Note that the WYSIWYG plugin has added an unwanted <P /> in front of the first line.
You can remove it in TML mode but not in WYSIWYG mode.
I can't reproduce this in FF 1.04, FF 1.5 or IE 6, following the above instructions. Guessing it's an artifact of Kupu 1.2 that has been fixed in 1.3.2
The tables behaves differently in IE and FF.
The problem I reported is EASY to reproduce with IE. Very very easy. And it also does it here on develop. I do not use an old kupu when I have an up to date SVN installation I assume.
Please try again. The bug is there.
Ah; assuming the bug I am seeing is the bug you are seeing, then that is not a WysiwygPlugin
bug, nor even a Kupu bug; it is a browser bug. Bill's Browser is Broken Again.
Not much I can do about it, sorry.
Maybe Bills browser is Broken. But that is what people have. Discarding does not make the problem go away.
I do not see a great need for people to put a <P /> as the first string in a table cell. I suggest you strip it off then when the topic is saved. The regex should look for the string right at the beginning of a table cell and strip it off. Making line breaks in tables is quite common and with the current problem quite many people will be very annoyed by this problem.
If people want empty lines in front they will probably use BR tags instead. I am sure you will solve more problems with this workaround than you will create. Naturally such a work around will not prevent the text from moving down when you edit but at least people will not have to re-edit in TML mode to get rid of the unwanted empty lines.
I'm very reluctant to put in "special fixes" for browsers, because of the flak it is bound to cause. For example: user starts with a cell containing only <p/>. Edit in Kupu, save, strip <p/> and the cell disappears because it has no content.
We need a total solution for table cells. Perhaps this technique has a place in it; feedback in Item1231
I understand your reluctance. But sometimes you need silly solutions to work around bugs in other people's software. In this case Billy-Boys browser.
I doubt many will key < p/>. They may press the enter button as the first action and that probably gives a <p> </p> sequence. Or a <BR>. But it is quite normal that people write some text, hit return to make a new line or some white space and write some more text. And this is where the very annoying problem happens with the extra <p />
I do not understand the connection to 1231
The connection to 1231 is the need for a global solution to tables. this problem is just one that relates to that.
After careful thought, I think we have to let this stand. There is no way for the plugin to recognise when a P was added "in error", and for it to strip out Ps in table cells would be a lot more irritating that the current situation.
Discarded, because I have no way to pass a bug on to IE and M$ would claim it's a feature anyway.
Well. I think discarding this bug is the wrong decision. "You can lead the horse to the water but you cannot force it to drink". So I will not reopen this. But I am sure you will see this bug reported again once the plugin becomes part of Dakar - because it makes the plugin close to useless when editing tables in WYSIWYG in IE.