Page MenuHomePhabricator

Wikibase Query Service calls get flagged as tracker calls by some Firefox extensions
Closed, ResolvedPublicBUG REPORT


When using a custom Wikibase instance, and a custom query service, with a browser extension, calls to the and Wikimedia domains get flagged as trackers.

Steps to Reproduce:
Go to, with Firefox and Ghostery. Calls to wikimedia and wikidata (used to populate examples) get blocked.

Actual Results:
One gets a query page loaded, but it is actually not functional. Most visibly it is missing the examples, and the toolbar on the left (this in itself is actually not so bad, but a visible indication that the page is not functional).

Expected Results:
Even if the calls to Wikidata and Wikimedia are blocked, the page should still work (the query service running should not be dependent on the existence of those services, or that calls there are not blocked).

Event Timeline

I do not see any bug in Wikibase code here but expected behavior. A Wikidata developer might correct me.

With uBlock Origin installed, it’s not a call to a Wikimedia domain that’s blocked, it’s a local request: UrlShortener.js is blocked by EasyList since easylist/easylist#3158. The symptoms are the same (no examples button, no toolbar on the left), so are you sure that in your case it’s one of the external requests being blocked?

Smalyshev subscribed.

But packed production version does not have UrlShortener.js? I think it's the code on that is using unpacked version that is blocked. I am not sure we can (or should) do anything here - maybe just the code on should rename the file?

UrlShortener.js is our file, if it’s causing problems I don’t think it’s fair to tell third-party installation admins to rename it. And the unpacked setup is what you get with wikibase-docker, I believe.

OK, but I am not sure what we can do here. We could rename the file, but there's no guarantee some blocker won't dislike our filenames again. Then again, if it's just renaming one file, maybe that's ok.

I think opening an EasyList issue has a decent chance of success, but that should probably be left up to the website operator (@pdehaye). The only Wikibase docker install that’s “““ours””” that I can think of right now is Wikibase Registry, which isn’t broken (because it’s on an older version, I assume), so we don’t really have a case to argue IMHO.

@pdehaye also, right now on a lot more things than just UrlShortener.js seem to be broken:

Loading failed for the <script> with source “”.
ReferenceError: less is not defined
Loading failed for the <script> with source “”.
ReferenceError: jQuery is not defined
Error: Bootstrap's JavaScript requires jQuery
(dozens of other errors about jQuery being missing)

It looks like your server isn’t serving those files correctly:

$ curl -sS -o /dev/null
curl: (18) transfer closed with 273489 bytes remaining to read
$ curl -sS -o /dev/null
curl: (18) transfer closed with 171959 bytes remaining to read

So you might have to fix that first.

Lydia_Pintscher subscribed.

Reopening this as we've now had several people run into this issue. We can't leave this as is.

T234041: wikibase-docker should build Query Service UI would be a general solution to this problem, but we can also:

  • rename UrlShortener.js to anything not on EasyList (not a nice solution, but a very simple one); or
  • open an EasyList issue (ideally done by someone who’s affected by this issue in a production environment, which I think rules out WMF/WMDE) and hope they unblock UrlShortener.js.

The last one has the advantage of unbreaking existing installations without requiring them to upgrade.

Yes let's rename it. It's biting people again and again.

Addshore claimed this task.

For production use cases people should use a built version of the query service UI.
And now we provide a docker image for that case too.