For MediaWiki (recent comments | status changes | tags | authors | states | release notes | statistics)
The fix seems very weird. Where did you get it? Does it have any side effects? I wasn't able to reproduce the problem at all.
The bug was first documented by Alex Grant on his blog (http://grantovich.net/posts/2009/06/that-weird-ie8-textarea-bug/), and he posted an alternative, CSS-based fix there (as opposed to adding the meta tag). This patch is based on the info on Alex's blog and Wikia's solution (see http://trac.wikia-code.com/browser/wikia/trunk/skins/wikia/css/IE80Fixes.css).
I myself had experienced the bug when editing longer pages. Someone else also noticed this bug back in April 2009 (see http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.beta&mid=19d4437c-d339-46cc-a7b5-c599e66e2fa1&sloc=).
For testing, I copied http://24.wikia.com/wiki/Jack_Bauer to my localhost development wiki and tried editing some of the sections in about the middle of the page (i.e. "Day 5") without using section edit links. Before applying this patch, editing the "Day 5" section (for example) was pretty much impossible. After applying this patch, editing works just as it should.
Great, thanks for the info. I've added a comment to the file in r62276. Why the height specification, though? Is that needed? Presumably it will change display, and doesn't seem to be necessary according to your links.
Also, shouldn't your selector really be "textarea" here, not "#wpTextbox1"? Nothing sets #wpTextbox1 to 100% width, only textarea, AFAICT. So the fix won't work properly on edit conflict resolution, say. I'd think the rule should apply to all textareas, and be loaded on all pages.
As an alternative implementation, we could put the fix in shared.css directly, and then use a * html hack or such to override it for IE6, since that doesn't support min/max-width. Currently only Monobook, Vector, Modern, Chick, and Simple set textareas to 100% width, but it probably doesn't hurt if we extend that to all other skins too.
Without the height property, the bug occurs in my IE8 — dunno why, but that's just the way it is. Using textarea instead of #wpTextbox1 (with or without height) doesn't seem to work. The current CSS works for me even in edit conflict cases.
Using shared.css instead of a separate file sounds like a good idea to me.
I can verify that this bug was there before and not after these CSS changes, suggesting that it be marked as resolved/ok
There are unresolved issues — for instance, it forces widths to 100% in IE8 even in skins where this isn't normally the case, like Cologne Blue. I'm meaning to test it and see if I can improve the fix, if no one else does, but I haven't found the time yet.
Okay, I obviously just don't care enough about IE8. So it would be nice if this could be fixed, but I'm not going to do it, and clearly no one else is. Dunno if we should keep this marked fixme in that case, it seems pointless.
In addition to skin problems noted above, the checked-in fix may not actually fix the problem in all cases. Instead, another fix is to simply set the COLS attribute of the textarea to a very large number (e.g. 5000). This seems to work in every case I've tried, and doesn't break skins or other CSS.
more details: After an hour investigating this, the problem seems to be caused by IE8's handling of a conflict between "COLS" attribute and "width" style on a textarea element. If the width CSS is wider than the default width (font width x cols), IE8 gets confused when you add text and scrolls the textarea. If, instead, the width CSS is smaller than the default width derived from the cols attribute, then all works OK.
The subtle dependence between cols and width is perhaps what makes the problem so tricky to repro, because the same exact page would break or not break depending on the ratio of cols to width. It's easy to build a page which reproes on a large browser window and doesn't repro on a small one!