Last modified: 2005-01-05 16:46:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1114 - "%0a" in URL is matched as a new-line
"%0a" in URL is matched as a new-line
Status: RESOLVED DUPLICATE of bug 752
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Talk:Moz...
: parser
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-16 13:38 UTC by Rowan Collins [IMSoP]
Modified: 2005-01-05 16:46 UTC (History)
0 users

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


Attachments

Description Rowan Collins [IMSoP] 2004-12-16 13:38:08 UTC
As you should be able to see, everything below the section of discussion
referenced, including other headers, is indented as though it were prefixed with
"::". It turns out that there is a URL referenced there which ends in "%0a"
(i.e. an escaped linefeed), and this is somehow breaking the parser;
specifically, the indentation of that particular line is never closed, so
everything below it is indented to the same degree.

I've constructed a simplified test-case at http://test.wikipedia.org/wiki/LFURL,
and it seems that what's happening is that the "%0a" is being unescaped in the
'title' attribute, and then the closing "</dd></dl>" added *to that attribute*.
Presumably, the parser is spotting what is now a plain newline and taking it to
be the end of the indentation.

I'm guessing there's code somewhere that unescapes such escape sequences to make
URL title attributes more readable [the href attribute works fine]; perhaps this
needs to be confined to only unescape printable characters?
Comment 1 Zigger 2005-01-02 08:24:34 UTC
Is this a duplicate of bug 752 ?
(test.wikipedia.org seems to be offline)
Comment 2 Rowan Collins [IMSoP] 2005-01-05 16:46:21 UTC
(In reply to comment #1)
> Is this a duplicate of bug 752 ?

Ah yes, so it is - I wonder why I didn't find that when searching...



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

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


Navigation
Links