| Summary: | Inspector should show workers that are loaded with the page | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yael <yael> |
| Component: | Web Inspector (Deprecated) | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | burg, bweinstein, joepeck, keishi, pfeldman, pmuellr, rik |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
|
Description
Yael
2010-01-29 14:17:14 PST
Off the top of my head thoughts: (a) every worker should basically have a separate window for itself - could have all the panels the current inspector window has, but doesn't need the Elements panel. Somewhere we would need to provide a list of the Workers that are available to debug. Perhaps a button next to the dock button which would present a list of "contexts" to open, which would be a list of the Workers and the main page, for now. Select one, it opens a window on that context. Calling these "contexts", since the "main page" needs to be there, perhaps IFrames could be also, as well as Workers. Who knows what other contexts may be invented later. (b) Just mix everything together in one inspector window. Long-term, this smells like it will get confusing, as more people use Workers (hence, option (a)). At a minimum, perhaps grouping the script list in the Scripts view by Worker would be good enough. To do (b), not clear how we'd handle having two paused contexts - say debugging something in the main page, as well as something in a worker. You'd also presumably have to have a context selector for Timeline, Profiles, and Console. I dont think seperate windows is correct. That sounds more ocnfusing to me. As far as resources loaded from a worker, I am not familar enough with works to know how that works. Pausing is simple. Pausing the main script pauses all contexts (halts their threads) for inspection. Similar to how pausing a multi-threaded program works in GDB/Xcode. You then have a thread switcher associated with the stack, so you can switch threads and see the different stacks. If resources can be loaded from a worker and are isolated from the main page (not shared via a cache, etc). Then we can have a context switch menu in Resource too (like I mentioned for scripts). But I suspect resources just load and share a cache with the main page, so they should just show in the same list. I don't see the need to seperate them. Scripts is where it is important to seperate them. And Profiles started from the panel should profile all contexts (threads), unless it is a console.profile()/profileEnd() instrumented area, then it should just profile that context it was called in. Is anybody going to work on this soon? (We had a guy interested in implementing). He is supposed to check in fake workers support soon. From my experience (I've done offline support for one of the large google app products), fake workers is more than enough in majority of cases. I don't lan too. I am intereded in seeing this fake worker stuff. *** This bug has been marked as a duplicate of bug 127634 *** |