[Phase 2] [Intermittent] The Address bar drop down flickers when typing or deleting characters slowly
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | affected |
People
(Reporter: cfat, Unassigned)
References
Details
Attachments
(2 files)
[Notes]:
- This issue is reproducible only if you are enrolled in the Firefox Suggest experiment, or if you have previously set the preferences from the prerequisites on the Firefox profile.
- This issue is also reproducible when deleting the characters slowly.
- This issue is also reproducible when you have at least 1 character typed in the Address bar, click outside the bar, and then click inside it.
- This issue is encountered no matter if the sponsored results are displayed or not.
- Since this issue is very intermittent we are not sure if it’s also reproducible on macOS or Linux. From our attempts, we didn’t manage to reproduce the issue on these OSes.
[Affected versions]:
- Firefox RC 89.0 Release (Build ID: 20210524222230);
[Affected Platforms]:
- Windows 10 x64;
[Prerequisites]:
- Have the latest RC 89.0 Release installed.
- Have the following prefs set:
browser.urlbar.quicksuggest.enabled
totrue
.browser.urlbar.experimental.firefoxSuggestLabels.enabled
totrue
.browser.urlbar.quicksuggest.showedOnboardingDialog
tofalse
.browser.startup.upgradeDialog.version
to89
.
[Steps to reproduce]:
- Open the Firefox browser with the profile from prerequisites.
- Open a new tab and type a character in the Address bar (e.g. “a”).
- Observe the Address bar drop down.
[Expected result]:
- There is no flicker of the Address bar drop down.
[Actual result]:
- The Address bar drop down flickers.
[Additional Notes]:
- Attached a screen recording of the issue.
- I also made a profiler in case it helps to find out what happens when reproducing the flicker. You can find it here and also in the attachments section of the bug.
Reporter | ||
Comment 1•3 years ago
|
||
Comment 2•3 years ago
|
||
Thanks Carmen. In your screen recording, no quick suggest result ever appears. What was the state of your profile at the time you made the recording? Was it exactly as your STR say? i.e., did you complete the steps in the prerequisites and then make the recording? Did you restart once or more? I'd like to know if quick suggest results never appeared using the profile in the screen recording, or if they appeared at some point and then you modified the profile so that they didn't appear anymore.
Also, is "Show search suggestions ahead of browsing history in address bar results" in about:preferences#search checked?
Right now I suspect bug 1710648, but that should only come into play when a QS result is present, which it's not in the screen recording.
Your profiler data is potentially very helpful so thanks for that. If you're ever able to get reliable STR, that would really help. If you can narrow the regression range to exclude/include bug 1710648, that would also help.
Reporter | ||
Comment 3•3 years ago
|
||
@Drew, so for the screen recording, I followed the prerequisites and the steps to reproduce from the description. After setting the preferences from the prerequsites, I restarted the browser once so that the prefferences are applied correctly to the browser session. After the restart, I started typing characters inside the Address bar and noticed the flicker of the drop down. I also noticed quick suggest results on the same profile, but I cannot explain why there aren't any in the recording. I didn't alter the "Show search suggestions ahead of browsing history in address bar results" option, so yes, it was checked all the time. The recording was indeed made after adding the preferences from prerequisites and after noticing that the flicker happens every time I type or delete a character in the Address bar.
However, this morning I was able to reproduce the issue again after enrolling in the experiment.
The exact steps were the following:
- I created a new Firefox RC 89 (release) profile and started the enrollment process by adding the user.js file in the Profile Folder from "about:support" page.
- After restarting the browser once to complete the enrollment, I typed several characters.
- The issue was not reproducible at that time, so I minimized the browser and took care of other tasks not relatable to the experiment.
- After ~1 hour, I maximized the browser and typed again different characters, slowly.
- At this point, I noticed that the bug was reproducible.
- I made another recording where you can see that the issue reproduces with or without quick suggest results being triggered.
- The "Show search suggestions ahead of browsing history in address bar results" option was checked.
- The bug is no longer reproducible if the browser is restarted.
- I followed the same steps few more times during the day (with new profiles) but didn't reproduce the issue again.
This is a very intermittent behavior and I think it would be very difficult to narrow down a regression range. My colleagues will resume testing Phase 2 next week and if they are able to find out more steady steps to reproduce or relevant information, they will add it to the report.
Comment 4•3 years ago
|
||
Thank you Carmen!
Comment 5•3 years ago
|
||
This actually looks like what happens when your network is a little slow, or when the search engine is a little slow to provide suggestions. I can't say for sure that's what this is, but that would have the same effect. I can reproduce it if I add an artifical ~200ms delay to the search suggestions provider.
I was thinking this might be related to the stale-rows timer, but the delay between keypress and view update in the gifs looks shorter than the stale-rows 400ms timeout to me. Hard to say.
Comment 6•3 years ago
•
|
||
I took a closer look at the attached profile. Using the profiler's marker chart and network tabs, you can see a series of the following steps:
- An input event
- A call to
startQuery
- A call to
SearchSuggestionController._fetchRemote
- A long period where nothing happens but the network request is pending
- The stale-rows timer fires after 400ms
- A little later (~20ms), the XHR for the remote suggestions finally gets
readystatechange
,progress
,load
,loadend
events. To take one example, the network tab shows that the HTTP response took 366ms.
There's a series of these steps, one per keystroke.
So it does look like the suggestions are just taking a while to arrive here. This isn't related to quick/Firefox suggest, and there's nothing we can do about slow suggestions or a slow network. We do have bug 1560690 for investigating urlbar behavior with a slow network, and there's room for improvement with regard to the flickering, which we would work on as part of that bug or a follow-up.
Carmen, thank you very much for providing the profile. I'll dupe this to bug 1560690. Pablo reported a similar bug, bug 1663949, and Marco duped it there. If you think there's a good reason to leave this open, please let me know.
Comment 7•3 years ago
|
||
Whoops, I meant bug 1647721 is the dupe. It's not exactly the same since it's about Amazon and Wikipedia, but the basic problem is very similar. I'll add bug 1560690 as a see-also.
Description
•