Best way to get location from inside a extension
Somehow I cant believe I'm asking this question, since it should be documented and used in almost every extension but there seems to be an almost endless way to get the URL of the current document. So my question is:
What's the recommended way from chrome of getting the URL of the current document being displayed in a window?
My requirements are that the answer works in both the current Mozilla SeaMonkey and Mozilla Firefox. If a page consists of frames or iframes it must return the top URL.
A couple of possible answers:
- document.location.href
- window.document.location
- window.top.content.document.location
- window.location.href
- document.url
- getBrowser().mCurrentBrowser.currentURI.spec
- gBrowser().mCurrentBrowser.currentURI.spec
- content.location
- ?
Can you come up with the ultimate JavaScript code that does this?
Update:
What if I need to scan through all the links on the current loaded document when I right click on a page?
Ads:
13 Comments
Yes, and if you are doing it from some script running outside the document loaded, then you probably need getBrowser().contentWindow.location.href.
Comment by Wladimir Palant at September 27, 2005 07:56 PM | Permalink"... in both the current Mozilla SeaMonkey and Mozilla Firefox."
I thought that SeaMonkey is no longer a part of Mozilla, as in it is now being developed independently of Mozillian trendy ideas? (Apart from the Mozilla Foundation providing infrastructure resources "only.")
Signed,
'Confused'
Do you want the exact URL of the page, the URL as displayed in the adddress bar (without wyciwyg), or the URL that sorta corresponds to the document's principal (without jar, javascript, data, wyciwyg)? This depends on what you're going to do with the URL.
Also, are you sure you want a URL string instead of an nsIURI object?
Comment by Jesse Ruderman at September 27, 2005 09:41 PM | PermalinkgBrowser().mCurrentBrowser.currentURI.spec
should be
gBrowser.mCurrentBrowser.currentURI.spec
Comment by LouCypher at September 27, 2005 09:50 PM | PermalinkLaurance: You are correct. But how exactly is that relevant to Henrik's extensions?
Comment by Jon Henry at September 27, 2005 10:36 PM | Permalinkguys, what's wrong with:
getBrowser().currentURI.spec?
seems easier than either of:
>gBrowser.mCurrentBrowser.currentURI.spec
and
>getBrowser().contentWindow.location.href.
Also, you should generally prefer URI objects to URI strings...
(as for your blog posting, "window" and "document" refer to the chrome window, so they are usually a chrome:// url. if you want the url loaded in the browser, you'd need content.* / content.document.*)
Comment by christian biesinger at September 28, 2005 03:41 AM | PermalinkGenerally, properties that start with "m" followed by a camelcased word or phrase are intended to be private variables, so you're setting yourself up to be broken at some point if you use |getBrowser().mCurrentBrowser| and friends; there are public interfaces which do the trick just as well and are less likely to be broken.
Another point to mention is that (to the best of my knowledge) a tabbrowser is supposed to have attributes and properties which are a superset of those of a browser, meaning that if you use browser properties on a tabbrowser you'll get the same results for the currently viewed URL in a browser. This is so that you don't need to know anything about tabbrowsers if your code doesn't explicitly interact with them.
Comment by Jeff Walden at September 28, 2005 05:28 AM | PermalinkI think what you should *officially* use is
window.content.location.href
This is what Firefox uses it's it's browser code for sending a URL via e-mail. This also assumes you want what is found in the location bar.
(see: http://lxr.mozilla.org/mozilla1.8/source/browser/base/content/browser.js#5603 )
I used to use:
Components.lookupMethod(window._content, 'location').call(window._content).href
As it's was the 'safe way' to do it as I think it was an older form of XPWrappers.
Comment by jed at September 28, 2005 05:34 AM | PermalinkWell, hello everyone.
It looks like this page talks about what I'm looking for! Maybe you guys can give me a big help.
I've place an extension in my Internet Explorer tool bar, which has to replace the current URL, depending on the situation...
for example: if the user is in URL1, then by clicking the button, the browser should redirect to URL2. If the user is in URL2, then he should go to URL1. So, when the user click the button, it will call a .js file, which will find out where the user is, then change the URL. The problem is, when the .js file is called, it can't get the current URL. I've made a test, with alert(window.location.href), but it shows the physical path of the file in my PC (like file:///C:/...) So, all I want now is to be able to find out where the user is, from an Internet Explorer extension. I've tried everything, like window.referrer, window.location, this.window.location, but nothing. Any ideas?
Thanks everyone.
Comment by Bob at October 25, 2005 07:48 PM | PermalinkUm, Bob, maybe this is noobish but how exactly do you make an Internet Explorer extension?
Comment by cheeseboy at July 31, 2006 09:06 AM | PermalinkIE calls it a Browser Helper Object (all native), which is more complex (C++) than an extension written in a high level language.
Comment by ed raket at September 15, 2006 02:50 PM | Permalink
top.location.href, definitely (at least if you are trying to do it from the document loaded - this wasn't quite clear from you post). If you want documentation - find JavaScript 1.3 Reference (this version still has some info on window and document objects unlike JS 1.5).
window.location - the string representation of the Location object matches the href property but you shouldn't rely on this
Comment by Wladimir Palant at September 27, 2005 07:51 PM | Permalinkdocument.location - this is only for compatibility, I think this was a IE-only feature originally
document.URL - JS 1.3 Reference explains how this differs from window.location.href. Usually you shouldn't need this.
window.top
getBrowser(), content etc - rrrright, why simple if you can do it complicated