[Webkit-unassigned] [Bug 76035] Add state attribute to history's dom interface.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jan 31 18:19:01 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=76035





--- Comment #76 from Kentaro Hara <haraken at chromium.org>  2012-01-31 18:19:00 PST ---
(From update of attachment 124856)
View in context: https://bugs.webkit.org/attachment.cgi?id=124856&action=review

>>> Source/WebCore/bindings/js/JSHistoryCustom.cpp:172
>>> +    if (!cachedValue.isEmpty() && !history->stateChanged())
>> 
>> I guess this might be dangerous. What happens if another call path updates history.state? For example,
>> 
>> (1) JSHistory::state() caches 1111 in |m_state|.
>> (2) Another call path updates history.state to 2222.
>> (3) Another call path calls History::state(), which returns 2222.
>> (4) JSHistory::state() is called again. It calls history->stateChanged() and it returns false. Consequently, JSHistory::state() will return the cached 1111.
> 
> Is the relationship between a History and a {JS,V8}History not 1-to-1? On what situation would there be multiple JSHistory objects using the same History object? Maybe i can make a test for that.

Sorry, the above example was wrong. But if PopStateEvent.state and history.state have to refer to the same object, isn't there any possibility like this? (sorry if I am still wrong)

(1) history.state  // JSHistory::state() caches 1111 in |m_state|.
(2) history.pushState(2222, "foo") // history.state is updated to 2222.
(3) popStateEvent.state // History::state() changes |m_lastStateObjectRequested| from 1111 to 2222.
(4) history.state // history->stateChanged() returns false, and history.state returns 1111.

>>> Source/WebCore/page/History.idl:40
>>> +        readonly attribute [CachedAttribute, Custom] SerializedScriptValue state;
>> 
>> [CachedAttribute] is not necessary, since the getter and setter are written as a custom getter and setter.
> 
> [CachedAttribute] declares a m_state member that's used in the custom getter to store the value (in JSC).

Makes sense.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list