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

[bugzilla-daemon at webkit.org]

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





--- Comment #77 from Pablo Flouret <pablof at motorola.com>  2012-01-31 19:30:47 PST ---
(In reply to comment #76)
> (From update of attachment 124856 [details])
> 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.

In that particular case, pushState will reset the cached value (which is probably superfluous), but let's say it was history.back() or the user with the back button, JSPopStateEvent::state is going through JSHistory::state, not History::state directly, so if there's a 1-to-1 mapping, the only one calling History::state is JSHistory::state and everything should be fine (as far as i can see).

In any case, it's a good observation, i can modify the deserialization test slightly to cover this, or make a new test to make it more explicit.

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