Closed Bug 1571161 Opened 2 months ago Closed Last month

Modify openViewOnFocus so that it doesn't open the view on the newtab page and private windows

Categories

(Firefox :: Address Bar, task, P1)

task
Points:
2

Tracking

()

RESOLVED FIXED
Firefox 70
Iteration:
70.3 - Aug 5 - 18
Tracking Status
firefox69 --- fixed
firefox70 --- fixed

People

(Reporter: adw, Assigned: adw)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

For the top-sites experiment, Verdi says that the view shouldn't open on focus when newtab is the current page since the top sites are already shown there. See bug 1547670 comment 3 and later, and the Slack conversation. The easiest thing to do is just modify openViewOnFocus so it doesn't apply to newtab.

Blocks: 1547279
No longer blocks: 1547301
Depends on: 1547301

I don't think I agree with the reasoning in bug 1547670 comment 3. The standard use case seems adequately addressed by not opening the popup by default, and if the user explicitly clicks in the urlbar another time that seems like a good indicator that they want to interact with the urlbar as they would in other contexts. What's the benefit of disallowing this?

Flags: needinfo?(mverdi)

(In reply to Dão Gottwald [::dao] from comment #2)

The standard use case seems adequately addressed by not opening the popup by default, and if the user explicitly clicks in the urlbar another time that seems like a good indicator that they want to interact with the urlbar as they would in other contexts. What's the benefit of disallowing this?

Opening the popup on focus is the whole point of our top sites experiment. We're trying this because we see that users who have activity stream find value in the top sites section. But we also see that many people either don't have access to activity stream or don't access it in their normal browsing behavior. We think we can provide a valuable pre-search interaction by displaying the top sites in the popup when the user focuses the address bar.

Flags: needinfo?(mverdi)

Sorry - I didn't fully explain:
In the comment above I explained how the interaction works when you are on a website. On a new tab, the popup should not open with the top sites when auto-focused or when the user clicks into it because showing the top sites over top of the top sites section is redundant. In other words, explicitly clicking into the address bar when the top sites are displayed on the new tab is an indication that the user does not want to interact with the top sites (and therefor we don't show them in the popup).

The urlbar is always autofocused on a new tab, so that other case is the user doing an /extra/ click in the already-focused urlbar which seems like a pretty clear signal. I still think we should open the popup then. For one thing the urlbar has an entirely different accessibility story than the new tab page and I can easily see how keyboard users or users of accessibility software would prefer the former. Could also just be a mouse user who built muscle memory for the list and prefers that over the grid.

Flags: needinfo?(mverdi)

Let's keep the interaction as specified for now and take up the question about the new tab interaction in user testing.

(In reply to Dão Gottwald [::dao] from comment #5)

For one thing the urlbar has an entirely different accessibility story than the new tab page and I can easily see how keyboard users or users of accessibility software would prefer the former.

That seems like a bug that should be addressed separately.

Flags: needinfo?(mverdi)

It's not a bug, the new tab page just has a different interaction model. I'm not aware of any plans to change that.

There's discussion in Slack that the popup should not open in private-browsing windows, either. I'll modify the patch for that.

Summary: Modify openViewOnFocus so that it doesn't open the view on the newtab page → Modify openViewOnFocus so that it doesn't open the view on the newtab page and private windows
Attachment #9083149 - Attachment description: Bug 1571161 - Modify openViewOnFocus so that it doesn't open the view on the newtab page. → Bug 1571161 - Modify openViewOnFocus so that it doesn't open the view on the newtab page and in private windows.
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/31f858085f7c
Modify openViewOnFocus so that it doesn't open the view on the newtab page and in private windows. r=dao
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Attached patch Beta/69 patchSplinter Review

Beta/Release Uplift Approval Request

  • User impact if declined: This bug supports the top-sites experiment that the quantumbar/search team would like to conduct on 69.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This only affects functionality behind a pref (browser.urlbar.openViewOnFocus). The pref is not enabled in the product at this time. It will only be enabled by an add-on experiment. It also comes with a test. I ran the test on a local beta build to make sure it passes.
  • String changes made/needed: None
Attachment #9086167 - Flags: approval-mozilla-beta?
Flags: qe-verify-
Flags: in-testsuite+
Comment on attachment 9086167 [details] [diff] [review]
Beta/69 patch

Need for experiments targeting Fx69. Approved for 69.0b15.
Attachment #9086167 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Regressions: 1575355
You need to log in before you can comment on or make changes to this bug.