On Tue, 28 May 2013, Brady Eidson wrote:
>
> The “unload a document” steps apparently don’t allow for the pagehide
> event to have “persisted” set to false.
Hm, yeah, it should only be set to true if /salvageable/ is true. Fixed.
> In the original design of these events and in WebKit’s impleme
On May 30, 2013, at 11:34 AM, Boris Zbarsky wrote:
> On 5/30/13 2:26 PM, Brady Eidson wrote:
>>> So how does your setup differ in a way that actually makes this
>>> impossible to implement?
>>
>> The design is that after pagehide returns, if the traversal is still
>> taking place and the page i
On 5/30/13 2:26 PM, Brady Eidson wrote:
So how does your setup differ in a way that actually makes this
impossible to implement?
The design is that after pagehide returns, if the traversal is still
taking place and the page is going into the cache, no further events
take place.
Yes, you said
On 5/30/13 2:24 PM, Brady Eidson wrote:
In WebKit, if you have an unload handler, you don’t go into the page cache.
This is also true in Gecko; I was talking about the events we dispatch,
not necessarily what a page can see.
-Boris
On May 30, 2013, at 10:38 AM, Boris Zbarsky wrote:
> On 5/30/13 1:04 PM, Brady Eidson wrote:
>> The long standing design goals and implementation of our page cache
>> prevents us from delivering these events to a page that was just sent
>> “pagehide with persisted set to true”.
>
> Actually, le
On May 30, 2013, at 10:31 AM, Boris Zbarsky wrote:
> On 5/30/13 1:04 PM, Brady Eidson wrote:
>> Correct. Of course note that pages that have been placed in the page
>> cache that are evicted have no visibility that the eviction occurred (at
>> least in WebKit)
>
> I believe this is also true i
On 5/30/13 1:04 PM, Brady Eidson wrote:
The long standing design goals and implementation of our page cache
prevents us from delivering these events to a page that was just sent
“pagehide with persisted set to true”.
Actually, let me try to clarify this a bit.
The way I would imagine logic lik
On 5/30/13 1:04 PM, Brady Eidson wrote:
Correct. Of course note that pages that have been placed in the page
cache that are evicted have no visibility that the eviction occurred (at
least in WebKit)
I believe this is also true in Gecko.
Let me ask you this - Are there any (reasonable) pages
On 5/30/13 12:41 PM, Brady Eidson wrote:
pageshow is a history traversal event, and not a visibility event. I
don’t see a guarantee in any spec that “pageshow” comes after the
document is actually visible.
It comes after it's visible in terms of document.visibilityState, for
pages not in backg
On May 29, 2013, at 6:36 PM, Boris Zbarsky wrote:
> Let's actually back up a second.
>
> What problem are you really trying to solve by changing the ordering? As I
> see it, right now the situation is as follows (in implementations, if not in
> the spec):
>
> 1) pagehide fires, with a boole
On May 29, 2013, at 5:34 PM, Boris Zbarsky wrote:
> On 5/29/13 4:30 PM, Brady Eidson wrote:
>> I see in the HTML spec that the step *before* firing pagehide is “set
>> the Document’s page showing flag to false,” but I can’t find language
>> that says pagehide fires *before* the page is actually
Let's actually back up a second.
What problem are you really trying to solve by changing the ordering?
As I see it, right now the situation is as follows (in implementations,
if not in the spec):
1) pagehide fires, with a boolean indicating whether at this point the
UA plans to place the pa
On 5/29/13 4:30 PM, Brady Eidson wrote:
I see in the HTML spec that the step *before* firing pagehide is “set
the Document’s page showing flag to false,” but I can’t find language
that says pagehide fires *before* the page is actually hidden, and
unload fires *after* the page is actually hidden.
On May 29, 2013, at 12:02 PM, Boris Zbarsky wrote:
>
>> I’ve tried these search terms and the only obviously relevant thing I
>> could find was
>> http://lists.w3.org/Archives/Public/public-web-perf/2012Feb/0111.html
>
> Uh...
> http://www.w3.org/Search/Mail/Public/search?keywords=pagehide&h
On 5/29/13 2:25 PM, Brady Eidson wrote:
So what happens when script calls dispatchEvent on a node that's in a
document that's in your page cache?
I believe the design is “nothing.”
That's a spec violation, then: there are no provisions in any DOM spec
for dispatchEvent on an EventTarget not
On May 28, 2013, at 10:11 PM, Boris Zbarsky wrote:
> On 5/29/13 12:55 AM, Brady Eidson wrote:
>>> This expectation was always wrong: events can be dispatched by script at
>>> any time to pages in the page cache.
>>
>> I'm sorry, who's page cache are you talking about?
>
> Gecko's, which initi
On 5/29/13 12:55 AM, Brady Eidson wrote:
This expectation was always wrong: events can be dispatched by script at any
time to pages in the page cache.
I'm sorry, who's page cache are you talking about?
Gecko's, which initially defined the pagehide/pageshow events. ;)
Page caches are (AFA
On May 28, 2013, at 12:46 PM, Boris Zbarsky wrote:
> On 5/28/13 2:02 PM, Brady Eidson wrote:
>> If a page receives “pagehide” with persisted set to true, it correctly
>> assumes that it might be revived at a later date with a pageshow event.
>> These pages do not expect any event dispatch betw
On 5/28/13 2:02 PM, Brady Eidson wrote:
If a page receives “pagehide” with persisted set to true, it correctly assumes
that it might be revived at a later date with a pageshow event. These pages do
not expect any event dispatch between the pagehide and the pageshow...
This expectation was a
While looking at page visibility, we noticed a couple of problems.
***First***
The “unload a document” steps apparently don’t allow for the pagehide event to
have “persisted” set to false. Step 5 states:
"Fire a trusted event with the name pagehide at the Window object of the
Document, but wit
20 matches
Mail list logo
