WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED LATER
131007
Web Replay: make uses of localStorage/sessionStorage deterministic during replay
https://bugs.webkit.org/show_bug.cgi?id=131007
Summary
Web Replay: make uses of localStorage/sessionStorage deterministic during replay
Brian Burg
Reported
2014-03-31 20:54:19 PDT
This is probably a good candidate for naive memoization (using the DOMMemoizedResult mechanism), at least initially. My understanding is that the vast majority of localStorage clients use it as a glorified cookie store.
Attachments
Add attachment
proposed patch, testcase, etc.
Brady Eidson
Comment 1
2014-03-31 21:01:38 PDT
LocalStorage is global and observable from all tabs that share the domain, including with notifications. Tread carefully.
Brady Eidson
Comment 2
2014-03-31 21:02:26 PDT
(In reply to
comment #1
)
> ... including with notifications.
I realize that problem doesn't make much sense. I meant, each open tab gets notifications when their local storage area changes from any other tab.
Brian Burg
Comment 3
2014-03-31 22:50:59 PDT
(In reply to
comment #1
)
> LocalStorage is global and observable from all tabs that share the domain, including with notifications.
Thanks for the heads-up about notifications. Here's my thinking on the implementation strategy. I will defer on this bug until some timers work has been completed. For all localStorage APIs we don't want to read or write the backing store since it may have changed. For getItem/length/contains, those can be memoized inside the Storage.cpp implementations. During replay, calls to setItem/removeitem should be ignored so that they have no effect on the backing store. For notifications, it suffices to only worry about one Page being deterministic. So, that means playing back observed notifications and ignoring all others that coincidentally may be triggered during replay by other pages in the same origin. This is similar to the logic in UserInputBridge which blocks user mouse/keyboard events on replay. Storage events may be captured as they are dispatched through StorageEventDispatcher (either in that class or in Frame). On replay, storage events can be enqueued in the Document's EventQueue in an EventLoopInput. The nondeterminism of the document event queue itself is handled in a different bug.
Blaze Burg
Comment 4
2017-07-10 14:01:30 PDT
Closing web replay-related bugs until we resume working on the feature again.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug