Editor: Add sessionStorage autosave mechanism #16490

aduth · 2019-07-09T21:05:48Z

Closes #7367
Related: #6322

Some edits by @mcsf

This pull request seeks to implement periodic ~~localStorage~~ sessionStorage autosave backups for posts. It reuses and extends the behavior of the existing server-persisted autosave component, leveraging sessionStorage when available to save data on a more frequent basis.

Implementation notes:

~~This was designed to be compatible with localStorage backup mechanism implemented in the classic editor (WordPress 4.9.x and older), hence the selection of the localStorage key 'post_' + postId.~~

This influenced the choice to not use the existing data persistence behavior, along with a desire to avoid creating saves until the interval has elapsed (vs. on every state change).

Even with the delay, we may want to explore using requestIdleCallback in addition to the timeout interval, since serialization can be a very non-performant operation, depending on the size of the post.

Testing Instructions:

The autosaves occur every 15 seconds after the last change has occurred. Verify that upon waiting this duration and reloading the page (dismissing the prompt), you see a restore option to restore the title, content, and excerpt of the post you had been working on.

Verify that the prompt is not shown if you proceed to make edits to the post and save (regardless of whether you choose to restore or dismiss the notice).

Checklist: (Added 2019-08-30)

Always run the autosave procedure every 15 seconds, not 15 seconds after the last change
~~Still try to save to storage only if a change has actually occurred~~
Explore whether requestIdleCallback is a reasonable improvement to avoid blocking operation
Add some more through inline code documention (e.g. lastDidSave)
Convert to use sessionStorage as a way to avoid accumulating storage and potential for lingering storage from other users
~~Should confirm that this data is in-fact purged upon logging out, or that an equivalent measure is taken to avoid access by other users even within the same storage~~
Fix useAutosavePurge, per Editor: Add sessionStorage autosave mechanism #16490 (comment)

swissspidy · 2019-07-10T13:35:20Z

Sounds like a good first step. I'd love to see using service workers for this though, as it makes for a more robust experience when offline.

aduth · 2019-07-10T14:06:02Z

@swissspidy Do you see service workers as an alternative to this approach, or a supplement? It's been some time since I've worked with service workers, so any resources you can share would be appreciated.

swissspidy · 2019-07-10T14:24:14Z

Using serve workers would be a supplement, especially because they require HTTPS. In #6322 @westonruter actually shared some very good ideas on how they could enhance the editing experience when offline.

For example, it can cache assets and even REST API responses locally. So when you are offline, you could still refresh the page, select tags, and write content as usual. You could even go and edit some totally different post and have all the (cached) data at your fingertips. And thanks to background sync, any attempt to save the post will be recorded and run as soon as you get online again.

While https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API covers the fundamental basics of service workers, I recommend checking out the PWA feature plugin as it includes some of these things I mentioned already, just for other parts of WordPress. For example, it has background sync for comments and support for a dedicated offline template that is shown when there's no cached content.

aduth · 2019-07-10T14:40:17Z

Thanks @swissspidy . These all sound like worthwhile explorations. In the short term, I think we can still pursue the approach in this pull request independently, and keep #6322 open for further discussion and enhancements.

aduth · 2019-07-12T21:16:33Z

I've finished fleshing out the remaining functionality, and have updated the original comment with an animation, implementation notes, and testing instructions.

packages/edit-post/src/components/layout/index.js

packages/editor/src/components/local-autosave-monitor/index.js

talldan

Seems to be on the right track. 👍

talldan · 2019-07-15T05:07:05Z

packages/editor/src/components/autosave-monitor/index.js

-		autosave: dispatch( 'core/editor' ).autosave,
+	withDispatch( ( dispatch, ownProps ) => ( {
+		autosave() {
+			const { autosave = dispatch( 'core/editor' ).autosave } = ownProps;


An option might be to extract a more generic BaseAutosaveMonitor component.

From an interface point of view, it feels a bit unusual to have this fall back to performing a regular autosave if for some reason the autosave prop is undefined. Especially given the current usage where there are multiple of these registered:

<AutosaveMonitor /> <LocalAutosaveMonitor />

An option might be to extract a more generic BaseAutosaveMonitor component.

Hmm, I see where you're coming from. Some of this is inherited from the previous behavior that the editor has some understanding of what an "autosave" action means (the server-persisted autosave).

Funny though that your recommendation is essentially the opposite of @mtias at #16490 (comment) 😄

😄 Hah, true.

Combining them would allow more coordination between the two autosave systems, which might be beneficial.

talldan · 2019-07-15T05:29:50Z

packages/editor/src/components/local-autosave-monitor/index.js

+	} ) );
+
+	return useCallback( () => {
+		window.localStorage.setItem( 'post_' + postId, JSON.stringify( {


The REST autosave system has some checks in place to make sure either post_title or content is defined before saving. Worth replicating that here?

We also should use sessionStorage. :)

Yes, let's switch to sessionStorage-

The REST autosave system has some checks in place to make sure either post_title or content is defined before saving. Worth replicating that here?

Could you point me to what it is you're referring to on this?

Yep, it's isEditedPostSaveable:
https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/store/selectors.js#L458-L462

Which is used to return early from savePost in the event there aren't changes to any of those autosave fields:
https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/store/actions.js#L439

I expect the overhead for saving to sessionStorage is very low, possibly lower than retrieving and comparing to the old data?

I expect the overhead for saving to sessionStorage is very low, possibly lower than retrieving and comparing to the old data?

Agreed, unless we measure otherwise.

talldan · 2019-07-15T05:38:52Z

packages/editor/src/components/local-autosave-monitor/index.js

+		didSave: select( 'core/editor' ).didPostSaveRequestSucceed(),
+	} ) );
+
+	const lastDidSave = useRef( didSave );


This works really nicely in testing. I was curious about when didSave would get set to false again after a successful save. It turns out that it's set to false when the next save request is initiated (possibly a bit confusing since it's not yet an unsuccessful save, which false might indicate to some).

It might be worth adding a brief comment that describes this.

Indeed. Now that this PR had been rebased on top of the merged core entities changes (#17368), useAutosavePurge no longer works, as didSave is defaulting to true.

Neither scenario is wrong, and both are unspecified behaviour. :)

Instead, this hook will need to observe some additional state, perhaps publish/draft status, or just dirtiness. @epiqueras, considering how entities now work, does any of these sound better to explore than the other?

I think this is what you want?

const { isSavingEntityRecord, getLastEntitySaveError } = select('core/data') const didSave = isSavingEntityRecord(...args) === false && !getLastEntitySaveError(...args)

Note that isSavingEntityRecord(...args) is undefined before the first save, hence the === false.

I had pushed something that seems to be working that's based on isDirty instead. If it won't cover our needs we could look at this.

talldan · 2019-07-15T05:57:17Z

packages/editor/src/components/local-autosave-monitor/index.js

+			actions: [
+				{
+					label: __( 'Restore the backup' ),
+					onClick() {


The hard part in terms of the user experience here is that this action might destroy more of the user's content if the user has added more to the post since the last local autosave. Although they can use undo, I don't think that's always apparent.

The other autosave system displays a diff before giving the option to apply changes. Although it's a bit of extra work, it could be worth trying. I believe there's a diff library already in use for block validation.

The hard part in terms of the user experience here is that this action might destroy more of the user's content if the user has added more to the post since the last local autosave. Although they can use undo, I don't think that's always apparent.

The other autosave system displays a diff before giving the option to apply changes. Although it's a bit of extra work, it could be worth trying. I believe there's a diff library already in use for block validation.

By other autosave, I assume you mean the revisions? There was also a localStorage/sessionStorage-based solution in the classic editor which, as far as I recall, took no such precautions.

I'm leaning more on the end that Undo should serve as the intended option should the changes not be what the user was expecting, maybe at least as a first pass.

Yep, I mean revisions. Wouldn't want to add too much more to this PR, so if considering that part separately is an option, that sounds good.

Good point, in the classic editor we show the user the following message when an autosave is present in sessionStorage:

Can we match something like that messaging here? Is this still true in Gutenberg, can the user use 'undo' to undo the restore?

The other autosave system displays a diff before giving the option to apply changes. Although it's a bit of extra work, it could be worth trying. I believe there's a diff library already in use for block validation.

Great idea! I suggest we revisit this when we develop a more full fledged revision UI into Gutenberg.

talldan · 2019-07-15T06:00:34Z

packages/editor/src/components/local-autosave-monitor/index.js

+
+	return (
+		<AutosaveMonitor
+			interval={ AUTOSAVE_INTERVAL_SECONDS }


This seems to require that the user is idle for 15 seconds before it'll trigger a save.

Since this is a last resort, I wonder if there's also an option to use additional strategies for saving local autosaves, like the beforeUnload handler.

I agree that the initial feel is that this isn't eager enough to locally autosave.

Given that localStorage is a synchronous API, should requestIdleCallback be used if available?

Perhaps related: https://github.com/WordPress/gutenberg/pull/16490/files#r303243055

Maybe we should only save locally if you cannot save otherwise? Would it make more sense then to implement it in a different layer of the application?

Since this is a last resort, I wonder if there's also an option to use additional strategies for saving local autosaves, like the beforeUnload handler.

I'd agree on this, and the fact that we should probably just schedule (or at least check for changes to justify) the autosaves to occur every 15 seconds, not just 15 seconds after the last change.

Given that localStorage is a synchronous API, should requestIdleCallback be used if available?

It could be worth exploring. I'd question whether it would make a measurable difference, however (related: #16657).

talldan · 2019-07-15T06:26:51Z

packages/editor/src/components/local-autosave-monitor/index.js

+
+		if ( ! hasDifference ) {
+			// If there is no difference, it can be safely ejected from storage.
+			window.localStorage.removeItem( 'post_' + postId );


This key format would mean that if a second user logs in to the same browser, they can restore an autosave made by the first user.

Not sure if that's an issue, but I know the current autosave system stores revisions by different users separately. One way to align with that but still keep the same localstorage key is to save the userId in the payload and check the value before showing the notice.

This key format would mean that if a second user logs in to the same browser, they can restore an autosave made by the first user.

Based on other comments, I think sessionStorage may be enough to resolve this.

Though technically it could still be an issue if the user logs out of the current user and into another user while still within the same tab / session. I'd be curious to know if / how this was addressed in the classic editor.

Currently in core we clear autosave data from session storage when the user logs out: https://github.com/WordPress/wordpress-develop/blob/6dad32d2aed47e6c0cf2aee8410645f6d7aba6bd/src/wp-login.php#L103 as long as we use the same key format, this code should continue to work.

talldan · 2019-07-15T06:33:22Z

packages/editor/src/components/local-autosave-monitor/index.js

+
+		const noticeId = uniqueId( 'wpEditorAutosaveRestore' );
+
+		createWarningNotice( __( 'The backup of this post in your browser is different from the version below.' ), {


Just thinking of all the weird and wonderful edge cases that might happen. I think there is a chance that a user might create local autosave on computer A, a revision for a post on a computer B, and then when returning to the computer A they'd be presented with both this notice and the normal autosave notice.

One option would be to timestamp local saves, and then only present the user with the notice for the most recent save whether it's a local or a server stored save.

Timestamping could help, but I'm not sure about any edge cases that may miss.

There's a few ways in which we may lead the user to make mistakes. One way to mitigate it is to tie this with the diffing view we use in block validation (which incidentally is also in need of love). edit: I now see that another comment by Dan suggests the same

mcsf · 2019-07-18T10:39:04Z

One thing that this PR doesn't need to address but which will need a solution to in the future is cleaning up after deleted posts.

In the following screencast, a draft with changes sitting in localStorage is deleted, leaving behind its entry in localStorage.

mcsf · 2019-07-18T10:49:16Z

packages/editor/src/components/local-autosave-monitor/index.js

+
+		const noticeId = uniqueId( 'wpEditorAutosaveRestore' );
+
+		createWarningNotice( __( 'The backup of this post in your browser is different from the version below.' ), {


Timestamping could help, but I'm not sure about any edge cases that may miss.

There's a few ways in which we may lead the user to make mistakes. One way to mitigate it is to tie this with the diffing view we use in block validation (which incidentally is also in need of love). edit: I now see that another comment by Dan suggests the same

mcsf · 2019-07-18T11:14:48Z

packages/editor/src/components/local-autosave-monitor/index.js

+				{
+					label: __( 'Restore the backup' ),
+					onClick() {
+						editPost( omit( edits, [ 'content' ] ) );


Per our conversation:

Let's see if we really need to pull 'content' out of edits for this particular editPost action. resetEditorBlocks should be taking care of the cleanup of edits.content in state. I'd rather have this use of editPost be immediately clear, even if it's unnecessarily setting edits.content.

mcsf · 2019-07-18T11:15:19Z

packages/editor/src/components/local-autosave-monitor/index.js

+
+	return (
+		<AutosaveMonitor
+			interval={ AUTOSAVE_INTERVAL_SECONDS }


I agree that the initial feel is that this isn't eager enough to locally autosave.

westonruter · 2019-07-18T21:07:18Z

This probably won't matter so much, but I wanted to mention: localStorage is a synchronous API. If many writes are being done with large bodies of content into localStorage, it is possible that this could degrade performance in the editor. See https://developers.google.com/web/updates/2019/03/kv-storage

Also, localStorage would persist in the browser even when the user is logged-out. On a shared computer, this would allow leakage of data, so ideally the data would be encrypted with some user-specific secret. Maybe this is overkill.

See also kv-storage for async storage: https://github.com/WICG/kv-storage

ellatrix · 2019-07-19T15:37:19Z

WordPress Core currently uses sessionStorage to back up the post content because of the security issues with localStorage.

aduth · 2019-07-30T20:40:50Z

Thanks all for the feedback!

A few specific action items I've observed:

Always run the autosave procedure every 15 seconds, not 15 seconds after the last change
- Still try to save to storage only if a change has actually occurred
- Explore whether requestIdleCallback is a reasonable improvement to avoid blocking operation
Add some more through inline code documention (e.g. lastDidSave)
Convert to use sessionStorage as a way to avoid accumulating storage and potential for lingering storage from other users
- Should confirm that this data is in-fact purged upon logging out, or that an equivalent measure is taken to avoid access by other users even within the same storage

paaljoachim · 2019-08-22T08:08:02Z

On occasion I have some hickups - as in a slow internet causing this: (I should perhaps instead say that the web sites have some hickups..:) #17015

It would be very helpful to have this PR merged! Thanks.

mcsf · 2019-08-30T19:52:46Z

As Andrew is enjoying some time off, I've revived this branch and applied some of the feedback that's been provided. A couple of notes:

In terms of terminology, I've kept LocalAutosave even though "local storage" became "session storage" throughout the diff. I think LocalAutosave is still more descriptive and perfectly apt, as it doesn't imply usage of localStorage, but rather only locality, which sessionStorage also provides.
@adamsilverstein's tip Editor: Add sessionStorage autosave mechanism #16490 (comment) was quite useful. I did however find a strange situation where attempting to log out while there are unsaved edits in the editor leads to deleting the autosaves from sessionStorage even if you cancel navigation in the onbeforeunload confirmation:

I don't think this is something to address in this PR, but it's something to be aware of.

* Base implementation on undo state of core entities * Expand unit tests

gziolo · 2019-09-16T00:51:32Z

packages/editor/src/store/selectors.js

- *
- * @return {*} A value whose reference will change only when an edit occurs.
- */
-export const getReferenceByDistinctEdits = createSelector(


We need to provide backward compatibility support here.

docs/designers-developers/developers/data/data-core.md

packages/core-data/src/test/selectors.js

gziolo · 2019-09-16T01:16:59Z

packages/editor/src/components/autosave-monitor/index.js

+		// The `shouldThrottle` props allows overriding this behaviour, thus
+		// making the autosave action "throttled".
+		if ( ! shouldThrottle ) {
+			clearTimeout( this.pendingSave );


Should clearTimeout call be guarded here to avoid executing this block when this.pendingSave is not defined?

gziolo · 2019-09-16T01:20:53Z

packages/editor/src/components/local-autosave-monitor/index.js

+	}, [ isDirty ] );
+}
+
+function LocalAutosaveMonitor() {


It would be great to add some docs as a follow-up PR since it's a public API :)

packages/editor/src/components/local-autosave-monitor/index.js

gziolo · 2019-09-16T01:31:01Z

packages/editor/src/components/local-autosave-monitor/index.js

+	return useCallback( () => {
+		const saveToSessionStorage = () => {
+			window.sessionStorage.setItem( postKey( postId ), JSON.stringify( {
+				post_title: getEditedPostAttribute( 'title' ),


What about other stuff like:

taxonomy

categories

featured image

and so on?

Worth noting that this wasn't saved in the classic editor, but that doesn't mean we should do the same. Just noting.

Yeah. Grzegorz and I also talked a little about this:

There's also a management of expectations to play with: the more data we autosave, the greater the expectations that this is a fully fledged offline support feature, which it isn't.

I think backing up post content really is 90% of the feature, and for an introductory PR this is more than fine. The fact that Classic did the same validates this.

As Gutenberg evolves to support more than just posts with content and into the realm of full-site editing, a lot of this might become a lot more ambitious if we're dealing with multiple entities to save in a single editor. (When we get there we can try autosaving around each BlockEditor and see where it takes us.)

For now, let's keep it focused on these three bits.

gziolo · 2019-09-16T01:37:25Z

packages/editor/src/components/local-autosave-monitor/index.js

+			} ) );
+		};
+		requestIdleCallback( saveToSessionStorage );
+	}, [ postId, getEditedPostAttribute ] );


getEditedPostAttribute - we put this action as a dependency here, but we don't do it for all actions in useAutosaveNotice. The question is why it is necessary here or why do we miss all those actions for useEffect inside useAutosaveNotice.

Is it because of useAutosaveNotice should be triggered only once per post id?

Per individual chat, let's drop getEditedPostAttribute from the deps. We don't yet have strong conventions on how to deal with this in React hooks.

If we were very strict about this we would list every single reference used in the closure, but the references in our case are all static constant functions, either directly (defined in the module or imported) or indirectly (selectors obtained via select). I don't feel strongly, but I'd err toward keeping references out for now and adding them if we tighten our expectations here.

gziolo · 2019-09-16T01:48:54Z

packages/e2e-tests/specs/autosave.test.js

+	pressKeyWithModifier,
+} from '@wordpress/e2e-test-utils';
+
+const AUTOSAVE_INTERVAL_SECONDS = 15;


That's a big number of seconds to wait in the test, to be fair. Can we set something lower through some sort of override? In other words, can we avoid using sleep as much as it is possible?

We could bring it down to 5, if that makes sense as a user experience.

It might also be beneficial to make this an editor setting so it could be customised. Would this be a requirement for this particular PR?

How slow would setting session storage be for large posts?

packages/e2e-tests/specs/autosave.test.js

mcsf · 2019-09-16T14:24:10Z

It needs to be profiled, and we also need to benchmark with the perf e2e suite.

gziolo

This works great, let's move forward with it once we add back deprecated message for the removed selector with the proper warning printed to the console. See: #16490 (comment)

As a follow-up tasks we should do the following:

Add documentation for the newly introduced component
Make the local autosave interval configurable so sites could tweak it and at the same time to speed up e2e tests
Let's add more e2e tests which cover other use cases like (mostly to prevent regressions):
- logging out - which wipes the saved post
- ensuring that the saved content doesn't get loaded in the other post

mcsf · 2019-09-16T20:05:44Z

A performance benchmark:

master

Average time to load: 10858ms
Average time to DOM content load: 10023ms
Average time to type character: 70.515ms
Slowest time to type character: 132ms
Fastest time to type character: 56ms

Average time to load: 10793ms
Average time to DOM content load: 9916ms
Average time to type character: 67.465ms
Slowest time to type character: 142ms
Fastest time to type character: 59ms

local autosave, no editor setting

Average time to load: 11169ms
Average time to DOM content load: 10211ms
Average time to type character: 71.01ms
Slowest time to type character: 190ms
Fastest time to type character: 61ms
		
Average time to load: 10685ms
Average time to DOM content load: 9811ms
Average time to type character: 72.015ms
Slowest time to type character: 156ms
Fastest time to type character: 58ms

local autosave, with editor setting

Average time to load: 9941ms
Average time to DOM content load: 9647ms
Average time to type character: 72.995ms
Slowest time to type character: 157ms
Fastest time to type character: 62ms

Average time to load: 10343ms
Average time to DOM content load: 10041ms
Average time to type character: 67.45ms
Slowest time to type character: 160ms
Fastest time to type character: 53ms

Follow-up of #16490

aduth · 2020-06-01T16:48:26Z

packages/e2e-tests/specs/autosave.test.js

+	beforeEach( async () => {
+		await clearSessionStorage();
+		await createNewPost();
+		await setLocalAutosaveInterval( AUTOSAVE_INTERVAL_SECONDS );


Should there be an associated tear down to this, to avoid the state bleeding over into other tests run in the same container?

Not sure it would have any noticeable impact since ideally those tests would be resilient regardless of an autosave interval, but seems like an undesirable side-effect in any case.

I guess it might depend if setLocalAutosaveInterval is something which would persist outside the current page. If most tests would create a new post and thus navigate away, it might not be a problem.

Then again, it's long been a desire of mine that createNewPost shouldn't have to trigger a full page reload (see #18668).

aduth added Backwards Compatibility Issues or PRs that impact backwards compatability [Feature] Saving Related to saving functionality [Feature] Offline Related to offline editing labels Jul 9, 2019

aduth marked this pull request as ready for review July 12, 2019 21:11

aduth requested review from ajitbohra, gziolo, jorgefilipecosta, talldan and youknowriad as code owners July 12, 2019 21:11

mtias reviewed Jul 14, 2019

View reviewed changes

packages/edit-post/src/components/layout/index.js Show resolved Hide resolved

mtias reviewed Jul 14, 2019

View reviewed changes

packages/editor/src/components/local-autosave-monitor/index.js Outdated Show resolved Hide resolved

ellatrix added the [Priority] High Used to indicate top priority items that need quick attention label Jul 14, 2019

ellatrix added this to the Gutenberg 6.2 milestone Jul 14, 2019

ellatrix self-requested a review July 14, 2019 18:25

talldan reviewed Jul 15, 2019

View reviewed changes

mcsf reviewed Jul 18, 2019

View reviewed changes

gziolo removed this from the Gutenberg 6.2 milestone Jul 30, 2019

mcsf added 4 commits September 15, 2019 14:30

LocalAutosaveMonitor: Wrap saving in requestIdleCallback

4b2e070

getReferenceByDistinctEdits: move to core-data

adb90a5

* Base implementation on undo state of core entities * Expand unit tests

Fix useAutosaveNotice by observing isEditedPostDirty

8d7645d

AutosaveMonitor: Support throttle apart from debounce

c6c7a8e

mcsf force-pushed the add/local-storage-autosave branch from ef43fcd to c6c7a8e Compare September 15, 2019 18:31

aduth requested a review from ntwb as a code owner September 15, 2019 21:06

Add e2e tests for sessionStorage-based autosave

52ca63e

mcsf force-pushed the add/local-storage-autosave branch from 8e1c26f to 52ca63e Compare September 15, 2019 21:34

gziolo reviewed Sep 16, 2019

View reviewed changes

gziolo approved these changes Sep 16, 2019

View reviewed changes

mcsf added 2 commits September 16, 2019 11:37

Address feedback

9c1b5b6

Make localAutosaveInterval a setting to speed up e2e tests

64fac7e

youknowriad merged commit e99c212 into master Sep 16, 2019

youknowriad deleted the add/local-storage-autosave branch September 16, 2019 19:23

mcsf added a commit that referenced this pull request Sep 16, 2019

Re-add & deprecate core/editor:getReferenceByDistinctEdits

37ffffa

Follow-up of #16490

mcsf mentioned this pull request Sep 16, 2019

Re-add & deprecate core/editor's getReferenceByDistinctEdits #17458

Merged

5 tasks

youknowriad pushed a commit that referenced this pull request Sep 18, 2019

Re-add & deprecate core/editor:getReferenceByDistinctEdits (#17458)

e7d4237

Follow-up of #16490

youknowriad pushed a commit that referenced this pull request Sep 18, 2019

Re-add & deprecate core/editor:getReferenceByDistinctEdits (#17458)

08819dc

Follow-up of #16490

This was referenced Sep 20, 2019

Local autosave: expand e2e test coverage #17495

Closed

Local autosave can conflict with remote autosave #17500

Closed

daniloercoli mentioned this pull request Sep 24, 2019

[RNMobile] Improve autosave on mobile and ping the native at each keystroke #17548

Merged

tellthemachines mentioned this pull request Feb 6, 2020

Autosaving feature jams-up #10416

Closed

mcsf mentioned this pull request Feb 26, 2020

Improve behaviour when saving content while offline #6322

Closed

aduth commented Jun 1, 2020

View reviewed changes

adamziel mentioned this pull request Jul 14, 2020

Investigate content loss issues after connection loss/long period of time. #23781

Closed

swissspidy mentioned this pull request Aug 12, 2020

Autosaving while offline (sessionStorage) GoogleForCreators/web-stories-wp#3842

Closed


		const noticeId = uniqueId( 'wpEditorAutosaveRestore' );

		createWarningNotice( __( 'The backup of this post in your browser is different from the version below.' ), {

Editor: Add sessionStorage autosave mechanism #16490

Editor: Add sessionStorage autosave mechanism #16490

Conversation

aduth commented Jul 9, 2019 • edited by mcsf Loading

swissspidy commented Jul 10, 2019

aduth commented Jul 10, 2019

swissspidy commented Jul 10, 2019

aduth commented Jul 10, 2019

aduth commented Jul 12, 2019

talldan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcsf Sep 14, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

westonruter Jul 18, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

talldan Jul 15, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamsilverstein Aug 22, 2019 • edited Loading

Choose a reason for hiding this comment

talldan Jul 15, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcsf commented Jul 18, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

westonruter commented Jul 18, 2019

ellatrix commented Jul 19, 2019

aduth commented Jul 30, 2019

paaljoachim commented Aug 22, 2019 • edited Loading

mcsf commented Aug 30, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcsf commented Sep 16, 2019 via email

gziolo left a comment

Choose a reason for hiding this comment

mcsf commented Sep 16, 2019

master

local autosave, no editor setting

local autosave, with editor setting

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth commented Jul 9, 2019 •

edited by mcsf

Loading

mcsf Sep 14, 2019 •

edited

Loading

westonruter Jul 18, 2019 •

edited

Loading

talldan Jul 15, 2019 •

edited

Loading

adamsilverstein Aug 22, 2019 •

edited

Loading

talldan Jul 15, 2019 •

edited

Loading

paaljoachim commented Aug 22, 2019 •

edited

Loading