alert + setTimeout = failure (was: GM_xmlhttpRequest fails silently) #1318

Closed
bokelskere opened this Issue Mar 24, 2011 · 20 comments

Comments

Projects
None yet
@bokelskere
// ==UserScript==
// @name           test
// @namespace      _test
// @include        http://stackoverflow.com/*
// ==/UserScript==

alert("_hello world_");

GM_xmlhttpRequest({
  method: "GET",
  url: "http://www.flickr.com/",
  onload: function(response) {
    alert("success");
  },
  onerror: function(response) {
      alert(
          [
            response.status,
            response.statusText,
          ].join("\n"));
  }
});

When I try this code, I get the "hello world", but the GM_xmlhttpRequest seems to fail silently.

I use Firefox 4.0, Greasemonkey 0.9.1.

@arantius

This comment has been minimized.

Show comment
Hide comment
@arantius

arantius Mar 26, 2011

Collaborator

Confirmed working in 3.6, failing in 4.0.
Simpler clickable test case: https://gist.github.com/888680

Collaborator

arantius commented Mar 26, 2011

Confirmed working in 3.6, failing in 4.0.
Simpler clickable test case: https://gist.github.com/888680

@arantius

This comment has been minimized.

Show comment
Hide comment
@arantius

arantius Mar 26, 2011

Collaborator

Scratch that. Provided case confirmed. My case linked above works as expected. So the bug is somewhere in the difference between the two. Also: when they both run on the same page neither work. But with both installed on a page that only runs mine, it works.

Collaborator

arantius commented Mar 26, 2011

Scratch that. Provided case confirmed. My case linked above works as expected. So the bug is somewhere in the difference between the two. Also: when they both run on the same page neither work. But with both installed on a page that only runs mine, it works.

@arantius

This comment has been minimized.

Show comment
Hide comment
@arantius

arantius Mar 26, 2011

Collaborator

The difference appears to be (this makes no sense to me yet) the leading alert. If I remove the 'hello world' alert from the provided test case, it works as expected.

Collaborator

arantius commented Mar 26, 2011

The difference appears to be (this makes no sense to me yet) the leading alert. If I remove the 'hello world' alert from the provided test case, it works as expected.

@NuckChorris

This comment has been minimized.

Show comment
Hide comment
@NuckChorris

NuckChorris Apr 3, 2011

I'm having the same issue on my scripts, but I don't have any alerts or anything. It also seems that nothing after the silent failure will run either.

Perhaps the issue has something to do with the double-checking of the scope chain? Can somebody test and confirm/refute this?

I'm having the same issue on my scripts, but I don't have any alerts or anything. It also seems that nothing after the silent failure will run either.

Perhaps the issue has something to do with the double-checking of the scope chain? Can somebody test and confirm/refute this?

@Lakritzator

This comment has been minimized.

Show comment
Hide comment
@Lakritzator

Lakritzator Apr 4, 2011

Same here: Firefox 3.6.15 and Greasemonkey 0.9.1 no problems, but with FireFox 4 the GM_xmlhttpRequest does "nothing" (at least nothing visible).

Same here: Firefox 3.6.15 and Greasemonkey 0.9.1 no problems, but with FireFox 4 the GM_xmlhttpRequest does "nothing" (at least nothing visible).

@hheimbuerger

This comment has been minimized.

Show comment
Hide comment
@hheimbuerger

hheimbuerger Apr 5, 2011

I'm also having the issue that the 'onload' of an GM_xmlhttpRequest() is never invoked, although opening the given URL directly in Firefox 4 works just fine. I'm connecting to a GAE instance via HTTPS. If I switch to HTTP, it works. But of course I'd prefer to use HTTPS and it has worked like that in Firefox 3.6.x.

I'm also having the issue that the 'onload' of an GM_xmlhttpRequest() is never invoked, although opening the given URL directly in Firefox 4 works just fine. I'm connecting to a GAE instance via HTTPS. If I switch to HTTP, it works. But of course I'd prefer to use HTTPS and it has worked like that in Firefox 3.6.x.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 6, 2011

It works for me on FF4 at one windows vista computer but not on a windows 7 computer.

ghost commented Apr 6, 2011

It works for me on FF4 at one windows vista computer but not on a windows 7 computer.

@arantius

This comment has been minimized.

Show comment
Hide comment
@arantius

arantius Apr 6, 2011

Collaborator

Here's what I found out so far. Test script: https://gist.github.com/906344

This script will do an alert() no more than once per minute. Launch your browser, and see the alert. Close and reopen it quickly, and you can see in the console:

starting gm_xhr ... done
gm_xhr loaded

Once per page loaded. The second line is the "success" case. Close your browser, wait a minute, then reopen it. You'll see the alert the first time, then for each page the console will only show the first line, the latter will never get called. This seems to happen forever, as soon as gm_xhr is broken by running the alert first (?!) it's broken "forever" (at least until browser re-launch).

This, at a minimum, helps explain the inconsistency in previously noted behavior. Stuff that happened in a completely different execution -- even in a completely separate script (tested with a second copy of this without the alert and altered log lines) -- will break all gm_xhr in this browser.

Collaborator

arantius commented Apr 6, 2011

Here's what I found out so far. Test script: https://gist.github.com/906344

This script will do an alert() no more than once per minute. Launch your browser, and see the alert. Close and reopen it quickly, and you can see in the console:

starting gm_xhr ... done
gm_xhr loaded

Once per page loaded. The second line is the "success" case. Close your browser, wait a minute, then reopen it. You'll see the alert the first time, then for each page the console will only show the first line, the latter will never get called. This seems to happen forever, as soon as gm_xhr is broken by running the alert first (?!) it's broken "forever" (at least until browser re-launch).

This, at a minimum, helps explain the inconsistency in previously noted behavior. Stuff that happened in a completely different execution -- even in a completely separate script (tested with a second copy of this without the alert and altered log lines) -- will break all gm_xhr in this browser.

@arantius

This comment has been minimized.

Show comment
Hide comment
@arantius

This comment has been minimized.

Show comment
Hide comment
@arantius

arantius Apr 8, 2011

Collaborator

Reduced test case! https://gist.github.com/910628

Calling alert() in a user script causes setTimeout() to fail. GM_xhr happens to depend on setTimeout().

Collaborator

arantius commented Apr 8, 2011

Reduced test case! https://gist.github.com/910628

Calling alert() in a user script causes setTimeout() to fail. GM_xhr happens to depend on setTimeout().

@sizzlemctwizzle

This comment has been minimized.

Show comment
Hide comment
@sizzlemctwizzle

sizzlemctwizzle Apr 8, 2011

Contributor
Calling alert() in a user script causes setTimeout() to fail. GM_xhr happens to depend on setTimeout().
Well it also fails in FF4 with GM 0.8.0 so it sounds like a moz bug to me.
Contributor

sizzlemctwizzle commented Apr 8, 2011

Calling alert() in a user script causes setTimeout() to fail. GM_xhr happens to depend on setTimeout().
Well it also fails in FF4 with GM 0.8.0 so it sounds like a moz bug to me.
@arantius

This comment has been minimized.

Show comment
Hide comment
@yate

This comment has been minimized.

Show comment
Hide comment
@yate

yate May 4, 2011

Okay seriously. I have FF4 and greasemonkey 0.9.2 and have been struggling with this for about 2 hours. It somehow worked when I decided to open up a new tab and run it. I don't know what killed the tab but it seems to be working fine now for me.

yate commented May 4, 2011

Okay seriously. I have FF4 and greasemonkey 0.9.2 and have been struggling with this for about 2 hours. It somehow worked when I decided to open up a new tab and run it. I don't know what killed the tab but it seems to be working fine now for me.

@theYeas

This comment has been minimized.

Show comment
Hide comment
@theYeas

theYeas May 4, 2011

Opening a new tab fixed this issue for me too. (After removing the alert.)

theYeas commented May 4, 2011

Opening a new tab fixed this issue for me too. (After removing the alert.)

@gbraad

This comment has been minimized.

Show comment
Hide comment
@gbraad

gbraad May 4, 2011

confirmed what @theYeas says; open a new tab. Might be an issue in upstream.

gbraad commented May 4, 2011

confirmed what @theYeas says; open a new tab. Might be an issue in upstream.

@arantius

This comment has been minimized.

Show comment
Hide comment
@arantius

arantius May 4, 2011

Collaborator

On 05/04/11 04:14, gbraad wrote:

confirmed what @theYeas says; open a new tab. Might be an issue in upstream.

It definitely is, I linked it above, and they've confirmed it and found
the underlying cause there.

Collaborator

arantius commented May 4, 2011

On 05/04/11 04:14, gbraad wrote:

confirmed what @theYeas says; open a new tab. Might be an issue in upstream.

It definitely is, I linked it above, and they've confirmed it and found
the underlying cause there.

@gbraad

This comment has been minimized.

Show comment
Hide comment
@gbraad

gbraad May 4, 2011

saw the link and reported this also on the stackoverflow question that brought me here. I bought this immediately affects users, but during development you can seriously cut yourself. For example, I saw traffic from the browser to the server, server responded correctly... but the onload never got triggered. Now I probably know why; earlier testing with alert.

gbraad commented May 4, 2011

saw the link and reported this also on the stackoverflow question that brought me here. I bought this immediately affects users, but during development you can seriously cut yourself. For example, I saw traffic from the browser to the server, server responded correctly... but the onload never got triggered. Now I probably know why; earlier testing with alert.

arantius added a commit to arantius/greasemonkey that referenced this issue May 18, 2011

@pallo

This comment has been minimized.

Show comment
Hide comment
@pallo

pallo May 18, 2011

If it just depends on alert, replace: alert("Alarm!"); with: window.setTimeout(function() { alert('Alarm!') }, 1000);

pallo commented May 18, 2011

If it just depends on alert, replace: alert("Alarm!"); with: window.setTimeout(function() { alert('Alarm!') }, 1000);

@arantius

This comment has been minimized.

Show comment
Hide comment
@arantius

arantius May 18, 2011

Collaborator

This -fix- is actually insufficient: confirm and prompt at least will cause the same failure. But ultimately all we can do is work around the upstream problem. I'm closing this, and adding another issue to track the upstream bug, and remove the workaround when it is resolved.

Edit: #1350

Collaborator

arantius commented May 18, 2011

This -fix- is actually insufficient: confirm and prompt at least will cause the same failure. But ultimately all we can do is work around the upstream problem. I'm closing this, and adding another issue to track the upstream bug, and remove the workaround when it is resolved.

Edit: #1350

@arantius arantius closed this May 18, 2011

@k100

This comment has been minimized.

Show comment
Hide comment
@k100

k100 Jun 3, 2011

hi, here work fine after my patch;
maybe helpful to you:

#1238

k100 commented Jun 3, 2011

hi, here work fine after my patch;
maybe helpful to you:

#1238

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