[Webkit-unassigned] [Bug 28269] Inspector: Improve Cookie DataGrid to Show Hidden Data

[bugzilla-daemon at webkit.org]

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





--- Comment #17 from Joseph Pecoraro <joepeck02 at gmail.com>  2009-08-17 10:06:04 PDT ---
> - I don't see why JSValue JSInspectorBackend::deleteCookie needs to be custom.
> It can be generated.
> 
> - JSValue JSInspectorBackend::cookies can also be implemented in
> InspectorBackend and only have custom accessors (see
> InspectorBackend::highlight). Otherwise produces too much duplicated code.

This sounds like a good idea.  I'm rather new to this and I don't know the
differences between Custom and Non-Custom bindings.  It seems here that a
non-Custom is better, and if that is the case then I'm all for it.  Can you
point me to some reading, or some code to read, that would help me understand
IDL and how WebKit handles bindings?

> - InspectorController.cookies() should not be called synchronously from the
> frontend. It is actually not clear how it relates to
> InjectedScript.getCookies() that is asynchronous. Should latter call into it?

That is a good point.  Right now, InjectedScript.getCookies() is only there for
the fallback behavior, by which I mean for platforms that haven't implemented
CookieJar's getRawCookies().  You make a good point about making it async.

I can look into renaming the current version as
InjectedScript.fallbackGetCookies or something similar and make the current
version async with the clearer name.  The end goal is to have all the platforms
(or most) implement the new cookies functionality and all of the fallback code
can then be removed, but in the meantime they can still get some data
(name/value pairs) via the inspected page's document.cookie string.

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