Edgewall Software
Modify

Opened 15 years ago

Last modified 17 months ago

#3416 new defect

IFrame

Reported by: anonymous Owned by:
Priority: low Milestone: next-major-releases
Component: wiki system Version: 0.9.6
Severity: normal Keywords: iframe html5
Cc: leho@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

If an iframe added to the wiki, via the HTML formatter, this is not viewed.

Attachments (0)

Change History (25)

comment:1 by Emmanuel Blot, 15 years ago

Resolution: wontfix
Status: newclosed

<IFRAME> has been deprecated in XHTML 1.1 and Trac produces XHTML 1.0 strict code. There are few chances Trac will ever support iframes as long as it produces XHTML.

Ref: http://liorean.web-graphics.com/xhtml/comparison.loose-strict.html

comment:2 by Christopher Lenz, 15 years ago

Milestone: 0.10
Resolution: wontfix
Status: closedreopened

Well, we don't produce XHTML 1.1, so using <iframe> should be perfectly legal. We're probably being too paranoid there.

comment:3 by Christopher Lenz, 15 years ago

Component: generalwiki
Owner: changed from Jonas Borgström to Christopher Lenz
Status: reopenednew

comment:4 by Christopher Lenz, 15 years ago

Status: newassigned

comment:5 by Emmanuel Blot, 15 years ago

Well, we don't produce XHTML 1.1, so using <iframe> should be perfectly legal. We're probably being too paranoid there.

We need to check that <iframe> is legal for 1.0 STRICT, I'm not sure it is (I did not find the info from the official w3c web site). It is illegal with XHTML 1.1 *, but I'm not sure it is even legal in 1.0 STRICT (i.e. perhaps it is only legal in XHTML 1.0 transitional, which we do not support).

Moreover, <iframe> is "officially" not recommended (I need to find the reference…) because it is known to cause several issues with several well known browsers, so I'm not sure it is worth adding it to Trac.

I'll try to find some official references about the above point.
(as a side note: I can't quote your comment, the Safari+"ticket reply" bug is back)

comment:6 by Emmanuel Blot, 15 years ago

Actually, <iframe> is not legal in XHTML 1.0 strict, only valid in XHTML 1.0 transitional.

in reply to:  6 comment:7 by Christopher Lenz, 15 years ago

Milestone: 0.10
Resolution: wontfix
Status: assignedclosed

Replying to eblot:

Actually, <iframe> is not legal in XHTML 1.0 strict, only valid in XHTML 1.0 transitional.

Okay, I forgot about that. I agree with your original resolution then.

comment:9 by anonymous, 13 years ago

Resolution: wontfix
Status: closedreopened
Version: 0.9.60.10.2

What is the accepted mechanism for embedding other html inline on Trac pages?

The expected answer of "You shouldn't do that," while a quick and easy solution from a Trac developer's perspective, is hardly acceptable from a user perspective.

If someone is savvy enough to install Trac and use the html processor, one would imagine they're savvy enough to know not to include dangerous embedded content.

Regardless, that isn't really the decision for Trac developers to make for the entire Trac user community.

in reply to:  9 comment:10 by Emmanuel Blot, 13 years ago

Resolution: fixed
Status: reopenedclosed
Version: 0.10.20.9.6

Replying to anonymous:

What is the accepted mechanism for embedding other html inline on Trac pages?

HTML: you should not. XHTML/strict, you may use {{{#!html ... }}} blocks.

If someone is savvy enough to install Trac and use the html processor, one would imagine they're savvy enough to know not to include dangerous embedded content.

There are options (see TracIni) to disable sanitization of the inlined XHTML code. It does not mean you can write invalid HTML code, you'll still need to write proper XHTML - it will be displayed as expected.

Regardless, that isn't really the decision for Trac developers to make for the entire Trac user community.

No it's a technical limitation: you cannot embed some PDF file into a JPEG image, can you? This is the same for Trac: if you'd use HTML, the resulting output would be an invalid stream from a w3c perspective.

comment:11 by anonymous, 13 years ago

Resolution: fixed
Status: closedreopened

The assertion likening this issue to embedding a PDF file into a JPEG image is entirely spurious. We're not talking about a binary file format. Whether XHTML or HTML, we're talking about a markup language. The entire point of it is to embed objects into it. Every element of XHTML represents an object that is part of an interpreted stream of data in the markup code. You want to be able to embed that JPEG image into a page, right? Why wouldn't I want to be able to embed a piece of formatted text from another place on the Trac wiki the same way?

Perhaps my question about "embedding" something in a Trac wiki page was not clear. I mean in the exact same way you embed an external image in the XHTML stream, what is the accepted way of embedding an external snippet of XHTML into a Trac wiki page? If you're saying that isn't possible without modifying these sanitization options, or if there's some other mechanism, that's fine. But I think that's clearly a major limitation, and this is definitely a bug, or at least a sorely lacking feature, even if it points to a deep underlying design flaw in Trac. At the very least, I should be able to embed in an iframe or an object tag other pages from the wiki. I don't think that's dangerous or something unreasonable to expect from the system.

in reply to:  11 comment:12 by Emmanuel Blot, 13 years ago

Replying to anonymous:

Whether XHTML or HTML, we're talking about a markup language.

Yes, but incompatible ones.

The entire point of it is to embed objects into it. Why wouldn't I want to be able to embed a piece of formatted text from another place on the Trac wiki the same way?

If you want to embed the code, it's quite easy: a !xml block would suffice.
If you want the code to be rendered by the browser, you need to tell the browser: this part of the stream is XHTML, this embedded section is HTML. I'm not sure it is possible. You can try doing this with <embed> or <object> tags.

At the very least, I should be able to embed in an iframe or an object tag other pages from the wiki.

<iframe> is not a valid tag in XHTML. That's it, you can request for it, but it is not part of the standard, Trac complies with W3C standards. What to add?

You want to add something invalid. Call it a bug if you like, but it is definitely not a bug.
At best (or worse, YMMV) it's a design choice of producing a XHTML rather than a HTML stream.

comment:13 by anonymous, 13 years ago

Using the latest version of Trac, I was able to turn off the sanitization of the XHTML stream, and it turns out including the wiki pages in an iframe or an object wasn't the right solution anyway, because the included pages had all the normal wiki headers and footers.

What I was able to do was use an XMLHttpRequest to parse out the content div of the wiki page I wanted to include on the parent. Here's some code for reference, in case anyone else needs a similar solution:

This is a list of features in Relase 1:

You'd actually need to strip off the form elements of the response to do it right, and place the node at the right point in the parent DOM, but this gets across the idea.

comment:14 by anonymous, 13 years ago

Resolution: worksforme
Status: reopenedclosed

This is the code referenced in the comment above:

open brace, open brace, open brace
hash-bang html

<div id="Release1"></div>

<script>
var req;
var a;
req = new XMLHttpRequest();
req.onreadystatechange=function()
{
if(req.readyState==4)
  {
    f = req.responseXML;
    c = document.getElementById("content");
    c.insertBefore(f.getElementById("content"), c.firstChild);
  }
}
req.open('GET', 'http://hadoop00.corp.millennialmedia.com/projects/mm/wiki/Feature1', true);
req.overrideMimeType('text/xml');
req.send(null);

</script>

close brace, close brace, close brace

comment:15 by Noah Kantrowitz, 13 years ago

It sounds like what you are looking for is the Include macro which lets you include one wiki page in another.

comment:16 by allyourcode@…, 12 years ago

I know iframe is not supported, but it'd be nice if there was some way to embed external resources like a Google Calendar. What is the recommended way of doing this?

comment:17 by skull, 11 years ago

bump:

the lack of this feature is VERY anoying since sanitization breaks mostly anything usefull (i.e. things that you cannot produce using the wiki formatter) :

  • can't use iframe
  • can't use object
  • cant use an external stylesheet
  • can't embed one either…

actually, i really believe it is much more unsafe to allow html embeds using the wiki syntax than use iframes or equivalent XHTML valid tags (object i guess) which definitely cannot break the parent page and let the writer use any document type that a browser can handle.

comment:18 by Christian Boos, 11 years ago

Keywords: iframe html5 added
Milestone: next-major-0.1X
Priority: normallow
Resolution: worksforme
Status: closedreopened

Well, in order to move the discussion past comment:12, we could consider that the <iframe> is making a comeback via HTML5, so we might support that once we get HTML5 support (probably requires #G108 first).

comment:19 by mmitar@…, 8 years ago

I would just add that using render_unsafe_content you can include iframe with {{{#!html ... }}}. At least in my 0.12 installation.

comment:20 by lkraav <leho@…>, 8 years ago

Cc: leho@… added

comment:21 by lkraav <leho@…>, 8 years ago

Is there no render_unsafe_content for Ticket system? I'm trying to render <iframe> in a ticket comment.

comment:22 by lkraav <leho@…>, 8 years ago

Nevermind. Ticket system, somewhat non-obviously, uses wikiformatter's setting for this.

comment:23 by anonymous, 7 years ago

So, is there a solution to incorporate a google calendar item (<iframe>), any alternative? Thanks

in reply to:  23 comment:24 by Carsten Klein <trancesilken@…>, 6 years ago

Replying to anonymous:

How about a Django like approach, e.g. at the trac plugin / macro / processor level, one would use safe_content(HTML.IFRAME(src=…, …)) with Genshi then rendering out the content as is without filtering it out in during one of the sanitation steps?

comment:25 by Ryan J Ollos, 6 years ago

Owner: Christopher Lenz removed
Status: reopenednew

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.