This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 220201 - Users need to be able to easily discover the JS behind a dynamic node
Summary: Users need to be able to easily discover the JS behind a dynamic node
Status: NEW
Alias: None
Product: web
Classification: Unclassified
Component: Inspection (show other bugs)
Version: 7.3
Hardware: PC Windows 7
: P2 normal (vote)
Assignee: Martin Entlicher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-16 17:39 UTC by lxlyons
Modified: 2016-02-10 14:25 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description lxlyons 2012-10-16 17:39:53 UTC 
This was a definite hole in the workflow identified in the recent usability test. When selecting dynamically generated nodes, users have no obvious way of discovering and navigating to the JS that contributed the dynamic node.

Note I'm logging this as a P2 because it's a pretty big hole, but recognize that this may be too big to solve in the short term.
Comment 1 Petr Jiricka 2012-10-19 15:24:32 UTC 
Not sure if this information is available easily, but doesn't the Live HTML plugin possess this information? If it's only available through Live HTML, then would we need to guide the user to rerun the page and do the deeper analysis during this second run?
Comment 2 David Konecny 2012-10-23 02:03:18 UTC 
This is impossible to do. LiveHTML is trying to collection this type of information but the way it does it is very hacky - setting up DOM breakpoints and "stepping" thorough debugger on the background while pretending that application just runs; it is very obtrusive way which can easily clash with users workflow/intentions if not run in purely separate mode as LiveHTML does currently.

This is a topic which we should try to discuss with Chrome team and see whether there would be enough interest of providing this type of information on WebKit protocol level. Chrome Dev Tools users would benefit from it too.