Front-end standards group/2017-09-27

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

New quests
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? 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 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 TT: phabricator stashes server-side 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 
 * FWIW, CentralNotice depends heavily on LocalStorage availability for banner selection
 * 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
 * but it's very basic - but dies silently if localstorage is exhausted
 * how does phabricator do this?
 * (your draft comment)
 * as part of preview rendering

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
Measure dwell-time impact of `touch-action: manipulation;` https://phabricator.wikimedia.org/T174002