Closed Bug 1614911 Opened 4 years ago Closed 4 years ago

Focus menu for search results displayed on Wikipedia when focus is restored to the webpage after accessing options from address bar

Categories

(Firefox :: Menus, defect, P3)

defect

Tracking

()

VERIFIED FIXED
Firefox 75
Tracking Status
firefox-esr68 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- verified

People

(Reporter: cfogel, Assigned: Gijs)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached image sws.gif

Affected versions

  • 72.0, 74.0b2, 75.0a1 (2020-02-11), 68.4.2esr

Affected platforms

  • Windows 10, macOS 10.15, Kubuntu 19;

Steps to reproduce

  1. Launch Firefox;
  2. access https://www.wikipedia.org/
  3. Inside the pagesearch for: sws+
  4. Click on the EPT button;
  5. Click away to close the ETP menu;

Alternative steps:
2. Set Wikipedia as the default search engine;
3. In the Adress bar search for sws+

Expected result

  • no unexpected issues;

Actual result

  • the search_results dropdown from inside the website is displayed;

Regression range

  • last good build_date: 2019-03-16
  • first bad build_date: 2019-03-17
  • Pushlog URL
  • potential regressor: 1506510

Additional notes

  • attached recording with the issue.

@Yzen, mind taking a look and confirming the regress-or?
Thank you!

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(yzenevich)
Regressed by: 1506510

I'm not totally sure this is a regression. From the video (and by testing myself) it looks like the default behaviour of the search input is to display autocomplete suggestions on focus if the input field is not empty. I see that in the video example the suggestions are dismissed (probably via the Esc key) and then the EPT is pressed. What happens next is that when the EPT is dismissed, the focus is correctly placed back onto the input field and the autocomplete gets open again (which seems like a default behaviour for that widget)..

Flags: needinfo?(yzenevich)

(In reply to Cristian Fogel, QA [:cfogel] from comment #0)

Regression range

  • last good build_date: 2019-03-16
  • first bad build_date: 2019-03-16
  • potential regressor: 1506510

The good and bad dates are the same, which doesn't make a lot of sense, and there's no pushlog so I can look for other suspects. Can you please provide one?

The regressing bug only changed CSS, some test files, and flipped a pref (browser.toolbars.keyboard_navigation). If I flip the pref back (to false), I can still reproduce. So it seems unlikely this was the regressing bug, tbh.

Also:

(In reply to Cristian Fogel, QA [:cfogel] from comment #0)

  1. Click away to close the ETP menu;

The recording clicks the same icon again. If instead of this, I click elsewhere on the webpage, I cannot reproduce. Do you see the same thing?

Flags: needinfo?(cristian.fogel)
Summary: Focus menu for search results displayed on Wikipedia when accessing options from address bar → Focus menu for search results displayed on Wikipedia when focus is restored to the webpage after accessing options from address bar

Indeed wrong copy in the section, sorry for the wasted time on this.
Oddly enough mozregression points out to the same bug after re-checking.

Updated the 1st comment with the main regression range, after a first bisection I got this result; hopefully it helps out more.

With clicking on the webpage at step 5, indeed the issue does not reproduce.
It appears to be limited to the browser(buttons, filler area between buttons).

Flags: needinfo?(cristian.fogel)

(In reply to Cristian Fogel, QA [:cfogel] from comment #4)

With clicking on the webpage at step 5, indeed the issue does not reproduce.
It appears to be limited to the browser(buttons, filler area between buttons).

Does the issue go away for you if you toggle browser.toolbars.keyboard_navigation to false and restart the browser?

Flags: needinfo?(cristian.fogel)

(In reply to :Gijs (he/him) from comment #5)

Does the issue go away for you if you toggle browser.toolbars.keyboard_navigation to false and restart the browser?

The issue does not reproduce after this.

Flags: needinfo?(cristian.fogel)
Attached video Focus changes

(In reply to Cristian Fogel, QA [:cfogel] from comment #6)

(In reply to :Gijs (he/him) from comment #5)

Does the issue go away for you if you toggle browser.toolbars.keyboard_navigation to false and restart the browser?

The issue does not reproduce after this.

I'm confused. I see the same thing even when the pref is false - see the attached screencast. Please clarify - does this only happen on some OSes if the pref is false, or something?

Flags: needinfo?(cristian.fogel)

You are right, there is an inconsistency here that, I overlooked in checking with Windows 10 alone.
So, with the preff: browser.toolbars.keyboard_navigation and Firefox 75.0a1 (2020-02-17) we have:

Windows 10

  • Pref On - menu pops up
  • Pref Off - no menu

macOS 10.13.6

  • Pref On - menu pops up
  • Pref Off - menu pops up

Ubuntu 19.04

  • Pref On - menu pops up
  • Pref Off - no menu
Flags: needinfo?(cristian.fogel)

Jamie, I'm not sure there's much to be done here, though I did just realize that the same thing doesn't happen with e.g. the hamburger menu - so there's something special about keyboard navigation and the protections panel. Any idea what, and/or if we can do without it?

Flags: needinfo?(jteh)

There are a few things at play here:

  1. The reason the hamburger menu and the protections panel are different is that the protections panel clears focus when it opens, but the hamburger menu doesn't. I'm guessing noautofocus might be set on the hamburger but not on protections, but I haven't verified that.
  2. When toolbar keyboard navigation is disabled, the protections button is always focusable (via -moz-user-focus). This preserves the behaviour prior to the toolbar key nav feature.
  3. That means that when you click the button, it gains focus. Then, the panel opens and we clear focus. When you dismiss the panel, DOM code restores focus to the last thing that was focused before the panel opened; in this case, the protections button.
    • While it does seem to avoid the problem being discussed here, I really don't think this is ideal. Focus should go back to where it really was.
  4. In contrast, when toolbar keyboard navigation is enabled, the button isn't focusable except when forced by toolbar key nav.
  5. That means that when you click the button, it does not gain focus. Then, the panel opens and we clear focus. When you dismiss the panel, DOM code restores focus to the last thing that was focused before the panel opened; in this case, the Wikipedia search field.

Possible solution: Set noautofocus on the protections and site identity panels.

  • I don't think this will break keyboard activation, since focus is explicitly managed when activated via keyboard, but that would need to be verified.
  • However, it might mean that you can't click to open the panel and then switch to the keyboard to navigate it. Again, needs to be verified.
Flags: needinfo?(jteh)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Priority: -- → P3
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/7cc74322940e
set noautofocus on identity and control center popups to prevent stealing focus from the content, r=Jamie,johannh
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 75

Verified with 75.0a1 (2020-02-24) on Windows 10, macOS 10.15, Kubuntu 19.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.