(2.9.5.2) ABE breaks internal Slack site

[wsha]

On my company's internal Slack site (domain.slack.com), the pages load normally but I do not get live updates of new chat messages (I have to refresh the page to see new chats). At the top of the page, a banner always says "Reconnecting ...". Looking at the error console, I see:

Code: Select all

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.host] contentPolicy.js:182:0
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIChannelEventSink.asyncOnChannelRedirect]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://noscript/content/ForcedRedirectionCallback.js :: CESDelegate.prototype.asyncOnChannelRedirect :: line 51"  data: no]CESDelegate.prototype.asyncOnChannelRedirect@chrome://noscript/content/ForcedRedirectionCallback.js:51:7

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIChannelEventSink.asyncOnChannelRedirect] ForcedRedirectionCallback.js:51:0
Firefox can't establish a connection to the server at wss://mpmulti-9oy3.slack-msgs.com/websocket/Tsmb1lY8....

I truncated the final wss address because the full address could not get through this forum's spam filter.

If I disable ABE, then the site works normally and I don't see these errors. I tried putting the following into the user rule set but it didn't help:

Code: Select all

Site *.slack.com
ALLOW ALL from *.slack-msgs.com

I also tried this but it didn't help:

Code: Select all

Site *.com
ALLOW ALL from *.com

Any suggestions for how I could allow the Slack web sockets to connect without competely disabling ABE? I am using NS 2.9.5.2 on Fx 45 ESR.

[barbaz]

Replaced the spammy-looking thread title. wsha, please make a related thread title in future, thanks.

Code: Select all

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.host] contentPolicy.js:182:0
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIChannelEventSink.asyncOnChannelRedirect]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://noscript/content/ForcedRedirectionCallback.js :: CESDelegate.prototype.asyncOnChannelRedirect :: line 51"  data: no]CESDelegate.prototype.asyncOnChannelRedirect@chrome://noscript/content/ForcedRedirectionCallback.js:51:7

Do you have any information about what URI this was?

Any suggestions for how I could allow the Slack web sockets to connect without competely disabling ABE?

I don't think there's any other way around that error, sorry.

Moving to NoScript Development as a bug report.

[wsha]

Sorry about the title. I was having trouble getting past the spam filter, so I stripped down the post until it got through and then started adding content back but forgot to add the title back.

I tested some more and found that by allowing scripts from some domains that were slow to load (did not show up originally) that I could get the site to work normally with ABE on. It is interesting that the site also worked with scripts from those domains blocked when ABE was disabled. Maybe Slack has a couple different methods of establishing the web socket connection.

I will make this as resolved since I don't have a problem now.

[barbaz]

Glad you have a workaround, but it is precisely that - a workaround. This behavior difference with ABE enabled is not right.

[Thrawn]

If ABE is blocking something, then there ought to be more in the Browser Console than that. It should log a message that clearly states what is blocked and which rule did the blocking.

[barbaz]

The messages above do clearly state what is going on, don't they? ABE is getting fed an unexpected URI and choking on it. The blocking is just the aftermath.

This issue looks to be a NoScript bug, not a mere 'run of the mill' support question.

[wsha]

I may have been wrong about Slack having multiple ways to connect. After a while, the connection went away (maybe after I restarted the browser) and now it doesn't work again unless I disable ABE. Perhaps I could get it to connect by disabling ABE and then re-enabling it after it is connected. I switched to using the Slack desktop client so I could leave ABE on. Let me know if I could help any more with diagnosing the problem.

[barbaz]

I know how I'd debug this if it were me, but not sure whether I can give instructions.

Basically I'd look at the line of code in NoScript where the error occurs, wrap it in a try-catch block in a way that makes sense, log all URIs that make it to that catch block, and post the results. This requires a modified NoScript XPI, and since I don't see this problem, I can't verify that the modifications are working as intended.

How much JavaScript experience do you have?

[wsha]

I have moderate JavaScript experience (and XUL addon experience). I don't need to modify NoScript though because the relevant line of code is already in a try-catch block. The main problem seems to be in this block:

Code: Select all

CESDelegate.prototype = {
  QueryInterface: XPCOMUtils.generateQI([Ci.nsIChannelEventSink]),
  asyncOnChannelRedirect: function(oldChan, newChan, flags, callback) {
    let label = "plugin forced redirection";
    try {
     label = (oldChan.loadInfo.externalContentPolicyType || oldChan.loadInfo.contentPolicyType)+ ": " + oldChan.name + " -> " + newChan.name + " - " + flags;
    } catch (e) {
      ns.log(e);
    }
    let cb = new RCBDelegate(callback, label);
    try {
      this.delegator.asyncOnChannelRedirect(oldChan, newChan, Ci.nsIChannelEventSink.REDIRECT_INTERNAL, cb);
    } catch (e) {
      ns.log(e);
      throw e;
    } finally {
      oldChan.notificationCallbacks = newChan.notificationCallbacks = this.delegator;
    }
  }
};

Specifically, the error

Code: Select all

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIChannelEventSink.asyncOnChannelRedirect]

is generated by this line:

Code: Select all

this.delegator.asyncOnChannelRedirect(oldChan, newChan, Ci.nsIChannelEventSink.REDIRECT_INTERNAL, cb);

It is generated for the URI "https://mpmulti-57zb.slack-msgs.com/web ... ce_aware=1".

I got this information by stepping through with the debugger. I am not able to step into the asyncOnChannelRedirect function. I hope this information is helpful.

By the way, there are public Slack channels if you felt like looking into the problem. One that I know of can be joined from here: http://pythontesting.net/slack/. I see the same problem for that public Slack channel as the internal company one.

[barbaz]

That is very helpful. Thanks for the detailed info!

Odd, it looks like errors thrown there really should already be suppressed (also ChannelReplacement.js line 44).

While waiting for Giorgio to look into this, does NoScript 2.9.5.2rc2 work properly?
Old NoScript @
https://addons.mozilla.org/addon/noscript/versions
*or*
https://noscript.net/feed?c=100&t=a

[wsha]

I tried 2.9.5.2rc2, but I see the same behavior in the error console (exception on the same line and for a slack-msgs.com URI).