Page MenuHomePhabricator

Toolbar icons overlap edit box in IE8
Closed, ResolvedPublic


Some toolbar icons overlap edit box in Internet Explorer 8, see screenshot [1]. This was reported in dewiki [2] and I can reproduce this.



Version: master
Severity: normal



Related Objects

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:26 AM
bzimport set Reference to bz47506.

Might be related to Bug 27698.

filzstift wrote:

I can confirm the issue with Internet Explorer 8 in Windows 7.

Filzstift, Thorsten: Is this still a problem?

Unchanged with IE 8.0 on Win XP.

filzstift wrote:

I don't have anymore an IE 8 environment so I cannot test it again.

I can reproduce with IE9 in compatibility mode on Windows 7.

Just open the advanced bar. In the groups with labels (format and insert), the icons will show below the label and overlap the textbox.

Also see screenshots in bug 49609

  • Bug 49609 has been marked as a duplicate of this bug. ***
  • Bug 49836 has been marked as a duplicate of this bug. ***
  • Bug 53442 has been marked as a duplicate of this bug. ***

gavinmunro wrote:

This bug also occurs in Chrome

(In reply to comment #11)

This bug also occurs in Chrome

Version information plus wiki URL to reproduce welcome.

gavinmunro wrote:

Comment 11 is an error. It applies to bug 54919.

gerd.huhn wrote:

Bug still there MW 1.21.2 and latest WikiEditor Snapshot and IE8 ... is there no fast solution? maybe it is possible to add a new line to the advanced menu and display the area always with a bigger hight?!? not nice but always better then overlapping in IE8 ...

wikimedia wrote:

If you are hosting MediaWiki as an Intranet site, IE will always force sites in the 'Intranet Zone' to compatibility mode.

To tell IE not to treat MediaWiki in compat mode, you need to add either the <meta http-equiv="X-UA-Compatible" content="IE=10" /> tag to the HTML content, or the "X-UA-Compatible: IE=10" HTTP header.

If you are hosting on IIS, you can modify your web.config file to add the custom HTTP header like so:


      <clear />
      <add name="X-UA-Compatible" value="IE=10" />


This issue is still present with MediaWiki 1.23wmf8 and WikiEditor 0.3.1 (b46c796). Changing compatibility mode does not alter the behavior. Applies to both and an internal wiki I administer.

It appears to be a CSS issue, but I can't determine the attribute to modify.

Someone should retriage this with the parent bug 25378 now fixed.

(In reply to comment #18)

Nothing changed.

Confirmed. WikiEditor master still presents this issue in IE 8. Compatibility mode does not effect results of testing. Appears on and internal wiki.

A work around (and possible hint as to what is causing the issue) is to remove the labels fro the Format and Insert groups.

in \w\extensions\WikiEditor\WikiEditor.i18n.php modify the following entries (removing the Format and Insert labels):
'wikieditor-toolbar-group-format' => '',
'wikieditor-toolbar-group-insert' => '',

Even with Chris Koerner's workaround (Comment 20), IE8 still throws the following error when I click on "Special characters":

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
Timestamp: Thu, 13 Feb 2014 18:13:22 UTC

Message: 'console' is undefined
Line: 566
Char: 3
Code: 0

The offending line in the above comment seems to be:

console.log( "A character for the toolbar was undefined. This is not supposed to happen. Double check the config." );

This console error you are seeing was fixed by now in master it seems. just FYI

Change 124335 had a related patch set uploaded by TheDJ:
Fix broken span of label in WikiEditor toolbar

I'm not 100% positive the above patch fixes it, but it does sound like a very logical candidate.

Change 124335 merged by jenkins-bot:
Fix broken span of label in WikiEditor toolbar

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

Could somebody verify that the patch fixed the issue? It's not yet deployed on Wikipedias, but I deployed it on my testing wiki: (use user: testwiki, password: testwiki to access the site, it's a crude antispam measure). Feel free to create accounts and edit articles and do whatever you think necessary. :)

I checked on a PC I have occasional access to and this does indeed fix the problem.

Confirm. Looks good for me on your testing wiki.