[Webkit-unassigned] [Bug 55844] Expose page dismissal event status through the WebKit API for chromium

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 11 15:07:08 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=55844





--- Comment #20 from Sreeram Ramachandran <sreeram at google.com>  2011-03-11 15:07:08 PST ---
(In reply to comment #19)
> (From update of attachment 84911 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=84911&action=review
> 
> > Source/WebKit/chromium/public/WebFrame.h:370
> > +    virtual bool pageDismissalEventBeingDispatched() const = 0;
> 
> have the events already been dispatched or are they just about to be dispatched?
> usually, we name methods like this using the "did" or "will" prefix.
> 
> willDispatchUnloadEvents or didDispatchUnloadEvents would be a good choices here.

It's actually in the "midst" of being dispatched. I.e., the FrameLoader has told the frame to dispatch the unload event; the event may block (e.g.: if there's an alert() within the event handler). Once the event handlers are done, the dispatch is "done". This API mirrors the method of the same name in FrameLoader. See how the underlying variable is set and unset at:
http://trac.webkit.org/browser/trunk/Source/WebCore/loader/FrameLoader.cpp#L377(for the unload event)
http://trac.webkit.org/browser/trunk/Source/WebCore/loader/FrameLoader.cpp#L2926 (for the beforeunload event)

> also, i'm a bit confused as to how this will be used.  if the beforeunload dialog
> is cancelled (i.e., if the new navigation is cancelled because the user wanted to
> stay on the page), then how will the embedder know that?

This doesn't affect the beforeunload dialog. I.e., only the actual onbeforeunload() and onunload() handlers (and not the "stay or leave" dialog) are considered to be "page dismissal event" in progress. Sequence of events (as per line 2926 in FrameLoader.cpp):
1. set m_pageDismissalEventBeingDispatched = true.
2. call onbeforeunload().
3. // perhaps it fires an alert(), which is where this API will be useful.
4. onbeforeunload() returns a value (see step 6).
5. set m_pageDismissalEventBeingDispatched = false.
6. if the return value was not NULL, dispatch the "stay or leave" dialog.

> also, i don't see why this behavior change wouldn't be implemented entirely within
> webkit.  i see no reason for their to be a chromium side to this behavior change.
> why do you need a webkit api?

I think the decision on whether alert()s should be ignored during unload events should be handled on the Chromium side. Safari and other webkit clients may not want to disable alerts (which is the current behaviour in all browsers). In addition, even in Chromium, we don't always want to ignore alerts (e.g.: I think extension_host doesn't want to).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list