Script not running until refresh on Fark.com #1445

Closed
AeroIllini opened this Issue Oct 14, 2011 · 12 comments

Comments

Projects
None yet
4 participants
@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

This comment has been minimized.

Show comment Hide comment
@arantius

arantius Oct 14, 2011

Collaborator

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

Collaborator

arantius commented Oct 14, 2011

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

@AeroIllini

This comment has been minimized.

Show comment Hide comment
@AeroIllini

AeroIllini Oct 14, 2011

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).

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

This comment has been minimized.

Show comment Hide comment
@arantius

arantius Oct 14, 2011

Collaborator

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?

Collaborator

arantius commented Oct 14, 2011

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

This comment has been minimized.

Show comment Hide comment
@arantius

arantius Oct 14, 2011

Collaborator

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?

Collaborator

arantius commented Oct 14, 2011

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

This comment has been minimized.

Show comment Hide comment
@johan

johan Oct 15, 2011

Collaborator

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.

Collaborator

johan commented Oct 15, 2011

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

This comment has been minimized.

Show comment Hide comment
@AeroIllini

AeroIllini Oct 26, 2011

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.

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

This comment has been minimized.

Show comment Hide comment
@arantius

arantius Oct 26, 2011

Collaborator

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

Collaborator

arantius commented Oct 26, 2011

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

@AeroIllini

This comment has been minimized.

Show comment Hide comment
@AeroIllini

AeroIllini Oct 27, 2011

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.

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

This comment has been minimized.

Show comment Hide comment
@arantius

arantius Oct 27, 2011

Collaborator

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.

Collaborator

arantius commented Oct 27, 2011

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

This comment has been minimized.

Show comment Hide comment
@AeroIllini

AeroIllini Oct 27, 2011

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.

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

This comment has been minimized.

Show comment Hide comment
@arantius

arantius Oct 28, 2011

Collaborator

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.

Collaborator

arantius commented Oct 28, 2011

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

This comment has been minimized.

Show comment Hide comment
@SmithsFAS1

SmithsFAS1 Nov 3, 2011

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 :)

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 :)

@arantius arantius closed this in 94693d5 Nov 3, 2011

arantius added a commit to arantius/greasemonkey that referenced this issue Aug 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment