In the current patch queue: https://phabricator.services.mozilla.com/D131802 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. 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 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. It allows to automatically display the right document in the inspector, or change the evaluation context of the console. This particular feature makes it hard to know that's actually the same toolbox. 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. Pros: * the toolbox is the same between the two documents, so that the panels state is 100% identical. If you set a breakpoint we have a strong guarantee that it is applied to the two documents. You will typicaly not have two distinct set of breakpoints between the two docs. * in some panels, you may care about the execution order between the two documents. For example, you could see the order of console.log calls between the original tab and the popup. This can only be possibly with a shared toolbox. * in term of implementation, it is trivial to catch early logs and break during page load without much side effects. Cons: * suddently, a toolbox can debug two distinct tabs, which may be something to learn and understand. You will most likely have to learn how the iframe dropdown works in order to easily switch devtools between the two documents without switching between the two tabs in firefox UI. * in term of implementation, it isn't trivial to move around the toolbox between the two tabs. It also breaks various old time invariant (one tab = one toolbox) I could always drop this in favor of the other option. Which is to freeze the page load until the toolbox is opened. This may simplify our implementation in DevTools, to the cost of having possible side effects on the popup load. This may make chasing race condition during a popup load much harder. Another possibility is to revisit something I tried before this patch. Force switching the toolbox to be visible in an independent OS Window and do the same as the current patch. It simplifies a bit the implementation as I would no longer have to move the toolbox between the two tabs. Instead we would only need to focus it correctly and still use the target selection to change the focus of the toolbox.
Bug 1569859 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
In the current patch queue: https://phabricator.services.mozilla.com/D131802 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. 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 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. It allows to automatically display the right document in the inspector, or change the evaluation context of the console. This particular feature makes it hard to know that's actually the same toolbox. 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. ## shared, moving toolbox for tab and popup Pros: * the toolbox is the same between the two documents, so that the panels state is 100% identical. If you set a breakpoint we have a strong guarantee that it is applied to the two documents. You will typicaly not have two distinct set of breakpoints between the two docs. * in some panels, you may care about the execution order between the two documents. For example, you could see the order of console.log calls between the original tab and the popup. This can only be possibly with a shared toolbox. * in term of implementation, it is trivial to catch early logs and break during page load without much side effects. * it should work almost seemlesly the same when debugging remote devices * this new pattern may open new opportunities, like a shared toolbox for all tabs, which may set optionaly set breakpoints for all tabs and could be made visible anytime a tab triggers a breakpoint. A somewhat browser toolbox restricted to tabs. Cons: * suddently, a toolbox can debug two distinct tabs, which may be something to learn and understand. You will most likely have to learn how the iframe dropdown works in order to easily switch devtools between the two documents without switching between the two tabs in firefox UI. * in term of implementation, it isn't trivial to move around the toolbox between the two tabs. It also breaks various old time invariant (one tab = one toolbox) ## load freeze, auto opening of toolbox and toolbox per tab I could always drop this in favor of the other option. Which is to freeze the page load until the toolbox is opened. Pros: * this may simplify our implementation in DevTools * it doesn't change the behavior of toolbox per tab, so it may be less confusing to users Cons: * it may have side effects on the popup load timings. This may make chasing race condition during a popup load much harder. * this would require some special code to auto open a toolbox if we want to support remote debugging * it is impossible/hard to debug code ordering issues between the two documents ## shared toolbox for tab and popup, but only visible as an independant window A third option would be to revisit something I tried before this patch. Force switching the toolbox to be visible in an independent OS Window and do the same as the current patch. It simplifies a bit the implementation as I would no longer have to move the toolbox between the two tabs. Instead we would only need to focus it correctly and still use the target selection to change the focus of the toolbox.
In the current patch queue: https://phabricator.services.mozilla.com/D131802 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. 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 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. It allows to automatically display the right document in the inspector, or change the evaluation context of the console. This particular feature makes it hard to know that's actually the same toolbox. 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. ## shared, moving toolbox for tab and popup Pros: * the toolbox is the same between the two documents, so that the panels state is 100% identical. If you set a breakpoint we have a strong guarantee that it is applied to the two documents. You will typicaly not have two distinct set of breakpoints between the two docs. * in some panels, you may care about the execution order between the two documents. For example, you could see the order of console.log calls between the original tab and the popup. This can only be possibly with a shared toolbox. * in term of implementation, it is trivial to catch early logs and break during page load without much side effects. * it should work almost seemlesly the same when debugging remote devices * if the popup is opened in a new independant smaller window, we may more easily debug it from the original tab toolbox. That, rathen that expanding the size of the popup to show the DevTools decently. * this new pattern may open new opportunities, like a shared toolbox for all tabs, which may set optionaly set breakpoints for all tabs and could be made visible anytime a tab triggers a breakpoint. A somewhat browser toolbox restricted to tabs. Cons: * suddently, a toolbox can debug two distinct tabs, which may be something to learn and understand. You will most likely have to learn how the iframe dropdown works in order to easily switch devtools between the two documents without switching between the two tabs in firefox UI. * in term of implementation, it isn't trivial to move around the toolbox between the two tabs. It also breaks various old time invariant (one tab = one toolbox) ## load freeze, auto opening of toolbox and toolbox per tab I could always drop this in favor of the other option. Which is to freeze the page load until the toolbox is opened. Pros: * this may simplify our implementation in DevTools * it doesn't change the behavior of toolbox per tab, so it may be less confusing to users Cons: * it may have side effects on the popup load timings. This may make chasing race condition during a popup load much harder. * this would require some special code to auto open a toolbox if we want to support remote debugging * it is impossible/hard to debug code ordering issues between the two documents ## shared toolbox for tab and popup, but only visible as an independant window A third option would be to revisit something I tried before this patch. Force switching the toolbox to be visible in an independent OS Window and do the same as the current patch. It simplifies a bit the implementation as I would no longer have to move the toolbox between the two tabs. Instead we would only need to focus it correctly and still use the target selection to change the focus of the toolbox.