Popups used to constantly update their position when moving the window they're attached to. They still emit `popuppositioned` events, but the popup does not actually position. For most of the main chrome UI popups, they update position when you stop dragging. But for OMC's feature callout panels, they never update position. The only things that are special about these panels are [the xul attributes](https://searchfox.org/firefox-main/rev/6041a25bd5854c5fa2edab36a719938b1d7ada6b/browser/components/asrouter/modules/FeatureCallout.sys.mjs#1040-1050) and the use of a [`popuppositioned` event listener](https://searchfox.org/firefox-main/rev/6041a25bd5854c5fa2edab36a719938b1d7ada6b/browser/components/asrouter/modules/FeatureCallout.sys.mjs#957) (which shouldn't do anything except set an attribute on the panel, which is only used by CSS to move the custom arrow). So the part most confusing to me is distinguishing the feature callout panels from other panels - what makes them different. These popups stay open even when you click outside them. For other popups, you would need to use the `disable_autohide` pref. But this can still matter for any popup, as the anchor can occasionally move without the user needing to click outside the popup. Anyway, popup movement is rare for the usual popups, but common for feature callouts because autohide is disabled. Another difference might be that our popup is not created by an event, so there is no `triggerEvent` param to pass to `openPopup`. Other popups tend to pass this, so maybe that's significant. ### Pushlog I suspect this was regressed by bug 1933181, but I'm not certain, because the bisection fell apart at the end: > 1:40.37 INFO: Pushlog: > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=860e9251e02806437cda3650e62d5747aaa45895&tochange=69063d81c4e1f54731d4a8698c63c3a703e83966 > > 1:42.64 INFO: ************* Switching to autoland by process of elimination (no branch detected in commit message) > 1:43.84 ERROR: Unable to exploit the merge commit. Origin branch is mozilla-central, and the commit message for 69063d81 was: > Bug 1994157 - Partially revert the previous patch to land what emilio intended. ### Testing Our feature callout panels can be easily tested by going to about:config and enabling `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled`, then going to about:asrouter, searching for "TEST_FEATURE_TOUR", and hitting the blue Show button under it. That will open a feature callout anchored to the app menu button, so it should follow the button around. But if you move the window, it doesn't - at least on Windows. If anyone can test this on another OS that would be great. --- I'm CCing @emcminn since she could probably easily test this on macOS, and @emilio since he knows about how the popup code has changed lately.
Bug 2012305 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.
Popups used to constantly update their position when moving the window they're attached to. They still emit `popuppositioned` events, but the popup does not actually position. For most of the main chrome UI popups, they at least update position when you stop dragging - not ideal, but at least the popup isn't left permanently hanging. But for OMC's feature callout panels, they never update position. The only things that are special about these panels are [the xul attributes](https://searchfox.org/firefox-main/rev/6041a25bd5854c5fa2edab36a719938b1d7ada6b/browser/components/asrouter/modules/FeatureCallout.sys.mjs#1040-1050) and the use of a [`popuppositioned` event listener](https://searchfox.org/firefox-main/rev/6041a25bd5854c5fa2edab36a719938b1d7ada6b/browser/components/asrouter/modules/FeatureCallout.sys.mjs#957) (which shouldn't do anything except set an attribute on the panel, which is only used by CSS to move the custom arrow). So the part most confusing to me is distinguishing the feature callout panels from other panels - what makes them different. These popups stay open even when you click outside them. For other popups, you would need to use the `disable_autohide` pref. But this can still matter for any popup, as the anchor can occasionally move without the user needing to click outside the popup. Anyway, popup movement is rare for the usual popups, but common for feature callouts because autohide is disabled. Another difference might be that our popup is not created by an event, so there is no `triggerEvent` param to pass to `openPopup`. Other popups tend to pass this, so maybe that's significant. ### Pushlog I suspect this was regressed by bug 1933181, but I'm not certain, because the bisection fell apart at the end: > 1:40.37 INFO: Pushlog: > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=860e9251e02806437cda3650e62d5747aaa45895&tochange=69063d81c4e1f54731d4a8698c63c3a703e83966 > > 1:42.64 INFO: ************* Switching to autoland by process of elimination (no branch detected in commit message) > 1:43.84 ERROR: Unable to exploit the merge commit. Origin branch is mozilla-central, and the commit message for 69063d81 was: > Bug 1994157 - Partially revert the previous patch to land what emilio intended. ### Testing Our feature callout panels can be easily tested by going to about:config and enabling `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled`, then going to about:asrouter, searching for "TEST_FEATURE_TOUR", and hitting the blue Show button under it. That will open a feature callout anchored to the app menu button, so it should follow the button around. But if you move the window, it doesn't - at least on Windows. If anyone can test this on another OS that would be great. --- I'm CCing @emcminn since she could probably easily test this on macOS, and @emilio since he knows about how the popup code has changed lately.
Popups used to constantly update their position when moving the window they're attached to. They still emit `popuppositioned` events, but the popup does not actually position. For most of the main chrome UI popups, they at least update position when you stop dragging - not ideal, but at least the popup isn't left permanently hanging. But for OMC's feature callout panels, they never update position. They used to work just fine, and smoothly follow the anchor around the screen. The only things that are special about these panels are [the xul attributes](https://searchfox.org/firefox-main/rev/6041a25bd5854c5fa2edab36a719938b1d7ada6b/browser/components/asrouter/modules/FeatureCallout.sys.mjs#1040-1050) and the use of a [`popuppositioned` event listener](https://searchfox.org/firefox-main/rev/6041a25bd5854c5fa2edab36a719938b1d7ada6b/browser/components/asrouter/modules/FeatureCallout.sys.mjs#957) (which shouldn't do anything except set an attribute on the panel, which is only used by CSS to move the custom arrow). So the part most confusing to me is distinguishing the feature callout panels from other panels - what makes them different. These popups stay open even when you click outside them. For other popups, you would need to use the `disable_autohide` pref. But this can still matter for any popup, as the anchor can occasionally move without the user needing to click outside the popup. Anyway, popup movement is rare for the usual popups, but common for feature callouts because autohide is disabled. Another difference might be that our popup is not created by an event, so there is no `triggerEvent` param to pass to `openPopup`. Other popups tend to pass this, so maybe that's significant. ### Pushlog I suspect this was regressed by bug 1933181, but I'm not certain, because the bisection fell apart at the end: > 1:40.37 INFO: Pushlog: > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=860e9251e02806437cda3650e62d5747aaa45895&tochange=69063d81c4e1f54731d4a8698c63c3a703e83966 > > 1:42.64 INFO: ************* Switching to autoland by process of elimination (no branch detected in commit message) > 1:43.84 ERROR: Unable to exploit the merge commit. Origin branch is mozilla-central, and the commit message for 69063d81 was: > Bug 1994157 - Partially revert the previous patch to land what emilio intended. ### Testing Our feature callout panels can be easily tested by going to about:config and enabling `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled`, then going to about:asrouter, searching for "TEST_FEATURE_TOUR", and hitting the blue Show button under it. That will open a feature callout anchored to the app menu button, so it should follow the button around. But if you move the window, it doesn't - at least on Windows. If anyone can test this on another OS that would be great. --- I'm CCing @emcminn since she could probably easily test this on macOS, and @emilio since he knows about how the popup code has changed lately.
Popups used to constantly update their position when moving the window they're attached to. They still emit `popuppositioned` events, but the popup does not actually position. For most of the main chrome UI popups, they at least update position when you stop dragging - not ideal, but at least the popup isn't left permanently hanging. But for OMC's feature callout panels, they never update position. They used to work just fine, and smoothly follow the anchor around the screen. The only things that are special about these panels are [the xul attributes](https://searchfox.org/firefox-main/rev/6041a25bd5854c5fa2edab36a719938b1d7ada6b/browser/components/asrouter/modules/FeatureCallout.sys.mjs#1040-1050) and the use of a [`popuppositioned` event listener](https://searchfox.org/firefox-main/rev/6041a25bd5854c5fa2edab36a719938b1d7ada6b/browser/components/asrouter/modules/FeatureCallout.sys.mjs#957) (which shouldn't do anything except set an attribute on the panel, which is only used by CSS to move the custom arrow). So the part most confusing to me is distinguishing the feature callout panels from other panels - what makes them different. These popups stay open even when you click outside them. For other popups, you would need to use the `disable_autohide` pref. But this can still matter for any popup, as the anchor can occasionally move without the user needing to click outside the popup. Anyway, popup movement is rare for the usual popups, but common for feature callouts because autohide is disabled. But I tried removing the `noautohide` attribute, and it still doesn't update position. behavior Another difference might be that our popup is not created by an event, so there is no `triggerEvent` param to pass to `openPopup`. Other popups tend to pass this, so maybe that's significant. ### Pushlog I suspect this was regressed by bug 1933181, but I'm not certain, because the bisection fell apart at the end: > 1:40.37 INFO: Pushlog: > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=860e9251e02806437cda3650e62d5747aaa45895&tochange=69063d81c4e1f54731d4a8698c63c3a703e83966 > > 1:42.64 INFO: ************* Switching to autoland by process of elimination (no branch detected in commit message) > 1:43.84 ERROR: Unable to exploit the merge commit. Origin branch is mozilla-central, and the commit message for 69063d81 was: > Bug 1994157 - Partially revert the previous patch to land what emilio intended. ### Testing Our feature callout panels can be easily tested by going to about:config and enabling `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled`, then going to about:asrouter, searching for "TEST_FEATURE_TOUR", and hitting the blue Show button under it. That will open a feature callout anchored to the app menu button, so it should follow the button around. But if you move the window, it doesn't - at least on Windows. If anyone can test this on another OS that would be great. --- I'm CCing @emcminn since she could probably easily test this on macOS, and @emilio since he knows about how the popup code has changed lately.