Any way for content scripts to access window.opener?

[Greg Cooksey]

In my extension, I'm trying to determine whether a new tab was created
as a popup by another tab and if so, which tab.

I thought I would be able to use window.opener from a content script
to help figure this out. But it looks like window.opener doesn't work
correctly in content scripts.

When I create a tab manually, it's window.opener is null as expected.

When a tab is created as a popup by another tab, its window.opener is
undefined. I can infer from this that the tab was created as a popup,
but I can't use it to figure out which tab created the new one.

Is this a known issue, and does anybody know of any workarounds?

[Adam]

Content scripts don't have access to the chrome.windows API. This must
be handled through the background.html page.

Your background.html page should register an event listener to listen
for new Windows as they are created.
http://code.google.com/chrome/extensions/windows.html#event-onCreated

When a window is created, it fires this handler, and passes the Window
object to the function.
You can identify what type of window it is by accessing the window
object directly. If the window object were stored in a variable called
'w' then you would access the type of the window by w.type.
w.type would either equal "normal", "popup", or "app"

Tabs have a similar event http://code.google.com/chrome/extensions/tabs.html#event-onCreated

Its a good idea to remove these event listeners when they aren't
needed, if possible.

-Adam

[Greg Cooksey]

I'm not asking about the chrome.windows.* api. I'm asking about the
DOM Window's opener property.

On Sep 2, 9:40 am, Adam <ldsfutbolpla...@gmail.com> wrote:
> Content scripts don't have access to the chrome.windows API. This must
> be handled through the background.html page.
>
> Your background.html page should register an event listener to listen

> for new Windows as they are created.http://code.google.com/chrome/extensions/windows.html#event-onCreated

>
> When a window is created, it fires this handler, and passes the Window
> object to the function.
> You can identify what type of window it is by accessing the window
> object directly. If the window object were stored in a variable called
> 'w' then you would access the type of the window by w.type.
> w.type would either equal "normal", "popup", or "app"
>

> Tabs have a similar eventhttp://code.google.com/chrome/extensions/tabs.html#event-onCreated

[Adam]

Content Scripts run in isolated worlds. They can access the DOM, but
not any javascript running on the page. Either the content script
isn't permitted to access the window.opener object, or the content
script is accessing the extension's window.opener property. Either
way, it seems like window.opener won't work from Content Scripts.

What exactly are you trying to do with your extension?

If you need to find out which tab created the popup, I would use 2
eventListeners. One to listen for new windows, and one to listen for
when a tab is changed. Whenever the active tab is changed, the change
is registered in background.html, so your background page would always
know which tab was active.

Then, when a new window was opened, it would fire the new window
listener, which would access the stored tab id of the currently active
tab.

chrome.windows.onCreated
chrome.tabs.onSelectionChanged

-Adam

[Adam]

If your desperate to access window.opener, then the content script
could embed a script in the page via document.createElement("script").
That script wouldn't be a content script and would be able to access
window.opener. It could access window.opener, then trigger a custom
event which would bubble the DOM and fire a custom event handler in
your content script.

Kind of convoluted, but it would get the data from window.opener that
you needed.

-Adam

[Greg Cooksey]

My extension is part of a browser automation project. I'm trying to
automate some, but not all, of the open tabs in the browser. If a new
tab is created by an already-automated tab, then I want to automate
this new tab. If a new tab is created by the user, then I don't want
to automate it.

It looks like your suggestion for tracking the onCreated and
onSelectionChanged events won't help me differentiate between those
situations.

Sounds like I should log this as a bug. It seems pretty similar to the
frames bug (http://code.google.com/p/chromium/issues/detail?id=20773)

-Greg

[Adam]

I'm not sure I quite understand your design goal. Are you trying to
determine whether a window is a popup or a tab? Or are you trying to
differentiate between a tab opened by a user and one opened by an
automation script?

If your content script is the one actually opening new tabs/windows,
then it could send a request to background.html, which would listen
for the next tab/window to be created, then once it captured the
necessary info, remove the listener and send the info back to the
content script.

However, if scripts in the page itself (one's not part of your
extension) are opening new tabs/windows, then I'm not sure what to do
about that.

-Adam

[Greg Cooksey]

I'm trying to differentiate between a tab (or popup window) opened by
a user vs. one opened by a page that is being automated.

The new tab would be opened by a script in the page or by a link that
specifies it should be opened in a new window. Since the Chromium Tab
object does not specify its opener, I was hoping that I could access
the DOM Window opener property and use information from that to handle
this situation.

-Greg

[Gildas]

You can inject a script into the page this way :
function sendMessage() {
[...]
}
location.href = "javascript:(" + sendMessage.toString() + ")()";

Then you have to write the sendMessage function which sends the
window.opener value to the content script with a "custom event", and
the listener function into your content script as described here :
http://code.google.com/chrome/extensions/content_scripts.html#host-page-communication.

[Johan Sundström]

On Fri, Sep 3, 2010 at 14:18, Gildas <gildas....@gmail.com> wrote:

You can inject a script into the page this way :
function sendMessage() {
 [...]
}
location.href = "javascript:(" + sendMessage.toString() + ")()";

This trick, for some reason, wrecks browser history in Chrome (tested on Chrome 8.0.552.231 mac, but I have seen the same on Linux too, and think it's been around for a while). Somewhat minimal test case:

* Try installing this basic ugh.user.js content script:

function ugh() {

}

location.href = 'javascript:('+ ugh.toString() +')()';

* Open a new tab

* Go to some page, say http://www.google.com/

* Click a link, say "Advertising Programs" | http://www.google.com/intl/en/ads/

* Click "back"

* You're back at the New Tab page, not the expected http://www.google.com/

--
 / Johan Sundström, http://ecmanaut.blogspot.com/

[PhistucK]

Search crbug.com for an existing issue and star it. If you cannot find one, file a new issue at new.crbug.com.

Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

Thank you.

☆PhistucK

2011/1/2 Johan Sundström <oya...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.