[Webkit-unassigned] [Bug 24529] Add support in Web Inspector for examining/changing data for HTML5 offline-Web-applications (application cache)

[bugzilla-daemon at webkit.org]

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


Joseph Pecoraro <joepeck at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs at apple.com




--- Comment #28 from Joseph Pecoraro <joepeck at webkit.org>  2010-04-26 14:41:06 PST ---
(In reply to comment #27)
> Thanx for putting a .h file in there for this stuff.

Sure. It makes the most sense as soon as the frontend starts making requests
for resources.


> What's the lifetime of the inspector controller/agents compared to the
> frames/pages/documents that are being inspected? That would help me understand
> what's going here quite a lot.

Pavel could best answer that. I'm still learning it myself and I would also
appreciate an in depth answer! =)


> I think it may be confusing to co-mingle the display of resources loaded on
> behalf of an update job running in the background with resources directly
> loaded by the page. I hope you plan on visually differentiating them in the UI.
> You've seperated out the call for the manifest resource having been loaded by
> the update job, but you haven't separated out a call for other resources being
> loaded by the update job. Having separate entry points into the 'inspector'
> would make it easier to differentiate them further downstream in the resources
> tab of the inspector. Have you considered adding another method for...
>   void didReceiveResourceResponse(...)
> ... to this new class.

Correct. This is the area of this patch I bombed (see above comments). I also
condensed most of the work I did, but not all, into this "part 1" patch. Many
of the points you raised I was hoping to address in a "part 2" or later patch,
but since I haven't made clear my plans it may be confusing. I also rushed to
get a patch up because I had promised one this weekend and so it could give
Kavita an idea of what I had done and how it could be worked with.

Briefly. In Part 1 I wanted at the very least for the Manifest file to show up
in the Resources panel, as a typical resource. In a Part 2 I would start
dealing with Cached Resources and I was toying with the idea of adding a new
InspectorResource type / category "AppCache". That way you could filter them in
the Resources Panel, and they would get their own color. At this point a
separate didReceiveResourceResponse would be necessary, and the seemingly
useless didReceiveManifestResponse would start to do something.



> Also, update jobs actually can be running on behalf of several pages. Looks
> like the plumbing you've got only routes the response info to one of those
> pages, so if your looking at the 'right' inspector view, you'll see them and if
> not you'll be out of luck i think. I'm not sure how to reconcile that with the
> per-page inspector interface really, except maybe to push the response info to
> all of the relevant inspectors.

Good point. This is a very strong argument for a "Browser Inspector" entity
above a "Web Inspector". Pavel was talking about this the other day. I don't
think there is currently an object that knows about multiple
InspectorControllers. I could attempt such an object in the next patch.


> The manifest url should probably show up somewhere in the UI very prominently.
> Maybe that could be the label on the left-hand-side?

How about in the screenshot where I say "manifest or domain"? I agree that the
manifest name would be very convenient. I will have to experiment.


> If there is no appcache, I think you can just have an empty APPLICATION CACHE
> section on the left-hand-side. (I think that's in keeping with how some of the
> others work when empty).

Yes, this was mentioned above and I plan to do that. There is already a few
FIXMEs.

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