views:

62

answers:

1

I am looking for a quick way to grab some data off of one Web page and throw it into another. I don't have access to the query string in the URL of the second page, so passing the data that way is not an option. Right now, I am using a Greasemonkey user script in tandem with a JS bookmarklet trigger: javascript:doIt();

// ==UserScript==
// @include        public_site
// @include        internal_site
// ==/UserScript==

if (document.location.host.match(internal_site)) {
  var datum1 = GM_getValue("d1");
  var datum2 = GM_getValue("d2");
}

unsafeWindow.doIt = function() {
  if(document.location.host.match(public_site)) {
    var d1 = innerHTML of page element 1;
    var d2 = innerHTML of page element 2;
    //Next two lines use setTimeout to bypass GM_setValue restriction
    window.setTimeout(function() {GM_setValue("d1", d1);}, 0);
    window.setTimeout(function() {GM_setValue("d2", d2);}, 0);
  }
  else if(document.location.host.match(internal_site)) {
    document.getElementById("field1").value = datum1;
    document.getElementById("field2").value = datum2;
  }
}

While I am open to another method, I would prefer to stay with this basic model if possible, as this is just a small fraction of the code in doIt() which is used on several other pages, mostly to automate date-based form fills; people really like their "magic button."

The above code works, but there's an interruption to the workflow: In order for the user to know which page on the public site to grab data from, the internal page has to be opened first. Then, once the GM cookie is set from the public page, the internal page has to be reloaded to get the proper information into the internal page variables. I'm wondering if there's any way to GM_getValue() at bookmarklet-clicktime to prevent the need for a refresh. Thanks!

A: 

Can you move the bookmarklet to a button or link -- that Greasemonkey will add to the page(s)? Then you could set click-event handlers to fire GM_getValue().

It looks like the current method is exploiting a "security hole" -- one that may be closed in the future. You might consider doing everything in a Firefox extension, instead.

Possibly useful link: http://articles.sitepoint.com/article/ten-tips-firefox-extensions/1

Brock Adams
Thanks, that was a good idea. Exploiting security holes is bad practice, after all.
slk