The patch up now doesn't change the visible behaviour, as it still explicitly untaints the statement once the edit is cancelled. Changing that behavior (so that the statement will be shown as tainted still) is just a matter of deleting a line now, though.

I think we're done as far as this task goes, the popper is now a easily-reusable component within our source tree (pulling it out would be trivial, but is out of scope here).

I just talked to @Tarrow about this, and for now it should be enough to use that new component directly in App.vue, but if that turns out to bloat App.vue to much we will revisit this.

@Tarrow Can you link the respective changes here?

So I just looked into this a bit and sadly this is not a trivial change. First of all, I don't think we want to expose backlinks (as in Special:WhatLinksHere) as these don't have the semantics the use cases here call for (and using them still would probably lead to strange behavior in the long run). That's because these are just all links pointing to a page, no matter where these originate from: statement (main) values, reference values, qualifier values (and probably even more).

I think this is actually fully done by now.

Thanks @Anomie, that makes sense.

But what is actually stored in the database (SELECT TYPEOF)?

In T238575#5675025, @Lucas_Werkmeister_WMDE wrote:

Hm, it still fails when calling initState() with [ '0' => 'foowiki' ], so I don’t think casting $siteID to a string in initState() would change anything. There’s some confusion between strings and numbers somewhere…

I think we're done here, the popper is now properly mounted to the tainted icon. Everything else (styling, wording, …) is out of scope for this task.

Note: We decided to wrap mw.track in a Vue component now. I made some initial progress here and will (hopefully) finish that tomorrow.

So bridge uses a ServiceContainer to hold (as 'tracker') a mw.track instance. They use that, via their EventTracker and via DataBridgeTrackerService. We should probably do the same or something similar, although we can probably get away with a little less abstraction?

I purged all pages from above (which haven't been re-parsed since) and gathered new numbers:

1. The average PC size is 101219.66 (down ~2.7%)
2. The median PC size is 68137 (down ~7.2%)
3. The minimum PC size is 12911 (down ~3.1%)
4. The maximum PC size is 393856 (down ~1.4%)

The same seems to be true for enwiki (logged out, private mode, random article):

I just implemented it like this, but I'm not sure that's going to suffice… if the user clicks on the popper, this will probably also trigger the blur and thus close the popper. Maybe if the popper is a direct child of the TaintedIcon <a> this will work, but I'm not sure.

So apparently OOUI sets tabindex="0" on the constraints icon, with that we can actually focus (and thus also handle blur). I'll do the same for us in order to re-implement the behavior as closely as possible.

I have a patch that wires up the "x" to close the popper, I didn't yet look into closing it if the user clicks onto something else.

In T233213#5639426, @hoo wrote:

In T233213#5639358, @Addshore wrote:

I just checked the live site and I still see the old code deployed when looking at the minified JS.

The new minified versions are present (alongside the current versions), but index.html was not updated on the individual hosts (so the state on deploy1001 differs from the state on the actual wdqs servers).

hoo@deploy1001:/srv/deployment/wdqs/wdqs/gui$ md5sum $(pwd)/index.html
11ee88217d78d98e52f9008add62a23c  /srv/deployment/wdqs/wdqs/gui/index.html
hoo@wdqs1005:/srv/deployment/wdqs/wdqs/gui$ md5sum $(pwd)/index.html
29ce000ed3201781a6c06eb03d73b002  /srv/deployment/wdqs/wdqs/gui/index.html

@Mathew.onipe Do you want to re-scap?

In T233213#5639358, @Addshore wrote:

I just checked the live site and I still see the old code deployed when looking at the minified JS.

I collected some data about the parser cache sizes of the ruwiki pages with the most hits this month (as per stats.wikimedia.org).

In T193781#5467485, @Richard_Nevell_WMUK wrote:

With T195751 fixed, will ArticlePlaceholders show up in Special:Search once the extension is configured for nowiki?

In T236888#5638230, @Lydia_Pintscher wrote:

This is in verification but I don't think I can verify this. Close?

In T236491#5635738, @Addshore wrote:

@hoo now that this is all merged and deployed, how is it looking? :) can we close?

Possibly related: T236749

In T236485#5635734, @Addshore wrote:

@hoo now that this is deployed, how is it performing?

In T237258#5635492, @Lucas_Werkmeister_WMDE wrote:

Another possible signature: wikibase.getReferencedEntityId( { ...fromEntityIds }, propertyId, { ...toIds } ). (Some previous discussion for this is in T179155#4104367 and following comments.)

In T233213#5635381, @Lucas_Werkmeister_WMDE wrote:

@hoo you mentioned you still have access to the WDQS servers, do you know how to deploy a change to the UI? (T233213#5584298 is probably the most important comment to catch up on.)