-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathbrowser_notes.txt
39 lines (39 loc) · 7.73 KB
/
browser_notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
* Opera (tested v10.63 & v11) needs a contentEditable=true element in the page in order to let document.queryCommandSupported report correct results
* Opera (tested v10.63 & v11) converts copied HTML into plain text when pasting into contentEditable elements
* Firefox (tested v3.6 & v4b) needs at least one character or a line break "<br>" in a contentEditable=true element in order to make sure that focussing works properly
* In Firefox (tested v3.6 & v4b) calling "document.queryCommandSupported" with any parameter causes a JS error (issue: https://bugzilla.mozilla.org/show_bug.cgi?id=456798)
* In Firefox (tested v3.6 & v4b) calling "document.queryCommandEnabled('styleWithCSS', false, anyValue)" while a contentEditable element has focus causes a JS error
* contenteditable=true and it's js api technically seems to be supported on iOS (tested v3.2.2 and v4.2) and Android (tested v2.2). Unfortunately it's not able to focus such fields. Also the onscreen keyboard refuses to open.
* IE9 seems to be the only browser who treats content pasted into contentEditable elements different, depending on whether the content is copied from a same origin or non-same origin host.
* IE6 sometimes randomly crashes while working with document.execCommand
* IE (tested v6-9) and Opera (tested v10-11) insert a new <p> elements when pressing return in contentEditable elements
* Chrome and Safari insert a new <div> element when pressing return in contentEditable elements
* Firefox is the only browser who inserts a <br> element on return
* Firefox (tested 3.6 and 4b): Setting "position: absolute;" on a contentEditable element makes the element resizable to the user (resize-handles are shown after focus) - (issue: https://bugzilla.mozilla.org/show_bug.cgi?id=462758)
* IE 8-9 don't convert relative urls (in "src" or "href" attributes) to absolute urls when they are inserted (copy&paste) into a contentEditable element from another page. However you can force IE to render the editor in IE7 compatibility mode by setting this meta tag: <meta http-equiv="X-UA-Compatible" content="IE=7">
* Opera (tested v11): When the caret is in the first and only item of a list (<ul><li>|</li></ul>) and the list is the first child of the contentEditable element, it's impossible to delete the list by hitting backspace. This behavior can be fixed manually by observing the keydown event.
* Opera (tested v11) on Mac reports event.ctrlKey == true when the CMD key is pressed, but event.ctrlKey == false when the CTRL key is pressed. This has to be taken into account when creating keyboard shortcuts for wysiwyg commands.
* IE (tested v6-8): If your contentEditable element is in an iframe which has no focus, then execCommand("<command>") will execute on the document that has the focus even though the execCommand method is invoked on the correct iframe's document object. This seems to be in IE9 standards mode.
* WebKit: If you set a selection range to a position that is not in the viewport (eg. at the end of a scrollable contentEditable) Safari and Chrome won't scroll it into view.
* WebKit: Editable elements can also be achieved by setting "-webkit-user-modify: read-write;" via CSS
* IE: The paste event (which is neat for parsing/sanitizing HTML before being inserted into editable elements) requires the user to opt-in in order to allow the javascript to access the clipboardData
* IE: URLs starting with www., http://, https://, ftp://, gopher://, mailto:, new:, snews:, telnet:, wasis:, file://, nntp://, newsrc:, ldap://, ldaps://, outlook:, mic:// and url: will automatically be auto-linked when either the user inserts them via copy&paste or presses the space bar when the caret is directly after such an url. This behavior cannot easily be avoided in IE < 9 since the logic is hardcoded in the mshtml.dll (related blog post on msdn http://blogs.msdn.com/b/ieinternals/archive/2009/09/17/prevent-automatic-hyperlinking-in-contenteditable-html.aspx). Since IE9 it's possible to turn this off by executing document.execCommand("AutoUrlDetect", false, false);
* WebKit: Manually resizing of objects (img, table, ...) isn't supported (see http://code.google.com/p/chromium/issues/detail?id=52800)
* IE: Resizing of objects can be disabled by preventing the default behavior of the proprietary 'onresizestart' event
* Firefox: Resizing of objects can be disabled by invoking the enableObjectResizing command with value 'false'
* IE & Firefox: When the user resizes objects (img, table, ...) in contentEditable both browsers will change/set the width/height inline style properties instead of the width/height attributes. Firefox can be forced to update the attributes by invoking the 'styleWithCSS' command with value 'false' prior to the resize action. In IE you manually need to do this by observing the proprietary 'onresizeend' event and moving the width/height values from the style object to the elements attributes.
* IE: When the editor is running under https:// inserting <img>'s that are not https:// will cause a security warning including a confirmation whether the user wants to display these images. If the user denies, a default image is rendered but the src-attribute still points to the original path.
* IE: Some query commands can be invoked via keyboard shortcuts (ctrl+b => bold, ctrl+i => italic, ctrl+u => underline)
* Firefox, Opera & Safari: These browsers don't seem to support keyboard shortcuts for query commands
* Chrome: Same commands are supported as in IE, except ctrl+b
* IE: query command 'formatBlock' can only be executed with the following tags H1-H6, DIV, ADDRESS, PRE. Besides that, unless other browsers, IE requires the tag name to wrapped in tag delimiters (< >): document.execCommand("formatBlock", false, "<H1>");
* WebKit: When having multiple lines selected and calling the "formatBlock" command, WebKit will wrap each line with the desired block element. Example: Imagine we have this html "foo <br>bar <br>baz" selected in a contentEditable element. If we now execute document.execCommand("formatBlock", false, "blockquote"); it will cause this result: <blockquote>foo <br></blockquote><blockquote>bar <br></blockquoute><blockquote>baz <br></blockquote>
* Firefox: The user agent stylesheet (contenteditable.css) sets a color (blue) and text-decoration (underline) on links (<a>) which can only be overruled with a "!important"
* IE: Selected <img> cannot be deleted by pressing backspace (however delete works). This behavior can easily be manually added by observing the keydown event.
* Chrome & Safari: Clicking on a <img> doesn't select it like in Firefox and IE. This behavior can easily be manually be added by observing the mousedown event and using the javascript selection/range api.
* Firefox >= 4: When copying an image via context menu option "Copy image" and inserting it into a contentEditable area, it gets inserted with a data-uri instead of an image path.
* Firefox 3.6: When removing or hiding (removeChild, display: none;, ...) a selected image within a contentEditable element, the image resize handles won't be removed until the user types in something. This misbehavior can be avoided by calling document.execCommand with a supported command identifier afterwards. (eg. document.execCommand("italic", false, null))
* Chrome, Safari & IE: When the caret is in an element that is bold and which is not wrapped by a <strong> or <b> then document.queryCommandState("bold") will return true. Same behavior applies to "italic".
* Firefox is the only browser who only returns true for document.queryCommandState("bold") when the caret is in a <b> (<strong> will return false)
* Firefox and Opera are the only browsers who only return true for document.queryCommandState("italic") when the caret is in a <i> (<em> will return false)
* IE: Execute "document.execCommand("MultipleSelection", null, true);" in order to enable multiple elements to be selected