7

I am working on a Greasemonkey script to turn some text into links on a a Rally page. The script works fine only when I reload the page. If I navigate to the page in any manner (links, browser forward/back) the script does not run, despite the fact that the Greasemonkey menu shows my script at the bottom, with a checkmark.

Here is an example URL:

https://rally1.rallydev.com/#/4745909548/detail/userstory/6138899084/changesets

My matching rule:

/^https://.*\.rallydev\.com/.*/changesets$/

I don't know if the hash is causing a problem, but everything is fine when I reload.

Not sure where to go from here. Any help is appreciated.

neilw
  • 475
  • 6
  • 15

1 Answers1

9

It's impossible to be sure what's going on, because the target page(s) are behind a pay-wall and their alleged "Free Trial" mechanism blows chunks.

Here are some possible causes of the current behavior:

  1. The initial request is insecure (http) but redirects to a secure page (https).
  2. The first page load does a some other kind of redirect to the actual page.
  3. The target content is in an <iframe> that does not load right away.
  4. The target content is AJAXed-in.
  5. Something exotic that we would need to see the actual page to figure out.
  6. The initial URL does not really end in changesets.

Also, get into the habit of escaping the /s in the middle of regular expressions. It's not always needed, but it will eventually bite you in the [censored] if you don't. So the script should use:

// @include  /^https:\/\/.*\.rallydev\.com\/.*\/changesets$/

to start, but see below.


Steps to a solution:

  1. Change your @include to account for http and the Possibility of trailing space or trailing slash in the URL. Use:

    // @include  /^https?:\/\/.*\.rallydev\.com\/.*\/changesets(?:\s|\/)*$/
  2. Examine the page with Firebug. Is the content AJAXed-in? Is it in an <iframe>? If so, what is the iframe URL, if any?
  3. To also detect AJAX and/or redirects, use Firebug's Net panel and/or Wireshark.
  4. If possible, provide us with login credentials so that we may see a problematic page.
  5. Snapshot a problematic page (Save it via Firefox) and link to that HTML and JS in Pastebin.com.

  6. Consider using code like:

    if (window.top != window.self) {
    //--- Don't run on/in frames or iframes.
    return;
}

    To have the script run only in (or not in) iframes, as applicable.


If the problem is caused by AJAX delays (or loading of new content), get around that by using the waitForKeyElements() utility as shown in "Fire Greasemonkey script on AJAX request".

Community
  • 1
  • 1
Brock Adams
  • 90,639
  • 22
  • 233
  • 295
  • 2
    This was monumentally helpful, thank you very much. It was an AJAX problem, though I was fooled initially by the way the links were configured on the page. I tried using waitForKeyElements(), applying the rule to the whole domain, and it seems to be working. It's a bit heavyweight (wish I didn't need to load jQuery), but it works and seems to be reliable. Thanks a bundle. – neilw May 07 '12 at 15:21
  • 2
    You're welcome. I once thought about creating a `waitForKeyElements` that didn't require jQuery, but all but the simplest of my scripts use jQuery anyway. It's not that heavyweight, especially since GM runs it off your local machine when you use the `@require` directive. And jQuery's awesome goodness makes scripting so much easier. – Brock Adams May 07 '12 at 22:40
  • 2
    Thanks very much to all involved. I'm working with Amazon's checkout process and I didn't realize it at first, but they're AJAX loading each "page" and changing the URL via `window.location.pathname`. I updated my script to @include any page in the process and easily converted it to use `waitForKeyElements`. It's a 3 minute solution to what would have been a massive debugging nightmare. – Joel Mellon Jul 21 '14 at 19:32