Closed Bug 1784692 Opened 2 months ago Closed 14 days ago

Despite setting https://www.google.com/ to "Homepage and new windows", address bar is focused when a new window is opened.

Categories

(Firefox :: Address Bar, defect, P2)

Firefox 105
Desktop
Windows 10
defect

Tracking

()

VERIFIED FIXED
107 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox-esr102 --- unaffected
firefox103 --- unaffected
firefox104 --- unaffected
firefox105 + verified
firefox106 + verified
firefox107 + verified

People

(Reporter: alice0775, Assigned: scunnane)

References

(Regression)

Details

(Keywords: nightly-community, regression)

Steps to Reproduce:

  1. Set https://www.google.com/ is to "Homepage and new windows" in about:preferences#home
  2. Restart Browser OR open new window(Ctrl+N)

Actual Results:
Address bar is focused

Expected Results:
Search field of the Google web page should be focused.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dfb8854e3ac0a4b64fa53b40a3712c082911bb96&tochange=b8566978a274b54ffe5cd4b3b2d876f5b3096981

:scunnane, since you are the author of the regressor, bug 1770818, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(scunnane)

Thanks for bringing this to my attention. Since it's a product question as to whether we want to special-case search engines as custom new window URLs, I'm currently discussing this with Henry Moseti.

Flags: needinfo?(scunnane)

Set release status flags based on info from the regressing bug 1770818

Hi Stephanie, any updates on this bug now that Fx105 is in Beta?

Flags: needinfo?(scunnane)

Yes, I've just had a product discussion with Henry Moseti. The core issue of this regression is a conflict between our goal of directing users to the address bar vs. user agency. In this case, we're going to favor user agency. Therefore we're planning to fix this regression by special-casing search engines when they are configured as the user's custom new window URL.

We'll fix this in our current development cycle or the next. However, this regression is not serious enough to warrant backing out the original patch.

Flags: needinfo?(scunnane)
Assignee: nobody → scunnane
Priority: -- → P2

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(adw)

Hi Stephanie, is this something we're planning to fix for Fx105 before it goes to RC in a couple weeks?

Flags: needinfo?(scunnane)
Severity: -- → S3
Flags: needinfo?(scunnane)

Ryan, no, the patch for this probably won't make it in time.

Flags: needinfo?(adw)
See Also: → 1789537

(In reply to Stephanie Cunnane [:scunnane] from comment #5)

Yes, I've just had a product discussion with Henry Moseti. The core issue of this regression is a conflict between our goal of directing users to the address bar vs. user agency. In this case, we're going to favor user agency. Therefore we're planning to fix this regression by special-casing search engines when they are configured as the user's custom new window URL.

We'll fix this in our current development cycle or the next. However, this regression is not serious enough to warrant backing out the original patch.

Stephanie, I would like to point out that it's not just search engines that need to be special-cased in order to avoid the behavior of focusing on the address bar.

  1. Search engines are not the only sites with a text field that is auto-focused, which the user wants to preserve. You have shipping tracking sites, internal company pages, support forums, Wikipedia, etc....

  2. For websites that do not have a text field that is automatically focused (e.g. news sites), the user will want to be able to simply hit the arrow or page down keys in order to start browsing - but again, if the focus is defaulting to the address bar, they won't be able to without extra effort.

It is imperative that Firefox have a way to configure it back to the old behavior to leave the focus on the site itself - for ALL sites.

Tandy, thanks for pointing this out. We'll take this into consideration when fixing this regression, likely putting the original behavior behind a pref.

Duplicate of this bug: 1789537

Will I be stuck with this problem now for one month with the release of 105? If so I am sticking with 104. If there is no fix for 105 when will it be in the beta or nightly builds? It would be nice to have at least one current browser that works the way I want it to.

Hi Larry, this change is shipping with the 105 release. We'll listen for overall feedback and may back out the change in the 105.0.1 planned dot release on October 4th. The regression fix where the user will have the option to revert to the original behavior should ship with the 107 release.

https://i.postimg.cc/ht0YWz0d/FFerror.png

I have a similar issue, the url address highlight on browser startup. seems to happen on Firefox startup I am guessing it has something to do with the Url bar being in focus. I only noticed this on the latest nightly(106) and FF 105. did not want to start a new bug but these are my step to reproduce as follows

  1. Close the Firefox Browser
  2. Open Firefox and the address is highlighted until you click any where else.

I have my homepage set to https://www.yahoo.com. Does not seem to happen on a new tab or open a tab in new window.

This came up on SUMO yesterday: https://support.mozilla.org/questions/1390064

(In reply to Stephanie Cunnane [:scunnane] from comment #14)

We'll listen for overall feedback and may back out the change in the 105.0.1 planned dot release on October 4th. The regression fix where the user will have the option to revert to the original behavior should ship with the 107 release.

I assume you don't mean you want users to reply here. What is the best venue for feedback?

This was an intentional change. Currently, it is estimated that there will be a user preference added to Firefox 107 to choose between placing the >cursor in the address bar or in the page. Between now and then, it hasn't been decided whether to keep the change or roll it back. So we need to >think about whether there is a workaround.

How do you usually launch your home page?

Initial startup
New window (for example, Ctrl+N)
>Home button or Alt+Home

Initial startup, however when opening Firefox the focus in on the urlbar with FF105/106/107 and not the page which is a tad useless! the whole point of a homepage, is to open the page that is set and to be able to interact with it without having to push F6 or click with mouse. I have also had this issue with my business set home page and have been getting support tickets to fix this. Currently all users are on FF105, however we have reverted to FF104 on all employee systems about 300-350 systems.

Apologies to all those who have been inconvenienced by this change! We've considered the user feedback we've gotten and have had a few internal discussions - we've decided to revert this change completely and close the original bug as RESOLVED - WONTFIX.

The behavior will be reverted no later than October 4th. Right now, it's scheduled to be backed out with the 105.0.1 planned dot release, though it will happen sooner if there's an unplanned dot release before that.

Thank you Stephanie.

Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/f55cd89e1199
Revert focus behavior for new windows introduced by bug 1770818. a=backout

This has been reverted for all channels (Nightly 107, 106.0b3, and 105.0.1). As noted in comment 18, we don't have a definite ETA for 105.0.1 yet, but it'll be released by October 4 at the latest.
https://hg.mozilla.org/releases/mozilla-beta/rev/7c9d4bc419e1
https://hg.mozilla.org/releases/mozilla-release/rev/3d01ce603448

Severity: S3 → S2
Status: NEW → RESOLVED
Closed: 14 days ago
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch
Duplicate of this bug: 1791513
Duplicate of this bug: 1791967
Duplicate of this bug: 1792056

As an update, we expect to ship 105.0.1 tomorrow with this revert included.

I managed to reproduce this issue on Firefox 105.0 on macOS 12. Verified as fixed on Firefox 105.0.1, Firefox 106.0b3 and Nightly 107.0a1 on macOS 12, Windows 10, Ubuntu 22.

Version 105.0.1 is now available. Users will be automatically updated over the coming days or they can manually check for updates to get it right away. Thanks again for the patience.

Duplicate of this bug: 1792160
You need to log in before you can comment on or make changes to this bug.