User:Catrope/IE bugs

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.

Elements with behave 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. 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.

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

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.

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  results in a DOM that looks like. 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 ?  ?   notation?   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. If you do, then   returns   and serializing the div using  /  also produces   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:
 * attribute shenanigans in this jsfiddle
 * is normalized to  and   is normalized to , but only on  s and  s (maybe on other elements too, but not on  s)
 * Same normalizations as for  also apply to the   attribute on   tags
 * is normalized to, and the same thing happens for   (only on  s)
 * is normalized to, and the same thing happens for  ; Firefox recently fixed the same bug

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

Default UA style for should be, not
The mirror image is true for, which should have   but also has. You can reproduce this by going to any page with a /  tag and inspecting it. If you choose to display all rules (not just user rules) in the "Computed" style view, you'll see that  is wrong, and if you run   in the console it'll return.

doesn't work
I don't know if this is because of, 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

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.

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.

does not clean up empty text nodes at the start/end
If you call  on a node, that's supposed to merge adjacent text nodes and remove empty text nodes. However, if you call 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
returns a document whose,   and   are all null. Other browsers return an empty document, same as when you pass.

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.

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  is used to change page's address. Changing  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 ( only): http://jsfiddle.net/rv9w9wr5/
 * Doesn't work ( 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

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

 * ✅ – Opening a link inspector for the first time, the UI for the inspector appears very broken
 * ✅ – Background colour on dir=rtl elements causes the text to be obscured
 * ✅ – Inspectors close immediately after opening
 * ✅ – 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?
 * ✅ – The corruption warning is (almost) always triggered; this is due to a browser bug that causes lots of false positives in the corruption checker.
 * ✅ – 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.