Script not running until refresh on Fark.com

[AeroIllini]

Scripts are not running on many comments pages on Fark.com. Refreshing the page (F5) runs the scripts properly. The first page of comments runs scripts fine, but subsequent pages do not.

Greasemonkey version: 0.9.12
Tested on: Firefox 3.6 and 6.0 in Windows XP, Firefox 3.6 on Linux (two separate computers in separate network environments). Tested with and without clean profiles, using "@include *".

[arantius]

Can you provide a specific script (the smaller the better) and a specific page?

[AeroIllini]

Sure. The script can be anything; I've tried it with many of my scripts.

// ==UserScript==
// @name           Test script
// @namespace      http://www.aeroillini.com
// @description    Test script
// @include        *
// ==/UserScript==

alert("boo!");

function yellBoo() {
    alert("boo!");
}   

GM_registerMenuCommand("Yell Boo", yellBoo);

And it doesn't seem to happen on specific pages, but it happens on every comment page after the first in a Fark thread. So go to http://www.fark.com, click on the comments page of a news item (the numbers in parentheses on the right). When the first page of comments appears, the script will run. Then click the right arrows to advance to page 2, and the script will not run. Hit F5 to refresh, and the script will run. Click on the right arrows to advance to page 3, and the script will not run. Hit F5, and the script will run. And so on.

Let me know if you need more info.

EDIT: removed reference to registered menus as a problem. This issue appears on all scripts (see below).

[arantius]

When I install that script, open a particular item on fark.com, and page through the comments, I get a "boo" alert on every page.

http://wiki.greasespot.net/Troubleshooting_(Users)

Especially the "fresh profile" stuff. Does that change anything?

[arantius]

When I install that script, open a particular item on fark.com, and page through the comments, I get a "boo" alert on every page.

http://wiki.greasespot.net/Troubleshooting_(Users)

Especially the "fresh profile" stuff. Does that change anything?

[johan]

Listing one specific url and what to click while there to make the problem appear could be helpful to help you tell what's going on.

To me, it sounds like HTML5 history pushState / popState API use (https://groups.google.com/d/msg/greasemonkey-dev/ZI_XsivNjT0/tdEBchTctbQJ), but I could be wrong. If Fark has started using silent ajax techniques to update partial page content while also updating the URL, this could be a second victim of that problem.

If so, Greasemonkey is working just as designed, and it just is the web that has started edging away from page behaviour that Greasemonkey was designed to work with.

[AeroIllini]

I've done some more experimentation. The problem only appears when I am logged in to Fark and have selected the "Automatically jump to first new comment when reading (requires Javascript)" option in my preferences. This option adds the following code to the page, near the bottom:

<script type="text/javascript">
//<![CDATA[
if (window.location.hash == '') window.location.hash = '#new';
//]]></script>

There is also an anchor tag called "new", put in the html by some server-side process.

When the above code is present, none of my Greasemonkey scripts execute, at all, even with "@include *" set. Without the above code (preference deselected), scripts function normally.

I found a groups post from someone with the same issue, but no working solution is presented: http://groups.google.com/group/greasemonkey-users/browse_thread/thread/6180e797719e09b0?pli=1 The suggested solution of checking for hash change in the script wouldn't work, since the script is never executed in the first place. This behavior is happening upstream of the user scripts.

As a workaround, I can just turn off this preference in my Fark user profile, but this exposes a larger issue with Greasemonkey... which is executing scripts either before or after location.hash changes via script. Currently they don't seem to execute at all.

[arantius]

Good work, that explains why our simple (and not-logged-in) tests didn't reproduce the error, and is a very actionable report.

[AeroIllini]

I did one more test...

The issue doesn't have anything to do with whether or not the hash is reset by script. Greasemonkey simply does not run scripts if the URL has a location hash in it, even if that's the first time the page has been loaded (i.e., not a link to itself).

Below is a test setup I created to illustrate the issue.

The user script is extremely simple:

// ==UserScript==
// @name           Test Script
// @namespace      http://www.aeroillini.com
// @description    Test script
// @include        http://www.aeroillini.com/lochash2.html
// ==/UserScript==

alert("boo!");

I created two files, which can be found at these links:
http://www.aeroillini.com/lochash1.html
http://www.aeroillini.com/lochash2.html

In case these files move off my hosting at a later date, here is the source code for both:

lochash1.html:

<html>
    <head>
        <title>Location Hash Redirect Greasemonkey Test</title>
    </head>
<body>
    <h1>Heading</h1>
    <p><a href="lochash2.html#hash" title="Link to hash">Link to hash</a></p>
    <p><a href="lochash2.html" title="Link to page without hash">Link to page without hash</a></p>
</body>
</html>

lochash2.html:

<html>
    <head>
        <title>Location Hash Redirect Greasemonkey Test</title>
    </head>
<body>
    <h1>Heading</h1>
    <p><a href="lochash2.html#hash" title="Link to self">Link to self</a></p>

    <p>Lorem ipsum... (wall of text)</p>

    <a name="hash"></a>
    <hr style="color: #ff0000;">

    <p>Lorem ipsum... (wall of text)</p>

</body>
</html>

Clicking the link "Link to hash" in lochash1.html does not run the script (no alert box), but clicking the link "Link to page without hash" does run the script (boo!). Clicking the link "Link to self" in lochash2.html also does not run the script (no alert box), but this behavior is more likely to be expected.

I can understand that links to self might not want userscripts to run a second time, but the first time the user is presented with the page, they would expect the scripts to run, even if that first presentation includes a location hash.

[arantius]

Clicking the link "Link to hash" in lochash1.html does not run the script

I disagree. Navigating to the new page (1 -> 2) does indeed cause scripts to run. Your script does not run on the 'link to hash' because the test case is flawed: the @include rule does not match that url (the one with the hash). Append a "*" to the include line and it will work as expected.

Scrolling within the page (for any reason, including "navigating to a hash") does not cause scripts to run, period. In your actual failure on fark, the script should run because you loaded the page, and the navigation to hash by the script should have no effect (besides, of course, the scrolling). There's a chance that changing the URL while the page is loading is confusing GM somewhere. Or maybe the real script has a similar @include problem.

[AeroIllini]

You're right. I changed the test the following way:

I changed the @include statement to the following:

// @include        http://www.aeroillini.com/*

I added the following code to lochash2.html (which is the same as the code on Fark.com):

<script type="text/javascript">
//<![CDATA[
if (window.location.hash == '') window.location.hash = '#new';
//]]></script>

Now, clicking "link to hash" causes the script to run. Clicking "link to page without hash" causes the script to not run, because the javascript adds the hash.

Thanks for the clarification.

[arantius]

Confirmed. This script:
https://gist.github.com/1322373

Should add some orange text with the current url to (the result frame inside of) this page:
http://jsfiddle.net/Sb6Vz/7/

And it does not -- until the ... hash='#new' bit of JS is commented out. You can replicate this test by the main jsFiddle page, or directly navigating to the 'show' page: http://fiddle.jshell.net/Sb6Vz/6/show/ . Reload that page after it has the '#new' in the URL (and thus the if fails and the location is not changed) and the script will run.

[SmithsFAS1]

Excellent debugging guys! Thanks a ton!

Too bad Fark keeps officially adding in features I put in my script about 6 months after I introduce them :)