On Nov 12, 2009, at 3:37 PM, Marius Gundersen wrote: > > > On Fri, Nov 13, 2009 at 8:16 AM, Brady Eidson <beid...@apple.com> wrote: > I should've responded to this more directly: > > On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote: > > > I think the use case I proposed is much better served by something > > like history.truncate(numBefore, numAfter), which would remove all but > > the numBefore entries before the current entry and the numAfter > > entries after the current entry. We'd subject this to the same-origin > > policy, of course, and stop removing entries in a direction as soon as > > we encountered an entry from another origin. > > 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. > > 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. > > 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. > > 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. > > 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: > > A1 A2 B1 *B2* B3 B4 C1 C2 > > 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: > > A1 A2 B1 *B2* B4 C1 C2 > > 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.
You're confusing the "same origin" policy with this API's inherent "Document object" policy. 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. ~Brady > Marius Gundersen
