| Summary: | Show DOM information as firebug console does | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Cliff <clifford.meece> |
| Component: | Web Inspector (Deprecated) | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | bweinstein, joepeck, keishi, pfeldman, pmuellr, rik, sam |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://cliffordmeece.com | ||
|
Description
Cliff
2009-12-02 12:15:21 PST
We show you DOM properties for the selected DOM element. But we don't have access to the Window or Document object. We need to fix that. One idea Sam had a while back was to show Window and Document in the element tree, at the root level with a divider then the DOM elements. This would avoid nesting the whole DOM tree and give these objects a special status. We would do this for iframes too, have the Window and Document inside the iframe element decorated in some way to disinguish them and have the regualr dom elements. That sounds like it might be ok. Having them nested in the element tree would be a nightmare though. I'm kinda a newbie to DOM in general though so I get confused about distinctions between DOM elements, Window, Document, etc. (In reply to comment #2) > One idea Sam had a while back was to show Window and Document in the element > tree, at the root level with a divider then the DOM elements. This would avoid > nesting the whole DOM tree and give these objects a special status. > > We would do this for iframes too, have the Window and Document inside the > iframe element decorated in some way to disinguish them and have the regualr > dom elements. The Window and Document would not be nested. They would be seperate with some decoration distinguishing them. Why loading UI with those, is dumping 'window' or 'document' in console and learning 'Drupal's properties not enough? Pavel, it would be useful to see the event listeners, and the prototype segregated properties. It's not merely an issue of reading Drupal docs to understand their properties. It's a top level object that many contributed modules use to store config information, and since Drupal is built around many modules, you ould potentially have 40 different modules, all with varying levels of documentation about what javascript variables they are setting, that it would help to just have a handy browser. Firebug does this extremely well and it doesn't pollute or clutter the ui as far as i can tell. They separate it from the elements browser as a separate tab. Beside the Drupal object, there may be other libraries added, all of which have a hierarchy of objects, properties, and functions. Just browsing my homepage, which is a typical drupal install, I see (with firebug) objects defined for Drupal, lightbox, jquery, addthis, tinymce, etc, etc. But I am interested in your suggestion of 'dumping window in console'. Can you tell me how to do that? Just type "window" with no quotes in the Console and hit return. Then expand the object to browse the properties. Awesome! thanks. I still think it would be nice to have it as a selectable ui element somewhere (unobtrusive of course). But as I said in the original bug report "I don't really care if it looks like firebug or not, I would just like a convenient place to get the information". Dumping the variable is an acceptable work around. If you decide to move forward with implementing it as a UI element, that would be great, but I'm happy for you close the bug otherwise since I now know where to get the info. (In reply to comment #8) > Just type "window" with no quotes in the Console and hit return. Then expand > the object to browse the properties. Closing as invalid, as this bug pertains to the old inspector UI and/or its tests. Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk. |