This can only be possibly with a shared toolbox. For example, you could see the order of console.log calls between the original tab and the popup. in some panels, you may care about the execution order between the two documents.You will typicaly not have two distinct set of breakpoints between the two docs. If you set a breakpoint we have a strong guarantee that it is applied to the two documents. the toolbox is the same between the two documents, so that the panels state is 100% identical.You may as well think that a new toolbox dedicated to the popup as you evaluate in it and see its document in the inspector. This particular feature makes it hard to know that's actually the same toolbox. It allows to automatically display the right document in the inspector, or change the evaluation context of the console. I'm using the new target selection feature (the iframe dropdown) to automatically select the popup document or the original tab document when moving between the two tabs in Firefox UI. In order to make that more usable, I ended up introducing some non-trivial code to move around the toolbox between the two tabs (original tab and popup's tab). I'm implementing the second option of comment 10: debug the popup from the original tab's toolbox, so that both the original tab and the popup are debugged via the same toolbox. As real popup, without browser chrome, can't have any toolbox. If popups, were still opening real popups, this would actually be a nice UX. Especially given that we now force loading all popups to new tabs. This is probably easier to implement, but may be not the best UX. This may help reproduce some bug which are race conditions as we wouldn't change significantly the timings of the popup load.ĭoing this sounds like a one week or two task.īut unless the Toolbox is displayed as a Window, this behavior can probably be confusing. To do that, we would only have to relax the checks where we only accept WindowGlobal matching the watcher's browserId.ĭoing this wouldn't require to pause the new popup while the toolbox is loading. We would leverage nicely all the work we did for fission. The original tab's toolbox, from which we opened the popup, would be able to debug the popup. how to synchronize server and client with two servers and two clients (one pair per toolbox!)īut again, even if fission did not make this easier to implement, it made it clearer by forcing use to better understand key points.how to spawn a new toolbox and how it initializes itself.most likely once Toolbox.open resolves.ĭoing this sounds like a 2 weeks and more task. Then, in parallel to that we should open a new toolbox, spawning its own new Watcher and DevToolsFrame JS Window Actor,Īnd will resume the thread once "the toolbox is initialized enough". Work from bug 1717005 probably helped understand platform API about how to pause a given thread. if the new WindowGlobal is a new popup related to our browserId, then.if the new WindowGlobal's browserId is different from the current watcher, we won't instantiated a new target, but,. Then, we should probably have some code in DevToolsFrameChild.handleEvent for DOMWindowCreated, which: These tests will help understand how the platform works. This other phabricator, which will probably not land highlighted even better each intermediate WindowGlobal.Ī first step would be to identify which WindowGlobal related to a new popup. And you may distinguish the various one via document.isInitialDocument. When using window.open there is actually more than one WindowGlobal being instantiated. Tests added in bug 1586830 highlighted a few interesting implementation detail of window.open. This is what has been described so far in this bug. So I think it would still be worth having this implemented. +1 about the Multiprocess Browser Toolbox (MBT), it should already be a way to somehow debug any new tab/popup.īut I could easily understand that today, the MBT can be too slow to use in some case, and overwhelming with data coming in from all the tabs.
0 Comments
Leave a Reply. |