This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22420 - PopStateEvent.state should be a copy (via structured clone) of the value it was initialized to
Summary: PopStateEvent.state should be a copy (via structured clone) of the value it w...
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-20 20:30 UTC by contributor
Modified: 2013-07-02 22:33 UTC (History)
3 users (show)

See Also:

Attachments

Description contributor 2013-06-20 20:30:21 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html
Multipage: http://www.whatwg.org/C#dom-popstateevent-state
Complete: http://www.whatwg.org/c#dom-popstateevent-state
Referrer: 

Comment:
PopStateEvent.state should be a copy (via structured clone) of the value it
was initialized to, not the value itself. This would make events generated by
the user agent and those generated by code calling new PopStateEvent() behave
the same way.

Posted from: 216.239.45.83
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1543.2 Safari/537.36
Comment 1 Adam Klein 2013-06-20 20:37:58 UTC 
This concern looks like it should also apply to MessageEvent, which uses the same wording and has the same difference between events created via new MessageEvent and those created via, e.g., postMessage.
Comment 2 Ian 'Hixie' Hickson 2013-06-20 21:00:33 UTC 
I don't understand. Why would we want to prevent an author from creating an event with the specific data they set?

That would be quite a radical departure from the behaviour of other event objects.
Comment 3 Adam Klein 2013-06-20 21:08:28 UTC 
I guess my argument is for consistency of behavior. Why should it be possible to create a MessageEvent with an HTMLDocument as its data when using the constructor form but not when using postMessage? I take it your response is that, in the constructor case, there's no need for restricting authors to those things which are structured-cloneable.

My motivation in filing this bug happens to involve implementation details of these events in Blink, where storing the passed-in object itself creates an opportunity for memory leaks and security bugs. But there are alternative fixes for those problems if it turns out that this inconsistency between organic and synthetic events is intentional.
Comment 4 Ian 'Hixie' Hickson 2013-07-02 22:33:09 UTC 
Closing per IRC discussion last week; reopen if I misremember our conclusion.