When opening a new window with a custom new window URL configured, the web content is initially focused rather than the address bar
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
People
(Reporter: scunnane, Assigned: scunnane)
References
Details
(Keywords: papercut, Whiteboard: [snt-scrubbed])
Attachments
(1 file)
Steps to reproduce:
- Open Firefox and visit
about:preferences#home - In the New Windows and Tabs section, select "Custom URLs..." in the first dropdown, then enter, for example, "https://connect.mozilla.org" into the input field immediately below
- Open a new window either via the app menu (App Menu > New Window) or the keyboard shortcut (Ctrl+N)
Expected results:
Upon opening a new window with a custom new window URL configured, the address bar should be focused and the URL text already selected
Actual results:
Upon opening a new window with a custom new window URL configured, the address bar is NOT focused and the web content is focused instead
Comment 1•3 years ago
|
||
The severity field is not set for this bug.
:adw, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
| Assignee | ||
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Thanks for filing this, Stephanie. We should document the motivation behind it. This is related to bug 1426058, where we asked Henry whether the urlbar should be focused when using a custom new-tab URL. Henry's answer was Yes according to bug 1426058 comment 3. This bug is about custom new-window URLs, which is not the same, but as I understand it Henry also said the urlbar should be focused for custom new-window URLs. Is that right, Stephanie? Or should we clarify with Henry before continuing?
| Assignee | ||
Comment 3•3 years ago
|
||
Yes, per my discussion with Henry, for both custom new tabs and custom new windows, we want the address bar focused initially. (I told Henry I'd be filing this current bug and sent him a link to it.)
| Assignee | ||
Comment 4•3 years ago
|
||
Comment 5•3 years ago
|
||
The following patch is waiting for review from an inactive reviewer:
| ID | Title | Author | Reviewer Status |
|---|---|---|---|
| D151946 | Bug 1770818 - WIP - Focus the address bar when opening a new window with a custom new window URL configured. r?adw | scunnane | adw: Back Aug 6, 2022 |
:scunnane, could you please find another reviewer?
For more information, please visit auto_nag documentation.
| Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 7•3 years ago
|
||
| bugherder | ||
| Assignee | ||
Comment 8•3 years ago
|
||
A day after the patch for this bug landed, a regression (1784692) was filed related to the patch. The custom new window behavior that I discussed with Henry was to always focus the address bar and select the URL text, regardless of what the custom new window's URL actually is. And this is what we've implemented with this patch.
I can see how setting https://www.google.com as the custom new window URL could be seen as a bit of an edge case. But I see 3 reasons not to special-case it:
- Henry has repeatedly emphasized that we always want to be driving users to the address bar, which was the original motivation behind this patch
- Typing directly into the search bar that's embedded into the new tab page immediately pops the focus to the address bar
- If a user has https://www.google.com configured as their custom new window URL and Google configured as their default search engine, it doesn't matter whether the user types a search term into the address bar or the Google search bar embedded into the web content - the result should be the same search engine result page from Google.
Drew, do you have thoughts on this? Thanks!
Comment 9•3 years ago
|
||
Could you ask Henry please? I think this is a big enough question to run by him, and it might not be something he considered. I tend to agree with you, but OTOH I don't think this is worth annoying users over -- maybe we could add special cases for search engine URLs.
Comment 10•3 years ago
|
||
Stephanie, I am one of those users that would be very annoyed if you don't allow users to use search engine pages. I am older and hate the idea of using the urlbar for searches. I want the cursor to focus on the large box in the Google webpage. The address bar is too small for my eyes.
| Assignee | ||
Comment 11•3 years ago
|
||
Hi Larry,
Thanks very much for this feedback - much appreciated.
You mention that the address bar is too small for your eyes. There's actually a way to improve this if you're interested:
- Type "about:config" into the address bar
- If a warning page appears, click "Accept the Risk and Continue"
- Search for a preference called
layout.css.devPixelsPerPx - Try setting that preference to a value of 3, 4 or 5
This may not be the most discoverable way to boost the size of the address bar (and it actually affects the size of the entire browser UI, not just the address bar), but hopefully it's helpful.
Comment 12•3 years ago
|
||
I do appreciate the feedback. I have always used css code to have everything the way I want it. In my case it is:
/* Global UI font */
- { font-size: 9pt !important;
font-family: Tahoma !important;
}
I have always used -1.0 as the layout.css.devPixelsPerPx setting. For fun I tried using 3.0 as you mention
and the size is ridiculously large.
I appreciate that you want to force users to use the urlbar for searches although I'm not sure why. As a compromise couldn't you have the urlbar as the default setting and then provide an about:config setting to change it for those of us who don't like it. I imagine that most users of Firefox don't bother with the advanced settings.
Comment 13•3 years ago
|
||
(In reply to Larry Snow from comment #12)
I do appreciate the feedback. I have always used css code to have everything the way I want it. In my case it is:
/* Global UI font */
- { font-size: 9pt !important;
font-family: Tahoma !important;
}
I have always used -1.0 as the layout.css.devPixelsPerPx setting. For fun I tried using 3.0 as you mention
and the size is ridiculously large.I appreciate that you want to force users to use the urlbar for searches although I'm not sure why. As a compromise couldn't you have the urlbar as the default setting and then provide an about:config setting to change it for those of us who don't like it. I imagine that most users of Firefox don't bother with the advanced settings.
| Assignee | ||
Comment 14•3 years ago
•
|
||
Hi Larry, there is an existing way to disable all searching functionality in the address bar if you'd like:
- Visit about:config
- Set the
keyword.enabledpref to false
And regarding comment 10 above, we're engaged in an ongoing product discussion about possibly special-casing search engine pages when they're configured as the custom new window URL.
Comment 15•3 years ago
|
||
Thanks Stephanie for considering this. BTW, the suggestion to set keyboard.enabled to false does not address the current problem. It merely takes away the ability to use the urlbar as a search engine. On startup the focus still goes to the urlbar and not the body of the search engine webpage.
| Assignee | ||
Comment 16•3 years ago
|
||
Hi Larry, I realize that setting the keyword.enabled pref to false doesn't relate to the core issue of this regression, but I initially misunderstood what you were asking in comment 12 - apologies!
Updated•3 years ago
|
| Assignee | ||
Comment 17•3 years ago
|
||
Here's an update on how we've decided to handle the regression caused by this bug's patch: 1784692#c5
I managed to reproduce this issue on a 2022-05-23 Nightly build on Ubuntu 22.04 using the STR from the Description. Verified as fixed on Firefox 105.0b5(build ID: 20220830185924) and Nightly 106.0a1(build ID: 20220831215447) on Ubuntu 22.04, macOS 12, Windows 10.
Comment 19•3 years ago
•
|
||
Per discussion with the Product and engineering teams, we're going to revert this change for all releases. Backed out from all affected branches (Nightly 107, Beta 106.0b3, Release 105.0.1).
Comment 20•6 months ago
|
||
| uplift | ||
Description
•