Even though the bug mentioned above indicates that the new LocalStorage should be available in Firefox 69, I would feel better if we were able to actually verify that.
However, I'm not sure how to do so. Any ideas?

From my initial thoughts it seems to make sense to start with storybook in the same repository for now. That should represent the state of the components at the tip of the master branch and facilitate communication from developers to UX.

This issue seems to be resolved in Firefox 69 and apparently the quota is now per origin. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1064466#c18

Thank you, @Lucas_Werkmeister_WMDE, for making a current version of the storybook available again :)

In T235055#5580471, @Lucas_Werkmeister_WMDE wrote:

Shouldn’t this go into the Verification column for UX to review the button?

In T232468#5575133, @Charlie_WMDE wrote:

@Michael you have a very good point, thank you for voicing it. After talking to the UX-colleagues I think it's the best idea to stick to the 1second rule, but make sure that we always show the loading indicator for at least 0.5 seconds.
the idea is to always add 0.2 seconds fade in and fade out at the beginning and end of the animation, which would ensure we always get 0.5 seconds in the worst case (worst case being the 0.1 seconds).
Is that technically possible?

In T233305#5579153, @Lucas_Werkmeister_WMDE wrote:

I couldn’t figure out how to make it part of the app module, but extracting the dispatcher into a separate module reduces the size of the init module substantially:

[...]
diff --git a/client/resources/Resources.php b/client/resources/Resources.php
index 9c9a0e0f2..085d2bccd 100644
--- a/client/resources/Resources.php
+++ b/client/resources/Resources.php
@@ -66,6 +66,24 @@
 			}
 		],
+		'wikibase.client.data-bridge.dispatcher' => [
+			'factory' => function () {
+				$clientSettings = WikibaseClient::getDefaultInstance()->getSettings();
+				return new ResourceLoaderFileModule(
+					[
+						'scripts' => [
+							'dispatcher.common.js'
+						],
+						'targets' => $clientSettings->getSetting( 'dataBridgeEnabled' ) ?
+							[ 'desktop', 'mobile' ] :
+							[],
+						'remoteExtPath' => 'Wikibase/client/data-bridge/dist',
+					],
+					__DIR__ . '/../data-bridge/dist'
+				);
+			},
+		],
+
 		'wikibase.client.data-bridge.app' => [
 			'factory' => function () {
 				$clientSettings = WikibaseClient::getDefaultInstance()->getSettings();

[...]

While working on this ticket a bug in @vue/test-utils was noticed and reported: https://github.com/vuejs/vue-test-utils/issues/1321
This bug could lead to falsely green tickets.

I think this would be more efficient and better for the user (no flash of unhidden edit buttons before we get around to hiding them).

In T233305#5556005, @Lucas_Werkmeister_WMDE wrote:

I’m still very tempted to rewrite it in plain JS and serve that as a regular old ResourceLoader module – according to find src/mediawiki/ -type f -name '*.ts' -exec cat {} + | wc -l it’s some 300 lines of TypeScript, that’s not the end of the world –

Correction: the init module also includes some files from src/data-access and a few others, so ca. 700 lines seems to be closer to the real number. (But that’s also including some interfaces and enums.)

I spent what felt like (and maybe even was) hours on this only to be hit at the head with the realization that npm/node for some unfathomable reason caches the contents of .browserlistrc and babel.config.js. This cache can be deleted with
$ rm -rf node_modules/.cache

From the description:

@Charlie_WMDE also mentioned the idea to approach this in a more general fashion, e.g. always showing the loading indicator if a transaction which is known to by asynchronous (e.g. the "saving") takes longer than 1 second.

In T227758#5555013, @Lucas_Werkmeister_WMDE wrote:

I think the forcelinkupdate option is just a very confusing name for a fuller purge (I’ll investigate if we need it), but apart from that, yes.

So the recommended workflow is:

In T234897#5554947, @Lucas_Werkmeister_WMDE wrote:

What is this phatality? I can’t find any information about it on Wikitech or MediaWiki.org.

In T234897#5554919, @Tgr wrote:

That's a duplicate of T231084: Assert.php: Bad value for parameter $oldContent: must be a TextContent|null (minus the pentesting aspect, which I would not be worried about).

Seems to depend on local server or mediawiki config.

Tentative first version: Showcase, Template, Item.

All patches got merged. Somehow the Gerrit bot got confused and forgot to report that for the patch that adds the selenium tests for pressing escape.

Thank you for the investigation!

In T231887#5529597, @Lucas_Werkmeister_WMDE wrote:

So, remaining action item – handle assert failures better?

In T231887#5525667, @Lucas_Werkmeister_WMDE wrote:

[...] basically, we add assert='user' or assertuser=mw.config.get('wgUserName') (not sure which) to the wbeditentity request if the user is logged in locally; rely on CentralAuth to do the right thing™; and if the assert fails, ask the user to log in and try again?

In T231887#5518714, @Matthias_Geisler_WMDE wrote:

I have a couple questions regarding this:
-> Do we make central auth as a dependency of DataBridge (especially regarding 3rd parties)? If yes we should somewhere doc (as well as ULS), or?

Using central auth in 3rd party installations seems to be generally discouraged, because it is complex to set up and maintain. For the purpose of this MVP I would assume that client and repo have in principle access to the same users.

After playing around with the creation of new users that have never been to wikidata, it seems that the startup API requests to wikidata are enough to create the user there.

Story time notes:

While the situation may happen as described in T231209 and T202028, that the user is only logged into the Wikipedia site with the bridge app, but not into Wikidata, that doesn't seem to be a problem as the login-check is made against central auth and not wikidata itself. Hence the edit is still made on wikidata as the logged-in user without actually being logged-in in wikidata on the browser.

I just tried it out (while looking into T231887) and this is weirdly asymmetric.

For reference: Termbox has something that is at least similar to what we want: https://tools-static.wmflabs.org/wikibase-termbox-storybook/?path=/story/indeterminateprogressbar--default

Story writing remark: This may need an investigation as to why we are currently not getting more specific edit summaries. Shouldn't there be a diff happening on the server side?