MediaWiki

Front-end standards group/2017-09-27

< Front-end standards group

Attending: Andrew R, Timo T, Ed S, Jan D, Jon R, Prateek S, Volker E

 Action & Code 

edit

New quests

edit

VisualEditor: Implement some form of auto-save (ES) https://phabricator.wikimedia.org/T57370 Articles in VE can reach up to over a MB due to conversion to HTML
localStorage with it's limit when
RL already using localStorage
Manually trashing stored edits?
Should we use localStorage? Or stashing stuff on server?
AG: Also more limited on FF because the limit is domain-wide o something IIRC?
AG: Storing diffs?
ES: Can be more efficient, with longer history could be less efficient
diff needs to know which version it started against
AG: Maybe store an initial version to diff against on the server right away, then diffs in LocalStorage?

  • FWIW, CentralNotice depends heavily on LocalStorage availability for banner selection

Upload speeds slower and no compression cause HTTP is stateless
We have libraries that could do this, but can be a lot on the client, especially on mobile
TT: You'd also want this to happen continously, not after a button press
ES: Comparisons and edge cases - https://phabricator.wikimedia.org/T57370#2976763
AG: Can the server store somewhere the initial state to diff against without having to fetch it from the client?
SessionStorage?
TT: LocalStorage, WebSQL, IndexDB
JD: Seems like service workers get lots of room https://stackoverflow.com/questions/35242869/what-is-the-storage-limit-for-a-service-worker
TT: Could do a regular ajax POST under the assumption service worker will intercept it

  • Alternatively the Cache Storage API from service worker is also available in the main window context actually (little known fact, but standardised)
  • Similar to how you'd use localStorage, basically. caches.open() then set() new Response(JSON), some such

JD: Here's a good table: https://www.html5rocks.com/en/tutorials/offline/quota-research/
AG: There's a task about LocalStorage lib for MW https://phabricator.wikimedia.org/T121646
JR: there's the mediawiki.storage module for localStorage if using localStorage

  • but it's very basic - but dies silently if localstorage is exhausted
  • how does phabricator do this?

TT: phabricator stashes server-side

  • (your draft comment)
  • as part of preview rendering

JR: Services were looking into a key value store might be worth talking to them about it too if you need an endpoint to do this on server side.
AG: CentralNotice has an expiry system (following Timo's suggestions), it checks for expiry frequently
JR: Services were looking into a key value store
might be worth talking to them about it too
AG: https://github.com/wikimedia/mediawiki-extensions-CentralNotice/blob/master/resources/subscribing/ext.centralNotice.kvStore.js
Here's the key expiry part: https://github.com/wikimedia/mediawiki-extensions-CentralNotice/blob/master/resources/subscribing/ext.centralNotice.kvStoreMaintenance.js
ES: Shared library or doing a custom solution in VE?
Action: follow-up 

Create an abstraction for the message box components (warningbox, errorbox etc) (JR, if there is time) https://phabricator.wikimedia.org/T166915
ES: Messages that appear close to form inputs?
There's also other messages like toast messages, postEdit messages, 
We need to make sure that this new 'legacy' version is consistent with OOUI. 
VE: Design should have been at the beginning as layed out in https://phabricator.wikimedia.org/T127405 but was de-prioritized
Action: JR to put in patch set to core

Follow-up

edit

Measure dwell-time impact of `touch-action: manipulation;` https://phabricator.wikimedia.org/T174002

Retrieved from "https://www.mediawiki.org/w/index.php?title=Front-end_standards_group/2017-09-27&oldid=2615026"