Confirmed users
496
edits
Remote Debugging Protocol: Difference between revisions
Jump to navigation
Jump to search
m
→Listing Top-Level Browsing Contexts: Note flaws in browsing-context / thread relationship.
mNo edit summary |
m (→Listing Top-Level Browsing Contexts: Note flaws in browsing-context / thread relationship.) |
||
| Line 340: | Line 340: | ||
<i>(This may not be the right information to provide in these packets; suggestions very welcome. The point here is to give the debugger enough information to select which context it would like to debug without having to do too many round trips. Round trips are bad for UI responsiveness, but large packets are probably not a problem, so whatever would help to add, we should add.)</i> | <i>(This may not be the right information to provide in these packets; suggestions very welcome. The point here is to give the debugger enough information to select which context it would like to debug without having to do too many round trips. Round trips are bad for UI responsiveness, but large packets are probably not a problem, so whatever would help to add, we should add.)</i> | ||
<i>There are other, more important ways this may be wrong-headed. In traditional Firefox, there is only one thread for all chrome and content. One can't attach to different tabs and then continue them independently; they're all sharing the same stack. This will still be true to some extent even when we have out-of-process content, because you'll necessarily have groups of tabs sharing a thread. The thread actor interactions described below seem like the right way to interact with a thread, but we need to explain how we select some parts of the browser to debug and others to ignore.</i> | |||
= Interacting with Thread-Like Actors = | = Interacting with Thread-Like Actors = | ||