Description
?action=raw no longer renders the raw source in a browser-readable way (it is no longer included into <pre>...</pre>
Steps to reproduce
just click FeatureRequests/TextColourMarkup
This displays the raw markup without proper linebreaks. The markup contains pseudo-HTML tags inside a table - these are rendered as invisible by the browser - thus you don't see the proper raw source.
Example
Details
This wiki (I don't think this bug has existed for much longer then 2 weeks because I view raw text quite often and never noticed a problem). I am using IE6, mabe other browsers cope better...
Workarounds
Workaaround by viewing source
- After displaying the raw text in the browser, use the browsers "show source" feature.
- After displaying the raw text, press reload (at least that works for me).
- Use not broken web browser
Write a RawForIE action that will send text/html with pre tags.
Workaround by disabling MIME sniffing
Supposedly in Windows XP SP2 it is possible to disable the "MIME sniffing" feature which is what causes IE to display incorrectly. See http://msdn.microsoft.com/workshop/security/szone/overview/sec_featurecontrols.asp
Discussion
Complains to Mr. Gates. The raw text is served as a normal text file, i.e. text/plain and should be displayed as such. It's Microsoft Internet Explorer that tries to be smart and renders it as HTML whenever it sees any HTML-like tags. -- RadomirDopieralski 2006-01-13 01:03:35
Sorry, I was a little confused, but the bug still is a bug. I thought that the raw output used to be enclosed by <pre> - this was a mismatch with something else I saw recently. Further research shows that the bug depends on the first line of the raw source: If the first line is a process instruction or comment, everything is fine, even IE renders the source as plain and you can see all the HTML-like tags. And YES, IE sucks big way but the "browser war" is over, Bill Gates has won and millions of "ordinary people" are forced to live in the Windows world and to use IE - so please stop telling the world that there are less broken browsers they should use - this is simply not possible for many people! If we want wikis and MoinMoin to be useful for many people, we have to cater for the market leader and for other browsers. -- RobertSeeger 2006-01-13 11:03:38 (a senior developer who has to deal with users from the big 30 and other in Germany and Europe who are using Microsoft products as company policy forces them to do)
I can't agree, this is not a MoinMoin bug. It's an IE bug, period. In fact it appears that Microsoft may be fixing this for the text/plain case in XP SP2 (but I don't have Windows so I can't verify). See http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp As far as the rant on the browser wars, have you not heard of Apple, or Firefox? Lotsa users there too. -- DeronMeranda 2006-01-13 16:04:26
Then maybe you could propose a solution that works in IE and doesn't break all the standard-compliat browsers. Note, that serving html with pre tags is not possible, as many applications use action:raw to fetch the sources, and expect plain text. And by the way, the "browser war" is not over! Har! Har! Har! 
(maybe you could serve it as proper XHTML, then IE will NEVER try to render it and will ask to save it instead or just crash... 
) -- RadomirDopieralski 2006-01-13 16:01:40
OK, I GIVE UP!
I did not want to start a new war, rather encourage developers to stop playing the "not my fault" game (I have been playing this for 15 years myself both as developer and QA manager, so I know the drill and to try to keep things simple so that every browser can understand them. I have noticed a tendency in 1.3 to 1.5 to create a lot of things that will not work in one or the other browser (maybe most often in IE, but I don't care) by trying every possible trick with CSS, javascript etc. Mind you, MoinMoin 1.1. does not even get the HTML tag sequence proper in many cases - but it works nicely, even with IE. Now it gets more powerful - but also more fragile. If I find something that works in version A of a product X and does no longer work in version B of X and I did not change the rest of the environment then I consider this a bug of X - no matter if my other environment is good or not. In this particular case I had the assumption that raw always worked nicely until recently and that it now suddenly does not, thus my conclusion that this is a MoinMoin bug. In this particular case I was wrong. I copied the above example to both MoinMoin 1.1 and 1.3 and got the same effect. On the other hand, raw works for most everyday cases (I accidentially copied a typical source from my wiki to this wiki and the raw looked OK.
Conclusion: It is a version-independent problem that occurs in some rare situations and may be browser-dependent. I can live with that in this particular case.
I kindly apologize to anybody wasting their time with this minor issue - however I urge you not to neglect or blame the IE community (as well as any other browser community) - just keep MoinMoin robust and simple enough (and yes, I have heard of other browsers and even spotted them out in the wild, but this does not change reality in the business world. I'm even old enough to remember slide rules, punchcards and life without Bill Gates ).
Robert, thanks for understanding. It was still useful for you to raise this issue, if nothing more so that we now can archive the rationale as to why this isn't a bug in this case. But still, if anybody can think of a reasonable moin fix to this which doesn't cause worse problems (such as use by bots or mucking with the URL) please do so. -- DeronMeranda 2006-01-13 17:22:26
Altrough I think that a ShowColorizedRaw action could be very cool, and as it would serve text/html, it would probably solve the issue. Since there's a moin.vim file, you could use the vimcolor parser for that, altrough just modyfying the default wiki.py parser would probably give the best and most complete results. -- RadomirDopieralski 2006-01-13 19:03:36
Plan
- Priority:
- Assigned to:
- Status: