Page MenuHomePhabricator

New Error Message for "Error Access to the remote domain was denied." (echo-api-failure-cross-wiki) message and use errorObj?
Closed, ResolvedPublic

Description

While browsing the English Wikipedia today, I had several cross-wiki Echo notifications of messages that had been left on my talk page on other projects in the past. Most of these notifications worked fine, but the one for the Italian Wikisource gave the following error message:

Could not retrieve notifications. Please try again. (Error Access to the remote domain was denied.)

This message appears when you click on the Echo message icon, then click on the "View 1 message" dropdown on the "More messages from another wiki" notification.

The notification was removed after I visited my talk page on the Italian Wikisource manually (by entering "wikisource:it:" in the search bar and then clicking on the "discussioni" link at the top), so that part is working fine.

I was able to replicate this behaviour by logging into a different account and leaving another message on my itwikisource talk page. I also got the same error from leaving a message on my dewikisource talk page, so it appears that all language versions of Wikisource are affected.

Details

Related Gerrit Patches:
mediawiki/extensions/Echo : masterRemove technical error from echo-api-failure
mediawiki/extensions/Echo : masterNew error message for failed to fetch notifications

Event Timeline

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptMar 13 2016, 3:36 AM
Restricted Application added subscribers: JEumerus, Aklapper. · View Herald Transcript
MrStradivarius renamed this task from Cross-wiki notifications from itwikisource: "Error Access to the remote domain was denied." to Cross-wiki notifications from Wikisource: "Error Access to the remote domain was denied.".Mar 13 2016, 3:43 AM
MrStradivarius added a project: Wikisource.
MrStradivarius updated the task description. (Show Details)

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

AuFCL added a subscriber: AuFCL.EditedMar 13 2016, 9:17 AM

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.

Aklapper renamed this task from Cross-wiki notifications from Wikisource: "Error Access to the remote domain was denied." to Cross-wiki notifications: "Error Access to the remote domain was denied." due to browser add-on.Mar 14 2016, 10:40 AM
Trizek-WMF triaged this task as High priority.Mar 14 2016, 12:43 PM
Trizek-WMF added a subscriber: Trizek-WMF.

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.

Mattflaschen-WMF renamed this task from Cross-wiki notifications: "Error Access to the remote domain was denied." due to browser add-on to Change "Error Access to the remote domain was denied." message?.Mar 14 2016, 3:47 PM
Mattflaschen-WMF lowered the priority of this task from High to Low.

Changed the priority. There's nothing we can do if an addon just blocks the request.

The only remaining thing to do here is consider a message change. If so, would need to reflect all the possible issues, not just the current one.

AuFCL added a comment.Mar 14 2016, 4:39 PM

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

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.

Mattflaschen-WMF renamed this task from Change "Error Access to the remote domain was denied." message? to Change "Error Access to the remote domain was denied." (echo-api-failure-cross-wiki) message and use errorObj?.Mar 15 2016, 2:46 AM
AuFCL added a comment.EditedMar 15 2016, 3:02 AM
In T129764#2121228, @Mattflaschen 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.)

Jay8g added a subscriber: Jay8g.Mar 15 2016, 5:12 AM

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

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.

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?

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.

jmatazzoni raised the priority of this task from Low to Medium.Apr 6 2016, 11:30 PM
jmatazzoni added a comment.EditedApr 11 2016, 5:53 PM

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

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

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.)
jmatazzoni renamed this task from Change "Error Access to the remote domain was denied." (echo-api-failure-cross-wiki) message and use errorObj? to New Error Message for "Error Access to the remote domain was denied." (echo-api-failure-cross-wiki) message and use errorObj?.May 7 2016, 12:57 AM

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

SBisson claimed this task.May 16 2016, 12:56 PM
SBisson moved this task from In Development to Needs Review on the Collab-Team-2016-Apr-Jun-Q4 board.

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

jmatazzoni closed this task as Resolved.May 31 2016, 3:34 PM

Attached screenshot shows the new message.

AuFCL removed a subscriber: AuFCL.Nov 21 2016, 7:39 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptNov 21 2016, 7:39 PM