<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 12, 2009, at 3:37 PM, Marius Gundersen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Fri, Nov 13, 2009 at 8:16 AM, Brady Eidson <span dir="ltr"><<a href="mailto:beidson@apple.com">beidson@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I should've responded to this more directly:<br>
<div class="im"><br>
On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote:<br>
<br>
> I think the use case I proposed is much better served by something<br>
> like history.truncate(numBefore, numAfter), which would remove all but<br>
> the numBefore entries before the current entry and the numAfter<br>
> entries after the current entry. We'd subject this to the same-origin<br>
> policy, of course, and stop removing entries in a direction as soon as<br>
> we encountered an entry from another origin.<br>
<br>
</div>The History object is - quite purposefully - very limited in scope and abilities. Today, it gives the ability to navigate back and forward a number of steps. Period.<br>
<br>
The pushState() API adds a very limited way of adding new items programatically. clearState() also adds the ability for a script to remove entries, but only ones that it added. Period.<br>
<br>
Same-origin policy be damned, I really don't like the idea of a script being able to remove items that it didn't add.<br>
<br>
As I said in my previous reply, I think it might be useful to give a more fine-grained version of "clearState()", but that could always be added later if there's demand. And I still think it should be limited to affecting the string of the Document object's entries.<br>
</blockquote><div><br>I don't think the history.truncate function proposed would be able to affect other Document object's entries. So for example, if the current history looks like this:<br><br>A1 A2 B1 *B2* B3 B4 C1 C2<br>
<br>Then you can only call history.truncate(1, 2). If you call it with a higher number in either parameter, then you will get a same origin exception. If the numbers are smaller though, it would still work. For example, calling history.truncate(0,1) would leave the following in your history:<br>
<br>A1 A2 B1 *B2* B4 C1 C2<br><br>I think this is the usecase clearState is designed for, but it's just not implemented in a very good way. This would not add a lot of extra work, and wouldn't complicate it for the user. truncate could also be called with no parameters, in which case it would clear the entire Document object's history, similarly to clearState.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></div></blockquote><div><br></div>You're confusing the "same origin" policy with this API's inherent "Document object" policy.</div><div><br></div><div>Document objects A, B, and C could all be from the same origin. I'm asserting that even with that qualification, Document B should not be able to remove entries for Document A and Document C.</div><div><br></div><div>~Brady<br><br><blockquote type="cite"><div class="gmail_quote"><div>Marius Gundersen<br></div></div>
</blockquote></div><br></body></html>