I believe this is caused by the NoScript browser extension, and you just need to whitelist the domain.

In T129764#2115370, @Quiddity wrote:

I believe this is caused by the NoScript browser extension, and you just need to whitelist the domain.

Frankly I was disbelieving of this but as I am running NoScript tried disabling the extension to no effect whatsoever. However also running Privacy Badger extension and that proved to be the sticking point (in my instance at least.)

So I owe Quiddity a (virtual) apology and generally note there may be more than one culprit for this behaviour.

Later addition:

Some kind soul apparently left me a message in Malayalam (no I don't speak it) back in 2014 which has just worked its way through notifications only to be blocked...this time by NoScript. So I can confirm both of these extensions can cause issues.

Although in hindsight this error message now makes more sense than initially may I urge that the error text be modified to more suggest that the root cause is the user's browser rather than somewhere between host servers? Even stating that javascript execution is being blocked (if detecting such is even possible—is this a "catch-all" situation?) might considerably help diagnose similar circumstances next time they arise.

In T129764#2116030, @AuFCL wrote:

Although in hindsight this error message now makes more sense than initially may I urge that the error text be modified to more suggest that the root cause is the user's browser rather than somewhere between host servers?

It is just reported to our code as a 'http' error, so it can't be identified that precisely.

Maybe:

1. It's a CORS configuration issue on the server (pretty likely on a new Echo installation).
2. You had internet when the page loaded, but no longer do, or it's unreliable.
3. The server went down (unlikely but possible).
4. You have a weird browser that doesn't support CORS.
5. You have a browser addon that is doing something.

Even stating that javascript execution is being blocked (if detecting such is even possible—is this a "catch-all" situation?) might considerably help diagnose similar circumstances next time they arise.

If JavaScript was being blocked entirely, you wouldn't see the error (which is displayed by JS). It seems in this case Privacy Badger was blocking third-party CORS JSON requests. So the error message was actually right.

Thanks @Mattflaschen. All good to know and makes sense now the topic is "hot."

If JavaScript was being blocked entirely, you wouldn't see the error (which is displayed by JS). It seems in this case Privacy Badger was blocking third-party CORS JSON requests. So the error message was actually right.

So just to be clear the text "Error Access to the remote domain was denied." is being emitted by the browser in a non-controllable fashion?

If so then the matter is closed...

...however as this is an end-user-facing message if there is any possibility of indicating to a user coming in cold as to how to proceed with resolving the issue then by all means lets try to do so. Even providing a URL maybe to some kind of FAQ might be more productive than a more technically correct but dead-end message? (Obviously this would only help in cases 4. and 5. mentioned above.)

In T129764#2118871, @AuFCL wrote:

Thanks @Mattflaschen. All good to know and makes sense now the topic is "hot."

If JavaScript was being blocked entirely, you wouldn't see the error (which is displayed by JS). It seems in this case Privacy Badger was blocking third-party CORS JSON requests. So the error message was actually right.

So just to be clear the text "Error Access to the remote domain was denied." is being emitted by the browser in a non-controllable fashion?

No. This is the text we're using in response to a 'http' error. Now that I look at it, we actually have more detailed error info in this part of the code already (in errorObj). This may help, but browsers are sometimes cagey about revealing the cause of permissions errors.

In T129764#2121228, @Mattflaschen wrote:

In T129764#2118871, @AuFCL wrote:

Thanks @Mattflaschen. All good to know and makes sense now the topic is "hot."

If JavaScript was being blocked entirely, you wouldn't see the error (which is displayed by JS). It seems in this case Privacy Badger was blocking third-party CORS JSON requests. So the error message was actually right.

So just to be clear the text "Error Access to the remote domain was denied." is being emitted by the browser in a non-controllable fashion?

No. This is the text we're using in response to a 'http' error. Now that I look at it, we actually have more detailed error info in this part of the code already (in errorObj). This may help, but browsers are sometimes cagey about revealing the cause of permissions errors.

O.K. This is progress. Even if only some browsers permit passing a reasonable hint through, isn't it worth the try? Even 20% less confused users is a significant reduction in support questions (just making up numbers for the sake of argument.)

I've been getting this on (highly customized) Firefox. Again, I'm sure it has something to do with my various blocking extensions, since it works in uncustomized Safari. Interestingly, it works with MediaWikiwiki for me, but not WikiBooks or WikiQuote. What I find most irritating is the fact that there is no way to dismiss these "broken" notifications, leaving them stuck in the menu and counter, even though I can tell they aren't anything I need to worry about (projects I have never edited...).

In T129764#2115370, @Quiddity wrote:

I believe this is caused by the NoScript browser extension, and you just need to whitelist the domain.

You're right - I'm using NoScript, and that was the problem. I just got the same error for Wiktionary, and it turned out that I hadn't whitelisted wiktionary.org yet. After I whitelisted it, it worked fine. Sorry for the false alarm. I agree with @Mattflaschen that a message change would help for those like me that don't immediately make the mental connection between this behaviour and whatever browser plugins they are using.

I also agree with @Jay8g that it would be good to do something about the notification being stuck in the menu with no obvious way to dismiss it. If the notification could link to the proper page on the remote domain that would work, if that is possible with the current architecture. Dropping the notification after one view would also work. One of those options plus a descriptive error message would be the sweet spot for this particular issue, I think.

Here's my stab at a message: "Could not load notifications from 'xxx.org'. Please check that you have enabled JavaScript for this domain and try again."

Apparently 1% of people browse without JavaScript enabled, so I think NoScript or similar will be a more likely cause for this error than Nos. 1-4 of Matt's scenarios. Although if there's a wording that could also infer that it may possibly be a server problem, then that may be better.

I've filed a bug with Privacy Badger to ask them not to block requests between WMF domains (more detail at T108505#2138145). I agree, however, that we should word the error message better.

In T129764#2129738, @MrStradivarius wrote:

Here's my stab at a message: "Could not load notifications from 'xxx.org'. Please check that you have enabled JavaScript for this domain and try again."

I like this suggestion, but I think "enabled JavaScript for this domain" is a bit misleading: you don't have to have JS turned on for that domain, you just have to not be blocking CORS requests to this domain. I'd replace that phrasing with something that covers ad blockers, NoScript and Privacy Badger; perhaps something like "Could not load notifications from xxx.org. This may be caused by an ad blocker or other browser extension blocking the request."? @jmatazzoni: thoughts on the language?

In T129764#2138147, @Catrope wrote:

Could not load notifications from xxx.org. This may be caused by an ad blocker or other browser extension blocking the request.

Yes, this would work well. I tried to think of some variations on this theme but couldn't come up with anything better.

According to Stephane, This bug will probably not needed after T130636 is done. So waiting for that.

That feedback may be related.

Seems to be related to Internet Explorer and its privacy settings, since the same issue doesn't occur when using Firefox.

In T129764#2223719, @Braveheart wrote:

Seems to be related to Internet Explorer and its privacy settings, since the same issue doesn't occur when using Firefox.

Yes, that's almost certainly the cause. People having trouble with this in Firefox and Chrome usually had Privacy Badger installed.

Work on T130636 is progressing so this should be fixed in the next few weeks.

This should be moot now that T130636 is fixed.

Checked in betalabs - cross-wiki notifications are displayed without error.

The present error text is as the following:

Failed to fetch notifications. Please try again. (Error Access was denied to the remote domain.)

Re. @Etonkovidova 's note about the error message:

Failed to fetch notifications. Please try again. (Error Access was denied to the remote domain.)

I talked to Roan and he thinks we should change it just to:

Failed to fetch notifications.

I asked him about "Please try again," and his answer was "Ummmmm" —which I took to mean "that might not really help" ?

With that, moving back to In Dev for new error message.

Change 288692 had a related patch set uploaded (by Sbisson):
New error message for failed to fetch notifications

https://gerrit.wikimedia.org/r/288692

Change 288692 merged by jenkins-bot:
New error message for failed to fetch notifications

https://gerrit.wikimedia.org/r/288692

The message was changed to: "Failed to fetch notifications. (Error: $1)".

The message was changed to: "Failed to fetch notifications. (Error: $1)".

This is a user-facing message so should not include code. Let's please change just to:

Failed to fetch notifications.

Moving back to In Development.

Change 291078 had a related patch set uploaded (by Sbisson):
Remove technical error from echo-api-failure

https://gerrit.wikimedia.org/r/291078

Change 291078 merged by jenkins-bot:
Remove technical error from echo-api-failure

https://gerrit.wikimedia.org/r/291078

The error message changed to: "Failed to fetch notifications."

Attached screenshot shows the new message.