417155 - Links within IFRAMEs pointing to the same domain as the IFRAME open in web browser

Status: RESOLVED WONTFIX

(Mozilla Labs :: Prism, defect)

Description

[Dylan Grose]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12
Build Identifier: 

Any links which are inside of IFRAMEs and which point to a URL with a domain which is not the same as the root document's domain get opened in a browser window. It seems that a link within an IFRAME should be subject to the same conditions as a link in the root document with respect to their parent document. This makes sense for web applications such as Netvibes which allow the user to embed webpages within IFRAMEs, and I assume would make sense anywhere else IFRAMEs are used.

Reproducible: Always

Comment 1

[Dylan Grose]

Attachment: Trivial possible fix

This works, but I'm not sure if this is the best way to do it since I'm not really familiar with the Mozilla APIs.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 302971 [details] [diff] [review]
Trivial possible fix

>Index: client/chrome/content/webrunner.js
>-        var currentDomain = this._tld.getBaseDomain(this._getBrowser().currentURI);
>+        var currentDomain = this._tld.getBaseDomain(aLink.ownerDocument.location.href);

Very close and thanks for taking the time to investigate the bug.

| aLink.ownerDocument.location.href | is a string and we need a nsIURI object.

But we can use:

| aLink.ownerDocument.documentURIObject | to get the nsIURI object for the link's document because we are chrome code, not web content.

This should work. I'll patch and test it out.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: Uses documentURIObject instead of location.href

Switch to the nsIURI object (.documentURIObject) instead of string (.location.href)

This makes links in IFRAMEs follow the same rules as top-level links

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

Whoops. Wasn't until I tested this that I realized that this is *not* what we want to do. The webapp domain is the domain we check all links against, even if the webapp has IFRAMEs. Any link in the IFRAME should be checked against the webapp domain, and opened externally if the base domains are different.

That is how the current code works, so marking this WONTFIX. IFRAMEs are not mini-webapps to Prism.

Comment 5

[Matthew Gertner]

So this means that something like NetVibes is not usually in Prism?