Closed Bug 262998 Opened 15 years ago Closed 15 years ago
Mode doesn't work anymore in this particular case
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041003 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041003 Firefox/0.9.1+ I'll attach a testcase. The testcase works in: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a4) Gecko/20040911 Firefox/0.9.1+ (8:44 am) But it doesn't work anymore in: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a4) Gecko/20040913 Firefox/0.9.1+ (9:46 am) Reproducible: Always Steps to Reproduce: 1. See testcase 2. 3. Actual Results: No designmode for iframe. Instead I get an error in the js console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.designMode]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///C:/Documents%20and%20Settings/Martijn/Desktop/dm.htm :: dm :: line 20" data: no] Expected Results: Set the designmode to on for the iframe without complaints. Normally this doesn't work in any build when I just put some string in the iframe. But before 2004-09-11, this did work because I used the iframe.contentDocument.innerHTML=textarea.value (instead of iframe.contentDocument.innerHTML='some random string'). Now that doesn't work also anymore. I guess the fundamental problem is that I have display:none set to the iframe. Setting designMode to an iframe with display:none is not possible (gives the error message I mentioned previously). But in the testcase, I set the display of the iframe back to block, just before setting designMode to on. That doesn't work also normally: setting designMode still would give the error message. But before 2004-09-11, the iframe.contentDocument.innerHTML=textarea.value way seemed to work, but that doesn't work nowadays.
Sorry for the rather complicated bug report. I think it would just better if it would be possible to set designMode on display:none iframes. This bug is just a side issue of that, I guess (some strange workaround which worked, but nowadays not anymore.
> Setting designMode to an iframe with display:none is not possible That's pretty bogus. jst, is there a reason this code tries to go through prescontext to get the window instead of just QIing nsIScriptGlobalObject?
(In reply to comment #2) > > Setting designMode to an iframe with display:none is not possible > > That's pretty bogus. > > jst, is there a reason this code tries to go through prescontext to get the > window instead of just QIing nsIScriptGlobalObject? Nope, at least no other reason than historic ones, I guess...
Comment on attachment 161284 [details] [diff] [review] Somewhat like this, perhaps? r+sr=jst
Assignee: mozeditor → bzbarsky
OS: Windows 2000 → All
Priority: -- → P3
Hardware: PC → All
Target Milestone: --- → mozilla1.8alpha6
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
So this should be fixed in the build I'm using, right? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041007 Firefox/0.9.1+ (8:21 am) The testcase still doesn't work for me. The URL testcase is the thing that I hope that gets fixed by this bug. Setting the designmode on second, third, etc instance doesn't work in that case.
This testcase is showing more explicitly that setting designMode is not working for iframes with display:none.
Ok, reopening. I can fix the original testcase here (by flushing pending restyles), but the bogosity of not being able to set designMode on display:none iframes will remain -- nsEditingSession::SetupEditorOnWindow requires a presshell.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This fixes "Testcase" by ensuring that the display change is processed before we look for a presshell, but not "Testcase2" (since there is simply no presshell in site there). Martijn, would you file a separate bug on that, please? Also, with this patch you don't need the textarea.value hack at all.
Attachment #161284 - Attachment is obsolete: true
Comment on attachment 161389 [details] [diff] [review] Ensure frames are up to date before grabbing for presshells r+sr=jst
(In reply to comment #10) > Martijn, would you file a separate bug on that, > please? Ok, I filed bug 263392 on that.
Fixed again, for real. ;)
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.8alpha6 → mozilla1.8alpha5
(In reply to comment #13) > Fixed again, for real. ;) Indeed. Thanks Boris!
Status: RESOLVED → VERIFIED
Pushed testcase: http://hg.mozilla.org/mozilla-central/rev/39ce9c1e4b56
You need to log in before you can comment on or make changes to this bug.