This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
mass-move component to LC1
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?
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.
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?
Okay, I was probably just being stupid. Navigation is async, right. Never mind this.