13144 2011-07-05 14:37:21 +0000 designMode needs to persist when an iframe is navigated 2011-09-23 18:58:29 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All CLOSED INVALID http://www.whatwg.org/specs/web-apps/current-work/#making-entire-documents-editable P3 normal --- 1 contributor ian ayg bzbarsky ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 50672 0 contributor 2011-07-05 14:37:21 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html Multipage: http://www.whatwg.org/C#making-entire-documents-editable Complete: http://www.whatwg.org/c#making-entire-documents-editable Comment: designMode needs to persist when an iframe is navigated Posted from: 68.175.61.233 User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.797.0 Safari/535.1 50673 1 ayg 2011-07-05 14:49:16 +0000 Testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1058 This sets designMode to "on" on an iframe's document, then navigates the iframe to a bunch of different pages. In IE9, Firefox 6.0a2, and Chrome 14 dev, designMode remains on across all the navigations, including cross-domain and to and from about:blank. In Opera 11.50, it apparently switches to off when the document is navigated to a different domain, which is of course wrong because it doesn't match the other browsers. As I read the current spec, new Document objects have their designMode off, and navigating a page creates a new Document object. This does not seem to be correct. The navigation algorithm probably needs to set designMode on the new document to on if the old document was in an iframe and had designMode on. This does only apply to iframes. I couldn't test easily with Live DOM Viewer, but I created two pages like <!doctype html><script> document.designMode = "on"; location = "/tmp/test2.html"; </script> and <!doctype html><script>alert(document.designMode)</script> and Firefox 6.0a2, Chrome 14 dev, and Opera 11.50 all alert "off". (IE9 doesn't perform the navigation, since it immediately stops executing script when designMode is turned on.) I didn't test with XML or any other funky cases, but presumably for consistency we'd want the same behavior for HTML over HTTP as everything else. 53807 2 mike 2011-08-04 05:17:31 +0000 mass-move component to LC1 55192 3 ian 2011-08-16 04:58:26 +0000 Well keeping it cross-origin sounds like a disaster waiting to happen. But that aside, is designMode something you are speccing or is that going to remain on my side of the fence? 55237 4 ayg 2011-08-16 15:02:55 +0000 The definition of editing host/editable depends on the definition of designMode, so if you're going to keep those you have to keep designMode too. For now I'll stick to just defining execCommand() and friends, and how user keystrokes map to various method calls, and Selection once I steal that from DOM Range. You can keep the rest. At some point it might make sense for me to take more, but I have plenty to do right now with what I have, so no rush. 57217 5 ian 2011-09-23 00:22:37 +0000 I can't reproduce this. The testcase linked above isn't testing it, since setting location is async and so all it is actually testing is the value of designMode against the same document a bunch of times in a row. This test (click the button) shows that it resets as I would expect on navigation: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1144 You can also test it by just seeing if the page is editable; it doesn't seem to be. Can you confirm if my testing is valid or whether I missed something? 57249 6 ayg 2011-09-23 18:58:20 +0000 Okay, I was probably just being stupid. Navigation is async, right. Never mind this.