New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 190 users
Status: Fixed
Owner: ----
Closed: Aug 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Let content scripts see other frames (instead of them being undefined)
Reported by dawag...@gmail.com, Sep 1 2009 Back to list
Chrome Version       : 4.0.203.2 (Official Build 24690)

What steps will reproduce the problem?
1. Try to access window.frames[some_index] from a content script

What is the expected result?
We get the frame

What happens instead?
For all n, window.frames[n] = undefined

Attached is an extension which shows the problem.  Load chrome with it and
go to frameset.html.
 
frames-bug.zip
939 bytes Download
Labels: -Area-Misc Area-WebKit
Status: Untriaged
Yes.  This will require some amount of work to restructure the bindings.  The trick will be have multiple contexts 
per isolated world and figuring out how to GC the memory.
Labels: Area-Extensions
Comment 3 by karen@chromium.org, Oct 21 2009
Labels: Mstone-4
dimitri, i assume extensions are mstone 4?
Comment 4 by abarth@chromium.org, Oct 21 2009
I don't think we should try to fix this for Mstone-4.  It's going to be pretty tricky.
Comment 5 by karen@chromium.org, Oct 22 2009
Labels: -Mstone-4 Mstone-X
np. moved to X.
Bummer!  I'm really looking forward to this feature.
Status: Assigned
Comment 8 by aa@chromium.org, Nov 16 2009
Labels: Feature-Extensions
Comment 9 by aa@chromium.org, Nov 19 2009
Labels: -Area-Extensions
Status: Started
Summary: Let content scripts see other frame (instead of them being undefined) (was: NULL)
First step is here:
https://bugs.webkit.org/show_bug.cgi?id=33087
Summary: Let content scripts see other frames (instead of them being undefined) (was: NULL)
 Issue 32087  has been merged into this issue.
Comment 14 by Deleted ...@, Mar 30 2010
I am really looking forward to this feature....
Getting window.frame[id] as undefined. I have 4.0.249.89 version of chrome installed.

Comment 16 Deleted
I got the same error, frames undefined... I got Chrome 5.0.375.70
Impeding an extension I developed.  Looking forward to the fix.
Comment 19 by Deleted ...@, Aug 19 2010
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
good--- im looking for many beautiful frames....
♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥
Comment 20 by kidok...@gmail.com, Aug 30 2010
same problem, Chrome 7.0.503.0 dev
Comment 21 by Deleted ...@, Sep 10 2010
it ain't working yet 
Comment 22 Deleted
bump. Need this
This is painful!!!
I thought I would work around the cross-domain restrictions of content scripts by using the safe and standard postMessage API. But since I can't even get a handle to the contentWindow of my iframe, I can't pass messages! Frustrating!

I would use a background page, but then all get/set of prefs become asynchronous, and I have to do a lot of redesign to handle that.

Hate to say it, but developing for Chrome is kind of painful compared to Firefox/Safari.
I was just talking about this bug with Anton yesterday.  He's doing some infrastructure work that might help with fixing this issue.
I am also running into this issue.  Any feedback on ETA would be much appreciated.  I need to be able to know which frames belong to which windows - and access the properties in those frames.  At this point the only recourse I see is to create a map of which frames belong to which windows by running my contentscript in every frame.  Then I will send a message to a tab, along with the frame name, and ignore the message unless the passed-along frame name matches the name of the frame.  This way I can target messages to the correct frames.  

There are some nice things about the Chrome APIs, but I must agree that at this point they are very rough and not nearly as easy to use as Firefox.

Very painful.
I am making an extension which applies to the Compose frame of Gmail.
As a test I have been applying css hide operations with JS (via
Jquery). The operations work when Gmail opens, however when accessing
the Compose section, it doesn't. 
A workaround mentioned on http://blog.afterthedeadline.com/2010/05/14/how-to-jump-through-hoops-and-make-a-chrome-extension/ is that you can get the contentDocument of the iframe, and from there you can use jQuery as normal, e.g. $('a', $($("#canvas_frame")[0].contentDocument)).

The workaround that Nathan suggested doesn't seem to work for Gmail, because as mentioned in the blog post I linked to above, even a content_script registered for '<all_urls>' does not load on about:blank, and Gmail's iframes have no @src. about:blank is also apparently not among the pages that it is possible for a Chrome extension to provide an Override Page for.

Sending my best wishes to Anton and whoever else is working on this! When you stare down this abyss, may it blink. :)

I don't agree with the assertions that Chrome extensions are more painful than Firefox extensions in general, but there certainly are things that are possible in Firefox that are not possible in Chrome.
I got excited about the suggestion to use contentDocument, and thought that it would be a good workaround - until I observed that it does not work across domains - e.g. if the frame uses a different domain than the frameset page.
Cc: a deleted user
 Issue 78245  has been merged into this issue.
Blocking: flactrlext:43
Labels: -mstone-x
Cc: -abarth%c...@gtempaccount.com abarth@chromium.org
Owner: a deleted user
mihaip is much more likely to solve this problem than I am at this point.
Any estimate when this might be worked on or fixed?  I'm finding myself spending a lot of time trying to work around it, which I can do for frames on the same domain but I haven't figured out how to reliably do for frames on a different domain.
#34: Actually I found out a workaround for this issue in SingleFile extension. It's (very) ugly but it works reliably. See the two "wininfo.js" scripts for more information.
https://github.com/gildas-lormeau/SingleFile/
 Issue 54790  has been merged into this issue.
Comment 37 by kra...@bubbler.com, Jun 14 2011
Gildas: I'm guessing you mean https://github.com/gildas-lormeau/SingleFile/blob/master/WebContent/core/scripts/content/wininfo.js and https://github.com/gildas-lormeau/SingleFile/blob/master/WebContent/core/scripts/bg/wininfo.js? Looks like what you're doing is injecting the former into all_frames, and then you send an initRequest message to the tab, which then gets received by the script in each frame, which then ... does something with setTimeout and location.href = 'javascript:stuff'? Do you want to explain in any more detail?

The workaround we've been using is just to inject a content script into all_frames, have it send a request to the background page when it loads, and handle any other kind of communication from there.  It's a little tricky to make interactions between frames work — the background page has to relay the message for them — but not nearly as tricky as what you're doing. :)
Status: Assigned
Is there currently any ETA for this issue? It would help a lot for my project on webui in ChromeOS.
This bug is unrelated to WebUI.
Hi Gildas,

I just wanted to thank you for providing the workaround you used for SingleFile.  The key idea there was using the window.postMessage API and passing the frame id in that message.  Those ideas allowed me to implement what I needed to.

I must say that your reply was literally an answer to my prayer.  That morning, I was pretty much sure I did not have a solution, and did not think I would get one.  I was planning to make a comment on this PR, hoping that someone would reply, but also didn't expect that.  But I needed help, so I told God "Please help me in SOME way".  And sure enough, you replied 30 minutes after my post.  He answered my prayer and you were that answer.

Thanks again!
Comment 42 Deleted
Can we have a progress report for this bug, or a sanctioned workaround.  My particular conundrum requires getting the selected text from websites that embed useful content in frames, hence when the user highlights text I need to interpret its inside frames I cannot see. An update / workaround would be dandy.
After two years... Well, there are a limited workarround that works for me:
window.onload = function( ) {
    console.log( this ); // Yeah, the real 'window' object!
}

If don't works, try with document.onload or document.body.onload.

--- 
For topic, my suggestion ir something like:
var win = window.documentWindow; // or .contentWindow
Comment 45 by aa@chromium.org, Oct 31 2011
Cc: mpcomplete@chromium.org
 Issue 100367  has been merged into this issue.
Blocking: -flactrlext:43
Cc: jochen@chromium.org
Owner: ----
Status: Available
Unfortunately I won't have time to work on this anytime soon.
Comment 49 by aa@chromium.org, Feb 8 2012
Labels: Restrict-AddIssueComment-Commit
Cc: nepper@chromium.org
Cc: japhet@chromium.org
Project Member Comment 52 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-WebKit -Feature-Extensions Cr-Content Cr-Platform-Extensions
Comment 53 by laforge@google.com, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 54 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Status: Fixed
this was fixed some time ago
Sign in to add a comment