Add option to extend feature callout page_event_listener to all windows
Categories
(Firefox :: Messaging System, defect, P1)
Tracking
()
People
(Reporter: cmuresan, Assigned: hanna_a)
References
Details
Attachments
(2 files)
[Affected versions]:
- Firefox Nightly 128.0a1 - Build ID: 20240529214854
- Firefox Beta 127.0b8 - Build ID: 20240529091551
- Firefox Release 126.0.1 - Build ID: 20240526221752
[Affected Platforms]:
- Windows 10
- macOS 14
- Ubuntu 22.04
[Prerequisites]:
- Have a Firefox build installed and use a new profile.
- Be enrolled in any branch (except control) of the Pin Email and Calendar experiment (early day / existing) through forced enrollment.
- Have the
browser.newtabpage.activity-stream.asrouter.devtoolsEnabledpref set totrue. - Unenroll from any experiment or rollout that the profile might be in using the about:studies page.
[Steps to reproduce]:
- Open the browser with the profile from prerequisites and open a New Window.
- Switch to the previous windows and navigate to the about:asrouter page.
- Search for the
PIN_EMAIL_AND_CALENDAR_TABSmessage ID. - Click the
Showbutton. - Switch to the other window and right click the active tab.
- Choose the
Pin Taboption and observe the message from the other window.
[Expected result]:
- The message is dismissed.
[Actual result]:
- The message remains displayed.
[Notes]:
- The issue is not reproducible when pinning a tab from the same window the message is anchored in, regardless of the tab state (active/inactive).
- Attached a screen recording of the issue.
Comment 2•1 year ago
|
||
Hanna: If you can find a solution in the next version, let's try to fix this. If not, we wouldn't delay it by another version since it's such an edge case.
You could possibly extend PageEventManager with the ability to create an EveryWindow callback.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 6•1 year ago
|
||
Backed out changeset 3cd5c74698b5 (bug 1899747) for causing bc failures at browser_feature_callout.js
Backout: https://hg.mozilla.org/integration/autoland/rev/dd4c3989bbb3657949300aa21cd68e419a0613eb
Failure log: https://treeherder.mozilla.org/logviewer?job_id=464946603&repo=autoland&lineNumber=5777
Updated•1 year ago
|
| Assignee | ||
Comment 7•1 year ago
|
||
I haven't been able to reproduce this locally, I've tried using the --verify flag as well. Any suggestions or similar backouts/bugs in the past?
Comment 8•1 year ago
|
||
Backfills confirmed that this was the culprit.
Comment 9•1 year ago
|
||
It's a leakcheck failure - this can only run with debug builds. Has a debug build been used locally?
| Assignee | ||
Comment 10•1 year ago
|
||
@Sebastian Thanks, I was able to reproduce it using a debug build locally, but it's not clear to me what's causing the window leak. Any suggestions?
Comment 11•1 year ago
|
||
The uninit is an arrow function as callback and uses the uuid - could you check the value if it's the expected one or got garbage collected?
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 12•1 year ago
|
||
There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:halemu, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 13•1 year ago
|
||
This bug was initially filed to fix a defect in an experiment, repurposing it to add "every_window" option to "page_event_listeners" in Feature callout.
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
| bugherder | ||
Updated•1 year ago
|
Comment 16•1 year ago
|
||
We still reproduce the issue on Firefox Nightly 135.0a1 (Build ID: 20241229214936) and Beta 134.0b10 (Build ID: 20241213091550) on Windows 10 x64 and macOS 12.6.1 using the experiment mentioned in the prerequisites of the bug report.
- The callout remains displayed after pinning the active tab from a different browser window.
However, since the Feature Callout message can be easily customized, maybe some changes to the message configuration are needed to prevent the issue from reproducing? Could you please confirm if this is the case or if the behavior should have been fixed with the message configuration as it currently is in the experiment recipe?
| Assignee | ||
Comment 17•1 year ago
|
||
Hi @carmen, thanks for looking into this. Yes, the issue is reproducible with the experiment recipe as-is because it was launched before this fix was landed in tree. To verify, the page_even_listeners attribute will need to be updated to:
"page_event_listeners": [ { "params": { "type": "TabPinned", "selectors": "#main-window", "options": { "every_window": true } }, "action": { "dismiss": true } } ],
Comment 18•1 year ago
|
||
Thank you, Hanna, for the quick response. We cloned the experiment recipe on stage and updated the page_event_listeners attribute as mentioned in the previous comment. This way we are no longer able to reproduce the issue; the callout message is dismissed from the first window after pinning a tab in the second browser window.
Environment:
- Firefox Nightly 135.0a1 (Build ID: 20241230205200) and RC 134.0 (Build ID: 20241230151726)
- Windows 10 x64. Ubuntu 20.04 x64. macOS 12.6.1
Description
•