Sorry for the confusing title, this is a bit hard to describe. ### STR 1. Open a browser toolbox, being careful not to mouse over any elements in the inspector. In fact, it's probably best if you just don't open the Inspector tab yet. 2. Disable Popup Auto-Hide, e.g., via the meatball menu (actually, `ui.popup.disable_autohide` will also work) 3. Open any <panel> (e.g., the app menu) 4. Now mouse over an element in the inspector, such that a highlighter will be drawn. ### Expected A highlighter should be drawn ### Actual A highlighter is drawn, but all open popups are closed, without a graceful exit. For some popups this isn't a big deal, but for panels that set `open` attribute on their anchors, this permanently breaks the anchor, making it impossible for the user to open the panel again within the menu. The `open` attribute is not unset when the popup closes, so the anchor remains styled like it's `open` and clicking it will not open the panel again. In my limited experience this permanently-open state has been a pretty common failure mode for panels when debugging the chrome. I've seen it triggered by some other, more marginal things in the past, though I think those have been fixed. So maybe the normal method of unsetting the `open` attribute should be reevaluated anyway, such that it's more automatic. But even so, it would be nice to work out whether the highlighter's popup-closing behavior is intentional and necessary, and if so, whether it could be done in a way that doesn't crash panels. Keep in mind this can only be triggered when the first highlighter of the toolbox process is drawn. So, it can be avoided by... 1. Open a toolbox 2. Mouse over an element to draw a highlighter 3. Now disable popup auto-hide and open a popup 4. Now you can use highlighters safely So if you're trying to reproduce it, make sure you're not accidentally doing that^
Bug 1769480 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Sorry for the confusing title, this is a bit hard to describe. ### STR 1. Open a browser toolbox, being careful not to mouse over any elements in the inspector. In fact, it's probably best if you just don't open the Inspector tab yet. 2. Disable Popup Auto-Hide, e.g., via the meatball menu (actually, `ui.popup.disable_autohide` will also work) 3. Open any <panel> (e.g., the app menu) 4. Now mouse over an element in the inspector, such that a highlighter will be drawn. ### Expected A highlighter should be drawn ### Actual A highlighter is drawn, but all open popups are closed, without a graceful exit. For some popups this isn't a big deal, but for panels that set `open` attribute on their anchors, this permanently breaks the anchor, making it impossible for the user to open the panel again within the menu. The `open` attribute is not unset when the popup closes, so the anchor remains styled like it's `open` and clicking it will not open the panel again. In my limited experience this permanently-open state has been a pretty common failure mode for panels when debugging the chrome. I've seen it triggered by some other, more marginal things in the past, though I think those have been fixed. So maybe the normal method of unsetting the `open` attribute should be reevaluated anyway, such that it's more automatic. But even so, it would be nice to work out whether the highlighter's popup-closing behavior is intentional and necessary, and if so, whether it could be done in a way that doesn't crash panels. Keep in mind this can only be triggered when the first highlighter of the toolbox process is drawn. So, it can be avoided by... 1. Open a toolbox 2. Mouse over an element to draw a highlighter 3. Now disable popup auto-hide and open a popup 4. Now you can use highlighters safely So if you're trying to reproduce it, make sure you're not accidentally doing that^ Edit: By the way, my title might be kinda misleading. I don't think the disable_autohide feature actually has anything to do with the etiology of the bug. It's just impossible to make the bug happen without it, because we can't otherwise use the toolbox without popups in the main window being automatically closed when the window is deactivated.