Last modified: 2014-02-25 12:37:47 UTC
On IE8, when editing a long article, the text being entered will jump/scroll to the bottom of the textarea as you type. This is very annoying for editors who choose to use IE (yes, there are some), who have to, or who just don't know any better (they both deserve our pity). The issue appears to be the handing of the editing textarea when its width is set to 100%. This appears to have previously been "fixed" by reducing the width to 96% for IE. IE8 does not change the situation but does prevent this fix from working - unless it is in its "IE7 compatibility mode". If a website is on this list, it will automatically have IE7 compatibility mode applied: res://iecompat.dll/iecompatdata.xml (accessible only from within IE8) This includes all subdomains of wikimedia.org, wikipedia.de, wikipedia.org and wiktionary.org, but not all Wikimedia sites, and obviously not *most* third-party users (wikia.com and wikihow.com got lucky). If the default cannot be fixed to work in IE8 and everything else, a "solution" might be to add one of: The HTTP header: 'X-UA-Compatible: IE=EmulateIE7' The meta tag: '<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />' This would force IE7 compatibility mode as described in http://blogs.msdn.com/ie/archive/2008/06/10/introducing-ie-emulateie7.aspx It should also be possible to detect IE8 by searching the User-Agent for 'Trident/4.0' and only sending the header or meta tag then. User agents - along with other details of compatibility mode - are given at http://blogs.msdn.com/ie/archive/2008/08/27/introducing-compatibility-view.aspx
Created attachment 6247 [details] Add X-UA-Compatible meta tag to EditPage::addHeaders() when Trident/4.0 user-agent detected I tried both the headers route and the http-equiv meta tag, the tag ended up two bytes shorter as it could be gzipped. Should only be output on the edit page, only on IE8.
Created attachment 6248 [details] Detect MSIE 8.0 rather than Trident/4.0 On second thought, there's no need to send this header if the page is already being viewed in compatability mode. If it is, the User-Agent will be MSIE 7.0 rather than MSIE 8.0; we should only send it if User-Agent is MSIE 8.0.
Trevor, can you peek at this?
Should be fixed in r62191.
I can't reproduce this. Can you give exact steps to reproduce? Visit the given URL, then do what? (In reply to comment #0) > If the default cannot be fixed to work in IE8 and everything else, a "solution" > might be to add one of: > The HTTP header: 'X-UA-Compatible: IE=EmulateIE7' > The meta tag: '<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />' We *definitely* do not want IE8 to emulate IE7 here. We should use the most standards-compliant rendering available, and hack around any minor problems as necessary (as Jack's fix does).
*** Bug 21595 has been marked as a duplicate of this bug. ***
*** Bug 22983 has been marked as a duplicate of this bug. ***
Looks like it's still an issue; see [[Wikipedia:Requests_for_comment/May_2010_skin_change/Bug_reports#Much_bouncing-about_of_text_during_editing]]
Fixed in r67455, fix deployed. Turns out the previous fix (r62191) was right on the money, but there was a CSS rule in wikiEditor.css overriding a critical part of it, so I spent two hours chasing down this bug and ended up removing one line.
Sorry, no. See [http://en.wikipedia.org/w/index.php?title=Wikipedia:Requests+for_comment_/May_2010_skin_change/Bug_reports], specifically the most recent posts to thread 89: Much bouncing-about of text during editing. This thing is NOT fixed, and it's not just me.
It turns out I overlooked the fact that a high cols attribute is needed on the textarea. I'll work on fixing that tomorrow; in the meantime, you can try setting the width of the edit area (in your preferences in the Editing section) to a high value like 1000 (it won't go higher than that), that should make the bug go away.
I'll be damned! The "jumping" is gone, I can again put arrows and stuff in my edit summaries, and the "new size" looks just about the same as the previous one, quite usable. Thanks a ton! Unless you've got reason to believe that there are some IE8 users that the above is not working for, I'd guess we should close this, but as I don't know about that I won't do so myself. Again, thanks.
I spoke too soon. Apparently the jumping now comes only after Preview mode is engaged (I might be wrong about that), and when one hits a key (whether Delete, Backspace, Space, or some letter, number or punctuation mark on the keyboard); cursor insertion itself doesn't cause a jump. So it certainly is not the problem it was, but it isn't completely gone either.
I'm getting the same problem with Firefox 3.6.17 under Ubuntu 10.04. Would it be possible to have something like the size parameter for HTML img tags, where space is held for the image even before it's been downloaded? Or are global templates and toolbars added after the page is rendered, with no possibility of knowing how high they'll be?
What exact behavior are you seeing in Firefox? It doesn't sound like the same bug.
I've figured out how to replicate it, and I think it's the enhanced editing toolbar. Edit a longish page e.g. <https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Constitutional_act_of_the_Czech_Republic&action=edit>, click in the edit box, scroll down until you can't see the first lines of the article anymore, and start editing. When the page finishes loading (I have a slow connection), the cursor leaves the edit box [when I continue typing Firefox's search in page comes up (Edit, Preferences, Advanced, General, "Search for text when I start typing" is selected)] and the top of the edit box is shown. The text is now also shown in a wider font. When I switch off the enhanced editing toolbar and keep the unenhanced toolbar, the page jumps a bit while following the same procedure for the images for the unenhanced toolbar, but the cursor stays in the edit box and the font stays the same.
That sounds like a different issue. I'd suggest you file a new bug.
Done: Bug 28947.
Can people still replicate this problem? Am removing the "patch" and "need-review" keywords because unfortunately Laurence 'GreenReaper' Parry's patch will no longer apply cleanly to trunk and I am thus marking it obsolete. Thanks for offering the patch, Laurence; if the problem's still happening and you're interested in updating the fix, please do revise and reattach. Thanks.
Comment on attachment 6248 [details] Detect MSIE 8.0 rather than Trident/4.0 This patch no longer applies cleanly to trunk per Rusty Burchfield's automated testing https://docs.google.com/spreadsheet/ccc?key=0Ah_71HHl7qa7dGtvSms3TGpHQU9NU2Y1VmNzUEUteWc .
The fix here might have caused bug 60237.
The partial fix from here has been reverted per bug 60237, as the original issue can no longer be reproduced – apparently either IE 8 was fixed by some updates, or something else magically causes this to work. Marking this bug as RESOLVED.
This bug occurs in Internet Explorer 8 in extension WikiEditor. Steps to reproduce: * Open a long text with WikiEditor for example: https://de.wikipedia.org/w/index.php?title=Wikipedia:Spielwiese&action=edit&oldid=127895879 * Scroll in the middle of the text. * Position the cursor with the mouse in the middle of the text. * Insert a text from the WikiEditor toolbar, for example the signature. --> The textarea scrolls up. In WikiEditor the bug 60237 cannot occur because WikiEditor has no marginally space: .wikiEditor-ui textarea#wpTextbox1 { border: none; padding: 0; } This bug should assigned to extension WikiEditor and the fixed in extension WikiEditor.
Change 115349 had a related patch set uploaded by Gerrit Patch Uploader: Workaround for scrolling bug in IE8 https://gerrit.wikimedia.org/r/115349
comment #23 is not the same bug. It is also a scrolling bug in IE8 but enabling the compatibility mode doesn't prevent the problem. I created a new bug 61908.
