Wikka and some Browser Incompatibilities
While generally Wikka works fine across browsers, gradually a few incompatibilites are becoming known. This page serves to gather what we know about such incompatibilities so we can look at possibly solving the problems or creating a workaround.
The items are organized by browser (type) with platform as a subheading (though the latter is redundant if a browser is platform-specific). Please keep this organization, and add version info if a problem is known to be version-specific.
Mozilla Firefox
Linux
- Version 1.0.3 crashes/hangs when scrolling down a page with UTF-8 characters (such as currently found in our SandBox). Maybe it's the mixture of languages? There doesn't seem to be a problem with (non-Wikka) pages in a single UTF-8 character range.
No solution known - seems to be a browser bug.
Windows
- Problem as described for version 1.0.3 on Linux does not occur on Windows.
Mac OS X
- Problem as described for version 1.0.3 on Linux does not occur on Mac OS X.
- Version 1.0.3 doesn't seem to display floats correctly. In particular, when using <<left float<<>>right float>> in Wikka to create a two-column layout, FF clears the first float before displaying the second float. This behavior does not occur with other browsers on Mac OS X nor for FF on other platforms.
- Does this occur even when there is no newline (rendered as <br />) between the left float and right float? --JW
- Yes, for instance it occurs in AdminTools where no newline is present between the two floats. -- DarTar
- Hmm - same problem in FF 1.0.3 in Windows; could it be a stylesheet problem? - Indeed it is (on Windows): when I use my own stylesheet instead of the default one the floats are next to each other. Can you test this on the Mac, please, DarTar? If you see the same it's just a problem/bug in our default stylesheet --JW
- Right, javawoman.css is ok, as well as other stylesheets: it seems then a problem with some stylesheets under Firefox, which doesn't occur with other browsers. Now: a firefox bug or an imperfect support of floats-related CSS in other browsers? -- DT
- I'd have to actually compare some stylesheets that work vs. ones that don't work but I now suspect it may actually be a (subtle) bug in the stylesheets where it doesn't work rather than a FireFox bug. Something like original default stylesheet tested on IE which has a box model bug; a width that will work in IE may then fail in a standards-compliant browser and push the second float down. Will report back. --JW
Opera
Windows
- Opera (7.2x) implements the standard ECMAscript instead of JavaScript. In many cases the difference is minimal, but in Wikka the WikiEdit toolbar does not appear (at all) in Opera.
Possible solution: rewrite the WikiEdit toolbar's JavaScript so it is more cross-browser compatible.
- The latest version of WikiEdit (not included in Wikka yet) is said to be compatible with Opera 8 now. --JW.
Safari
Mac OS-X
- When Safari is used to edit a page that contains UTF-8 characters, the result may look OK in Safari but is "character soup" in any other browser that supports Unicode. It seems Safari's support for UTF-8 is non-standard.
No solution known.
- Using the WikiEdit toolbar can crash Safari. While Safari shouldn't crash when encountering JavaScript it cannot handle, more cross-browser JavaScript might help, too.
Possible solution: rewrite the WikiEdit toolbar's JavaScript so it is more cross-browser compatible.
CategoryTroubleshooting
