[Webkit-unassigned] [Bug 56203] Web Inspector: Allow access to rendered content in Network tab

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 11 10:12:58 PST 2011


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





--- Comment #1 from Patrick Mueller <pmuellr at yahoo.com>  2011-03-11 10:12:58 PST ---
I assume you are specifically talking about rendering HTML content from an XHR request "inline" in the Network panel's Content pane, like images are rendered.

I suspect the result isn't going to be terribly pleasing.  I'd guess most folks XHR'ing HTML are getting back HTML that they are injecting into the current page (via innerHTML), and individually rendered content like this isn't going to have any of that context - CSS style rules, for instance.

Another issue is JS embedded in the HTML.  I'm leery of letting JS code run in an embedded view like that.  I suppose the actual implementation of something like this would throw the HTML into an iFrame, and so you could get some measure of security.  But you'll also have JS contextual issues - presumably JS code XHR'd might reference objects that exist in the page that issued the XHR - and of course not much can be done about those.

Just my initial thoughts, there.

I think if I really wanted to do this, I'd set up something in the page itself, to render that content in some debug/diagnostic area of the screen.  Which you'd only enable for development.

If you're using Safari, there's a handy menu item Develop / Show Snippet Editor that you could dump your XHR content into.  I just tried this with a GitHub page, where I started at a top-level project, and traversed to a file with the new slidy single-page thingee at GitHub.  This gives you HTML content for that file content, which it gets via XHR.  Select that content, paste into the Snippet Editor.  The result isn't terribly useful to me, certainly doesn't match what's actually rendered on the page at all.

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