1805413 - [Experiment] The PDF Feature Callout messages are not pointed to their specific icons if an infobar message is displayed

Status: VERIFIED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Simona Rosu [:srosu], Ecosystem QA]

Attachment: PDFcallouts_Infobar.png

[Affected versions]:

• Firefox Beta 109.0b1 (Build ID: 20221212143511)

[Affected Platforms]:

• Windows 10 x64
• macOS 11.7.1
• Ubuntu 22.04 x64

[Prerequisites]:

• Have the latest version of Firefox Beta 109 installed.
• Have created and opened a Firefox profile between 6 weeks and 3 months old.
• Have the Firefox browser not set as default.
• Have the “nimbus.debug” pref set to true in the “about:config” page.
• Have the "Always check if Firefox is your default browser" option from the “about:prefererences” unchecked.

[Steps to reproduce]:

1. Force enroll in the Treatment A branch of the experiment using the following link: about:studies?optin_slug=pdfjs-feature-callout&optin_branch=treatment-a&optin_collection=nimbus-preview
2. Open a new tab and restart the browser.
3. Ensure that the “Set as default” infobar is displayed.
4. Navigate to a PDF URL (e.g. https://www.clickdimensions.com/links/TestPDFfile.pdf) in the same tab.
5. Observe the top-right part of the page.

[Expected result]:

• The first message of the PDF Feature Callout message points to the Text icon.

[Actual result]:

• The first message of the PDF Feature Callout message points to the info bar.

[Notes]:

• This issue is also reproducible in the Treatment B of the experiment.
• The second message of the PDF callout also points to the info bar.
• Attached is a screenshot of the issue.

Comment 1

[Meg Viar [:mviar]]

A possible short-term workaround might be updating the experiment targeting to exclude users with the browser.shell.checkDefaultBrowser pref set to false. Those user's won't see the set to default infobar. We'd want to investigate and see if there are other infobars currently in use and whether we could use targeting to avoid them.

Does that sound like an acceptable option here @vtay?

We could work on an on-train solution. However, I'm hesitant to put too much additional engineering effort into this niche case as it won't give us value outside of this one experiment.

Comment 2

[Simona Rosu [:srosu], Ecosystem QA]

Hi Meg! This issue is also reproducible when the "Session Restore" infobar is displayed, and possibly with all active infobars.

Comment 3

[Meg Viar [:mviar]]

Another possible approach for fixing this would be to allow the position override to be relative to an element found via the callout message's parent_selector. Then we would position the callout related to the box element in chrome with class navigator-toolbox-background which grows and shrinks with infobars.

Comment 4

[Vtay]

That sounds like an acceptable option. thank you.

Comment 5

[Jason Prickett]

Attachment: Bug 1805413 - Implement relative position for feature callout positioning overrides r=mviar

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox109 (beta) and tracked for firefox110 (nightly). However, the bug still has low severity.

:tspurway, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c168847136ae
Implement relative position for feature callout positioning overrides r=mviar

Comment 8

[Cristian Tuns]

Backed out for causing mochitest failures

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | browser/components/firefoxview/tests/browser/browser_feature_callout_position.js | Feature callout container has a top position of 500, and left position of 500 -

bc log: https://treeherder.mozilla.org/logviewer?job_id=400437847&repo=autoland

Comment 9

[Jason Prickett]

That test was for functionality that my patch changed and is covered in new tests. I'll remove it and re-land.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6a4131dd9c46
Implement relative position for feature callout positioning overrides r=mviar

Comment 11

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/6a4131dd9c46

Comment 12

[Meg Viar [:mviar]]

Comment on attachment 9308173 [details]
Bug 1805413 - Implement relative position for feature callout positioning overrides r=mviar

Beta/Release Uplift Approval Request

• User impact if declined: If an infobar or other element that increases the size of the browser chrome is present when the PDF.js annotation Feature Tour begins, the tour messages won't point to the buttons they describe. This may result in confusion or frustration for the user.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Navigate to about:config and set the browser.pdfjs.feature-tour pref to {"screen":"FEATURE_CALLOUT_1_A","complete":false}, and set the browser.newtabpage.activity-stream.asrouter.devtoolsEnabled pref to true.

2. Navigate to any PDF file (https://upload.wikimedia.org/wikipedia/commons/d/d3/Test.pdf)
3. Note that the feature callout is positioned as expected, and that the callout's arrow points to the appropriate PDF.js button.
4. In a new tab, navigate to the AS Router Dev Tools, and do a find in page for INFOBAR_DEFAULT_AND_PIN_87.
5. Click on the "Show" button for the infobar message, and note that the set default browser infobar has appeared.
6. Navigate back to the PDF page in the previous tab, and refresh it.
7. Note that the callout's position is updated as expected, and that the callout's arrow still points to the appropriate PDF.js button.

We are aware that this solution is not responsive (if an infobar appears while a message is already displayed, the message will not reposition without refresh / navigating to the next message in the tour).

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): These changes are limited to the Feature Callout messaging surface and the other use case for this surface in Firefox View is well covered with automated tests.
• String changes made/needed:
• Is Android affected?: No

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9308173 [details]
Bug 1805413 - Implement relative position for feature callout positioning overrides r=mviar

Approved for 109.0b8.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/00093cdf8138

Comment 15

[Simona Rosu [:srosu], Ecosystem QA]

I‘ve verified this issue using the latest Firefox Nightly 110.0a1 (Build ID: 20230104163752) and Firefox Beta 109.0b8 (Build ID: 20230103185821) on Windows 10 x64, macOS 11.7.1, and Ubuntu 22.04 x64.

• The PDF Feature Callout messages are pointed to their specific icons if an infobar message is displayed.