You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently do not handle content of an <iframe srcdoc="....">. We inline the iframe's inner doc, when available, into the src as a data: URL, regardless whether it came from the src or from a srcdoc; but a viewer will use the srcdoc instead of src when it is available, thus things break.
We could choose to always remove srcdoc attributes (or always use them), or we could process srcdoc content as a subresource (except we don't even need to fetch it, and its base URL is equal to the parent document's base URL) and keep it in the srcdoc attribute. Or something in between.
The text was updated successfully, but these errors were encountered:
Similarly, a (i)frame without either src or srcdoc is ignored. The frame may nevertheless have content inserted into it by a script (e.g. Etherpad content is currently not stored because of this issue). Time to start seeing a frame as more than just a single subresource..
Another note: a frame with e.g. an image as its src will, both in Firefox and Chromium (but each slightly differently), be rendered into an ad-hoc generated DOM. We currently snapshot that DOM, but should just inline the image file instead.
We currently do not handle content of an
<iframe srcdoc="....">
. We inline the iframe's inner doc, when available, into thesrc
as adata:
URL, regardless whether it came from thesrc
or from asrcdoc
; but a viewer will use thesrcdoc
instead ofsrc
when it is available, thus things break.We could choose to always remove
srcdoc
attributes (or always use them), or we could processsrcdoc
content as a subresource (except we don't even need to fetch it, and its base URL is equal to the parent document's base URL) and keep it in thesrcdoc
attribute. Or something in between.The text was updated successfully, but these errors were encountered: