Last modified: 2010-05-15 15:33:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2785, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 785 - * and # are not always replaced following <pre> in list
* and # are not always replaced following <pre> in list
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.4.x
All All
: Normal minor with 2 votes (vote)
: ---
Assigned To: Antoine "hashar" Musso (WMF)
http://meta.wikimedia.org/wiki/Sandbo...
: parser, patch, patch-need-review
: 1873 2914 3396 (view as bug list)
Depends on:
Blocks: 1581
  Show dependency treegraph
 
Reported: 2004-10-26 12:35 UTC by Cyril Cauchois
Modified: 2010-05-15 15:33 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch for closing pre-tag on single line (654 bytes, patch)
2005-02-25 08:09 UTC, Christoph Dittberner
Details
correctly get out of a pre element when using list (921 bytes, patch)
2005-07-08 08:06 UTC, Antoine "hashar" Musso (WMF)
Details

Description Cyril Cauchois 2004-10-26 12:35:09 UTC
Here is the text I enter in the edit form :


* '''Gras''' : <pre> '''Mon texte en gras''' </pre>
* ''Italique'' : <pre> ''Mon texte en italique'' </pre>
* '''''Gras Italique''''' : <pre> '''''Mon texte en gras italique''''' </pre>
* <cite>Police à chasse fixe</cite> : <pre> <cite>Police à chasse fixe</cite> </pre>
* Un Titre de niveau 1 : <pre>=== mon titre 1 ===</pre>
* Un Titre de niveau 2 : <pre>== mon titre 2 ==</pre>
* Un Titre de niveau 3 : <pre>= mon titre 3 =</pre>


The 3rd and the 6th line, the * is not replaced by a bullet ; it appears * in the 
rendered page.
Comment 1 Guttorm Flatabø 2004-10-26 12:51:15 UTC
I have confirmed this here:
<http://nn.wikipedia.org/w/wiki.phtml?title=Brukar:Dittaeva/Sandkasse&oldid=2352>.

The way the text is made you solve the problem by writing it like here
<http://nn.wikipedia.org/wiki/Brukar:Dittaeva/Sandkasse>, using a space in as
the first character of a new line, instead of <pre></pre> on the same line as
the description.
Comment 2 Cyril Cauchois 2004-10-27 07:56:05 UTC
(In reply to comment #1)
> I have confirmed this here:
> <http://nn.wikipedia.org/w/wiki.phtml?title=Brukar:Dittaeva/Sandkasse&oldid=2352>.
> The way the text is made you solve the problem by writing it like here
> <http://nn.wikipedia.org/wiki/Brukar:Dittaeva/Sandkasse>, using a space in as
> the first character of a new line, instead of <pre></pre> on the same line as
> the description.

Ok this way, the text is framed, but it is interpreted. I used <pre> in order to see formatting 
characters ; I don't want them to be rendered.
Comment 3 Guttorm Flatabø 2004-10-27 08:13:00 UTC
(In reply to comment #2)
> Ok this way, the text is framed, but it is interpreted. I used <pre> in order
to see formatting 
> characters ; I don't want them to be rendered.

True, I didn't notice that. It iterprets and formats the bold and italic text
but not the headers. I think that is also a bug!?
Comment 4 Antoine "hashar" Musso (WMF) 2004-11-09 15:41:33 UTC
confirmed in HEAD.
Comment 5 Antoine "hashar" Musso (WMF) 2004-11-09 16:01:11 UTC
Simplier test case:

--[Cut below]-------
* <pre>foo1</pre>
* <pre>bar2</pre>
* another list item
--[Cut above]-------
Comment 6 Brion Vibber 2005-01-29 07:27:34 UTC
Confirmed still present in REL1_4 and HEAD.
Comment 7 Christopher W. Curtis 2005-02-16 06:33:13 UTC
I think this bug is more generic than what is stated.  Here is the problem I've
found in the latest (2005-02-08) release:

#Item 1<pre>pre1</pre>
#Item 2<pre>pre2</pre>
#Item 3<pre>pre3</pre>
#Item 4<pre>pre4</pre>
#Item 5<pre>pre5</pre>
#Item 6<pre>pre6</pre>

And you can't just add newlines with spaces because it breaks the numbering, so
there is no workaround (that I've been able to find).
Comment 8 Brion Vibber 2005-02-16 07:11:25 UTC
(In reply to comment #7)
> I think this bug is more generic than what is stated.  Here is the problem I've
> found in the latest (2005-02-08) release:

That looks exactly like the samples already provided. All list types are processed with the same code, so it would be 
surprising for numbered lists to behave differently from bullet lists here.
Comment 9 Christoph Dittberner 2005-02-24 09:50:57 UTC
(In reply to comment #7)
> I think this bug is more generic than what is stated.  Here is the problem I've
> found in the latest (2005-02-08) release:
> 
> #Item 1<pre>pre1</pre>
> #Item 2<pre>pre2</pre>
> #Item 3<pre>pre3</pre>
> #Item 4<pre>pre4</pre>
> #Item 5<pre>pre5</pre>
> #Item 6<pre>pre6</pre>
> 
> And you can't just add newlines with spaces because it breaks the numbering, so
> there is no workaround (that I've been able to find).

If you look at the parser code in includes/Parser.php there is a handling for a
pre-open tag but no handling if the pre-close tag is in the same line. Something
like this should solve the problem:
old:
$preOpenMatch = preg_match('/<pre/i', $oLine);

new:
$preOpenMatch = preg_match('/<pre(.*)$/i', $oLine,$preOpenMatches );
$preOpenCloseMatch = preg_match('/\s*\/\s*pre\s*>/i', $preOpenMatches[1] );
$preOpenMatch -= $preOpenCloseMatch;

Comment 10 Christoph Dittberner 2005-02-25 08:09:45 UTC
Created attachment 313 [details]
patch for closing pre-tag on single line
Comment 11 Christoph Dittberner 2005-02-25 08:10:52 UTC
Comment on attachment 313 [details]
patch for closing pre-tag on single line

mediawiki 1.4rc1
Comment 12 JeLuF 2005-03-13 21:18:57 UTC
Notice: Undefined offset: 1 in /var/www-phase3/includes/Parser.php on line 1518
Patch apparently doesn't work when there's no <pre> within the page
Comment 13 JeLuF 2005-04-11 18:51:30 UTC
*** Bug 1873 has been marked as a duplicate of this bug. ***
Comment 14 Antoine "hashar" Musso (WMF) 2005-07-08 07:43:15 UTC
Probably got a fix for it. Under testing at the momment.
Comment 15 Antoine "hashar" Musso (WMF) 2005-07-08 08:06:20 UTC
Created attachment 679 [details]
correctly get out of a pre element when using list

* remove a test to find if the parser is in a pre block. This is already done
at the beginning of the foreach.
* correctly get out of pre block when we have </pre>
Comment 16 Antoine "hashar" Musso (WMF) 2005-07-08 08:08:38 UTC
My patch need review. It passes the parser test but I am not sure
it is the best way to get out of the pre block.
Somewhere above in the code, there must be a point where the pre
block is closed. That's where the patch should occur. Unfortunatly
I haven't been able to find that point :(
Comment 17 Antoine "hashar" Musso (WMF) 2005-07-13 15:19:55 UTC
Commiting, I haven't found a better way to do it.
Parser test already in cvs.
Comment 18 Zigger 2005-08-06 06:56:42 UTC
*** Bug 2914 has been marked as a duplicate of this bug. ***
Comment 19 Brion Vibber 2005-09-08 08:50:19 UTC
*** Bug 3396 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links