>> > I've also made back()/forward()/go() not work during the document's
>> > unload handler, since that could be used for griefing. I'm tempted to
>> > disable it entirely for all docs a la alert(), but I've no idea if
>> > that's Web- compatible and I suspect not.
>>
>> I don't know what you mean
reasons other than stop(). For
> example, document.open(), navigation, the user hitting "STOP", going
> back() in history, etc. In particular, "The End" can block on network, so
> we definitely don't want to require that UAs do that when you close a tab,
> fo
It's time for another episode of everyone's favorite show: "Find the
session history spec bug". Today's episode is a double-header of
related issues.
== Issue #1 ==
Suppose an attack page evil.html controls a separate frame F (e.g.
evil.html frames F, evil.html opened F as a popup window, or vic
> From an author's point of view, there's no such thing as the
> document's original URI and, unless you're a nerd, you've never heard
> of the base URI. There's just the document's URI, modified by
> pushState.
>
> From this point of view, I'd say it's less surprising that relative
> URIs would b
On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson wrote:
> On Wed, 15 Feb 2012, Justin Lebar wrote:
>> > - It sets "the document's current address" to ".../page.html#foo".
>>
>> Well, this is pretty bad. document.location is the document&#x
t.location from
page2.html to page.html#foo, which I certainly wouldn't expect (and
does not match implementations).
-Justin
[1] The href attribute [of document.location] must return the current
address of the associated Document object, as an absolute URL.
On Wed, Feb 15, 2012 at 3:50 PM, Ian
Hixie's explanation of why the event should be sync makes sense to me.
I recall that Olli had an objection other than this race condition,
but now I can't find the e-mail!
On Mon, Nov 7, 2011 at 11:39 PM, Jonas Sicking wrote:
> On Wed, Mar 23, 2011 at 5:37 PM, Ian Hickson wrote:
>>
>> I'm study
elow, since I have a bad habit of deleting these
test files right before someone else wants to look at them).
Ian, how hard do you think it would be to spec changing the base and
resolve the issues with that?
-Justin
#foo
?foo
foo
pushState
to new file
pushState to new directory
On Tue, Jul 19,
The document base URL [1] is used when fetching resources.
Right now, if a page doesn't have a element, the document base
URL is set to the document's address. (I'm going to call this the
"document's original address".) The document's original address does
not change when you call pushState; on
The document base URL [1] is used when fetching resources.
Right now, if a page doesn't have a element, the document base
URL is set to the document's address. (I'm going to call this the
"document's original address".) The document's original address does
not change when you call pushState; on
> The problem with option B is that pages can't display correctly until
> the load event fires, which can be quite late in the game what with
> slow loading images and ads. It means that if you're on a page which
> uses state, and reload the page, you'll first see the page in a
> state-less mode wh
4: https://bugzilla.mozilla.org/show_bug.cgi?id=615501
On Mon, Feb 7, 2011 at 5:07 PM, Jonas Sicking wrote:
> On Sun, Feb 6, 2011 at 10:18 AM, Justin Lebar wrote:
>>> 1) Fire popstates as we currently do, with the caveat that you never
>>> fire a stale popstate -- that is, if
I don't know if this is something we can get done in time for FF4, but
I can see.
-Justin
On Wed, Feb 2, 2011 at 3:37 PM, Justin Lebar wrote:
> Oh, I think I now understand what Jonas meant.
>
> Proposal A, as I understand it:
>
> 1) Don't fire an initial popstate, bec
ewer changes. (We could,
of course, add the DOM property later -- it's orthogonal to proposal
B, but required by proposal A.)
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#traverse-the-history
On Wed, Feb 2, 2011 at 2:48 PM, Jonas Sicking wrote:
> On Wed,
, then
I think what Jonas proposed is reasonable. I just wish we had
something with fewer gotchas.
-Justin
On Wed, Feb 2, 2011 at 2:15 PM, Jonas Sicking wrote:
> On Wed, Feb 2, 2011 at 2:05 PM, Justin Lebar wrote:
>> I'm a bit uncomfortable with this behavior, since it seems that
I'm a bit uncomfortable with this behavior, since it seems that having
replaceState cancel the initial popstate is at least somewhat
surprising.
How is this better than never firing an initial popstate?
-Justin
On Mon, Jan 31, 2011 at 6:32 PM, Jonas Sicking wrote:
> On Thu, Dec 23, 2010 at 6:18
> It might also help if the event wasn't called "popstate", since that
> implies a 1:1 relationship with pushState calls, but you can already
> get popstate events without corresponding pushState calls.
> "historytraversal" perhaps?
I think we've decided here that the time for major changes to thi
-nopkg.html
-Justin
On Mon, Aug 9, 2010 at 1:40 PM, Justin Lebar wrote:
>> Can you provide the content of the page which you used in your whitepaper?
>> (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820)
>
> I'll post this to the bug when I get home toni
throttles. But I also
> know that doing so worsens the user experience by delaying the time to first
> paint. So - is it possible to measure both times? I'm betting
> time-to-paint goes through the roof with resource bundles:-)
> If you provide the content, I'll try to run
ot a small hack like resource packages.
-Justin
On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor wrote:
> On Fri, Aug 6, 2010 at 7:40 PM, Justin Lebar wrote:
>> I think this is a fair point. But I'd suggest we consider the following:
>>
>> * It might be confusing for resour
e
problem of duplicated downloads. I don't think resource packages can
fix it with any caching policy.
-Justin
On Fri, Aug 6, 2010 at 2:17 PM, Aryeh Gregor wrote:
> On Tue, Aug 3, 2010 at 8:31 PM, Justin Lebar wrote:
>> We at Mozilla are hoping to ship HTML resource packages in Firef
On Fri, Aug 6, 2010 at 12:46 AM, Christoph Päper
wrote:
> Justin Lebar:
>> Christoph Päper wrote:
>>>
>>> Why do you want to put this on the HTML level (exclusively), not the HTTP
>>> level?
>>
>> If you reference an image from a CSS file and incl
> If you do want it to work the same then you'll need to hook into the
> parser and ignore dynamic updates.
Indeed. And since I explicitly *do* want dynamic updates, it'll need to change.
Thanks.
On Wed, Aug 4, 2010 at 1:32 PM, Philip Taylor wrote:
> On Wed, Aug 4, 2010
> Brett Zamir wrote:
> 1) I think it would be nice to see explicit confirmation in the spec that
> this works with offline caching.
Yes. I'll do that.
> 2) Could data files such as .txt, .json, or .xml files be used as part of
> such a package as well?
> 3) Can XMLHttpRequest be made to refer
We at Mozilla are hoping to ship HTML resource packages in Firefox 4,
and we wanted to get the WhatWG's feedback on the feature.
For the impatient, the spec is here:
http://people.mozilla.org/~jlebar/respkg/
and the bug (complete with builds you can try and some preliminary
performance numbe
n
On Wed, Jun 23, 2010 at 11:15 AM, Justin Lebar wrote:
> Safari 5 and Chrome 5 recently shipped the history.pushState and
> replaceState methods. Firefox 4 will also include those methods when
> it ships.
>
> pushState and replaceState take three arguments: An opaque data
>
nly after a
replaceState.
http://people.mozilla.org/~jlebar/test/general/pushstate-post.html
-Justin
On Fri, Jul 16, 2010 at 3:11 PM, Aryeh Gregor wrote:
> On Fri, Jul 16, 2010 at 1:13 PM, Justin Lebar wrote:
>> We have a minor issue using replaceState in Bugzilla that we may or
>> m
We have a minor issue using replaceState in Bugzilla that we may or
may not want to fix up in the spec.
When you make a change to a bug, Bugzilla POSTs you from a nice-looking URL, say
https://bugzilla.mozilla.org/show_bug.cgi?id=577720 ,
to
https://bugzilla.mozilla.org/process_bug.cgi
Section 6.5.9.1 [1] says:
> The popstate event is fired when navigating to a session history entry that
> represents a state object.
In contrast, section 6.5.9 [2] indicates in step 10 that a popstate
event is fired if the history entry represents a state object or the
first entry for a document
Safari 5 and Chrome 5 recently shipped the history.pushState and
replaceState methods. Firefox 4 will also include those methods when
it ships.
pushState and replaceState take three arguments: An opaque data
object, a title, and an optional URL. Currently, Safari and Chrome
both ignore the title
> On Thu, Jan 14, 2010, Hixie...oh dear.
>> On Tue, 18 Aug 2009, Justin Lebar wrote:
>> (An attempt at describing how pushstate is supposed to be used.)
> That's not quite how I would describe it. It's more that each entry in the
> session history has a URL and opt
> 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.
>
> 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 activate
> - allow for self-contained components to handle own state
> [not supported by spec, *2]
I'm generally in favor of a minimalistic approach to this kind of
thing. Ideally, we'd be able to compose independent components using
the API, but I'm not convinced that it's worth the complexity that
woul
re suggesting is what the implementation
> that Justin Lebar has written for Firefox does.
Yes, with my patch, the forward button is never active after a
pushState. It wasn't an intentional deviation from the spec, but I
agree with Darin's reasoning: If pushState is a replacement for
On Mon, Nov 23, 2009 at 6:46 PM, Ian Hickson wrote:
> On Mon, 23 Nov 2009, Justin Lebar wrote:
>> I'm not sure I agree. It seems to me that if you set the page's URL,
>> it's likely that you'll want to change the state object (if you're not
>> st
On Mon, Nov 23, 2009 at 5:01 PM, Ian Hickson wrote:
> On Fri, 13 Nov 2009, Justin Lebar wrote:
>> On Thu, Nov 12, 2009 at 5:43 PM, Ian Hickson wrote:
>> > The idea is that the string you would put into the back button or
>> > history menu is not the same as the st
On Sat, Nov 14, 2009 at 5:23 PM, timeless wrote:
> what if pushState returned a value which could be passed to clearState?
I'm not sure how this would work. What would clearState do with that value?
> (i can't find clearState in
> http://www.whatwg.org/specs/web-apps/current-work/#dom-history-p
On Thu, Nov 12, 2009 at 5:43 PM, Ian Hickson wrote:
> The idea is that the string you would put into the back button or history
> menu is not the same as the string you would put into the title bar or
> bookmarks (i.e. not the same as ).
That doesn't seem too unreasonable, but I think it's strang
On Thu, Nov 12, 2009 at 1:08 PM, Olli Pettay wrote:
> On 11/12/09 10:00 PM, Justin Lebar wrote:
>>
>> Perhaps a better idea is leaving this whole issue to the UA, which
>> could collapse all the entries from a single origin in the UI. Then
>> we wouldn't need e
As I alluded to in the thread "AJAX History Concerns," I'm not
convinced that we need the history.clearState() function.
I haven't been able to come up with a compelling case where a page
would use this. I guess the idea is that I'm on Google Maps, which is
using pushState to make a history entry
> "The title [argument to pushState] is purely advisory. User agents might use
> the title in the user interface."
>
> But unlike the URL which actually changes in the Document object and is
> therefore exposed to the DOM, this "purely advisory" title change is hidden
> from the DOM. I'm questi
In section 6.10.2:
"The pushState(data, title, url) method adds a state object to the
history." perhaps should be "... adds a state object *entry* to the
history."
"The replaceState(data, title, url) method updates the current entry
in the history to have a state object." perhaps should be
"The r
To be clear, I'm not suggesting that pushState obviates the need for
global script. My point is that pushState is useful in its own right,
with our without global script.
Without pushstate, you can't make a non-hash navigation without
hitting the network. Even if you're clever and store all of J
> Dimitri Glazkov wrote:
> But more to the point, I think globalScript is a good replacement for
> the pushState additions to the History spec.
I'm not sure I agree. pushState lets you change the URI very quickly,
without doing any kind of navigation at all. To emulate a pushSate
with globalScri
Mike Wilson wrote:
> The result is that the address bar URL can't be trusted, as
> any page on the site can impersonate any other without
> consent from that page or part of the site?
Someone will correct me if I'm wrong, but I think this is already
pretty much the case with today's same-origin po
Mike Wilson wrote:
> It would be interesting to see a concrete
> example on how you intend the dynamics of your solution to
> work. It would be great if you could outline the different
> events and method calls used (in order) to save and restore
> the history state object in the following situatio
Mike Wilson wrote:
> What you're essentially saying here is that when restarting
> the browser, you will also restore history data, correct?
>
> For tabs that were open when the browser was closed, this
> will mean that these will reappear after restart with full
> history, being able to go Back an
> Sorry, it seems we are not talking about the same application.
> Jonas referred to attachment pages in your bug database, which
> I assumed would f ex be a page like this one:
> https://bugzilla.mozilla.org/attachment.cgi?id=386244&action=edit
> (The textarea in this app is not created onload, it
> Overall, I think preserving history API information when restoring sessions
> is a good thing. My only concern is whether web developers will program in
> such a way that this works. Unless ALL state will need to be either saved
> in the history API or reconstructible from that information, bad
ry state to something unserializable? (I guess that's what you're
> already doing?)
Right now, I just serialize to JSON and throw an exception if that
fails. I don't have a problem continuing to do that, at least until
we get the structured clone thing sorted out.
-Justin
>
> I guess this is just a vision about what the developer really
> wants to do, or are you thinking of any solutions that would
> actually allow changing path (or query string) without loading
> a new Document?
The pushState function as currently specified allows you to do
precisely this. History.
On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlow wrote:
> but here it seems like everything can just stay in memory...right?
My thought was that if you had a tab open and restarted the browser,
that the state objects would be there after the restart, so we'd have
to serialize to disk. I also thought
I'm in the process of implementing the HTML5 History API
(History.pushState(), History.clearState(), and the PopState event) in
Firefox. I'd like to discuss whether the API might benefit from some
changes. To my knowledge, no other browser implements this API, so
I'm assuming we have freedom to m
t various font sizes. :-(
>
> On Thu, 6 Aug 2009, Justin Lebar wrote:
>>
>> Happens to me on Ubuntu 9.04 with FF 3.5.2.
>>
>> Screenshot at [1] http://stanford.edu/~jlebar/moz/screen1.png
>
> Do either of you have a minimum font size pr
>> That being said, inline spec comments sound interesting.
> I'm not quite sure what the
> UI would look like, but if anyone has any ideas, feel free to e-mail me
> directly and we can figure something out. (This would be exceedingly
> useful once we're in last call in a few months.)
Ian,
Other
> What does IE do in these two examples?
It appears that IE8 has the following behavior:
>>
start = 4
>>
start = 1
Test at http://stanford.edu/~jlebar/moz/list.html
-Justin
On Tue, Jul 14, 2009 at 12:43 AM, Jonas Sicking wrote:
> On Thu, Jun 18, 2009 at 9:33 AM, Smylers wrote:
>> It als
57 matches
Mail list logo
