Re: [whatwg] Comments on @sandbox
On Thu, 5 Nov 2009, Adam Barth wrote: One interesting feature of @sandbox is that the hosting page can change the value of the sandbox attribute. Even though it's clear that having both allow-same-origin and allow-script at the *same* time lets the sandboxed content escape, it's probably less clear to folks that first setting allow-same-origin and then removing it and adding allow-script is also very dangerous. The reason is slightly subtle. Essentially, when the frame is in the allow-same-origin mode, it is very easy for the outer document to leak a JavaScript object into the DOM of the inner document. Then, when the frame enters the allow-script phase, the document can abuse the leaked object to XSS the outer page, as described in http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf. The reverse sequence is also dangerous because the inner page could use the techniques in this paper http://www.adambarth.com/papers/2009/adida-barth-jackson.pdf to build a fake DOM during the allow-scripts phase and confuse the outer page into XSSing itself in the allow-same-origin phase. To avoid these subtle traps for developers, I recommend to freezing the privileges of a sandboxed document at the time the document is loaded into the frame. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question about header and footer
Bruce Lawson wrote: Is it permissible for one element to have more than one child headers, or more than one child footers? Yes. And, if is permissible, should it be? Unless we have a very good reason, I don't think we should start placing arbitrary restrictions on how elements can be used. In fact, there's a very good reason to allow footers to be used more than once per section, as illustrated by the first footer element example in the spec. I don't believe it's a problem for multiple headers either as the sectioning algorithm will create implied sections from the headings anyway. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Question about header and footer
On Tue, 12 Jan 2010 09:19:04 -, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Bruce Lawson wrote: Is it permissible for one element to have more than one child headers, or more than one child footers? Yes. And, if is permissible, should it be? Unless we have a very good reason, I don't think we should start placing arbitrary restrictions on how elements can be used. In fact, there's a very good reason to allow footers to be used more than once per section, as illustrated by the first footer element example in the spec. I don't believe it's a problem for multiple headers either as the sectioning algorithm will create implied sections from the headings anyway. Makes sense. Thanks Lachy. b -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
Re: [whatwg] Comments on @sandbox
On Thu, 5 Nov 2009, Adam Barth wrote: If a page contains a sandboxed frame, the document contained in the frame is only sandboxed because the user encountered the document via the frame. If the use encounters the same document directly (e.g., in a top-level browsing context), then the document will not be sandboxed. I recommend letting servers deliver the sandbox policy both via the sandbox attribute and via an HTTP header. The value of the HTTP header approach is that the document will be sandboxed in whatever context the user agent loads the document. For various esoteric reasons, I wrote up a description of how this might work on Mozilla's Wiki: https://wiki.mozilla.org/Security/CSP/Sandbox. Based on our discussion, and inspired by Helen Wang's proposal, I've introduced a new MIME type text/sandboxed-html for this case. I expect CSP will make this more powerful going forward, but CSP doesn't solve the problem for legacy browsers, which this does. (I'll be doing more work on sandbox= in the near future. Sorry for not getting through all the backlog today.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img copyright attribute
On Sun, Jan 10, 2010 at 4:53 AM, will surgent will...@gmail.com wrote: It would be nice if there was a copyright attribute for the HTML 5 img tag. This would make it easy for users and search engines to filter out images that can not be used for certain purposes. external metadata on copyright is a disaster. it gets lost immediately. GIF and friends have supported embedding (c) into images for decades. As google is fully capable of caching images (and obviously does so), I question how adding a tag to html will solve a problem which is already solved by the native image formats themselves. For lack of a more useful reference about comment fields, i'll just point to one application which is aware of them (although at the time of the posting it only supported them for certain image types): http://www.group42.com/ts-wi04.htm
Re: [whatwg] img copyright attribute
And it is worth saying that a copyright notice is not a license. Copyright Martin Luther 1517 doesn't tell you anything at all about what permissions Martin is granting you. And rights permissions languages are much more complex... On Jan 12, 2010, at 6:06 , timeless wrote: On Sun, Jan 10, 2010 at 4:53 AM, will surgent will...@gmail.com wrote: It would be nice if there was a copyright attribute for the HTML 5 img tag. This would make it easy for users and search engines to filter out images that can not be used for certain purposes. external metadata on copyright is a disaster. it gets lost immediately. GIF and friends have supported embedding (c) into images for decades. As google is fully capable of caching images (and obviously does so), I question how adding a tag to html will solve a problem which is already solved by the native image formats themselves. For lack of a more useful reference about comment fields, i'll just point to one application which is aware of them (although at the time of the posting it only supported them for certain image types): http://www.group42.com/ts-wi04.htm David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Inconsistent behavior for empty-string URLs
Hi guys, Sorry to pester, but I want to make sure this comes to resolution before it's forgotten. Any other feedback? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, January 07, 2010 1:09 PM To: Nicholas Zakas Cc: Simon Pieters; Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, Jan 7, 2010 at 1:03 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: I'm going to take a lack of response to this question as a no. :) Given the disparate browser implementations for dealing with empty string URLs, it seems unlikely that anyone is relying upon the current behaviors, so I'd like to suggest this change be added to HTML5: For any img, link, script, iframe, audio, video, audio, object, embed, input, html manifest, or frame tag that will result in an automatic download of an external resource must ignore any empty string URL and not download the external resource. This is true even when a base href is applied to the page. Does that sound right? Sounds good to me. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, 12 Jan 2010, Nicholas Zakas wrote: Sorry to pester, but I want to make sure this comes to resolution before it's forgotten. Any other feedback? Don't worry, all e-mail sent to this list ends up in a pile that I eventually go through and reply to. You can see all the e-mail pending review here: http://www.whatwg.org/issues/ (This thread is under processing-model currently, though that can vary over time as I rearrange the buckets to fit the prevalent topics.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] question about the popstate event
Hi, I've been discussing this issue with Brady Eidson over at https://bugs.webkit.org/show_bug.cgi?id=33224, and his interpretation appears to be different. (I think he may have convinced me too.) I'd really like some help understanding how pushState is intended to work and to see how that lines up with the spec. Also, assuming Brady is correct, then I wonder why pushState was designed this way. It seems strange to me that entries in session history would disappear when you navigate away from a document that used pushState. -Darin On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar justin.le...@gmail.com wrote: From my reading of the spec, I would expect the following steps: 5. Page A is loaded. 6. The load event for Page A is dispatched. 7. The popstate event for Page A is dispatched. I think this is correct. A popstate event is always dispatched whenever a new session history entry is activated (6.10.3). -Justin On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher da...@chromium.org wrote: I'd like to make sure that I'm understanding the spec for pushState and the popstate event properly. Suppose, I have the following sequence of events: 1. Page A is loaded. 2. Page A calls pushState(foo, null). 3. The user navigates to Page B. 4. The user navigates back to Page A (clicks the back button once). Assuming the document of Page A was disposed upon navigation to Page B (i.e., that it was not preserved in a page cache), should a popstate event be generated as a result of step 4? From my reading of the spec, I would expect the following steps: 5. Page A is loaded. 6. The load event for Page A is dispatched. 7. The popstate event for Page A is dispatched. Do I understand correctly? Thanks, -Darin
[whatwg] HTML5 cut/copy
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard The current spec says that drop events should be fired while handling copy/cut operations. Is this intended? The clipboard is not a DOM element; it seems like it'd make sense only to fire the drop event for pastes. Daniel
Re: [whatwg] Inconsistent behavior for empty-string URLs
Cool, thanks. I just wanted to make sure the relevant folks from Mozilla, Opera, and WebKit were all in agreement and that I hadn't missed anyone. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Tuesday, January 12, 2010 2:21 PM To: Nicholas Zakas Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Tue, 12 Jan 2010, Nicholas Zakas wrote: Sorry to pester, but I want to make sure this comes to resolution before it's forgotten. Any other feedback? Don't worry, all e-mail sent to this list ends up in a pile that I eventually go through and reply to. You can see all the e-mail pending review here: http://www.whatwg.org/issues/ (This thread is under processing-model currently, though that can vary over time as I rearrange the buckets to fit the prevalent topics.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Appcache feedback
On Thu, 17 Dec 2009, Joseph Pecoraro wrote: We could delay the application cache download process so that it doesn't start until after the 'load' event has fired. Does anyone have an opinion on this? It seems pointless to provide hooks in the API that allow for a custom interface, when fundamentally they may never be triggered in an otherwise compliant user agent. On Thu, 17 Dec 2009, Michael Nordman wrote: I don't think we'd have to delay the update job, just the delivery of any events associated with the appcache until 'load' has happened to get the desired effect. On Fri, 18 Dec 2009, Anne van Kesteren wrote: I believe we (Opera) found this is what at least some implementations are doing now and we do this as well. What Michael suggested makes sense and I suppose as the effects are indistinguishable in the end that (delaying either the events or the download process) should be fine. Done. All the events fired during the update process are delayed if the Document whose ApplicationCache they are targetting hasn't loaded yet. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 cut/copy
On Tue, 12 Jan 2010, Daniel Cheng wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard The current spec says that drop events should be fired while handling copy/cut operations. Is this intended? The clipboard is not a DOM element; it seems like it'd make sense only to fire the drop event for pastes. Oops. Fixed. It should have been dragstart, drag, and dragend. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How do sandboxed iframes interact with localStorage / sessionStorage / databases / etc?
On Sat, 9 Jan 2010, Adam Barth wrote: The following question came up in implementing the sandbox attribute in WebKit: [[ Description From Patrik Persson 2009-12-10 02:18:50 PST (-) [reply] This is a followup to bug 21288, which concerned the implementation of the HTML5 iframe sandbox attribute. How should WebKit interpret the HTML5 spec regarding sandboxed storage and databases? I believe the HTML5 spec does not say much explicitly on this, but rather relies on the origin sandboxing. Here is my interpretation. * I think sessionStorage would make sense with sandboxed origins. * I think localStorage would end up equivalent to sessionStorage in a sandboxed frame, making it somewhat less useful. (The unique origin of a sandboxed frame means, in my interpretation, that the same frame would not be able to access its own localStorage in another session.) * Similarly, I think a sandboxed database would be useful only within a session. The database could be reclaimed when the session ends. This defeats much of the purpose of databases, but perhaps it would still be useful for compatibility. The current implementation disables storage and databases in sandboxed frames. There is some more discussion in the thread for bug 21288, comments 43..49: ]] -- https://bugs.webkit.org/show_bug.cgi?id=32369 I think that disabling access to these APIs makes sense given that we disable access to cookies. They now raise a SECURITY_ERR if called when the origin is not a scheme/host/port tuple. (This also affects other times that the origin is a unique ID, e.g. data: URLs in some situations.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] question about the popstate event
If I'm understanding the bug correctly, Brady is suggesting not that a popstate event isn't fired when we navigate back to a document which has been unloaded from memory, but that the state object in that popstate event is null. As I understand it, the crux of his argument relates to the algorithm to update the session history with the new page [1]: 2) If the navigation was initiated for entry update of an entry 1) Replace the entry being updated with a new entry representing the new resource and its Document object and related state. I think he's arguing that the set of related state that is copied to the new entry does not contain the state object. His evidence for this is mostly textual: This state is referenced in other parts of the spec, and in those places, it's made clear that the state consists of scroll position and form fields: (From comment #4 at https://bugs.webkit.org/show_bug.cgi?id=33224) I believe state in this context is not referring to state objects, but rather persisted user state as set forth in 5.11.9 step 3: For example, some user agents might want to persist the scroll position, or the values of form controls. I think this is a good point from a textual perspective. But I think it's clear that we actually want to persist state objects across Document unloads. If we didn't care about this use case, we could do away with state objects altogether. A document could just call pushstate with no state variable and store its state objects in a global variable indexed by an identifier in the URL. When the page receives a popstate, it checks its URL and grabs the relevant state object. Simple. (This doesn't handle multiple entries with the same URL, but hash navigation doesn't handle that either, so that's not a big problem.) My point is that state objects are pretty much useless unless you persist them after the document has been unloaded. I also think the fact that we take the structured clone of a state object before saving it (and that structured clone forbids pointers to DOM objects and whatnot) indicates that the spec intended for state objects to stick around after document unload. Otherwise, why bother making a restrictive copy? (It should go without saying that if you're saving state objects across document unloads, you should also be saving the has same document relationships between history entries. That is, suppose history entry A calls pushstate and creates history entry B. Some time later, the document for A and B is unloaded, then the user goes back to B, which is re-fetched into a fresh Document. Then the user clicks back, activating A. We should treat the activation of A from B as an activation between two entries with the same document, and not re-fetch A.) Where the spec needs to be clarified to support this, I think it should be. But let's first agree that this is the right thing to do. -Justin [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher da...@chromium.org wrote: Hi, I've been discussing this issue with Brady Eidson over at https://bugs.webkit.org/show_bug.cgi?id=33224, and his interpretation appears to be different. (I think he may have convinced me too.) I'd really like some help understanding how pushState is intended to work and to see how that lines up with the spec. Also, assuming Brady is correct, then I wonder why pushState was designed this way. It seems strange to me that entries in session history would disappear when you navigate away from a document that used pushState. -Darin On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar justin.le...@gmail.com wrote: From my reading of the spec, I would expect the following steps: 5. Page A is loaded. 6. The load event for Page A is dispatched. 7. The popstate event for Page A is dispatched. I think this is correct. A popstate event is always dispatched whenever a new session history entry is activated (6.10.3). -Justin On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher da...@chromium.org wrote: I'd like to make sure that I'm understanding the spec for pushState and the popstate event properly. Suppose, I have the following sequence of events: 1. Page A is loaded. 2. Page A calls pushState(foo, null). 3. The user navigates to Page B. 4. The user navigates back to Page A (clicks the back button once). Assuming the document of Page A was disposed upon navigation to Page B (i.e., that it was not preserved in a page cache), should a popstate event be generated as a result of step 4? From my reading of the spec, I would expect the following steps: 5. Page A is loaded. 6. The load event for Page A is dispatched. 7. The popstate event for Page A is dispatched. Do I understand correctly? Thanks, -Darin
Re: [whatwg] question about the popstate event
On Tue, Jan 12, 2010 at 7:30 PM, Justin Lebar justin.le...@gmail.comwrote: If I'm understanding the bug correctly, Brady is suggesting not that a popstate event isn't fired when we navigate back to a document which has been unloaded from memory, but that the state object in that popstate event is null. As I understand it, the crux of his argument relates to the algorithm to update the session history with the new page [1]: 2) If the navigation was initiated for entry update of an entry 1) Replace the entry being updated with a new entry representing the new resource and its Document object and related state. I think he's arguing that the set of related state that is copied to the new entry does not contain the state object. His evidence for this is mostly textual: This state is referenced in other parts of the spec, and in those places, it's made clear that the state consists of scroll position and form fields: (From comment #4 at https://bugs.webkit.org/show_bug.cgi?id=33224) I believe state in this context is not referring to state objects, but rather persisted user state as set forth in 5.11.9 step 3: For example, some user agents might want to persist the scroll position, or the values of form controls. I think this is a good point from a textual perspective. Ah, yes... agreed. But I think it's clear that we actually want to persist state objects across Document unloads. If we didn't care about this use case, we could do away with state objects altogether. A document could just call pushstate with no state variable and store its state objects in a global variable indexed by an identifier in the URL. When the page receives a popstate, it checks its URL and grabs the relevant state object. Simple. (This doesn't handle multiple entries with the same URL, but hash navigation doesn't handle that either, so that's not a big problem.) My point is that state objects are pretty much useless unless you persist them after the document has been unloaded. Right! This is the very perspective I viewed pushState from, and it also seems to me that the feature is far less useful if state objects are not persisted after document unload. -Darin I also think the fact that we take the structured clone of a state object before saving it (and that structured clone forbids pointers to DOM objects and whatnot) indicates that the spec intended for state objects to stick around after document unload. Otherwise, why bother making a restrictive copy? (It should go without saying that if you're saving state objects across document unloads, you should also be saving the has same document relationships between history entries. That is, suppose history entry A calls pushstate and creates history entry B. Some time later, the document for A and B is unloaded, then the user goes back to B, which is re-fetched into a fresh Document. Then the user clicks back, activating A. We should treat the activation of A from B as an activation between two entries with the same document, and not re-fetch A.) Where the spec needs to be clarified to support this, I think it should be. But let's first agree that this is the right thing to do. -Justin [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher da...@chromium.org wrote: Hi, I've been discussing this issue with Brady Eidson over at https://bugs.webkit.org/show_bug.cgi?id=33224, and his interpretation appears to be different. (I think he may have convinced me too.) I'd really like some help understanding how pushState is intended to work and to see how that lines up with the spec. Also, assuming Brady is correct, then I wonder why pushState was designed this way. It seems strange to me that entries in session history would disappear when you navigate away from a document that used pushState. -Darin On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar justin.le...@gmail.com wrote: From my reading of the spec, I would expect the following steps: 5. Page A is loaded. 6. The load event for Page A is dispatched. 7. The popstate event for Page A is dispatched. I think this is correct. A popstate event is always dispatched whenever a new session history entry is activated (6.10.3). -Justin On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher da...@chromium.org wrote: I'd like to make sure that I'm understanding the spec for pushState and the popstate event properly. Suppose, I have the following sequence of events: 1. Page A is loaded. 2. Page A calls pushState(foo, null). 3. The user navigates to Page B. 4. The user navigates back to Page A (clicks the back button once). Assuming the document of Page A was disposed upon navigation to Page B (i.e., that it was not preserved in a page cache),
Re: [whatwg] question about the popstate event
On Jan 12, 2010, at 7:30 PM, Justin Lebar wrote: As I understand it, the crux of his argument relates to the algorithm to update the session history with the new page [1]: 2) If the navigation was initiated for entry update of an entry 1) Replace the entry being updated with a new entry representing the new resource and its Document object and related state. I think he's arguing that the set of related state that is copied to the new entry does not contain the state object. His evidence for this is mostly textual: This state is referenced in other parts of the spec, and in those places, it's made clear that the state consists of scroll position and form fields: (From comment #4 at https://bugs.webkit.org/show_bug.cgi?id=33224) I believe state in this context is not referring to state objects, but rather persisted user state as set forth in 5.11.9 step 3: For example, some user agents might want to persist the scroll position, or the values of form controls. I think this is a good point from a textual perspective. My debate with Darin has so far primarily been about how one reads the spec, and this is most certainly how I've read it. long rant about why state objects should survive document unload, and that state objects are pointless if they don't I think you're totally right. As I've been discussing the spec with Darin in email and the webkit.org bug I've basically come to the same conclusion. That said... Where the spec needs to be clarified to support this, I think it should be. But let's first agree that this is the right thing to do. The discussion between Darin and I was about my interpretation of the spec, what I implemented based on that interpretation, and how his interpretation was different. I think we're now in agreement on what it *should* be, I think the spec should be explicit about it, and I think the ambiguity between state, state object,, and persisted user state is what might've led us all to misread the other's positions. Entry with persisted user state is already used quite explicitly in two places, but needs application in key place at the end of 6.11.1. 2 - If the navigation was initiated for entry update of an entry: 1 - Replace the entry being updated with a new entry representing the new resource and its Document object and related state. The user agent may propagate state from the old entry to the new entry (e.g. scroll position). might read: 2 - If the navigation was initiated for entry update of an entry: 1 - Replace the entry being updated with a new entry representing the new resource and its Document object. If the entry being updated is a state object entry the user agent must propagate the state object to the new entry. The user agent may propagate persisted user state from the old entry to the new entry (e.g. scroll position). Thoughts? ~Brady PS: On a related note... If I'm understanding the bug correctly, Brady is suggesting not that a popstate event isn't fired when we navigate back to a document which has been unloaded from memory, but that the state object in that popstate event is null. My argument was actually indeed, that the event is not fired at all. But as I hit up the spec to present my reasoning why, I discovered that 6.11.9 step 10 basically says that popstate events are fired for *ANY* history traversal except for fragment scrolls between non-state-object entries. So my argument shifts to what you say - the state object in that event is null. This was just sloppy reading on my part. That we don't currently fire the popstate event in such cases is a WebKit bug that I have filed as https://bugs.webkit.org/show_bug.cgi?id=33571 -Justin [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher da...@chromium.org wrote: Hi, I've been discussing this issue with Brady Eidson over at https://bugs.webkit.org/show_bug.cgi?id=33224, and his interpretation appears to be different. (I think he may have convinced me too.) I'd really like some help understanding how pushState is intended to work and to see how that lines up with the spec. Also, assuming Brady is correct, then I wonder why pushState was designed this way. It seems strange to me that entries in session history would disappear when you navigate away from a document that used pushState. -Darin On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar justin.le...@gmail.com wrote: From my reading of the spec, I would expect the following steps: 5. Page A is loaded. 6. The load event for Page A is dispatched. 7. The popstate event for Page A is dispatched. I think this is correct. A popstate event is always dispatched whenever a new session history entry is activated (6.10.3). -Justin On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher da...@chromium.org wrote:
