820213 - Can't load content from "data" directory into an iframe

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Will Bamberg [:wbamberg]]

Reported on the forum: https://forums.mozilla.org/addons/viewtopic.php?f=27&t=11689 - it's not possible to load content from an HTML file in an add-on's data directory into an iframe.

I tried the new-in-1.13 "content-permissions" key, which will be delivered by bug 7686681, but that didn't seem to help.

Comment 1

[Gabor Krizsanits (INACTIVE)]

I think the problem is a restriction around the different url schemes. Something that content-permissions won't fix for sure. I've seen this problem before and there are some usefull hints in bug 792479 how to workaround it. In general I wonder if we intend to encourage add-on developers to change the content/layout of a web page, since I've heard some opinions against that in general from the content team. Also there is a feature suggestion in the same bug we should consider. Will, can you remind me to bring up this topic on the jetpack meeting today?

Comment 2

[jared]

Gabor, how did the discussion go in the jetpack meeting?

I'm also writing an extension that needs this capability. We currently inject our overlay (HTML and styles) into the page without an iframe, but would like to use an iframe for better style encapsulation (to avoid unintended style leakage on random pages). The workaround in bug 792479 is cumbersome. Thanks.

Comment 3

[Gabor Krizsanits (INACTIVE)]

The current approach I think that would work here the best is based on a custom protocol. With that the intention is to make some resources publicly available for content. I think there are some recent patches being landed about blocking mixed content, so there might be some platform changes required, which will delay this feature probably. And it didn't help that I was on holiday and there are some urgent bugs on my plate atm. Dave, do we have someone who could give it a try to solve this problem with a custom protocol without changing platform code? If that does not work out, I could look into the platform code, or ask around what kind of changes are required...

Comment 4

[Dave Townsend [:mossop] (PTO until Aug 21st)]

I've verified that a custom protocol can solve this problem

Comment 5

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Dave Townsend (:Mossop) from comment #4)
> I've verified that a custom protocol can solve this problem

Interesting! And doesn't thin solve some other issues we might have as well?

Comment 6

[Dave Townsend [:mossop] (PTO until Aug 21st)]

(In reply to Jeff Griffiths (:canuckistani) from comment #5)
> (In reply to Dave Townsend (:Mossop) from comment #4)
> > I've verified that a custom protocol can solve this problem
> 
> Interesting! And doesn't thin solve some other issues we might have as well?

Sadly not. Here we want a protocol that is totally accessible to content. Bug 779197 however wants a protocol that is totally inaccessible to content. It's possible to make both, but they have to be two different protocols.

Comment 7

[Dave Townsend [:mossop] (PTO until Aug 21st)]

Also it probably means that if we do this then we want the public protocol to be somewhere special in the add-on's files. Maybe /data/public or just /public.

Comment 8

[flying sheep]

i think i have the same problem: i want to use a webfont locally loaded from the data directory (i.e. via resource:// uri)

this fails:

[17:59:02.760] downloadable font: download failed (font-family: "Averia Serif Libre" style:normal weight:bold stretch:normal src index:2): status=2147500037
source: resource://jid1-zucgqelxgbxyuq-at-jetpack/man-protocol/data/Averia%20Serif%20Libre/AveriaSerifLibre-Bold.woff @ resource://jid1-zucgqelxgbxyuq-at-jetpack/man-protocol/data/Averia%20Serif%20Libre/AveriaSerifLibre.css

Comment 9

[Roland Pihlakas]

I think this is a duplicate of this: https://bugzilla.mozilla.org/show_bug.cgi?id=792479

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562