113476 - Converting formatted text into a table will create visible HTML code on page

Status: NEW

(SeaMonkey :: Composer, defect, P3)

Description

[TucsonTester1]

Tested on Composer rev. 2001120303 on Win 98

Steps to reproduce:
1. Launch Composer and create a new blank page
2. Enter five lines of text with 20 characters each
3. Select all text and increase the size once, apply bold, underline, italic,
and a color then make it into a numbered list.
4. While the text is still selected, click on TABLE then CREATE TABLE FROM
SELECTION (The default paramaters are fine)

Exptected results:
Each line of text should be placed inside a table cell and retain its rich text
formatting. 

Actual results:
The text will be inserted into table cells although the first cell will not
retain its color because the tag is now visible on the page right before the
text (e.g color="#33ff33">testtext)
If the text is hyperlinked, the href tag will be visible instead.

Comment 1

[TucsonTester1]

For my step 4 where the table is created, it appears that the default settings
might not recreate the bug. Instead we need to make sure the table creation
parameters are set to use a space to separate columns versus a comma or other
character. 

This bug is reproducible every time.

Comment 2

[Syd Logan]

I misapplied the steps, forgetting to assign a color, and not converting to a
bulleted list (i.e., make a table out of 5 rows of styled text). The result --
all the style (size, italic, underline, and bold) is applied only to the first
cell in the table. The rest are plain text.

Since taking 5 rows of styled text and converting to a table has got to be a
basic operation, marking EDITORBASE.

Comment 3

[Joe Francis]

who owns the relavent table making code?  charlie?  I can help you with this, but 
I'm hoping you can investigate first.

Comment 4

[Charles Manske]

There are no "default" settings once you use the dialog, since they persist, so
I'm glad you specified that.
Loosing text styles in the table created is covered by bug 99487.
This feature is done by character substitution of the HTML source strings, which
is efficient, but makes it very difficult to redistribute text properties into
the table cells. Usually, inline properties are retained only for the first cell.
This feature should probably be rewritten to use DOM node manipulation (that's 
where jfrancis can help!)
So if we want to consider this EDITORBASE, that's fine, but it won't be fixed 
for moz 1.0. 
But we should not be mangling the source in such as way as to destroy the inline
styles, which is why we are seeing some HTML source in the resulting table.
At least that part should be fixed sooner.

Comment 5

[TucsonTester1]

Able to reproduce on Mac OS X Build 2001121805. Changed Platform/OS to all.

Comment 6

[Kathleen :Brade]

marking EDITORBASE- per meeting
cmanske to re-evaluate

Comment 7

[Charles Manske]

changing milestone

Comment 8

[mel pullen]

A bit confused about progress, it appears to have 1.2beta as milestone, yet
remains at Assigned. Sorry, I'm new to this defect system.

I still find this defect on Mac OSX, 'about' says it is:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130

I created some text and asked for it to be converted into a table. The
formatting was visible in the normal, tags and preview mode and the tags had
been escaped in the HTML source mode. Table conversion is disabled in source
mode, so there appears to be no work-around.

Comment 9

[Charles Manske]

Sorry about lack of progress. I'll try to look at it soon

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:hsinyi, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 12

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Still reproducible with SeaMonkey 2.53.11.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I cannot reproduce this bug with Thunderbird Daily ("Format" -> "Table" has "Create Table from Selection").

This feature is implemented by JS in chrome.

• https://searchfox.org/comm-central/rev/e8c18e9b507f8fe0db25ca5d9ce63b5ce9014663/suite/editor/components/dialogs/content/EdConvertToTable.js#77
• https://searchfox.org/comm-central/rev/e8c18e9b507f8fe0db25ca5d9ce63b5ce9014663/mail/components/compose/content/dialogs/EdConvertToTable.js#77

So anyway, this is not a bug of editor.