Fri, Oct 18
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.
Thu, Oct 17
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 :)
Wed, Oct 16
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.
Tue, Oct 15
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).
Thu, Oct 10
Wed, Oct 9
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
Tue, Oct 8
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.
So the recommended workflow is:
Seems to depend on local server or mediawiki config.
Mon, Oct 7
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.
Wed, Oct 2
Thank you for the investigation!
Tue, Oct 1
Thu, Sep 26
Wed, Sep 25
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.
Tue, Sep 24
Story time notes:
Mon, Sep 23
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.
Sep 20 2019
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?