User:Catrope/IE bugs

Text disappears when both a colored background and are applied
If you have HTML like, the text is not rendered. This works fine if there is no background color, of if the direction is set to LTR instead of RTL. It doesn't matter whether you use a  attribute or   in CSS. See this jsfiddle. This also seems to be a hasLayout-related bug: setting  works around it, but for text that is not usually a practical workaround.

Resize handles appear when clicking elements with hasLayout in contentEditable, with no way to prevent this
It so happens we set overflow: hidden; on headings, which triggers hasLayout, which means that if you click on a heading in a contentEditable div, the first click selects the entire heading and presents resize handles, and the second click drops the cursor in the heading. There appears to be no way to disable this behavior without removing the styles that trigger hasLayout. For headings we can do that, but ideally we wouldn't have to. Also, this creates a "damned if we do, damned if we don't" situation for spans containing RTL text, because we have to force hasLayout on those to work around another browser bug, but we also have to avoid hasLayout on them to avoid resize handles.

Elements with are still editable
If you have an element with  inside of   then it's still editable, but it really shouldn't be. See this jsfiddle.

Blinking cursor is not obscured when it should be
If you have a cursor blinking in a contentEditable div, and there is another element with a solid background on top of it, the content of the div is correctly obscured, but the cursor is still visible. See this jsfiddle.

Measuring the position of superscripted and subscripted text is broken
This is really nasty bug that fatally breaks our ability to overlay highlights on top of references like this one:. If you have HTML like, measuring the   coordinate of the   and the   should produce different results (because the superscripted text is raised above the baseline), but in IE11 it doesn't. The entire browser seems to believe that the  's box is down at the paragraph's baseline instead of where the text is actually rendered. You can tell by computing the position of the element in JavaScript, or even highlighting the element in the inspector (!). The same bug also applies to spans with styling that makes them superscripted. These styles should be the default UA style for  tags, but computing the   property on a   returns   rather than , which is also a bug. Not just the  itself, but even elements (like spans or links) inside of a   exhibit this bug. The mirror image of this bug happens for  tags. See this jsfiddle.

This seems to be a hasLayout-related bug. Setting  works around it.

is broken for click and mousedown events
is supposed to count the number of times the mouse was clicked: 1 for a normal click, 2 for a double-click, 3 for a triple-click, etc. This works just fine in IE9 and IE10, but it's broken in IE11. For click events,  is always zero in IE11. In IE11 on Windows 7, it's correct for mousedown events. But in IE11 on Windows 8.1, it's wrong for mousedown events: it counts all mousedowns that have ever happened in the tab, including mousedowns on different elements. The value of the counter even persists across reloads and navigations to different pages. The only way to reset the counter is to open a new tab. See this jsfiddle; try single, double- and triple-clicking on the two lines of text. This breaks our ability to detect triple-clicks, and causes triple-clicks to be detected even when they didn't actually happen. We can probably work around this by disregarding  and keeping count ourselves.

Opacity inheritance does not work for elements absolutely positioned outside of their parent
Opacity is supposed to be inherited multiplicatively, but in IE11 a child element does not inherit its parent's opacity if it is absolutely positioned outside of its parent. Instead, it gets  by default, which makes things that should have been transparent fully opaque. See this jsfiddle.

Scrollbars appear for zero-width elements
If you have an element with zero width, non-zero height and  whose contents are taller than the element itself, a scrollbar is rendered in IE11 but not in other browsers. The contents of the next element are then rendered on top of this scrollbar. See this jsfiddle. We can probably work around this by actually hiding these elements rather than relying solely on setting their width to zero.

DOMParser with empty string
returns a document whose,   and   are all null. Other browsers return an empty document, same as when you pass.

Empty strings for computed values of aggregate properties
Create an element like , then   correctly returns   and   correctly returns  , but  ,   and even    return an empty string. In other browsers, they return the (normalized) value of the aggregate property. This is not a jQuery bug, the same thing happens if you do. See this jsfiddle. This is also broken in Firefox :(

DOM inspector mispositions highlights for elements in iframe whose container is
If you create a div that is positioned with, then put an iframe in it, and inspect an element in the iframe, the inspector displays a highlight and several measuring lines around the inspected element. If you then scroll the viewport, the iframe and everything inside it correctly stays in the same place, but the inspector highlight and measuring lines are scrolled. See this jsfiddle.

When mousing over a reference node, the highlight appears in the wrong place (below the reference, at the baseline)
This is due to a browser bug. There is a workaround that makes references inline-block to trigger hasLayout. This would cause resize handles to appear, but in practice that's not a problem because the highlight acts as a click block.

Text with a language annotation is invisible, appears as a blue rectangle
This is due to a browser bug. We cannot work around this by forcing hasLayout, because that causes resize handles to appear.

When mousing over nodes, the highlights that appear are not transparent
This is due to a browser bug. There is a workaround that styles the highlights slightly differently.

After clicking a few times, lots of text is selected and dropping a selection with the mouse is impossible
This is due to a browser bug in click counting. We can work around this by not relying on the browser's click count and keeping count ourselves instead.

A second scrollbar appears on the left of the simple template dialog
This is due to a browser bug. We can work around this by actually hiding the outline when we're in simple mode, rather than giving it a width of 0 and a height of 100%.

Clicking on a heading selects the entire heading and allows the heading to be resized
This is due to a browser bug. We may be able to work around this for headings specifically, but there is no known workaround for other types of content.

Clicking beside a protected node (e.g. template) drops the cursor inside of that node
This is due to a browser bug, which not only lets you put the cursor there but even lets you edit it. However, because we add click-blocking overlays on hover, it's hard (but not impossible) to get the cursor inside of a protected node.

Black and gray rectangles appear while VE is loading
We don't know why this happens yet.

When VE opens, the page is scrolled down a bit, and the cursor blinks through the toolbar
We don't know why this happens yet. The cursor being visible through the toolbar is related to a browser bug; but really the page shouldn't be scrolled down and the cursor should have been scrolled into view already.

Dialogs open without any styles applied
We don't know why this happens yet. We're probably failing to account for some IE-specific behavior in our iframe dark magic code. We also have hacks in there for Chrome and Firefox (separately), so this isn't necessarily very surprising. This seems to work in debug mode though.