You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Impetus: writing a comment on a youtube video, immediately going to a new video which has a distinctly different url, and the same entry in the history is overwritten currently as the comment on the previous video because they use the same framework and the underlying forms have identical names.
Suggestion: serialize records with URL (as a toggled option) to ensure distinctly intentional new entries don't overwrite previous entries when the supposed changed data is within the time or character limit required to currently generate a new entry.
Additional thought: if a form entry is cleared, consider the blank form sharing the same details as a new entry even if it doesn't meet the other time/character criteria, to avoid any situation where page refreshes and accidental typing erases all the history; I would allow for superfluous formatting such as a with nothing else to trigger being a distinct entry, i.e. if the old one was more than 40 characters and the new one is under 5, consider that a cleared form and archive the existing copy.
My concern here is a page timeout shorter than this apps settings accompanied by a forced reload of a page, and then some sort of automated focus to the form with starting formatting added then clears everything. I haven't tested for this; I know if you don't return to the page, such as staying on a logged out page, it would be fine, but it seems like a potential edge case.
Another thought: a hotkey to trigger archiving/forcing a history checkpoint i.e. starting a duplicate entry with the now old one stored. I can think of a lot of reasons for this being desirable, such as different combinations of wording or keys that the user wants quickly stored when trying others, where the changes fall short of the character limit for a new record.
The text was updated successfully, but these errors were encountered:
Using the URL to distinguish instanced sites does not cover cases where the URL is the same and for example session cookies or session-id's are used.
I might be able to make a distinction based on a DOM-id or tab-id in relation to the entry in the database, possibly using a temporary cache.
Impetus: writing a comment on a youtube video, immediately going to a new video which has a distinctly different url, and the same entry in the history is overwritten currently as the comment on the previous video because they use the same framework and the underlying forms have identical names.
Suggestion: serialize records with URL (as a toggled option) to ensure distinctly intentional new entries don't overwrite previous entries when the supposed changed data is within the time or character limit required to currently generate a new entry.
Additional thought: if a form entry is cleared, consider the blank form sharing the same details as a new entry even if it doesn't meet the other time/character criteria, to avoid any situation where page refreshes and accidental typing erases all the history; I would allow for superfluous formatting such as a
with nothing else to trigger being a distinct entry, i.e. if the old one was more than 40 characters and the new one is under 5, consider that a cleared form and archive the existing copy.
My concern here is a page timeout shorter than this apps settings accompanied by a forced reload of a page, and then some sort of automated focus to the form with starting formatting added then clears everything. I haven't tested for this; I know if you don't return to the page, such as staying on a logged out page, it would be fine, but it seems like a potential edge case.
Another thought: a hotkey to trigger archiving/forcing a history checkpoint i.e. starting a duplicate entry with the now old one stored. I can think of a lot of reasons for this being desirable, such as different combinations of wording or keys that the user wants quickly stored when trying others, where the changes fall short of the character limit for a new record.
The text was updated successfully, but these errors were encountered: