Tidy sometimes goes ballistic when a block-level element is wrapped in an inline element
OpenPublic

Description

Author: bugs

Description:
Witnessed with Firefox 2.0.0.1 on XP:
http://en.wikipedia.org/w/index.php?title=List_of_poker_terms&oldid=127060338

The definition for Fifth Street renders as follows:
fifth street

  1. The last card dealt to the board in community card games. Also "river". 2.
  2. The fifth card dealt to each player in stud poker.

(actually I don't see the 2., but when I copy/paste, it appears). Compare the
source code:

<span id="fifth street">
; fifth street

The last card dealt to the board in community card games. Also "[[River

(poker)|river]]".

The fifth card dealt to each player in stud poker.

</span>


Version: unspecified
Severity: trivial
URL: http://en.wikipedia.org/wiki/User:Simetrical/9737

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz9737.
bzimport created this task.Via LegacyApr 30 2007, 5:47 AM
bzimport added a comment.Via ConduitApr 30 2007, 5:04 PM

ayg wrote:

I have a writeup at [[User:Simetrical/9737]]. The behavior is rather bizarre,
but I doubt we want to hack Tidy to fix it. Maybe if there's a configuration
option or something, marginally, but the bottom line should be don't wrap block
elements like lists in inline elements like <span> (use <div> instead). Tidy
will try to make sense of it, but it's going to be an uphill battle, and you'll
have some screwed up results like this in particular cases. (The exact trigger
case, incidentally, is an ordered list wrapped in an inline-level element with
an id. Remove the id, or use anything but an ordered list, and you'll have no
visible strangeness.)

Not our bug, not reasonably fixable by us given its lack of severity, INVALID.

bzimport added a comment.Via ConduitMay 31 2007, 3:31 AM

ayg wrote:

*** Bug 10077 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitMay 31 2007, 3:31 AM

ayg wrote:

Also sometimes happens with <font color=...>, per bug 10077. URL updated. The same resolution reason applies.

Ilmari_Karonen added a comment.Via ConduitAug 13 2007, 11:25 PM

*** Bug 10901 has been marked as a duplicate of this bug. ***

MZMcBride added a comment.Via ConduitAug 13 2007, 11:47 PM

Did anyone contact the developers of HTML Tidy?

Ilmari_Karonen added a comment.Via ConduitAug 14 2007, 2:33 PM

After trying unsuccessfully for quite some time to reproduce this bug outside MediaWiki (so that I could report it to the Tidy developers), I finally discovered that the bug is triggered by the presence of a newline at the end of the first list item(!). That is, the following input to Tidy triggers the bug:

<span id="xxx">
<ol><li>Foo
</li><li>Bar</li></ol>

...but the following doesn't:

<span id="xxx">
<ol><li>Foo</li><li>Bar</li></ol>

Thus, we probably _could_ work around it fairly easily by modifying Parser::doBlockLevels() so that the newline gets removed or moved after the </li>. Reopening in light of this.

Ilmari_Karonen added a comment.Via ConduitAug 15 2007, 7:52 PM

Patch to Parser::doBlockLevels() to put newlines after close tags, to work around a bug in Tidy

I've made a quick parser patch that I believe should work around the bug. Some might even argue that it actually makes the output prettier. The reason I haven't committed it yet is that the change breaks about 390 parsertests, and I'm not _quite_ completely and absolutely certain yet that all of those are false alarms. Even if they are, the test cases would still need to be updated.

Attached: parserNewlines2.diff

MZMcBride added a comment.Via ConduitAug 27 2007, 2:22 AM

The Tidy bug tracker (http://sourceforge.net/tracker/index.php?func=detail&aid=1773932&group_id=27659&atid=390963) says that this issue has been fixed in the CVS.

Danny_B added a comment.Via ConduitDec 30 2008, 6:15 PM

*** Bug 16815 has been marked as a duplicate of this bug. ***

mkroetzsch added a comment.Via ConduitFeb 9 2009, 3:40 PM
  • Bug 17417 has been marked as a duplicate of this bug. ***
demon added a comment.Via ConduitAug 12 2009, 12:43 AM

Adding upstream keyword since that's what it is :)

Adding testme...has this indeed been fixed in released versions since #comment 9 (I would assume so)?

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

bzimport added a comment.Via ConduitNov 9 2011, 7:53 PM

sumanah wrote:

screenshot of resulting page, should have shown 3 bullet points

The original steps-to-reproduce now show up as shown, so there's still a problem (if we want that formatting to work).

https://www.mediawiki.org/w/index.php?title=Sandbox&oldid=452753

Attached:

bzimport added a comment.Via ConduitSep 24 2014, 3:26 PM

pravinxyz wrote:

This seems to be problem with IE only.

When I write:

#One
#Two
#Three

<font color=red>
#One
#Two
#Three
</font>

I see (screenshot in Firefox 32.0.2 on Win7):

and (screenshot in IE 8.0.7601 on Win7)

And when I copy and paste, I see:
One
Two
Three
One

Two
Three

Edited using below

Interesting Wiki Bug (look at the automatic numbering):

#One
#Two
#Three

<font color=red>
#One
#Two
#Three
</font>

BUG

  1. One
  2. Two
  3. Three

SPAN
<span style="color: blue>

  1. One
  2. Two
  3. Three

</span>

DIV

<div style="color:#0000FF">

  1. One
  2. Two
  3. Three

</div>

Workaround

<font color=red>

One

#:

Two

#:

Three

</font>

<font color=blue>

One

#:

  1. Two
  2. Three

</font>

  1. One
  2. Two
  3. Three

PRE

<pre style="color: red">

  1. One
  2. Two
  3. Three

</pre>

Aklapper added a comment.Via ConduitOct 17 2014, 10:46 AM
  • Bug 72172 has been marked as a duplicate of this bug. ***
demon removed a subscriber: demon.Via WebSun, Aug 23, 4:09 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldSun, Aug 23, 4:09 PM

Add Comment