Bug with iframe / history update failing using addon SDK



Add-on SDK
6 years ago
6 years ago


(Reporter: Steve Sobel, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120129021758

Steps to reproduce:

I have a strange issue that went away with the release of addon SDK v1.3, but came back with 1.4.2 (I have not used any versions in between those two)... I did also test 1.5b3 and there is still an issue there.  Here's what happens:

My addon allows you to view images inline on Reddit without leaving the site -- so links get a little "expand image" button that you click...

People complained that the link to the image wasn't being marked as visited (turning purple in color), so I added a little hack that's unfortunately the only way I can solve this issue...

The hack is to load an invisible iframe, and once the image finishes loading, set the iframe source to that image's URL...

Actual results:

What happens in versions 1.3rc1, 1.4.2 and 1.5b3 of the addon SDK is that this "hack" only works the first time an image is expanded on a page. Subsequent images after that (and changes to the href of the iframe) do not properly get marked as visited.

In 1.3 official, however, it does...

Expected results:

What should have happened is each time I change the iFrame's source, it should load that image, and the link pointing at that same URL should turn purple / be marked visited in browser history.
Alex, could you take a look at this and figure out what changed?
Whiteboard: [triage:followup]
Steve, is your addon on Addon builder? or on AMO?
So that I can run it and diagnose what's wrong.

Comment 3

6 years ago
Alexandre: this is Reddit Enhancement Suite - available in XPI at http://redditenhancementsuite.com/ - source code available on github at:


(weird note on source: take the reddit_enhancement_suite.user.js from the lib/ folder... I'm having problems with git and windows symlinks, the user.js file should be the same in ALL browser versions...)

Comment 4

6 years ago
I just wanted to post an update that I just tried v1.5rc1 and still see this same behavior...

I can only use v1.3 at this point to compile a releasable version of my addon.

Comment 5

6 years ago
Sorry, just posting another update: 1.5rc2 doesn't fix the issue.  I imagine since I already pointed out rc1 didn't fix it that this is self evident unless you've had the chance to try it out for yourself... but just in case...
Alex, can you take a look at his addon when you get a chance?

Comment 7

6 years ago
Hey, I have an update.. I'm not sure if I just derped on this or what... but I've tested with the official 1.5 SDK, and I get an error message in the console that I don't recall seeing before:

error: An exception occurred.
Traceback (most recent call last):
  File "resource://jid1-xufzosoflzsoxg-at-jetpack/api-utils/data/content-proxy.j
s", line 761, in
    return wrap(o, obj, name);
  File "resource://jid1-xufzosoflzsoxg-at-jetpack/api-utils/data/content-proxy.j
s", line 270, in wrap
    if ("__isXrayWrapperProxy" in value)
Error: Permission denied to access property '__isXrayWrapperProxy'

Comment 8

6 years ago
Sorry to be a bother but has anyone looked at this?

This bug is a blocker for me releasing an update to my extension... :-\
Hey Steve,
Sorry for being so long to respond to you.
I've already take a look at your addon some weeks before and noticied your issue.
Now, I'm not able to reproduce it. Have you landed a workaround in your code?
(Tested against last master from your git repo and 1.5b3 and yesterday's sdk master)

Otherwise, then exception about '' is due to a bug released in 1.5. It is going to be fixed in next beta for 1.6. (Landed a fix today, bug 715755)
In the meantime, you can avoid this exception by avoiding accessing `contentWindow` here:
(This exception fires every time you try to access an object from another domain)
Created attachment 603692 [details] [diff] [review]
Patch against RES addon

I looked at your git history, and yes, you've added a workaround!
Here is a patch to make it work against today's master.
I'll try to get bug 715755 landed for the next 1.6 so that it will be fixed for 1.6 release due to 2012-04-03.

Otherwise, you should be able to fix it for 1.5 if you can avoid accessing `contentWindow` attribute.

Can you confirm me that your issue is solved?

Comment 11

6 years ago
Hey thanks for the update - I did in fact commit a hack in to github late last night that got around the issue.

It may be an unnecessary hack now that I understand a bit more, but basically I am avoiding accessing contentWindow by checking for self.on - and then just destroying and recreating the iframe instead of trying to use location.replace - the github diff is here:


Thanks for following up!
Depends on: 734891
Closing as bug 715755 has landed + Steve has used a workaround for pre 1.6
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [triage:followup]
You need to log in before you can comment on or make changes to this bug.