Pressing down on the current url should search for the url, not the empty string
Categories
(Firefox :: Address Bar, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox68 | --- | fixed |
People
(Reporter: mak, Assigned: adw)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
In the awesomebar clicking the dropdown always runs the empty-string search, but pressing DOWN always searches the current string, even if it's the current url.
STR:
- in this tab, click on the urlbar
- press DOWN
Actual result:
The empty-string search runs
Expected result:
the current url should be searched
Bug 1538158 fixed the dropdown case, but broke this one.
|
Reporter | |
Updated•6 years ago
|
|
Assignee | |
Comment 1•6 years ago
|
||
|
|
Assignee | |
Comment 2•6 years ago
|
||
Also, clicking the dropmarker shouldn't clear the input text.
|
||
Comment 3•6 years ago
|
||
(In reply to Marco Bonardo [::mak] from comment #0)
In the awesomebar clicking the dropdown always runs the empty-string search, but pressing DOWN always searches the current string, even if it's the current url.
STR:
- in this tab, click on the urlbar
- press DOWN
Actual result:
The empty-string search runsExpected result:
the current url should be searched
FWIW I'm not really sure what the point of that behavior is. It seems mostly useless legacy, although I can see how a tiny minority of users would get used to it and somehow expect it. Still, I'm not yet convinced we should carry that behavior forward.
|
|
Reporter | |
Comment 4•6 years ago
|
||
The current goal is to replicate the old urlbar behavior. I agree we should revise this in the future, and that's also the argument of the first experiment. Until then, we should reduce the number of different behaviors as far as possible.
|
|
||
Comment 5•6 years ago
|
||
I don't think that's how we've actually operated. Yes, the first goal is to reach parity, but we deliberately changed little things where that made sense to us. Can somebody make a case for why this behavior is generally desirable or important for feature parity?
|
|
Reporter | |
Comment 6•6 years ago
|
||
The fact pressing down clears the current url looks just wrong and prone to spoofing issues. The same when clicking on the dropmarker, the textbox value should stay there. Having to escape twice to get it back is a usability regression.
In any case I think we must revert that change, the current value must stay in the textbox in all the cases.
We may discuss about the panel contents, but since we don't know what we want there, until we actually collect data from experiments, we have nothing telling us the old behavior is worse or better. On the other side, this change looks like may influence the results for the first experiment that indeed wants to measure differences when we make down/dropdown always return a consistent set of results (top sites) instead of results relative to the current url. Doing this now would mostly compare the effect of slightly changing the list of results, rather than the behavior. It would take the result of the experiment without measuring it first.
Regarding use-cases for the old behavior, first it is consistent with Chrome, that is a positive for users migrating. Then if I'm on the homepage of a website, I can press down to get the most common pages from that website. These may not be good enough, that's why Verdi is thinking to provide a pre-search experience.
|
|
||
Comment 7•6 years ago
|
||
(In reply to Marco Bonardo [::mak] from comment #6)
The fact pressing down clears the current url looks just wrong and prone to spoofing issues. The same when clicking on the dropmarker, the textbox value should stay there. Having to escape twice to get it back is a usability regression.
In any case I think we must revert that change, the current value must stay in the textbox in all the cases.
Yes, that was an oversight / unintended side effect. The empty search however wasn't from my POV.
Regarding use-cases for the old behavior, first it is consistent with Chrome, that is a positive for users migrating.
... only if users actually want that. Personally I kind of got used to the behavior, i.e. I accepted it as a quirk, but I never really want it. It's not something I'd consider positive when switching browsers.
Then if I'm on the homepage of a website, I can press down to get the most common pages from that website.
Yes, that's the type of tiny minority use case I was thinking about. Given that most users don't even understand URLs, I expect that presenting top sites is better for most users. Power users could still get those site results by going to the end of the URL and pressing Space.
|
|
||
Comment 8•6 years ago
|
||
One more thing I haven't commented on but should have for clarity: Having data is definitely a plus (assuming the data is good and interpreted correctly, etc.), but it's not like we can't make educated guesses to come to design decisions without telemetry. We've done that forever (including in the most recent quantumbar work) and data isn't going to fully replace that.
|
|
Reporter | |
Comment 9•6 years ago
|
||
IT's all true, but we have an experiment in the pipeline that exactly affects this case, that's still the main reason for which I think we should not confuse things by having 3 different behaviors (legacy, qb, experiment) for QA and us to discuss about.
|
|
||
Comment 10•6 years ago
•
|
||
I made a similar argument for the search suggestions notification: implementing it in the Quantumbar would make for a fairer comparison with the legacy urlbar, when looking at how new users interact with the urlbar. Yet we decided not to port that.
For the experiment, we're primarily going to measure against the then-status-quo, i.e. the Quantumbar, right? For that I think it would actually be beneficial if we made the base behavior as sane as possible to the best of our knowledge before comparing.
|
||
Comment 11•6 years ago
|
||
For UI elements that need to be re-implemented at significant cost for an insignificant gain, we should re-evaluate whether we should do it. I still think that not implementing the search suggestions notification was a good idea.
For behavorial changes and considering to deviate from the AwesomeBar is a different case, where we should be easier in accepting to port over debatable patterns and defer the design and implementation to a followup. When we're done getting QB ready for release, we are far from done with making changes to it; it should be more straightforward and easier to do in fact.
|
|
||
Comment 12•6 years ago
|
||
(In reply to Mike de Boer [:mikedeboer] from comment #11)
For UI elements that need to be re-implemented at significant cost for an insignificant gain, we should re-evaluate whether we should do it. I still think that not implementing the search suggestions notification was a good idea.
FWIW, porting it would have been trivial. And my point was that I didn't think the gain was insignificant when it came to being able to compare the Quantumbar against the legacy urlbar. In any case I consider the gain of parity with legacy here even less significant for the purpose of the experiment, if not even harmful as explained in comment 10.
|
|
Assignee | |
Comment 13•6 years ago
|
||
I'll make a revision that adds a test and addresses the technical problem that Dao noted in review, but I'll keep the behavior (i.e., parity with awesomebar) since most votes are for that.
|
|
Assignee | |
Comment 14•6 years ago
|
||
| Comment hidden (obsolete) |
|
|
||
Comment 16•6 years ago
|
||
(In reply to Drew Willcoxon :adw from comment #13)
I'll make a revision that adds a test and addresses the technical problem that Dao noted in review, but I'll keep the behavior (i.e., parity with awesomebar) since most votes are for that.
I don't think my points in comment 10 were really addressed, and I'd rather be convinced than outvoted. I'll bring this bug up in the next meeting.
|
|
||
Comment 17•6 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #16)
(In reply to Drew Willcoxon :adw from comment #13)
I'll make a revision that adds a test and addresses the technical problem that Dao noted in review, but I'll keep the behavior (i.e., parity with awesomebar) since most votes are for that.
I don't think my points in comment 10 were really addressed, and I'd rather be convinced than outvoted. I'll bring this bug up in the next meeting.
Resolved in the meeting; there was a misunderstanding on my side about what exactly the planned experiment is going to test. Turns out it's not just about activity stream becoming the source for the top sites, but also specifically about showing these results instead of searching for the current URI when clicking the dropdown. I'm not sure if we really need an experiment for that aspect (because I'm sure the legacy behavior is fairly useless for most users) but since the experiment is already planned we'll restore the legacy behavior for now.
|
|
||
Updated•6 years ago
|
|
||
Updated•6 years ago
|
|
|
||
Updated•6 years ago
|
|
||
Comment 18•6 years ago
|
||
|
||
Comment 19•6 years ago
|
||
| bugherder | ||
|
||
Updated•6 years ago
|
|
||
Updated•4 years ago
|
I wasn't able to reproduce this issue. Please, would you be so kind as to verify this fix on latest the latest Beta/Nightly builds?
Thank you.
|
||
Comment 21•3 years ago
•
|
||
I don't believe this fix is relevant anymore. Functionality here has changed.
AIUI, this is a missed qe+ that slipped betwen the cracks before we have had implemented failsafes to catch the qe+ flags.
|
|
Assignee | |
Comment 22•3 years ago
|
||
(In reply to Adrian Florinescu [:aflorinescu] from comment #21)
I don't believe this fix is relevant anymore. Functionality here has changed.
Yes, you're right. Thanks Ardelean and Adrian.
Description
•