Textarea jumps when editing articles unless IE8 compatibility mode is on
Closed, InvalidPublic

Description

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


Version: unspecified
Severity: normal
OS: Windows Vista
URL: http://en.wikibooks.org/w/index.php?title=Talk:Main_Page&action=edit
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47708
https://bugzilla.wikimedia.org/show_bug.cgi?id=60237

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz19334.
GreenReaper created this task.Via LegacyJun 22 2009, 8:04 AM
GreenReaper added a comment.Via ConduitJun 22 2009, 8:57 AM

Created attachment 6247
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.

attachment EditPage.php.patch ignored as obsolete

GreenReaper added a comment.Via ConduitJun 22 2009, 9:22 AM

Created attachment 6248
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.

attachment EditPage.php.patch ignored as obsolete

brion added a comment.Via ConduitJul 20 2009, 4:02 AM

Trevor, can you peek at this?

ashley added a comment.Via ConduitFeb 9 2010, 7:51 PM

Should be fixed in r62191.

bzimport added a comment.Via ConduitFeb 10 2010, 9:47 PM

ayg wrote:

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).

Umherirrender added a comment.Via ConduitMar 3 2010, 11:18 AM
  • Bug 21595 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMar 29 2010, 5:43 PM

ayg wrote:

*** Bug 22983 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitJun 3 2010, 4:57 AM

shubinator1 wrote:

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]]

Catrope added a comment.Via ConduitJun 6 2010, 11:37 AM

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.

bzimport added a comment.Via ConduitJun 13 2010, 10:50 PM

tbrittreid wrote:

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.

Catrope added a comment.Via ConduitJun 13 2010, 11:09 PM

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.

bzimport added a comment.Via ConduitJun 14 2010, 9:37 PM

tbrittreid wrote:

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.

bzimport added a comment.Via ConduitJun 14 2010, 9:55 PM

tbrittreid wrote:

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.

bzimport added a comment.Via ConduitMay 11 2011, 5:30 PM

jackdt wrote:

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?

bzimport added a comment.Via ConduitMay 11 2011, 10:00 PM

ayg wrote:

What exact behavior are you seeing in Firefox? It doesn't sound like the same bug.

bzimport added a comment.Via ConduitMay 12 2011, 5:00 PM

jackdt wrote:

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.

bzimport added a comment.Via ConduitMay 12 2011, 5:28 PM

ayg wrote:

That sounds like a different issue. I'd suggest you file a new bug.

bzimport added a comment.Via ConduitMay 12 2011, 8:33 PM

jackdt wrote:

Done: Bug 28947.

bzimport added a comment.Via ConduitJan 10 2012, 10:26 PM

sumanah wrote:

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.

bzimport added a comment.Via ConduitJan 10 2012, 10:27 PM

sumanah wrote:

Comment on attachment 6248
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
.

matmarex added a comment.Via ConduitJan 20 2014, 3:49 PM

The fix here might have caused bug 60237.

matmarex added a comment.Via ConduitJan 27 2014, 8:29 PM

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.

Fomafix added a comment.Via ConduitFeb 24 2014, 2:47 PM

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.

gerritbot added a comment.Via ConduitFeb 25 2014, 8:54 AM

Change 115349 had a related patch set uploaded by Gerrit Patch Uploader:
Workaround for scrolling bug in IE8

https://gerrit.wikimedia.org/r/115349

Fomafix added a comment.Via ConduitFeb 25 2014, 12:37 PM

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.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.