Page MenuHomePhabricator

External property links break in Chrome
Closed, DeclinedPublic


I looked at and refreshed the page several times. I noticed that sometimes properties like VIAF are linked to their counterpart on a external dataset and sometimes it is only the the raw text without link.

As aude pointed out it may be something with the gadget initialisation. I have, however, no knowledge about the internals, so I dump here a copy of the irc log - hope this helps:

2015-02-11 15:30:10	<aude>	ebekebe: i think there is an issue with the way the gadget's javascript is initialized
2015-02-11 15:30:27	<aude>	it works for me with debug=true, but see the issue otherwise
2015-02-11 15:42:09	<ebekebe_>	aude: It works for me in Firefox and Safari too, so it seems to be a Chrome issue.
2015-02-11 15:43:24	<jzerebecki>	ebekebe_: yes it's a bug. can't reproduce in firefox, but aude could in chrome. please file a bug.
2015-02-11 15:43:25	<ebekebe_>	aude: craches my Chrome tab as well as (which is funny, because it is heart attack)
2015-02-11 15:44:32	<aude>	ebekebe_:
2015-02-11 15:45:04	<aude>	is the chrome bug
2015-02-11 15:45:52	<aude>	looks like they at least have a tentative fix and hopefully release an update for chrome soon with it
2015-02-11 15:59:58	<ebekebe_>	jzerebecki: I don't have a phabricator account yet and the email confirmation doesn't seem to work for me at the moment. I try to file the bug later.
2015-02-11 16:00:16	<Harmonia_Amanda>	am I the only one who can't order items in a property? the order of the items can be significant...
2015-02-11 16:00:30	<sjoerddebruin>	not possible atm
2015-02-11 16:00:34	<Harmonia_Amanda>	this morning I could do it, and now I can't
2015-02-11 16:00:38	<sjoerddebruin>	sorting was broken I think
2015-02-11 16:01:04	<Harmonia_Amanda>	do you know when we could sort again?
2015-02-11 16:02:19	<sjoerddebruin>	Nope. When it's fixed.
2015-02-11 16:02:44	<aude>	ebekebe_: for the gadget, applying something like
2015-02-11 16:02:46	<sjoerddebruin>
2015-02-11 16:03:00	<aude>	might help, so we are not depending on the dom being initialized or timing things
2015-02-11 16:03:20	<aude>	it might be the dom is partially initialized, so things at the top of the page tend to get linked on large items
2015-02-11 16:03:26	<aude>	but not at the bottom of ht epage

Chrome 40.0.2214.111
OS X 10.10

Event Timeline

Ebekebe assigned this task to Wikidata-bugs.
Ebekebe raised the priority of this task from to Needs Triage.
Ebekebe updated the task description. (Show Details)
Ebekebe added subscribers: Ebekebe, aude.
JanZerebecki added a project: Wikidata.
JanZerebecki set Security to None.

I think this is a timing issue, with not all the dom elements initialized when the gadget is being initialized. might fix but I have some difficulty in verifying it.

As a user script, the old version always works (suppose because load timing of scripts is different than gadgets). In debug=true, the (current code) gadget also works for me.

On test.wikidata, the current gadget code works for me as well, on Q22 (without debug=true).

As far as I can tell, my changes don't break anything and might be worth a try, unless someone has a better idea how to fix.

my changes for the timing issue probably do help, but I looked at the gadget further during the weekend.

It works by going through all statements on an item page, finds the main snak property, adds it to an array containing a list of property ids. Then it does a batch api request to wbgetentities with all these property ids. If the Property has a "formatterURL" statement then it is added to another "properties" array and the links are added.

There are a few issues:

  1. If a particular property is only used in a reference or qualifier (e.g. not in a main snak), then the value does not get linked
  2. If there are more than 50 properties in the wbgetentities request, then only the first 50 are returned, due to api limits. (possibly this could be chunked into multiple requests) This means that for an item with more than 50 statements, the ones at the bottom will not get linked.
  3. There is a performance cost to doing an api request (for all page views, since this is a default gadget).

Best solution in my opinion is to have the PROPERTIES array (all properties that have formatterURL) maintained by a bot on wiki, on a js / json page. The bot could address issue 1 and 2, and avoid the api request.

There also may be issues with initialization timing of the gadget, per above, that the above change helps fix.

Integrating this functionality properly into formating might be even better. But that should not prevent small improvements.

I'm going to close this ticket. We should implement the functionality properly in Wikibase itself instead.