Wiki Wiki Bugs

Suggested Pattern for a New WikiCitizen adding to this page: Read this page and WikiWikiBugsResolved before you write to it. Also check out WikiWikiSuggestions; that bug you found might just be a feature request.

Sometimes Wiki exhibits behavior that surprises us, and that may or may not be a bug. Try visiting WikiQuestions to see if anyone else has seen the same behavior, or perhaps add your question if not.

Notes: The indexing of this page has been improved to make it easier to find. Edit collisions note from Ward moved to EditConflictResolution. TooBigToEdit discusses the problem of editing large WikiWiki pages with some browsers. 

  Sand Box 37, -37, 1, new 2861,

The pages produced by the QuickDiff feature (which rocks!!!) produce tables which are exactly 600 pixels wide. This is a BadThing as it means you can see less of big changes in wide browsers, and less of changes in small browsers (palm/CE devices). -- BrianEwins

The pages produced by the QuickDiff feature (which rocks!!!) underline and turn blue BumpyCase words which should only have a blue question mark following them. I love the feature. Thanks. -- ChrisGarrod

If you go to http://c2.com/cgi/wiki it will display the content of FrontPage. All the links work except the referer-based ones: BackLinks, LikePages, VisualTour, etc. My suggestion for fixing this is to issue "301 Moved permanently" for any URL which resolves to Wiki content but !~ m{(www\.)?c2\.com/cgi/wiki\?.}i . The only side-effect I can think of would be to break access for people who are forced to do some strange form of munging to get past a firewall. (Yes I know the (www\.)? is redundant since the pattern isn't left anchored, but it serves to illustrate lack of prejudice against the alternative URL form.)

Here are a few problems recently noted with LikePages:

  1. The page from which the request was made should not be included in the lists.
    • Sorry - have to disagree on this one. I like having the "back" feature this implies. I know that any 21st century browser will do it, but it's nice anyway. -- MartySchrader

  2. Clicking on a link on the LikePages page results in another call to LikePages, which is not what one would expect.
  3. Each link listed by the like function contains a trailing space.

http://www.example.com/Note/The/Trailing/Colon: <-- the trailing colon gets slurped into the URL, which is not similar to the existing "ignore trailing punctuation" rule. [This is documented, but inconvenient.]

Excess Spacing: <p></p> in pre-formatted text

This Wiki produces invalid HTML for some pages. Its handling of pre-formatted text is especially irritating.

On page LongFunctionsDiscussion, someone noted "(Note that Mozilla displays too many blank lines in this example.)" and "visual spacing is a key element of this debate".

We have some text that's already just the way we want it. The space character at the beginning of each line *should* tell the Wiki parser to leave it alone. In the middle of that text, there is a single blank line.

edit mode: 

  //---- Wake Up ----
  [blank line here]
  foo = bar + adsfsdf()
Wiki rendered (as of 2004-04-17) 

  <PRE>
  //---- Wake Up ----
  <p></p>
  foo = bar + adsfsdf()
  </pre>
Wiki should render it as 

  <PRE>
  //---- Wake Up ----
  [blank line here]
  foo = bar + adsfsdf()
  </pre>
which gives correct results on all browsers.

This breaks the rules for HTML (<p> is illegal inside <PRE> ... </PRE>, according to http://validator.w3.org/). -- BruceAdams

What's the best way to fix this?

-- DavidCary

You could either generate 

 </pre><br/>&nbsp;<br/><pre>
or simply 
 " \n"
The same thing happens with the KonquerorBrowser too, so it isn't just a Mozilla/Netscape problem. In any case, I have a lot of difficulty thinking of any way to interpret the spec that would justify this behaviour. -- GarethMcCaughan

by "this behavior", do you mean the allegedly invalid HTML that the WikiEngine is producing, or the strange inconsistencies between web browsers?

I certainly think this is a minor Wiki bug. But, it is a bug. http://validator.w3.org/ is very good at telling you if your HTML is valid. By its standards, ordinary Wiki pages have a few problems, all of which, I think, should be fixed. If the code is available, I'd be happy to make the fixes myself. -- BruceAdams

I disagree that it is minor. It makes for some ugly-looking and sometimes confusing code samples and AsciiArt. Perhaps "medium" bug? Why do you rank it low? True, its not a show-stopper, but it's either uglied-up or made editing difficult for roughly 50 pages that I've read or participated in. It has a medium-low per-page impact, but it is a high-quantity bug. And, non-IE browsers are growing more common. I'd like to see the cost/benefit analysis compared to other wiki bugs.

I noticed that people are altering their formatting habits apparently to work around this bug, resulting in non-WYSIWYG text in the edit view.

FireFox 2 rendering suffers from this also.

It seems a re-formatting gnome is going around and "fixing" the spacing in the edit window, which breaks it in Mozilla-based browsers (showing excess space). They are probably using Internet Explorer and not realizing the impact of their spacing "fix".

<p></p> in non-pre-formatted text

WikiWiki uses <p></p> for the empty line between paragraphs. In OperaBrowser, this is rendered as a line break, not an empty line. This makes all paragraphs run together. Readability suffers. -- RichardCyganiak

And there is no real reason. You could put <P> into the header, </P> into the footer, and <P> or even </P><P> in place of a blank line.

Recent versions of OperaBrowser (checked with 7.02) render <p></p> as an empty line, solving this problem. However, marking up paragraph breaks as <p></p> is still a bad idea. -- RichardCyganiak

[Doing without <p></p> is a litttle tricky if one wishes to avoid the side-effect of unwanted blank lines.]

Why can't the WikiEngine simply use <p>? My HTML 4.01 documents never have any </p>, and they (usually) pass the W3 validator.

things that may look like invalid HTML, but turn out to be perfectly valid

I've noticed that the source for the "?edit=[WikiName]" page look like this at the end: FrontPage <input type="hidden" size=1 name="post" value="WikiName"></form>

Is there a reason for the trailing "body" and "html" tags to be missing? -- AndrewMartin

The HTML pages returned by Wiki are not HTML since they do not have an HTML-element. Just look at the source code of the page you are currently viewing.

The HTML 4.01 spec says that the start and end tags for the HTML element are optional. The pages have HTML elements; their tags are just implicit.

I just edited LinuxDistribution, but this did not show up on RecentChanges. It did not appear on QuickChanges either. It should not have been on the latter two anyway of course, but I checked them just in case. And no, I did not remove the line when I edited RecentChanges a little bit later. Maybe a grue hiding in the dark ate the line. ;-) -- MarkoSchulz

With OperaBrowser for the mac (which claims to be fully http 1.1 compliant), Wiki doesn't provide <br> tags for LF/CR even when such is specified on the edits page. This makes text that isn't supposed to run together do so. (9/2001)

The data sent in a textarea field can basically be anything so http1.1 compliance doesnt come into it. Mac sends CR, windows sends CRLF, and unix sends LF for line ends in this embedded text (while the HTTP request as a whole is only supposed to use CRLF, your submission is often encoded and thus the original macness shines through). The regexp for para breaks probably needs changed to something like /\r{2,}|(?\r\n){2,}|\n{2,}/ , but you need to be careful about the magicness of \n in perl. -- BrianEwins

If the text contains '\ text', 'ext' is listed as a spelling error.

Jan 2, 2004: Is this a bug? Or am I doing something wrong? I haven't seen this before. I attempted to edit AutomaticLocking the ordinary (and only) way, and when it was saved, all the whitespace was encoded, and all the formatting characters were treated literally. It was like the cgi output from the form submission was not processed. This happened only in a recent version of Mozilla for Linux, and not Firebird. I was able to fix the damage (when others didn't get to it first) by using Firebird. I hope this edit works okay now.

Archived pages appear to be susceptible to deletion. See comment at the bottom of HistoryPages.

Question: Why do these both work, but the "," version not display the WikiWiki logo?

http://www.c2.com/cgi/wiki,?FindPage

http://www.c2.com/cgi/wiki?FindPage

Microsoft Live-Search inserts commas in URL links sometimes.

ReverseIndex is not working when you click on the title.

When using features at the bottom of each page:

Clicking on the (broken) image in the VisualTour item at the bottom currently produces an error from this page: "http://www2.research.att.com/~north/cgi-bin/webdot1.7.11/webdot.cgi/http://c2.com/cgi/locale/w2.d2/WikiWikiSuggestions.dot.dot.map?18,15"

Clicking on LikePages link at the bottom currently produces: "The requested URL /cgi/like was not found on this server."

Why is this image not in-lining? Are the dashes throwing the reg-ex's off?

The extension is CaseSensitive. Upper-case 'JPG' extension is not recognised as an image format. LowerCase 'jpg' is recognised.

Solved the mystery and provided a work-around, thanks!

CategoryWikiMaintenance CategoryWikiImplementation

EditText of this page (last edited January 4, 2014) or FindPage with title or text search