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

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

Trevor, can you peek at this?

Should be fixed in r62191.

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

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

ayg wrote:

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

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

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.

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.

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.

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.

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.

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?

ayg wrote:

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

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.

ayg wrote:

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

jackdt wrote:

Done: Bug 28947.

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.

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
.

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.