Badge turns from green to red all the time

[bastik-1001]

With Firefox 21.0 (32bit) on Windows 7 (64bit) and 0.1.0 the badge turns from green to red, every single time. It always reports "...having a problem. If you keep reading this after browser restart, please report this. " and never received a connection based on what the add-on says.

I tried yesterday and today. The badge on http://crypto.stanford.edu/flashproxy/ doesn't turn black (or gray) it just sits there and waits. So far I have not seen it working, but it may does.

I'm not sure if your add-on points to the new facilitator "fp-facilitator.org" or not.

[reezer]

Thank you for your report. Yes, it already uses the new address (see the DEFAULT_FACILITATOR_URL constant on the top of flashproxy.js). I am looking forward to implement a way to make this easier to look at but could you look up the error in the Error Console (CTRL+SHIFT+J)?

[bastik-1001]

This is the only error available, the others are "just" warnings issued for visiting this website:

I translated the [German word(s)]:

Time stamp: 30.05.2013 13:02:46 Error: uncaught exception: DataCloneError: The object could not be cloned.

I'm not sure if this error is created by your add-on.

BTW: I use NoScript, which allows "about:blank" and "fp-facilitator.org". I had the badge on Stanford working (with the new host for the facilitator) with FF 21 and NoScript. Your add-on worked as well.

EDIT/UPDATE:

Time stamp: 30.05.2013 13:10:51 has changed, there is no new error.

UPDATE2: I restarted Firefox. The badge is still green, but the same error appears. I'm letting the error-console open and wait for the circle to turn red.

UPDATE3: Add-on still showing a green icon. No connections yet. The badge on Stanford was used (don't know how long it has been used) and it's still awaiting connection (it did not broke).

[bastik-1001]

It turned red again, but the error console is empty.

No error, no warnings or messages.

On update3 from above: I'm not entirely sure that the badge was used. I was away for lunch and saw it as I came back. It looked like it were switching from active to passive.

[bastik-1001]

I got Firefox Portable (English) version 22. (Built from http://hg.mozilla.org/releases/mozilla-beta/rev/1b5782f637b3)

and get this error, while the icon remains green.

Timestamp: 30.05.2013 15:38:40 Error: Firefox can't establish a connection to the server at ws://[censored]:9000/. Source File: resource://gre/modules/XPIProvider.jsm -> jar:file:///C:/Users/[username]/Desktop/FirefoxPortableTest/Data/profile/extensions/jid0-1kqApO5BUHwjBQft5BEUXHXZjCA@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-1kqapo5buhwjbqft5beuxhxzjca-at-jetpack/tor-flashproxy-badge/lib/flashproxy.js Line: 240

Line 240 contains var ws = new this.window.WebSocket('ws://' + addr.host + ':' + addr.port + '/');

The error appears twice with the same "server".

Update: It happened again on the portable version. With a different "server". The icon is still green. It even says I served two people (I know there's an update fixing the information shown, but that is not available yet).

(please note that the UI appears in the middle of Firefox 22 (beta) portable; but as this is a) a portable version and b) not the final product I will not file a ticket unless you say I should in which case I can provide a screenshot)

[bastik-1001]

I'm a bit spammy, but the same error appears for the regular badge on Stanford. (The badge stays active, just like your icon stays still green)

Time: 30.05.2013 16:43:52 Error: Firefox kann keine Verbindung zu dem Server unter ws://[censored]:9000/ aufbauen. Source: http://crypto.stanford.edu/flashproxy/flashproxy.js Line: 444

The line appears to be the same as yours.

I don't know why this happens and I don't know what impact it has (beside that a client doesn't get served).

[reezer]

So it stays green? Hmm, maybe the problem lies somewhere else. I am not sure what is going on, but could you maybe use a new Firefox Profile without NoScript and see how it is related? I know people with similar setups, even using NoScript, so it actually shouldn't cause a problem, but it would be interesting to see, if a default profile causes the same behavior for you.

See: http://kb.mozillazine.org/Creating_a_new_Firefox_profile_on_Windows

Also when it turned red, could you filter for "exception while connecting" and tell me, if you find something?

[bastik-1001]

FF(portable) 22 beta is a fresh profile with no other add-ons, the icon remains green and I got:

Timestamp: 30.05.2013 18:09:27 Error: The connection to ws://[censored]:9000/ was interrupted while the page was loading. Source File: resource://gre/modules/XPIProvider.jsm -> jar:file:///C:/Users/[username]/Desktop/FirefoxPortableTest/Data/profile/extensions/jid0-1kqApO5BUHwjBQft5BEUXHXZjCA@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-1kqapo5buhwjbqft5beuxhxzjca-at-jetpack/tor-flashproxy-badge/lib/flashproxy.js Line: 240

and

Timestamp: 30.05.2013 18:04:08 Error: tor-flashproxy-badge: An exception occurred. ReferenceError: clearTimeout is not defined resource://jid0-1kqapo5buhwjbqft5beuxhxzjca-at-jetpack/tor-flashproxy-badge/lib/flashproxy.js 285 Traceback (most recent call last): File "resource://gre/modules/commonjs/sdk/timers.js", line 31, in notify callback.apply(null, args); File "resource://jid0-1kqapo5buhwjbqft5beuxhxzjca-at-jetpack/tor-flashproxy-badge/lib/flashproxy.js", line 285, in clearTimeout(this.flush_timeout_id);

Firefox 21 (installed) stayed green the whole time. I did not turn red, so no error.

Once it turns red on either Firefox I'll report it with an error if I find one. (It's pretty annoying to just wait for either the badge on Stanford to work or your add-on to turn red)

I it turns red again on the installed Firefox, I'm trying a fresh profile.

[reezer]

So, it stays green with a fresh profile? Does it work? Do you receive connections? I am sorry for it being hard. Thanks so much for helping with debugging though. Your help is greatly appreciated.

[bastik-1001]

Strange I commented 3 hours ago, but the comment is not shown....

"So, it stays green with a fresh profile?" Firefox Portable 22 (beta2): yes Firefox 21 (dirty): no, it turns red Firefox 21 (fresh): yes (I created a fresh-profile yesterday), it did not turn red

"Does it work?" FF Portable 22 beta2: I have not observed it. The add-on said it would have had connections, while the error was "Firefox can't establish a connection to the server at ws://[censored]:9000/", so I still assume it works. Firefox 21 (dirty): All the time is a large time scale. 0.1.0 never had any connection and turned red. I switched to 0.1.1 today and it reports to have had an connection. Firefox 21 (fresh): The new profile was used for 4+ hours and didn't appear to be used. The add-on said "no" connections. (it may work, but I can't confirm that, it did not turn red however.)

The only set-up leading to turning from green to red is with FF 21 (dirty).

I'm using FF 21 (dirty) right now. Let's see how it works. The add-on reports a connection, something that it hasn't done before.

"I am sorry for it being hard" Not your fault. The "painful" thing is that it takes hours to turn red. (Maybe it doesn't turn red on a fresh profile)

"Thanks so much for helping with debugging though. Your help is greatly appreciated."

Sure. Don't look into this. If it works with FF 21 (dirty), I'll report back.

If it fails with (dirty) I'll try FF 21 (clean) and if that works I blame the profile (in which case I call this "not a bug") I'll report back or if it fails with it I'll also report back.

[bastik-1001]

Alright, I may found what caused this to happen. It's another add-on called RequestPolicy. It blocks resources from cross-sites being requested unless the source is allowed to request everything or the target is white-listed or the source is allowed to request resource xzy.

My request policy is 0.5.x

Well I knew how it worked and had allowed as source: stanford.edu (so it can reach the unknown client and server) target: fp-facilitator.org

and this worked for your add-on as well. However your changes affected this.

I allowed as source: about:blank

(beside that I allowed other sources from FF internals like chrome://, but I don't think this is necessary, they might be not even monitored)

However, the icon (of version 0.1.1) stays green with FF 21 (dirty) and I can confirm it is working, since the icon switched to active (changing it's color) and the add-on itself says 4 connections have been made.

I conclude it's working.

I planned to create a wiki-page (provided github let's me do that) called 'compatibility' and list what could be conflicting and that RequestPolicy users have to allow new sources.

It turns out that RequestPolicy is hosted on GitHub, should I create a ticket there? It's not a compatibility issue of RequestPolicy since it does what it does.

I'm letting this open for the moment, you can close it. I'm waiting for your input anyway.

[reezer]

Nice! Well, I am not sure, but in my opinion it would make sense to allow about:blank, like NoScript does. The reason for all of this is that I need a DOM-Tree, so I can access window.WebSocket. I wonder if there is another way to get to it, but I'd suggest allowing about:blank in RequestPolicy per default, but I am not sure. You could ask them and if they reject this they might have a better idea. I am fairly new to extension development, but I'll check if I can find a way to create it in a different way from another context.

[bastik-1001]

Well, I created a ticket (see their #377) and maybe it's reasonable and it will be added to the allowed sources or not.

Maybe there'll be help from other people. I know you are working alone on this add-on and I'm not able to help you out.

[asymmetric]

Is this still relevant after your refactoring of the addon, @reezer ?

[reezer]

It is because of JavaScript being blocked (by NoScript or RequestPolicy). It's not about:blank anymore, but the facilitator and flashproxy sites. There should at least be a warning, maybe even an automatic configuration for them, but only if the user grants us permission of course.