Closed Bug 1627861 Opened 8 months ago Closed 8 months ago

megabar should not have additional padding if suggestions popup is not open but has focus

Categories

(Firefox :: Address Bar, defect)

75 Branch
defect
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: yoasif, Unassigned)

References

Details

(Keywords: losing-users, parity-chrome, parity-safari)

Attachments

(1 file)

Seeing a lot more feedback about megabar post 75 release, and this enhancement just struck me.

Steps to reproduce:

  1. Open Firefox
  2. Do Ctrl-l
  3. Type anything
  4. Hit escape

Expected result:

Since there is no reason for expansion (no top sites or suggestions), I expect that the padding should not be around the megabar, and instead, it ought to look like the old addressbar focus (just a stroke around the bar).

What happens:

The megabar padding is present and looks out of place. The styling of megabar looks great in the expanded state, but looks bulky and out of place when not expanded.

Note: I am not a megabar hater. I generally like it and I think it makes Firefox look more modern and the old full-width addressbar didn't really have that much more going for it.

However, there is one thing that has been nagging me for a while, and I just realized what it is: the megabar always expands even when there is no reason for it to be expanded. Focus isn't enough (imo) to explain why it ought to be expanded, because if that were the case, the separate search box should also be expanded as soon as it gets focus - the fact that it doesn't implies to me that it simply isn't that interesting for it to have to be consistent.

I hope this suggestion wasn't already WONTFIXed - it would go a long way to making the megabar look great in all states, not just the expanded one.

FWIW, this is exactly how Chromium works. No shadows (for example) until suggestions appear. Just a simple focus otherwise.

See Also: → 1627857
Summary: megabar should not have additional padding if suggestions popup is not open → megabar should not have additional padding if suggestions popup is not open but has focus

We had this state and eventually removed it in bug 1589826 after discussing this extensively with Verdi.

Status: NEW → RESOLVED
Closed: 8 months ago
Depends on: 1589826
Resolution: --- → WONTFIX

I have been using this for the entire time, and while it hasn't annoyed me enough to open a bug previously, it feels really weird. The fact that that feeling hasn't gone away in 5 months isn't a great sign that I will eventually get used to it - it just feels like a straight up improvement.

I'll point out (as earlier) that Chromium acts the same way - I don't use it often, but this interaction in Chromium has never felt weird to me, I think basically due to this bug.

I hope that you folks eventually reconsider, especially since you haven't felt the need to make this behavior consistent with the separate search bar - which retains the original stroke without padding look that I referenced in this bug.

I'll also point out that I just ran build 20191018214804 to see what it looked like, and it isn't really the same thing that I have asked for at all. Prior to bug 1589826, expansion still occurred without any suggestions being present, for example (in a new tab). The styling was there, but the interactions prior to bug 1589826 feel like they are a mix of old and new behaviors, rather than a considered interaction to show expansion when there are suggestions, and to go back to a non expanded view when there are none.

I too think this reduces the uncomfortableness of the new design. The userChrome.css below implements the proposed change--maybe it helps some users stumbling upon this ticket.

/* based on https://old.reddit.com/comments/fwhlva//fmolndz */
#urlbar[breakout][breakout-extend]:not([open]) {
  top: calc((var(--urlbar-toolbar-height) - var(--urlbar-height)) / 2) !important;
  left: 0 !important;
  width: 100% !important;
}
#urlbar[breakout][breakout-extend]:not([open]) > #urlbar-input-container {
  height: var(--urlbar-height) !important;
  padding-block: 0px !important;
  padding-inline: 0px !important;
}
#urlbar[breakout][breakout-extend][breakout-extend-animate] > #urlbar-background {
  animation-name: none !important;
}
#urlbar[breakout][breakout-extend]:not([open]) > #urlbar-background {
  box-shadow: none !important;
}
Keywords: parity-chrome

I think that it should not expand unless there is text entered. Opening a new tab and having this already expanded hurts me eyes.
Also, hitting the escape key kills suggestions, then removes text. I use that feature a lot. I think hitting escape should shrink the box back to normal because there is then no more text.
Forgive me if I am wrong to post this in a "closed" report.

Duplicate of this bug: 1628092

Just as an heads up, even if this specific bug is wontfixed, your feedback is being reported to our UX experts.

See Also: → 1628243
Duplicate of this bug: 1628022
Duplicate of this bug: 1628054
Duplicate of this bug: 1628035

After evaluating and discussing feedback, we decided to keep the expansion when the panel is closed. We'll address concerns about the bookmarks toolbar in Bug 1628243.

Status: RESOLVED → VERIFIED

expansion when the panel is closed.

So, to escape:

  1. do not key Esc
  2. key Tab
See Also: 1628243

I've commented previously on bug 1629303 about the expansion animation being distracted. I've now tried the userChrome.css from tobias above and this is by far my preferable solution (the bar expanding only when there is extra content to show).

Sidenote: I really appreciate nextbern linking to specific bugs here on reddit, bless his soul for having to deal with all the people upset at him.

Possible solution for many megabar-oriented frustrations...

(In reply to maciej.hirsz from comment #21)

I've commented previously on bug 1629303 about the expansion animation being distracted. I've now tried the userChrome.css from tobias above and this is by far my preferable solution (the bar expanding only when there is extra content to show).

As a professional functional analyst, I've been thinking about the interface for a few hours. I also made mock-ups in GIMP to try some solutions.
I totally agree with the above comment, and come to the same conclusion as many hidden commentators. The padding shouldn't be there when there are no suggestions or Top Sites shown. This would solve many problems users are reporting here, on Reddit and other places.

I made an activity diagram to show a possible solution (see attachment). The presented diagram is also a solution for bug 1628243 (as bookmarks won't be covered at the wrong time i.e. when the user is not interacting with the address bar). It eliminates the need for a collapsed megabar state (I think).

Please consider reopening this bug!!

They made it to bring attention to the address bar. The extra padding is only needed until you begin to interact with it. If they remove it when there are no suggestions or Top Sites, there is no need to add it back when there are. It is WONTFIX'd because it defeats the purpose of adding extra padding in the first place.

IMHO the easiest and best solution is to add a preference to turn it off.
That way new and inexperienced users will get the desired behaviour, while power users can enjoy browsing without that annoyance.
Win-win.

Also https://old.reddit.com/r/firefox/comments/fwhlva/-/fmq222r/?context=1

(In reply to Csaba Bencze from comment #25)

They made it to bring attention …

That's the essence of the problem. Use cases where the attention is unwanted; distracting, disruptive to trains of thought.

This is not a knee-jerk reaction. I tried to like (or at least ignore) the repeated unwanted enlargement for a few hours. Ultimately intolerable.

https://old.reddit.com/r/firefox/comments/fwhlva/-/fn6cdbe/ includes a link to a specification document.

… add a preference to turn it off. …

👍

From https://bugzilla.mozilla.org/show_bug.cgi?id=1561531#c68

… instinctively click somewhere else or use the esc key …

This bug has been closed as WONTFIX by the people responsible for making decisions on the components in question. As we've already had to deal with abusive comments towards other contributors here. I'm closing this bug to further comment.

Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.