User:Catrope/IE bugs

Confirmed in Spartan/Edge

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 opacity: 1; by default, which makes things that should have been transparent fully opaque. See this jsfiddle.

Broken as of build 12.10240

In our backlog [Sarah Kunkler, Microsoft Software Engineer]

Backspacing with contentEditable="false" behaves strangely

See this jsfiddle. If you put your cursor between the "w" and "o" of "world" and press backspace a few times, the cursor will jump to the end when the space is removed. If you keep pressing backspace, the cursor jumps over the uneditable span, then when removing the space before the span it jumps to the end again, and then removes the "l" of "cruel" before getting stuck. Not only should the cursor not jump around randomly when backspacing, you shouldn't be able to delete uneditable text using backspace.

Broken as of build 12.10240

Working on a fix for all issues here [Sarah Kunkler, Microsoft Software Engineer]

Scrollbars appear for zero-width elements

If you have an element with zero width, non-zero height and overflow-y: auto; whose contents are taller than the element itself, a scrollbar is rendered in IE 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.

Broken as of build 12.10240.

In our backlog [Sarah Kunkler, Microsoft Software Engineer]

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.

Broken as of build 12.10240.

In our backlog [Sarah Kunkler, Microsoft Software Engineer]

style attributes are aggressively normalized, causing data loss

Parsing HTML with style attributes often doesn't round-trip because IE aggressively normalizes the contents of the style attribute. Parsing HTML like <div style="color: #ffd;"></div> results in a DOM that looks like <div style="color: rgb(255, 255, 221);"></div> . From this DOM, there is then no way to recover the original value of the style attribute. This means that parsing an HTML string into DOM and serializing that DOM back to an HTML string causes irreversible data loss (did they use #ffd? #ffffdd? rgb() notation? rgb() notation but without spaces?): it makes it impossible to make minimal modifications to the HTML that only represent the user's edit, because inline styles are changed all over the place.

Even if there was a way to get the original value, we can't create a DOM that will serialize back to a string with the original value in it, because the normalization also happens when you change attributes using setAttribute(). If you do div.setAttribute( 'style', 'color: #ffd;' );, then div.getAttribute( 'style' ) returns 'color: rgb(255, 255, 221);' and serializing the div using .innerHTML/.outerHTML also produces rgb() notation.

A jsfiddle with more examples of things that get normalized is here. In compliant browsers, the left and right columns are the same, because attribute normalization of this kind is not allowed by the spec, but in IE they are different. In IE11, this normalization wasn't technically a normalization because it wasn't idempotent: invalid CSS was normalized to an empty string, but an empty string is normalized to null (attribute absent). In Spartan, invalid CSS is also normalized to null, so the normalization is now idempotent.

Full list of normalization behaviors I found:

• style attribute shenanigans in this jsfiddle
• bgcolor="#FFD" is normalized to bgcolor="#ffd" and bgcolor="Red" is normalized to bgcolor="red", but only on <td>s and <tr>s (maybe on other elements too, but not on <div>s)
• Same normalizations as for bgcolor also apply to the color attribute on <font> tags
• width="20px" is normalized to width="20", and the same thing happens for height (only on <img>s)
• rowspan="02" is normalized to rowspan="2", and the same thing happens for colspan (only on <td>s); Firefox recently fixed the same bug

Broken as of build 10074.

Working on a fix [Sarah Kunkler, Microsoft Software Engineer]

filter: url(foo.svg#bar); doesn't work

I don't know if this is because of filter:, or the use of a URL as a filter, or the use of an SVG, or the use of an entity reference, but when you put all of these things together, it doesn't work. This test case breaks in Chrome, Firefox and Spartan in different ways:

• In Firefox, the middle one correctly does not apply the filter (because the URL doesn't resolve), but it also fails to apply the background color
• In Chrome, the top one incorrectly does not apply the filter (because the URL doesn't resolve but should), and the middle one incorrectly does apply the filter (because the URL shouldn't resolve but does)
• In Spartan, none of them apply the filter at all; the network panel doesn't even show a network request being made for the SVGs

Broken as of build 10074.

Filters are in development [1], url() function is in our backlog [Sarah Kunkler, Microsoft Software Engineer]

Broken in IE11, fixed in Spartan/Edge

Default UA style for <sup> should be vertical-align: super;, not vertical-align: baseline;

The mirror image is true for <sub>, which should have vertical-align: sub; but also has vertical-align: baseline;. You can reproduce this by going to any page with a <sup>/<sub> tag and inspecting it. If you choose to display all rules (not just user rules) in the "Computed" style view, you'll see that vertical-align is wrong, and if you run getComputedStyle($0).verticalAlign in the console it'll return 'baseline'. See this jsfiddle.

Fixed as of build 10074.

Working on a fix [Sarah Kunkler, Microsoft Software Engineer]

Text disappears when both a colored background and dir="rtl" are applied

If you have HTML like <span style="background-color: yellow;" dir="rtl">Foo</span>, 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 dir="rtl" attribute or direction: rtl; in CSS. See this jsfiddle. This also seems to be a hasLayout-related bug: setting display: inline-block; 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. See this jsfiddle.

Elements with contentEditable="false" are still editable

If you have an element with contentEditable="false" inside of <div contentEditable="true"> then it's still editable, but it really shouldn't be. See this jsfiddle.

event.detail is broken for click and mousedown events

event.detail 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, event.detail 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 event.detail and keeping count ourselves.

.normalize() does not clean up empty text nodes at the start/end

If you call .normalize() on a node, that's supposed to merge adjacent text nodes and remove empty text nodes. However, if you call .normalize()on a node that contains two text nodes with text and one that is empty, IE merges the two adjacent text nodes but does not remove the empty one. This only happens if the empty text node is at the start or end: if the empty text node is surrounded by non-empty text nodes on both sides, it does get cleaned up. See this jsfiddle: per the DOM spec, the number for "After normalize" should always be 1, and in Firefox and Chrome that is indeed the case.

DOMParser with empty string

new DOMParser().parseFromString( '', 'text/html' ); returns a document whose .head, .body and .documentElement are all null. Other browsers return an empty document, same as when you pass '<body></body>'.

DOM inspector mispositions highlights for elements in iframe whose container is position: fixed;

If you create a div that is positioned with position: fixed;, 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.

Looks fixed in build 10074.

clipboardData is a global object rather than an event property

In Chrome and Firefox, the ClipboardData object is exposed as event.clipboardData where event is a cut/copy/paste event (see MDN). In IE11, it's exposed as window.clipboardData (see MSDN). The spec on this is still in draft, but it favors the event property approach. See this jdfiddle.

Fixed in build 10074.

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 <p><span>Foo</span><sup>Bar</sup></p>, measuring the 'top' coordinate of the <span> and the <sup> 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 <sup>'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 (font-size: smaller; vertical-align: super;). Not just the <sup> itself, but even elements (like spans or links) inside of a <sup> exhibit this bug. The mirror image of this bug happens for <sub> tags. See this jsfiddle.

This seems to be a hasLayout-related bug. Setting sup, sub { display: inline-block; } works around it.

Broken as of build 10074, fixed in 12.10240.

Cursoring with contentEditable="false" behaves strangely

See this jsfiddle. Clicking in the uneditable text doesn't drop a cursor, so that's good. But skipping over it with the arrow keys also skips the space to the right of it, which is not covered by the uneditable span.

Broken as of build 10074, fixed in 12.10240.

Link styling aggressively preserved on paste

If you copy linked text from a place where one set of CSS rules applies, then paste it into a place where another set of CSS rules applies, IE11 inserts tags to try and preserve the link's appearance. Other browsers do not do this. For instance, if you copy a regular link into a contentEditable div where a CSS rule like #myDiv a { text-decoration: none; color: red; } applies, the link will be pasted as <a href="..."><u><font color="#0066cc">Link text</font></u></a> in an attempt to work around the CSS. This doesn't even preserve the appearance of the link completely, because the <u> and <font> tags are nested the wrong way around, so the text is blue but the underline is red. In Chrome and Firefox, the link is simply inserted as <a href="...">Link text</a> and its appearance matches that of the other links in its new environment. See this jsfiddle.

dataTransfer.getData() doesn't support MIME types

According to the spec, the parameter to getData() is supposed to be a MIME type, so you can obtain different types of data from a DataTransfer object using e.g. .getData('text/plain') or .getData('text/html'). In IE11, the only accepted types are 'text' and 'url' (see documentation on MSDN). This seems to be a legacy thing, as the spec maps 'text' to 'text/plain' and 'url' to 'text/uri-list'.

dataTransfer.getData() throws exception for unrecognized type

The spec prescribes that the empty string be returned if the type passed to getData() is unrecognized. IE11 instead throws an "Invalid argument" exception for types it doesn't recognize, which due to the above includes types that it is supposed to recognize.

dataTransfer.setData() doesn't support custom MIME types

This is kind of a consequence of the issues with .getData() above. Chrome lets you do stuff like dataTransfer.setData( 'application-x/VisualEditor', JSON.stringify( foo ) );, but in IE we have to use dataTransfer.setData( 'text', JSON.stringify( foo ) );, which sucks because it means we have to modify the real drag data.

Reports with broken jsfiddle links :(

Changing page's address via HTML5 history API doesn't scroll to new fragment

IE10 and IE11 don't scroll the page to given fragment when history.replaceState is used to change page's address. Changing location.hash afterwards, even though it's a no-op, results in the page scrolling properly. It doesn't matter whether the call is executed while the page is loading, on DOM read or on load – the effect is always the same.

JSFiddle test case:

• Works (location.hash only): http://jsfiddle.net/rv9w9wr5/
• Doesn't work (history.replaceState only): http://jsfiddle.net/e6fy0mar/
• Works again (both): http://jsfiddle.net/o8vc5grf/

It is also interesting to try visiting the test cases with a fragment already in the URL. It seems that the history API in IE updates the page's address, but doesn't update "fragment state" – the broken, second testcase scrolls to #first in spite of displaying #second in the address bar.

• http://fiddle.jshell.net/rv9w9wr5/show/light/#first
• http://fiddle.jshell.net/e6fy0mar/show/light/#first
• http://fiddle.jshell.net/o8vc5grf/show/light/#first

Reported upstream

Hearsay

Drag&drop should support .setDragImage() and dataTransfer.items

According to caniuse, .setDragImage() isn't supported in IE11 and 12, and dataTransfer.items is only supported in Chrome.

Returning null from onbeforeunload is equivalent to 'null' rather than undefined

In Chrome and Firefox, returning null from an onbeforeunload handler causes no warning to be shown, which is the same behavior you get as when you return undefined. However, in IE11, returning null results in a warning popup with the text 'null'. The spec about this is very unclear and imprecise, so it's not clear which behavior is "right".

focusin/focusout events wrongly emitted oniframe

In IE11, when the focus moves into an iframe, focusout is emitted on the element that used to have focus (which is correct) and focusin is emitted on the iframe (which is incorrect). Even worse, when the focus moves between two iframes, focusout is emitted on one and focusin is emitted on the other, while really from the perspective of the main document nothing is happening.

User-observable bugs using VE in IE11

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.

Language inspector closes and saves when opening language selector

If you try to use the language selector to change the language in the language inspector, the dialog opens, but the inspector then closes and saves the old language. The language you choose in the selector dialog then goes nowhere.

Special character inspector does not insert selected character if you use the mouse to drag the scrollbar down

Open the special character inspector, drag the scrollbar down with the mouse, then choose a character. The character isn't inserted. If you click a character immediately or use the mouse wheel to scroll down, the selected character does get inserted. This appears to be a focus stealing problem, since the surface is blurred and the toolbar is grayed out once the inspector closes.

Clicking on an image navigates away to the image page

This happens in beta labs but not on my localhost. I don't know why. Update: as of August 22 I can't reproduce this in beta labs either.

Clicking on a reference scrolls to the top

This is the same issue as clicking on an image. Update: can't reproduce as of August 22.

Bugs from Rummana

• While clicking on a link, a small box like context menu appears on top of it with the link text
  • It looks like this is how IE does tooltips in general; what you're seeing is the link's tooltip, which is visible while hovering over the link
• Increasing indentation adds a new line and then indents the bullet point or numbered point to the right
  • This is because IE renders nested empty list items differently from Firefox/Chrome. The way it looks in VE matches the way it looks on the page.
• Sometimes the Media Settings dialog (also the media search dialog) appears to be transparent making some text in CE visible through it
  • Yeah dialogs become transparent sometimes. This seems to happen to the beta welcome dialog quite frequently
• A block of grey highlight appears after clicking on change image, right after adding an image
  • I don't see this? I do sometimes see a weird flash over the search box briefly right before it says "No results found".
• There is an underline that appears below the citation needed template, clicking on that redirects to the template page from VE mode
  • This is probably similar to clicking on an image and clicking on a reference
• The highlight for template is appearing few pixels below
  • Which template? I think this might be similar to a bug we had with references
• Hovering over Add template, Add content , Add parameter in Transclusion dialog shows a tooltip like box over it.
  • It looks like that's how IE does tooltips in general.
• Snowman appeared after adding cite web template.
• All the inspector loses its UI when they are opened inside Reference or Media Settings dialog and does not retain back.
  • Working for me locally now
• When there are two nodes adjacent to each other, cannot place cursor at the end of the line, that is after the second node.
  • Yeah, I can reproduce that. Even if there's just a single inline template in a paragraph, you can't put the cursor after it with the mouse. You can get there using the keyboard though.
• Cannot place the cursor on a an empty line added between two lines.
  • This you can do with the mouse, but not with the keyboard.
• Cannot place cursor after a citation which is added inside a reference.
  • Yeah, that's another case of putting the cursor after an inline node at the end of a line.
• While trying to apply link to a text which has another text next to it, opening link inspector throws range error and cannot close the inspector after that.
  • Do you have more detailed steps for this? I can't reproduce.

Bugs now fixed or worked around

•  2014-08-19 – Opening a link inspector for the first time, the UI for the inspector appears very broken
•  2014-08-22 – Background colour on dir=rtl elements causes the text to be obscured
•  2014-08-27 – Inspectors close immediately after opening
•  2014-08-28 – After clicking through keep/discard changes dialog, a browser warning appears with "null". Might be a browser bug: apparently returning null from onbeforeunload doesn't do what it's supposed to?
•  2014-08-28 – The corruption warning is (almost) always triggered; this is due to a browser bug that causes lots of false positives in the corruption checker.
•  2014-08-28 – 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.