* [#not_a_bug__bugs_ Not a Bug, Bugs ] * [#ancient_history__or_closed_bugs_ Ancient History (or Closed Bugs)] ** [#bug_1 Bug 1] * [#current_bugs Current Bugs] ** [#bug_2 Bug 2] ** [#bug_3 Bug 3] ** [#bug_4 Bug 4] ! Not a Bug, Bugs I've just discovered [Bugs] - should these be there? Bugs appears to be a listing of known bugs. On the other hand, this page is more a sandpit for discussion, cluesticks, Hummin' 'n hahin' or anything else that helps to define and kill the blighters. It started as a query page for one particular bug where I was unsure if it was the wiki or the browser so I put it here. (see Bug 1 in the archive box above) -- [GlennMcKechnie graybeard] 14/07/2004 ! Ancient History (or Closed Bugs) ++++ !! Bug 1 Is this a Bug or is it related to the browser. A recent (/wiki/?diff=minitar minitar) edit shows garbage characters between '''RealTek(RTL8181)at''' and '''11:22:57 CST 2003 version 1.0''' . Displayed below hopefully... (page widening bug example text removed - see history for details- graybeard 07/2004) > - ---!RealTek(RTL8181)at (page widening bug example removed - graybeard 07/2004) 7 11:22:57 CST 2003 version 1.0 Interestingly, it appears to morph into something else while toggling between '''Preview''' and '''Edit Text''' ,and also reproduces itself. Perhaps it's something to do with the preview mode although the next occurence was (I think) before the preview was introduced. They also show up in (/wiki/?diff=ConnectingToTheNetworkFAQ Connecting To The Network FAQ) under '''Convert degrees, minutes, and seconds to decimal degrees''' - apparently the degrees symbol won't display and conjures up a replacement {/regexpicons/emoticons/emoticon-face3.png ;)} > +* The latitude and longitude needs to be converted to decimal degrees for locfinder. For example, the AMG coordinates for my house at lat. -37(page widening bug example removed - graybeard 07/2004)50' 43.53603" and long. 145(page widening bug example removed - graybeard 07/2004)5' 31.85668" need to be converted to lat. -37.8454(page widening bug example removed - graybeard 07/2004)and long. 145.0922(page widening bug example removed - graybeard 07/2004) Many scientific and engineering calculators have an hours.minutes.seconds-to-hours (decimal) function which can do this. Otherwise, do the following steps. I know first hand about the last one as I reimported the relevant section and it appeared to be fine straight after the import, it's since morphed into the garbage characters again. I'm currently viewing using IE5 version 6.0.26 under win2000. The edit I refer to fixing above was Mozilla 1.6(?) under Linux Fedora core 1. [GlennMcKechnie graybeard] Okay, you've got me stumped. I think this bug is probably related to unicode character translations. All of the wiki backend is written in ASCII, but it wouldn't suprise me if the browser reinterpreted some of the ASCII as Unicode/ANSI. I'm using Mozilla Firefox 0.8, and when I look in the __V__iew menu under the __C__haracter Coding submenu I can see that '''Unicode (UTF-8)''' is selected. If someone gets a chance to play, let me know if you can narrow this down a little more. Update: I had trouble saving the above paragraph, I'm pretty sure that something is barfing on unicode input. This may be a PHP bug rather than a RegExpWiki bug or browser bug... Update 2: Looking at the page source of preview mode, things start to take shape. It seems that the PHP functions used to ensure correct transfer of special characters such as the degree symbol on the preview form across to the save page are translating too much or too little, or perhaps the browser is interferring with the expected form inputs. I might have even used the wrong function at one end of the transfer... Update 3: Lets try a single degree symbol and see what happens in preview mode... here we go: (page widening bug example removed - graybeard 07/2004)(ends up getting translated to '''(page widening bug example removed - graybeard 07/2004) ''') Update 4: Seems I may have found a (http://lists.oasis-open.org/archives/docbook-apps/200205/msg00348.html clue) - but the problem is that I'm already including the HTML head element that is suggested. D'oh. {/regexpicons/emoticons/emoticon-face9.png :/} [TysonClugg tc] Nothing much to add unfortunately, I've just trimmed the page as it had grown to approx 105 KBs and IE wasn't coping with it too well. I've trimmed the examples to show the minimum effect to hopefully reduce the growth problem. Interestingly your '''Update :3''' doesn't appear to grow/expand, apparently only certain characters come into play for that to occur. This browser (IE) is set to Unicode(UTF-8) encoding, the one I reported it from is set to Western European(ISO). The growth occurs with them both. One observation, under IE the problem text wordwraps, Under Mozilla 1.7-beta it doesn't wordwrap but goes into page widening mode. {/regexpicons/emoticons/emoticon-face3.png ;)} minor update: Nope, '''Update :3''' did grow. From the version diffs on this page, that I did at home, I didn't think it had changed between your edits. It seems this one with the Unicode encoding is adding it's own ingredients to the mix? Cutting and pasting from the minitar page into this page reproduces the clipboard content faithfully, A ''Preview'' then ''Edit Text'' cycle does morph some of the characters (the generic 'empty square' takes their place) [GlennMcKechnie graybeard] An attempt to fix things by avoiding use of the degree symbol (using '''(page widening bug example removed - graybeard 07/2004)''' instead): 12(page widening bug example removed - graybeard 07/2004)51' 12" ++++ ! Current Bugs ---- !! Bug 2 In preview mode, the last item in a bulleted list does not appear as bulleted if there is no line underneath it, instead appearing as it does in edit mode with the asterisk. (as demonstrated below) {http://www.bdzone.net/~gummay/wikibullet.jpg Example} If it is indeed a bug, it is a very minor one as it is magically fixed in the final product in the wiki page. -- [gummAY] ---- !! Bug 3 Wiki Links are stuffed in those nifty background highlighting things. (all three colours) As per below: {http://www.bdzone.net/~gummay/wiki_green_thing.jpg Example} Unlike the above 'bug', it is not fixed magically in the final product. ---- !! Bug 4 There's also a hiccup when constructing the TitleSearch string - an extra space before or after the search string plays havoc with the parser. Try it by adding an extra space before or after "Bug" in the TitleSearch below and witness the result. (The returned page will be at the bottom of the '''looonng''' page, so just scroll down) -- [GlennMcKechnie graybeard] 14/07/2004 * [Bugs] ----