Closed Bug 1826588 Opened 2 years ago Closed 2 years ago

Add FeatureCallout to newtab

Categories

(Firefox :: Messaging System, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
117 Branch
Iteration:
117.1 - July 3 - July 14
Tracking Status
firefox117 --- fixed

People

(Reporter: jprickett, Assigned: jprickett)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

In support of sentiment collection, we'd like to use the feature callout surface to give users an opportunity to provide sentimental feedback in newtab.

The scope of this bug is to add Feature Callout to newtab, similar to the way it was added to firefox view

Priority: -- → P2
Iteration: --- → 114.1 - Apr 10 - Apr 21
Priority: P2 → P1

newtab unfortunately doesn't have the same permissions as fx view. If done right now, it would need to be done the same way as PDF.js. But that "simulated content" approach is very restrictive on what kinds of callouts can be used, and it also has bug 1824016 which seems difficult to resolve. I think this would be another good reason to reconsider making a JSActor wrapper for FeatureCallout to go into page content. So FeatureCallout.sys.mjs can be imported directly in chrome code, but for unprivileged content, it would need to be imported by a child actor, e.g. ContentFeatureCalloutChild.sys.mjs

I think this would be a good opportunity to do it, because loading Feature Callout in the chrome when it's really supposed to go in the content restricts us to only fixed-position callouts. That is, we have to know the coordinates of the parent element in advance, and the callout can't be dynamically positioned (same situation as bug 1824016). If we want to make Feature Callout an ongoing part of the newtab experience then it would be great to support dynamic positioning. This would also solve that issue for the PDF.js callouts, since they could start using a parent_selector instead of a fixed position, if we loaded them through a JSActor.

It's difficult because FeatureCallout currently relies on awareness of both the content document and the browser element. So some of its responsibilities need to be handled by the parent actor, and some by the child actor. Which means FeatureCallout.sys.mjs needs to hand off some of its capabilities to the code that's constructing it, since we should still support chrome feature callout for elements that actually exist in the chrome.

Iteration: 114.1 - Apr 10 - Apr 21 → 114.2 - Apr 24 - May 5
Priority: P1 → P2
Iteration: 114.2 - Apr 24 - May 5 → 115.1 - May 8 - May 19
Iteration: 115.1 - May 8 - May 19 → 115.2 - May 22 - June 2
Assignee: nobody → jprickett
Iteration: 115.2 - May 22 - June 2 → 116.1 - June 5 - June 16
Iteration: 116.1 - June 5 - June 16 → 116.2 - June 19 - June 30
Attachment #9341625 - Attachment description: WIP: Bug 1826588 - add newtab feature callout trigger and prefs → Bug 1826588 - add newtab feature callout trigger and prefs r?aminomancer

[Tracking Requested - why for this release]:
Fix needed for microsurvey experiment in Fx116

Priority: P2 → P1
Duplicate of this bug: 1831375
Iteration: 116.2 - June 19 - June 30 → 117.1 - July 3 - July 14
Depends on: 1821826
Pushed by jprickett@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ccdd2dc5fe78 add newtab feature callout trigger and prefs r=aminomancer
Flags: qe-verify+

We've decided not to uplift these to 116.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 117 Branch

I have tested this task using the steps from the received Test Plan and here are the results:

  1. Note that on the about:newtab page, a callout appears in the upper right hand corner
  • I noticed a flicker on the top left side of the screen when opening the new tab - logged an issue under Bug 1844797.
  1. Change the location of the tab, and note that the callout disappears
  • The feature callout remains displayed when moving the tab into a New Window with drag and drop.

Other mentions:

  • The feature callout disappears when moving the New Window back to the Original’s Window tabstrip with drag and drop.
  • The feature callout remains displayed when moving the tab’s place through the tab strip.
  • The feature callout is not displayed when clicking a non-about:newtab, but gets displayed again when switching to an about:newtab.
  1. Open another new tab ensuring it's on the default newtab page, and note that the callout reappears
  • In the New Window, opening another about:newtab makes the callout appear (the callout is now displayed on both new tabs when switching between them).
  1. Navigate back to the non-about:newtab tab, and note that the callout disappears
  • We didn’t previously open a non-about:newtab, we focused the Mozilla Privacy tab instead (from the Original Window) and the callout disappeared.
  1. With the non-newtab tab open, open a 2nd window and ensure the new 2nd window is on the about:newtab page, and note that the callout appears
  • We dragged and dropped the non-about:newtab in order to create a New Window and also opened a new tab in the same New Window -> the callout is displayed.

Other mention:

  • While the non-about:newtab tab is focused, we opened a New Window where an about:newtab was displayed -> the callout is displayed.
  1. In the original window, navigate away from then back to about:newtab, and note that the feature callout reappears
  • The callout appears briefly when navigating from an about:newtab to a website - logged an issue under Bug 1844796.

@Shane, can you please confirm that the featureCallout works as expected considering our notes from the steps above?

Also, I was wondering if the featureCallout is supposed to appear each time a New Tab is opened? Or are there certain conditions that must be met in order to trigger the featureCallout (such as the number of open New Windows’, reloads of the New Tab page etc.)? I am asking this because I’ve noticed inconsistent behavior regarding this matter, so I would like to investigate this a bit next week. Thank you.

Flags: needinfo?(shughes)

Jason might be more equipped to answer whether this is working as expected (aside from the bugs you already filed, which do seem like bugs we should fix).

I think our goal is to show the feature callout each time a new tab page is opened. The only reason not to show it is if it's already showing in another window. So if you opened a new tab page in tab 1, opening another new tab page in tab 2 (and focusing tab 2) should cause the feature callout for tab 1 to disappear, and a feature callout for tab 2 to appear. Which may not be visually obvious since they will open in the same place.

But if instead you opened a new tab page in tab 1, then opened a new window (while tab 1 was still focused in window 1), then a feature callout should never appear in window 2, unless you go back to window 1 and navigate away from the new tab page so that a feature callout is not showing.

Basically it should be impossible to have 2 feature callouts visually displaying at the same time, across all windows. But there aren't any other rules or conditions about triggering the callout. The only real trigger is visiting the new tab page.

Flags: needinfo?(shughes) → needinfo?(jprickett)
Flags: needinfo?(jprickett)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: