86 bytes, text/html
932 bytes, text/html
98 bytes, text/html
1.15 KB, text/html
Can you give more precise steps to reproduce? Is there a button in that page I can press that moves the designMode iframe around in the DOM?
Thanks for the testcase. So the problem is that the function declared in the iframe cannot be called after moving it?
Dup of bug 254144?
Thanks. I believe this is actually a dupe of bug 254144. The objects in the iframe are not accessible right after the iframe is moved because the document in the iframe has not yet finished (re)loading by that time. If you try accessing them again later, everything will work fine. (On slower connections, you might need to select Work offline before clicking "Test" in the testcase)
Summary: IFRAME DISABLED WHEN MOVED VIA DOM → objects in a document inside iframe are not accessible after the frame is moved using DOM methods
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Summary: objects in a document inside iframe are not accessible after the frame is moved using DOM methods → objects in a document inside iframe are not accessible right after the frame is moved using DOM methods
Gah, sorry for the multiple mails. Please resolve appropriately if you agree this is a dupe.
Assignee: nobody → general
Component: General → DOM
QA Contact: general → ian
Hi! I already tried adding a setTimeout("xxx",10000); to access the IFRAME but that does NOT work! Your test does not move the iframe so I don't understand why you posted it. Best Regards, Jan Jaap Hakvoort
p.s. wouldn't it be better to have the content of the iframe remain intact when you move it? Imagine if you want to move user generated content inside an iframe, it won't be possible in Firefox...
> I already tried adding a setTimeout("xxx",10000); to access the IFRAME > but that does NOT work! You're right, sorry. The problem is, you're getting the [object Window] for the frame's document, which goes away as the frame reloads. So naturally accessing it doesn't work even after timeout. If you do |IFrameObj = document.getElementById("the_iframe").contentWindow| before using it in the timeout, everything will work. Interestingly, just repeating |IFrameObj = self['the_iframe'];| doesn't set IFrameObj to point to correct [object Window]. > Your test does not move the iframe so I don't understand why you posted it. What's relevant is that the element is removed from the DOM and reinserted back. My testcase does that. The actual position in the tree does not matter. > p.s. wouldn't it be better to have the content of the iframe remain intact > when you move it? Imagine if you want to move user generated content > inside an iframe, it won't be possible in Firefox... Sure, I'm not arguing against that, but it's what bug 254144 is about, and I was trying to figure out if your issue is caused by the same bug.
*** Bug 351333 has been marked as a duplicate of this bug. ***
Created attachment 241329 [details] testcase #2 - self.frame_name doesn't get updated to point to the new window
(comment #14) > Interestingly, just repeating |IFrameObj = self['the_iframe'];| doesn't set > IFrameObj to point to correct [object Window]. > The above testcase demonstrates this, tested in Firefox 2.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.