Page MenuHomePhabricator

Adding a value to a statement prompts for a property
Closed, ResolvedPublic

Description

Sometimes, when attempting to add another value to an entity, the UI presents an input for a property ID, as if one had started to add a new statement, instead of just an input for the value.

I haven’t seen this myself yet, but it was reported by @Magnus here and confirmed by @agray and by @Harmonia_Amanda in the replies. According to Andrew, it “went away after a few refreshes“, and Harmonia suspects that “it’s when [you] do too many edits in too little time”.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 24 2018, 8:02 PM
agray added a subscriber: agray.Sep 24 2018, 8:06 PM

Can confirm that my experience (probably on ~20 Sept if that helps narrow it down; Firefox 62 under Ubuntu) was as Magnus describes it. It happened on one or two pages; I haven't had it happen since and assumed it was some weird local browser issue so didn't file a bug for it.

Wikidata moved from 1.32.0-wmf.20 to 1.32.0-wmf.22 on September 19th, sounds like it could be a bug in that window. But I’m not seeing anything especially suspicious in the git log.

Hitting "Random item", I can reproduce the effect on roughly 1 in 3 pages. On any given item page, this effect shows either for no statement, or for all of them.

No error messages in the JS console on affected pages, only the following warnings (probably unrelated):

JQMIGRATE: Migrate is installed with logging active, version 3.0.1 load.php:141:149
This page is using the deprecated ResourceLoader module "jquery.jStorage".
Please use "mediawiki.storage" instead. load.php:720:947
This page is using the deprecated ResourceLoader module "jquery.ui.position". load.php:77:291
This page is using the deprecated ResourceLoader module "jquery.ui.widget". load.php:108:942
This page is using the deprecated ResourceLoader module "jquery.tipsy". load.php:761:171
This page is using the deprecated ResourceLoader module "jquery.ui.core".
Please use OOUI instead. load.php:20:84
JQMIGRATE: jQuery.expr[':'] is deprecated; use jQuery.expr.pseudos load.php:141:731
Your skin is incompatible with VisualEditor. See <https://www.mediawiki.org/wiki/VisualEditor/Skin_requirements> for the requirements. load.php:662:737
JQMIGRATE: jQuery.fn.bind() is deprecated load.php:141:731
JQMIGRATE: jQuery.fn.unbind() is deprecated load.php:141:731
JQMIGRATE: jQuery.fn.offset() requires an element connected to a document load.php:141:731
Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. load.php:4:719
Use of "wgUserLanguage" is deprecated. Use mw.config instead.
load.php:4:719
JQMIGRATE: jQuery.fn.delegate() is deprecated load.php:141:731
JQMIGRATE: jQuery.fn.offset() requires a valid DOM element load.php:141:731
This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools and features!

I am using Firefox 62/Mac

The effect is persistent on specific items, e.g. https://www.wikidata.org/wiki/Q29201051

It happens on that item after reload, even after flushing the browser cache.

Confirmed in Firefox 63b6/Mac.

Happens to me on https://www.wikidata.org/wiki/Q29201051 even after I logged out and cleared the browser cache.

Happens on the same page in Safari Version 12.0 (13606.2.11) / Mac.

agray added a comment.EditedSep 24 2018, 8:31 PM

Can confirm I've just had it on https://www.wikidata.org/wiki/Q29201051 as well.

I get it on other items in the same browser session (https://www.wikidata.org/wiki/Q211775; https://www.wikidata.org/wiki/Q904305) but not others (https://www.wikidata.org/wiki/Q287; https://www.wikidata.org/wiki/Q10387684).

The effect seems to persist on reloading the pages.

(Update: now replicated on Chrome 69, Firefox 60, and IE 11 under Windows 10 - all logged out so shouldn't be any script/gadget issues. Q29201051 reliably triggers the odd behaviour; Q10387684 does not)

Haven't encountered this so far using the same configuration as Magnus. Maybe lists of enabled gadgets would be nice to have? Already checked common.js/global.js files of the listed users.

@Sjoerddebruin: Happens logged out as well, browser cache cleared, so no scripts/gadgets.

I’m able to reproduce this on Q29201051, thank you. It happens on any of the existing statements.

The entity data (via the wikibase.entityPage.entityLoaded hook) looks sane, and when I tried importing the entity into a local wiki via WikibaseImport, the error didn’t happen there.

Lucas_Werkmeister_WMDE triaged this task as High priority.Sep 25 2018, 11:06 AM

I can also confirm that checking random items shows the bug fairly frequently (though it feels like less than 1 in 3 to me, but I haven’t counted), so raising priority for now.

I notice that the random items where I was able to reproduce this (1, 2, 3, 4, 5) have all been edited this month, but I’m not sure if that’s related: some of the random items I found where the bug did not happen had also been edited in that period.

Purging the page does not remove the glitch (tested on item 5 above).

Lucas_Werkmeister_WMDE raised the priority of this task from High to Unbreak Now!.Sep 25 2018, 1:12 PM

Since purging doesn’t fix it, UBN per @Lydia_Pintscher.

Restricted Application added subscribers: Liuxinyu970226, TerraCodes. · View Herald TranscriptSep 25 2018, 1:12 PM
Tarrow added a subscriber: Tarrow.Sep 25 2018, 1:16 PM

I have my suspicions that this may be due to work done on: https://phabricator.wikimedia.org/T196226

So Q29201051 is no longer a test item since I edited it to test something: proceeding to add a statement, with a different property, will succeed; the statement will initially be in the wrong statement group, but after a page reload it will look as normal.

Also, it looks like I did my earlier test incorrectly, because now it appears that purging the page does fix the glitch. (Keeping the UBN though since this happens so commonly.)

It seems like this could be due to current JavaScript being incompatible with old, cached HTML. A simple way to fix that would be to purge all caches and drop all the old, cached HTML (e. g. increment the cache epoch); we should check with Ops if that’s acceptable or if we need a cleverer solution.

Restricted Application added a project: User-Addshore. · View Herald TranscriptSep 25 2018, 1:21 PM

I'm pretty sure this has been introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/460379
A data-attribute got introduced to store the statement group's property id which was previously stored in the html id attribute. If the HTML is outdated and doesn't contain the data attribute, the statement group doesn't know which property it belongs to and goes on to behave like a new statement.

DOM of a statement group of a buggy item

DOM of a statement group of a healthy item

Not the data-property-id attribute.

Change 462728 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Invalidate wikidatawiki cache with wgCacheEpoch

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

This is another case of this HTML not being in sync with the JS; seems that we need a way to at least predict this and do the invalidation but ideally have it automatic.

I'll leave this assigned to me as I'll look to get the cache epoch bump deployed once checking with Operations and Performance .

Change 462864 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Set testwikidatawiki CacheEpoch to 2018-09-19

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

Change 462865 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Set wikidatawiki CacheEpoch to 2018-09-03

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

Change 462866 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Set wikidatawiki CacheEpoch to 2018-09-10

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

Change 462867 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Set wikidatawiki CacheEpoch to 2018-09-15

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

Change 462864 merged by jenkins-bot:
[operations/mediawiki-config@master] Set testwikidatawiki CacheEpoch to 2018-09-19

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

Mentioned in SAL (#wikimedia-operations) [2018-09-26T07:48:55Z] <addshore@deploy1001> Synchronized wmf-config/InitialiseSettings.php: [[gerrit:462864|Set testwikidatawiki CacheEpoch to 2018-09-19]] T205330 (duration: 00m 56s)

Change 463202 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-15

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

Change 463203 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-06

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

Change 463203 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-06

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

Change 463207 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-08

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

Change 463207 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-08

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

Change 463208 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-12

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

Change 463208 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-12

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

Change 462867 abandoned by Addshore:
Set wikidatawiki CacheEpoch to 2018-09-15

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

Change 462866 abandoned by Addshore:
Set wikidatawiki CacheEpoch to 2018-09-10

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

Change 462865 abandoned by Addshore:
Set wikidatawiki CacheEpoch to 2018-09-03

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

Change 462728 abandoned by Addshore:
Invalidate wikidatawiki cache with wgCacheEpoch

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

Change 463202 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-15

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

Change 463221 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-19

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

Change 463221 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-19

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

We've now invalidated the cache for all pages in the parser cache before the train was deployed last week so it should now be fixed for logged in users. There is still a possibility that un-logged in users will see something stale from the Varnish cache

@Addshore:

the varnished cached pages would expire 14 days after the deployment that caused an issue, if they aren't purged for another reason before hand

Tarrow lowered the priority of this task from Unbreak Now! to Normal.Sep 27 2018, 10:04 AM
Nikki added a subscriber: Nikki.Sep 27 2018, 11:51 AM

Change 467913 had a related patch set uploaded (by Addshore; owner: Addshore):
[operations/mediawiki-config@master] Remove Wikidaat RejectParserCacheValue hook

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

Change 467913 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove Wikidata RejectParserCacheValue hook

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

Mentioned in SAL (#wikimedia-operations) [2018-10-17T11:15:13Z] <addshore@deploy1001> Synchronized wmf-config/CommonSettings.php: SWAT: T205611 T205330 Remove Wikidata RejectParserCacheValue hook [[gerrit:467913]] (duration: 00m 56s)