After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 345463 - the generated html for bullets is incorrect
the generated html for bullets is incorrect
Status: RESOLVED DUPLICATE of bug 334814
Product: GtkHtml
Classification: Other
Component: Editing
3.10.x
Other All
: Normal normal
: ---
Assigned To: gtkhtml-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-06-20 19:23 UTC by Jorge Urdaneta
Modified: 2006-06-25 06:31 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
i saved to a file a message with bullets from the sent directory (1.97 KB, message/rfc822)
2006-06-20 21:49 UTC, Jorge Urdaneta
  Details
the patch to fix the bug (549 bytes, patch)
2006-06-23 19:03 UTC, Jorge Urdaneta
none Details | Review

Description Jorge Urdaneta 2006-06-20 19:23:08 UTC
Please describe the problem:
when i write a message using bullets (html formatting) the generated html code doesn't look good under some browsers like those using gecko. The problem (looking the code) is that some tags are missing. The missed tags are:
* <ul> that start the bullet section
* </li> that should be at the end of each item
* </ul> that ends the bullet section 

Steps to reproduce:
1. Write a message with a bullet section with some items
2. Send the message to someplace were you can see it using a browser
3. See the message using a geko based browser


Actual results:
The bullets aren't shown correctly because the html code is invalid
something like that:
<li>item1
<li>item2
<li>item3
... so on ...

There isn't <ul> at the begining nor </li> at the end of the items nor </ul> at the end

Expected results:
something like that:
<ul>
  <li>item1</li>
  <li>item2</li>
  <li>item3</li>
  .... so on ...
</ul>

Does this happen every time?
yes

Other information:
that invalid html code looks good inside evolution, IE and Konqueror
Comment 1 André Klapper 2006-06-20 20:02:39 UTC
does not happen here, evolution 2.7.3/gtkhtml-3.11.3 correctly sets
<UL>
<LI>bla
<LI>bla
<LI>bla
</UL>

which gtkhtml version do you use?
Comment 2 Jorge Urdaneta 2006-06-20 21:16:37 UTC
It is the 3.10.2 on Dropline Gnome 2.14.2

But the code that you show still need the tag </LI> at the end of the bla's. Like this:

<UL>
<LI>bla</LI>
<LI>bla</LI>
<LI>bla</LI>
</UL>
Comment 3 Jorge Urdaneta 2006-06-20 21:18:03 UTC
forgot the evolution version. It is 2.6.2
Comment 4 André Klapper 2006-06-20 21:31:32 UTC
http://www.w3.org/TR/1998/REC-html40-19980424/intro/sgmltut.html#h-3.2.1 :
"Some HTML element types allow authors to omit end tags (e.g., the P and LI element types)", so this if you have problems in gecko based browsers, file a bug against them. this is not an evolution bug (though i'd also love to see evolution to add </li> tags - (i know that evolution generates pretty crappy html code, anyway, it's still valid code).

i cannot reproduce the missing <UL></UL> tags, though, so if you find a way, please reopen this bug.
Comment 5 Jorge Urdaneta 2006-06-20 21:49:35 UTC
Created attachment 67740 [details]
i saved to a file a message with bullets from the sent directory

I haven't seen the tag </UL> before but in this file it is present
And looks like the gtkhtml version that i use put an empty tag instead of <UL>
Comment 6 André Klapper 2006-06-20 22:08:21 UTC
hmm... indeed.
Comment 7 Jorge Urdaneta 2006-06-23 15:53:54 UTC
I changed int the file htmlclueflow.c the function get_start_indent_item near to the line 1553 and looks like:

static const char *
get_start_indent_item (HTMLListType type)
{
	/*JU*/
	
	FILE *f =fopen("/home/jorgeu/gtkhtml_log.log","a");
	fprintf(f,"wanna get the item type %d\n",type);
	if (type) {
		switch (type) {
		case HTML_LIST_TYPE_UNORDERED:
		case HTML_LIST_TYPE_MENU:
		case HTML_LIST_TYPE_DIR:
			fprintf(f,"UL!\n");
			return "UL";
		case HTML_LIST_TYPE_ORDERED_LOWER_ALPHA:
			return "OL TYPE=a";
		case HTML_LIST_TYPE_ORDERED_UPPER_ALPHA:
			return "OL TYPE=A";
		case HTML_LIST_TYPE_ORDERED_LOWER_ROMAN:
			return "OL TYPE=i";
		case HTML_LIST_TYPE_ORDERED_UPPER_ROMAN:
		return "OL TYPE=I";
		case HTML_LIST_TYPE_ORDERED_ARABIC:
			return "OL TYPE=1";
		case HTML_LIST_TYPE_GLOSSARY_DD:
		case HTML_LIST_TYPE_GLOSSARY_DL:
			return "DL";
		case HTML_LIST_TYPE_BLOCKQUOTE_CITE:
			return "BLOCKQUOTE TYPE=CITE";
		case HTML_LIST_TYPE_BLOCKQUOTE:
			return "BLOCKQUOTE";
		default:
			fprintf(f,"requesting an unknow type!! (%d)\n",type);
		}
	} else {
		fprintf(f,"requesting NULL type!!!\n");
		return "";
	}
	fclose(f);
}

Compiled and installed and test it with evolution creating a message with a bullet like 

*bla
*bla
*bla

Then the file /home/jorgeu/gtkhtml_log.log has that content:

$ cat /home/jorgeu/gtkhtml_log.log
wanna get the item type 0
requesting NULL type!!!

I saw that the function save near line 1807 in the same file, calls the above function and looks like data loaded in the object passed is the problem, so i think that maybe evolution isn't using gtkhtml correctly for unordered lists.

Hope it help
Comment 8 Jorge Urdaneta 2006-06-23 18:29:03 UTC
wait, wait, wait!

looking at htmlenums.h i have seen the light...

at line 129:

typedef enum {
        HTML_LIST_TYPE_UNORDERED,
        HTML_LIST_TYPE_ORDERED_ARABIC,
        HTML_LIST_TYPE_ORDERED_LOWER_ALPHA,
        HTML_LIST_TYPE_ORDERED_UPPER_ALPHA,
        HTML_LIST_TYPE_ORDERED_LOWER_ROMAN,
        HTML_LIST_TYPE_ORDERED_UPPER_ROMAN,
        HTML_LIST_TYPE_MENU,
        HTML_LIST_TYPE_DIR,
        HTML_LIST_TYPE_BLOCKQUOTE,
        HTML_LIST_TYPE_BLOCKQUOTE_CITE,
        HTML_LIST_TYPE_GLOSSARY_DL,
        HTML_LIST_TYPE_GLOSSARY_DD
} HTMLListType;

HTML_LIST_TYPE_UNORDERED is 0!!!!

so, the function get_start_indent_item is considering that it is invalid or unknow

changing it to:


static const char *
get_start_indent_item (HTMLListType type)
{
	switch (type) {
		case HTML_LIST_TYPE_UNORDERED:
		case HTML_LIST_TYPE_MENU:
		case HTML_LIST_TYPE_DIR:
			return "UL";
		case HTML_LIST_TYPE_ORDERED_LOWER_ALPHA:
			return "OL TYPE=a";
		case HTML_LIST_TYPE_ORDERED_UPPER_ALPHA:
			return "OL TYPE=A";
		case HTML_LIST_TYPE_ORDERED_LOWER_ROMAN:
			return "OL TYPE=i";
		case HTML_LIST_TYPE_ORDERED_UPPER_ROMAN:
		return "OL TYPE=I";
		case HTML_LIST_TYPE_ORDERED_ARABIC:
			return "OL TYPE=1";
		case HTML_LIST_TYPE_GLOSSARY_DD:
		case HTML_LIST_TYPE_GLOSSARY_DL:
			return "DL";
		case HTML_LIST_TYPE_BLOCKQUOTE_CITE:
			return "BLOCKQUOTE TYPE=CITE";
		case HTML_LIST_TYPE_BLOCKQUOTE:
			return "BLOCKQUOTE";
		default: 
			return "";
	}
}

solves the problem!!!

I have tested it and everything work perfect!! :D

It is my first fix!
Comment 9 Jorge Urdaneta 2006-06-23 19:03:23 UTC
Created attachment 67902 [details] [review]
the patch to fix the bug

here is the patch!
Comment 10 Jorge Urdaneta 2006-06-25 02:42:42 UTC
Can any of the maintainers verfy that the problem is solved and notify the packagers of the distros?
Comment 11 Jorge Urdaneta 2006-06-25 06:31:37 UTC
ups!, searching in the lauchpad of ubuntu y landed on the bug #334814 that months ago were reported and fixed officialy

*** This bug has been marked as a duplicate of 334814 ***