parsed, so the alert may or may not happen.
Yeah, this is an oversight as specced. Fixed.
On Sun, 16 Sep 2012, Justin Lebar wrote:
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 vice
versa).
We discovered
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 by the last
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 break
the current
address of the associated Document object, as an absolute URL.
On Wed, Feb 15, 2012 at 3:50 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 20 Jul 2011, Justin Lebar wrote:
The spec as written decides whether a link is a same-resource
reference or not based on comparing the URLs
On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson i...@hixie.ch 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's current
address [1]. So clicking #foo changed
On Tue, Jul 19, 2011 at 5:35 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 27 Apr 2011, Justin Lebar wrote:
The document base URL is used when fetching resources.
Right now, if a page doesn't have a base element, the document base
URL is set to the document's address. (I'm going to call
The document base URL [1] is used when fetching resources.
Right now, if a page doesn't have a base 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;
wrote:
On Sun, Feb 6, 2011 at 10:18 AM, Justin Lebar justin.le...@gmail.com wrote:
1) Fire popstates as we currently do, with the caveat that you never
fire a stale popstate -- that is, if any navigations or
push/replaceStates have occurred since you queued the task to fire the
popstate, don't
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 while
.
-Justin
On Wed, Feb 2, 2011 at 3:37 PM, Justin Lebar justin.le...@gmail.com wrote:
Oh, I think I now understand what Jonas meant.
Proposal A, as I understand it:
1) Don't fire an initial popstate, because this causes stale popstates
when pushState is called before the popstate.
2) Expose
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 jo...@sicking.cc wrote:
On Thu, Dec
.
-Justin
On Wed, Feb 2, 2011 at 2:15 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Feb 2, 2011 at 2:05 PM, Justin Lebar justin.le...@gmail.com wrote:
I'm a bit uncomfortable with this behavior, since it seems that having
replaceState cancel the initial popstate is at least somewhat
surprising
, Justin Lebar justin.le...@gmail.com wrote:
So during loading, any script that wants to know what the initial (or
current) state is does not need to wait for the first popstate, but
can simply grab the state and go.
Yeah, I think it's too late to move to this approach.
Even if we also include
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 this API
, not a small hack like resource packages.
-Justin
On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Fri, Aug 6, 2010 at 7:40 PM, Justin Lebar justin.le...@gmail.com wrote:
I think this is a fair point. But I'd suggest we consider the following:
* It might be confusing
goes through the roof with resource bundles:-)
If you provide the content, I'll try to run some tests. It will take a few
days.
Mike
On Mon, Aug 9, 2010 at 9:52 AM, Justin Lebar justin.le...@gmail.com wrote:
On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.com
wrote
-nopkg.html
-Justin
On Mon, Aug 9, 2010 at 1:40 PM, Justin Lebar justin.le...@gmail.com 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 tonight
On Fri, Aug 6, 2010 at 12:46 AM, Christoph Päper
christoph.pae...@crissov.de wrote:
Justin Lebar:
Christoph Päper christoph.pae...@crissov.de 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 include
.
-Justin
On Fri, Aug 6, 2010 at 2:17 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Tue, Aug 3, 2010 at 8:31 PM, Justin Lebar justin.le...@gmail.com wrote:
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
Brett Zamir bret...@yahoo.com 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
at 9:01 PM, Justin Lebar justin.le...@gmail.com wrote:
What happens if the document contains multiple html elements (not
all the root element)? (e.g. if it's XHTML, or the elements are added
by scripts). The packages spec seems to assume there is only ever one.
The packages attribute should work
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
On Wed, Jun 23, 2010 at 11:15 AM, Justin Lebar justin.le...@gmail.com 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
object
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
) warns on a refresh only 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 simetrical+...@gmail.com wrote:
On Fri, Jul 16, 2010 at 1:13 PM, Justin Lebar justin.le...@gmail.com wrote:
We have a minor issue
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
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 optionally some data. The data can
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
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
you are 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 the
hash
On Mon, Nov 23, 2009 at 5:01 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 13 Nov 2009, Justin Lebar wrote:
On Thu, Nov 12, 2009 at 5:43 PM, Ian Hickson i...@hixie.ch 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
On Mon, Nov 23, 2009 at 6:46 PM, Ian Hickson i...@hixie.ch 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
storing all your data in the URL
On Sat, Nov 14, 2009 at 5:23 PM, timeless timel...@gmail.com 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
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 questioning the
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
On Thu, Nov 12, 2009 at 1:08 PM, Olli Pettay olli.pet...@helsinki.fi 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 either function.
How
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
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
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
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
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=386244action=edit
(The textarea in this app is not created onload, it is
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 and
On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlowjor...@chromium.org 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
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.
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
On Thu, Aug 20, 2009 at 11:05 AM, Justin Lebar
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
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
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 preference set?
--
Ian Hickson U+1047E
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:
ol start=+4
start = 4
ol start=H2SO4
start = 1
Test at http://stanford.edu/~jlebar/moz/list.html
-Justin
On Tue, Jul 14, 2009 at 12:43 AM, Jonas Sickingjo...@sicking.cc wrote:
On Thu, Jun 18, 2009
51 matches
Mail list logo
