User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:18.104.22.168) Gecko/20060728 Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:126.96.36.199) Gecko/20060728 Firefox/188.8.131.52 This bug is related to bug 295930, in that it is caused by the absolute-to-relative conversion that that bug contends should not happen. If that bug is fixed, this one will become irrelevant. When HTML is added to the editor by calling document.execCommand ("inserthtml", false, "<html to insert here>"), any URLs in the HTML (for example in 'src' tags of images) are converted to relative URLs based on the address of the document that contains the iframe. For instance, if I have a document at 'http://myserver/site/page/edit' and insert the HTML '<img src="http://myserver/static/image.gif">', this gets converted internally to '<img src="../../static/image.gif">'. Now, if the containing document contains a <BASE> tag, this is ignored. So, if the page contained '<BASE href="http://myserver/">' we would expect the location of the iframe to be set to reflect that base, at which point the correct relative URL would be 'static/image.gif', yet still '../../static/image.gif' is produced. This gets even worse if we add a <BASE> tag to the content of the iframe. In this case, the image is inserted with the URL in the same relative form as all the other cases, but the image cannot be loaded because it is wrong even for the document it is being placed directly into. Reproducible: Always
In order to be able to reproduce the latter problem using the filenames in my example, you'll need to use URLs with an extra degree of nesting, e.g. http://myserver/mysite/site/page/edit with a base of http://myserver/mysite, etc.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 295930
You need to log in before you can comment on or make changes to this bug.