[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
Sun Mar 13 17:20:58 PDT 2011


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





--- Comment #24 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2011-03-13 17:20:58 PST ---
(In reply to comment #23)
> (In reply to comment #22)
> > Should I withdraw this API and the CL in progress at http://codereview.chromium.org/6627063/?
> 
> Er, I meant to add: Is it okay if I implement this entirely in the Chromium port of the API (i.e., in ChromeClientImpl; thus not needing any #defines), or would you like to see this in WebCore (#defined out for other clients for now)?

In general, I think we are best served when our implementation does not suffer from unusual constraints like this.  It is better to do the cleanest possible implementation even if it has to be behind #defines.  That way, your code will be easier to maintain in the future.

At the very least, I think it should be completely implemented in WebKit and there should be accompanying layout tests.  This way, once we prove that it is safe for the web, the cost for other WebKit ports to adopt this behavior change will be as close to zero as possible.

If we don't do the above, then there will be additional work to redo the patch to be a proper WebCore patch.  That adds a more cost, and there will be less incentives on our part to do this work, so we should just do it properly from the start.  Pros: less engineering work, Cons: ugly #ifdefs.  Seems like the pros outweigh the cons.

-- 
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