1561531 - (urlbar-update-1) [meta] Quantumbar design update 1

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, enhancement, P3)

Description

[Dão Gottwald [:dao]]

Invision spec: https://mozilla.invisionapp.com/share/DNSDVW5E8QK#/screens/367251846_Photon_Design_Update

Comment 1

[Nathan V]

The invisionapp link is dead, so I don't know what this is SUPPOSED to look like, but it looks like trash on the latest nightly. It extends past other chrome elements around it, giving it a modal feel. On top of that, it doesn't even increase the size of any elements inside of the awesome bar. So all you get is an ugly, over-padded modal around the same exact UI you had before. Even if you did change the elements inside to match, why? What purpose does this serve? Was any testing done at all or did somebody at a focus group just say "hey, I've got an idea to change the UI for the 15th time in the last 2 years!"?

I have absolutely no idea how this got past the design phase and why you guys decided to just roll with yet another big UI change with 0 input from anybody who actually uses Firefox.

Comment 2

[Marco Bonardo [:mak]]

(In reply to Nathan V from comment #1)

but it looks like trash on the latest nightly

Thank you for your valuable feedback.

Comment 3

[B.J. Herbison]

(In reply to Dão Gottwald [::dao] from comment #0)

Invision spec: https://mozilla.invisionapp.com/share/DNSDVW5E8QK#/screens/367251846_Photon_Design_Update

The link is no longer valid. Where is the spec?

Comment 4

[Marco Bonardo [:mak]]

The spec is what you see in Nightly, modulo the bugs blocking this bug.

Comment 5

[Nathan V]

(In reply to Marco Bonardo [::mak] from comment #2)

Thank you for your valuable feedback.

Terribly sorry for my rudeness. Let me retry this:

Given that today, when this was turned on, was the very first time I'd even heard of "megabar", I'm going to assume most of it's conception and development was done in-house in meetings.

Given such a... radical... design change, I was wondering as to the technical merits of the design. As comment #3 pointed out, the spec link is dead so users coming here can't see what your intended purpose of the change is, and what's in Nightly is just what we had before, but with extra padding and a border. I guess the overall question is just a: why?

Design change for design's sake is rarely interesting or appreciated by users.

Comment 6

[Marco Bonardo [:mak]]

(In reply to Nathan V from comment #5)

Given such a... radical... design change, I was wondering as to the technical merits of the design.

I'll give you my opinion, that is not official at all, I'm not working on UX, I'm just a developer. The address bar is the primary point of interaction for all users, it deserves to be easily reachable and prominent. Users too often end up going through complicate hoops to visit a page they heard about (type www.facebook.com into www.google.com just to open facebook, for example), not even getting help during that navigation. Due to this, there are a bunch of wokarounds that browsers implement, like providing a search field in the new tab page, or showing notifications ("hey you can type your searches here!") for example. Also results and the input field now appear as a single entity, being less distractive, more workflow efficient and clearer.

Keep up with constructive feedback, we iterate over it.

Comment 7

[Serak Shiferaw]

Can i say it annoys Growing and shrinking, there is no problem with the original implementation. and if you are going to grow it please just expand it down wards only. everybody thought it was a bug,

Comment 8

[Serge]

Hi here,
Wanted to share my thoughts on this.
On compact mode it covers 2 toolbar buttons from each side which is awful.
The paddings are unnecessary huge.
It's hard to tell what purpose it serves. No doubt it attracts attention to the focused URLbar, but it a bad way by blocking other UI elements.
A simple box shadow (in the current implementation) update can serve similar purpose but in a better way.
Please also see feedback here
https://www.reddit.com/r/firefox/comments/dcksat/firefox_nightly_got_a_new_awesome_bar/

To sum up:
All in all it seems as a really bad idea.
As for now this is barely usable for me, it needs severe improvements

Comment 9

[Nathan Hubbard]

I would just like to provide some additional feedback about this change.
I discovered when opening firefox today that something was wrong with the browser because the urlbar was enormous and I couldn't get to the elements nearby (which I generally use, since I have bookmarks I like to visit) without clicking off it.
I assumed this was a broken theme change or something (I run daily builds after all), searched about:config, found the "browser.urlbar.megabar" option. Disabled it.
Well I cannot imagine how in any way having the urlbar grow enormously and covering up buttons I actually intended to press could improve usage for someone, perhaps I'm in the minority here.
Can this at least be disabled more obviously? Like right in the customize page?
Perhaps on compact views it is grayed out and not available?
Thanks.

Comment 10

[Marco Bonardo [:mak]]

The bookmarks problem is covered by bug 1561904.

Comment 11

[Danny Colin [:sdk]]

Can this at least be disabled more obviously? Like right in the customize page?

Megabar will become the default. However, I think (hope) the actual behavior is probably due to the fact that the new megabar hasn't been polished for the compact theme and also in the case the user removed the "flexible space" item in the toolbar. There's bug 1585958 covering that issue.

Comment 12

[Nathan Hubbard]

(In reply to Marco Bonardo [::mak] from comment #10)

The bookmarks problem is covered by bug 1561904.

I'm not using the toolbar, I have a single folder next to the urlbar. It was a great solution that's probably broken by this pointless giant urlbar feature. I recognize that I'm in the minority here, possibly the only person doing something like that.
I don't think that's really the issue though, because this new feature would annoy me anyway.

I've added "browser.urlbar.megabar = false" to my long list of things to undo in about:firefox. Hopefully that keeps working.

Comment 13

[Nathan Hubbard]

(In reply to Danny Colin [:sdk] from comment #11)

Can this at least be disabled more obviously? Like right in the customize page?

Megabar will become the default. However, I think (hope) the actual behavior is probably due to the fact that the new megabar hasn't been polished for the compact theme and also in the case the user removed the "flexible space" item in the toolbar. There's bug 1585958 covering that issue.

I hope that's true. Honestly the problem I have with the megabar is that it's mega to begin with.

Comment 14

[Gian-Carlo Pascutto [:gcp]]

I'm not using the toolbar, I have a single folder next to the urlbar.

I think that's covered by bug 1585958 (don't overlap toolbar buttons).

Comment 15

[Filip Š]

I personally don't like this version of Megabar.

With more details, I don't like Megabar "overflow" when it is clicked. It can block other buttons under it and it actually looks like some bug. Activated Megabar should be the same size as non-activated, only with some focus, and without so big padding and any overflow.

Other than that, I quite like Megabar, but that overflow looks like a very important fix to me.

Comment 16

[Matt Cosentino]

(In reply to Nathan Hubbard from comment #12)

(In reply to Marco Bonardo [::mak] from comment #10)

The bookmarks problem is covered by bug 1561904.

I'm not using the toolbar, I have a single folder next to the urlbar. It was a great solution that's probably broken by this pointless giant urlbar feature. I recognize that I'm in the minority here, possibly the only person doing something like that.
I don't think that's really the issue though, because this new feature would annoy me anyway.

I've added "browser.urlbar.megabar = false" to my long list of things to undo in about:firefox. Hopefully that keeps working.

You're not the only one, I put the bookmarks menu button next to the url bar and I often open an new tab and go directly to it. Now I open a new tab and this megabar overlays on top of the button. So now I have to click on the blank page to unfocus the megabar just to press the button. Not that I'm a fan of the full width dropdown for the old url bar though, so at least that is an improvement. Still seems like a lot of wasted horizontal padding for no reason.

Comment 18

[Sollace]

Hi. I got here from reddit (https://www.reddit.com/r/firefox/comments/dcksat/firefox_nightly_got_a_new_awesome_bar/)

Just wanted to put in my "me too" about the weird popping the new "ultra mega awesome bar" does. It's really distracting, and serves no real purpose than to get in the way of other parts of the browser UI.

Whilst this thing is open, I can't access any of the buttons to the immediate left or right of the "double ultra mega awesome bar". It covers the downloads button (if visible, otherwise it covers the main hamburger and spreads all the way off the end of the browser window). It covers the bookmarks/library button to the left, and most of the home button.

And again, it serves no actual purpose because the content inside the address bar doesn't even make use of that extra space. It's just padding for padding's sake. It's the kind of bad design decision that would, quite honestly, look more at home in Microsoft Edgernet Explorer.

Comment 19

[Celso]

I thought is was a bug because it doesn't look that good, at least on macOS with the dark mode enabled... I don't mind the change, but I think it should be expanded only when we start typing.

Right now it hides some important content when we open a new tab, even if we don't intend to use the bar: some Firefox buttons (home, reload), some add-ons, and part of the bookmark bar (which, by the way, doesn't centre the content (favicons/link text) in the middle of the bar due to different margins above/under the content - but this is unrelated to the new bar).

Sometimes I want to type an URL or search, but sometimes I just want to access a bookmark or see the new tab page content, so having the bar hiding stuff is not good.

Comment 20

[Chris Garcia]

-Ctrl + T
-Try to open a bookmark, but the button is blocked (would also apply to bookmark bar users)

I'm not a fan of the expanding Awesome Bar, or at least the way it behaves currently. I'm not inherently opposed to the idea but it should probably only expand while typing, it should be easier to dismiss, and currently the expanded window doesn't provide any extra information/usability (it just takes up more space)

Comment 21

[Marco Bonardo [:mak]]

Thanks everyone for the feedback and bugs filed, we are working on the problems you reported, and we'll come with solutions. Keep up with the good work.

Comment 22

[Nathan V]

I still don't think we've ever gotten an explanation as to why this change is happening in the first place. Given the amount of issues it's causing, and the general negative opinion from everybody commenting here, I think it might be best to explain the goals behind this change.

As far as I can tell, the input field and search results aren't changing, or if they are it's very minor. You're literally just making the field they're in disconnected from the rest of the chrome and making it bigger. It's a UI change, not a UX change. I'm surprised how adamant you guys are about implementing this.

Comment 23

[trinywiky]

Hi there,
I was also surprised at the beginning by this behaviour. It is true, that it drives the user's focus towards the navbar, however, it also distracts quite a lot and blocks different parts of the toolbar as other users have mentioned. I do like though the idea that url-suggestions belong to the bar and do not appear over the whole browser's width independently of it.

Maybe it would be possible to retain the original size and only enlarge it downwards when suggestions are shown. It would still block everything in the toolbar beneath (which does not happen with the current bar), but would not divert attention so much.

Comment 24

[Pomax]

This has been a rather jarring change, I've tried finding what this thing was even called for the past several days just so I can find the correct about:config flag to turn it right back off. The idea seems fine (put focus square and center on the awesome bar) but the execution is far too universal-behaviour-breaking. Text inputs that become overlay modals when focused is one of those things that, yes, draws people's attention, but shouldn't have to do this by "taking their attention hostage".

It'd probably also be worth adding a context option once you're in the megabar view that lets you turn that functionality off, immediately, with a checkbox. Similar to the checkboxes for the toolbar and menu bar.

(Also, and I don't know if this is specific to the megabar or not, changing the about:config flag for it requires a firefox restart. That feels unusual, changes to about:config usually just kick in without needing to restart the browser?)

Comment 25

[M Sikma]

I say this with the greatest of respect to the developers and the designers, but I believe it's worth reflecting on the amount of people (current users) who mistook this for a bug, or were so surprised they immediately left negative feedback. That's a sign that something is wrong. And it seems it's not just one or two specific fixable bugs, but the design concept in and of itself.

I understand that Firefox has carefully planned releases and that this is already decided and set in stone, and that no combination of words written here is possibly going to change that. But I do find this to be very questionable. How many software programs, websites and apps do you know make use of such intrusive design for commonly used elements? How was the determination made that users are insufficiently able to identify the URL bar when it is highlighted and that this necessitates such a change? How was the exact size and amount of padding decided on? What sort of feedback process was done and did it involve people outside of development?

I'm just one random Firefox user, and I understand you might not want to explain the rationale to every random user who happens to show up here. But this change is so controversial that I'll be surprised if this went through a sufficiently diligent feedback process. It's disappointing to see that feedback from users such as in the /r/firefox topic is essentially ignored—unless responses (other than "thanks for your feedback" which is not a real response) were given elsewhere and I've missed them.

Seriously, I totally respect the developers and I'm glad to be using Firefox every day. I've switched back from Chrome maybe two years ago and I haven't looked back. It's not my intention at all to come here and agitate people doing the work on this project.

But to me, the key issue here is that this is controversial—and controversial changes, such as major design changes to UI that is constantly seen and felt by every user, shouldn't be taken lightly. And I think that might be what happened here. At least the very least, I hope you can understand that it's frustrating when a ton of people who have committed to this software and use it every day respond to a major change negatively, and there is no reciprocal engagement.

Comment 26

[Marco Bonardo [:mak]]

Thanks everyone for the feedback and the bugs filed, please continue reporting unexpected problems as blocking this bug.

The team decided to delay releasing the feature to Firefox 72, taking a bit more time to ensure concerns are properly addressed.

Comment 27

[Nathan V]

The fact that you gave a "Thanks for your feedback" reply immediately after a user pointed out that nobody has addressed our comments with anything other than such a reply means that you're either not reading the feedback, or find it funny to the point that you're willing to mock it.

Both make me sad.

Comment 28

[Danny Colin [:sdk]]

(In reply to Nathan V from comment #27)

The fact that you gave a "Thanks for your feedback" reply immediately after a user pointed out that nobody has addressed our comments with anything other than such a reply means that you're either not reading the feedback, or find it funny to the point that you're willing to mock it.

Hm, Marco Bonardo mentioned, right after thanking people for their feedback, that the release of the megabar will be delayed to FF 72 so they can address the issues mentioned by all of us. I wonder who's not reading the comment :whistle:.

Comment 29

[Nathan V]

(In reply to Danny Colin [:sdk] from comment #28)

Hm, Marco Bonardo mentioned, right after thanking people for their feedback, that the release of the megabar will be delayed to FF 72 so they can address the issues mentioned by all of us. I wonder who's not reading the comment :whistle:.

Nightly is already on 71, he said he'll delay it to 72 (so a maximum of 6 weeks) to deal with bugs. The concerns posted on this thread are asking why they decided to implement such a design change, and whether or not it should be done. This was not addressed, nor does it seem they plan on answering any questions. My point remains valid.

In the end, the only conclusion I can come to is that there IS no reason for the design. Change for change's sake. Another "if we change the UI more, maybe some more Chrome users will want to use Firefox instead" with no thought given to how current users will view it.

Comment 30

[Roderic Day]

Hey, I also thought this was a bug and quizzed my friends to see if they were having it. It literally looks like a poor accidental out of control CSS rule.

It blocks buttons including forward and refresh, and half my bookmark icons.

Please make this optional.

Comment 32

[krystian3w]

No compatible with Classic theme on system (Windows 7, I no tested 8.1 / 10 with Classic theme).

Comment 33

[Marco Bonardo [:mak]]

(In reply to krystian3w from comment #32)

No compatible with Classic theme on system (Windows 7, I no tested 8.1 / 10 with Classic theme).

Please file a new bug, a screenshot of the current state would be nice there.
(note that Windows 7 extended support from Microsoft will cease on 14th of January 2020).

Comment 34

[krystian3w]

(In reply to krystian3w from comment #32)

No compatible with Classic theme on system (Windows 7, I no tested 8.1 / 10 with Classic theme).

https://bugzilla.mozilla.org/show_bug.cgi?id=1590103 marked as won't fix, becasue Classic theme support has already expired in Firefox ≈ 53.

Comment 35

[M Sikma]

Thanks everyone for the feedback and the bugs filed, please continue reporting unexpected problems as blocking this bug.

The team decided to delay releasing the feature to Firefox 72, taking a bit more time to ensure concerns are properly addressed.

I appreciate that this feature is being given more time for consideration, but I'm curious what exactly the process will be from here on?

First of all, is there any chance whatsoever that people's negative feedback to this feature will cause it to not become the default, even in version 72? I assume the answer is "yes", and that user feedback is considered valuable and useful rather than just an obstacle.

That being the case, how does Mozilla determine that a feature is worth including over the objections of numerous people? I understand that people who complain are also more likely to comment, and UX design doesn't just stop and end at the user's whims, but I would suggest there is none the less cause here to pause and fundamentally rethink this—and I'm wondering how exactly user feedback will be part of that process.

Comment 36

[Laurențiu Nicola]

How does Mozilla determine that a feature is worth including over the objections of numerous people?

You're ignoring the selection bias: most people who like the new design or simply don't care won't show up on Bugzilla to thank the developers. So if you come from an echo chamber like Reddit or whatever, you're unaware of what most people will think.

There was a lot more pushback on other Mozilla decisions (like Pocket) and while they promised they'll document the endpoint and open-source the server side, that still hasn't happened. If you insist, please pick a better fight than the URL bar taking an extra 100 pixels in width.

Comment 37

[Nathan V]

(In reply to Laurențiu Nicola from comment #36)

There was a lot more pushback on other Mozilla decisions (like Pocket) and while they promised they'll document the endpoint and open-source the server side, that still hasn't happened. If you insist, please pick a better fight than the URL bar taking an extra 100 pixels in width.

The difference there being that Pocket can be disabled, doesn't disrupt workflow, and had an obvious reason for being added to Firefox (mozilla had just purchased them and wanted to expand the userbase and make Firefox look more appealing to existing pocket users).

Meanwhile, devs have said they're removing the pref to disable the megabar, it definitely gets in the way of many workflows, and has no obvious reason for existing. Plus, the design spec is STILL missing, so I'm wondering if even the devs know what the hell it's supposed to look like.

Not to mention, you call Reddit an echo chamber, but I disagree. For more focused subreddits, yes. For one as generic as "Firefox" with almost 90k users, there's enough variety there. Not to mention, the most active mod (throwaway) has some raging love for Firefox that goes beyond mere words. He alone offsets any hatred for FF the sub has.

But as I've seen, bugzilla is not a place for discussion apparently. The devs won't even answer simple questions here. I guess we should stop giving feedback completely, seeing as how any negative feedback is seen as selection bias.

Comment 38

[Danny Colin [:sdk]]

(In reply to Nathan V from comment #37)

But as I've seen, bugzilla is not a place for discussion apparently. The devs won't even answer simple questions here. I guess we should stop giving feedback completely, seeing as how any negative feedback is seen as selection bias.

Lots of feedback have been taking into account. One example is the megabar was obfuscating the toolbar icons. It doesn't anymore. The only visible difference at the moment versus the old urlbar is that it doesn't take the whole width and there's a new search icon in the toolbar. So, it's a bit exaggerated to that it "gets in the way of many workflows"

Plus, the design spec is STILL missing, so I'm wondering if even the devs know what the hell it's supposed to look like.

Well, don't use Nightly if you don't want to be a guinea pig. This version is definitely the right place to test new ideas and see how it goes. Again, you should stick to Release (or Developer Edition if you do webdevelopment).

Comment 39

[Albert Scheiner [:alberts]]

While I was a bit averse of the effect at the beginning (while it also was much bigger), I now must say that I gotten used to it and even start liking the bigger active UI. Still think the search icon looks a bit disjointed, but I might file a ticket for that tomorrow or so.
Just wanted to throw in another perspective, as I am usually also loudest when I want to complain about something. Sry for the noise ;)

Comment 40

[Simon THOBY [:nightmared]]

Hello there, just wanted to say I kind of liked it despite all the hate it got on this thread ;)

And also, I was wondering: why was the default switched to 'false' in about:config ? (latest nightly build by Mozilla, on x86_64 GNU/Linux)

Do you plan on deferring this feature further ?

Anyway, keep up the good work !

Comment 41

[Marco Bonardo [:mak]]

We're waiting for a new design spec, in the meanwhile testing the current one is not particularly useful. We'll re-enable the feature when ready, you can still enable it manually flipping browser.ulrbar.megabar and browser.urlbar.view.stripHttps to true.

Comment 42

[Marco Bonardo [:mak]]

I'm updating the specs link for the first iteration. There will be more work, features and experiments coming after this.

Comment 43

[Mehmet]

(In reply to Marco Bonardo [:mak] from comment #42)

I'm updating the specs link for the first iteration. There will be more work, features and experiments coming after this.

Thank you for providing the link 👍

Comment 44

[Sollace]

(In reply to Marco Bonardo [:mak] from comment #41)

We're waiting for a new design spec, in the meanwhile testing the current one is not particularly useful. We'll re-enable the feature when ready, you can still enable it manually flipping browser.ulrbar.megabar and browser.urlbar.view.stripHttps to true.

IMO browser.urlbar.view.stripHttps shouldn't even be an option. Removing visual indicators that you're on a secure page are TERRIBLE for user security.

Chrome did it, Firefox definitely SHOULD NOT.

P.s. Though it no longer obstructs part of the UI, I still don't like the obnoxious bulging. It's pointless, and imo really distracting. If you do keep it, I'd only enable it on touch devices and keep it off for desktop users by default.

Comment 45

[Danny Colin [:sdk]]

(In reply to Sollace from comment #44)

IMO browser.urlbar.view.stripHttps shouldn't even be an option. Removing visual indicators that you're on a secure page are TERRIBLE for user security.

There still is a visual indicators (the lock icon) that is even more accurate than the HTTPS. It's better because it let you know if the whole page is served as HTTPS or if there's mixed content. It also lets you know that the page is insecure when it's a self-signed HTTPS page.

Comment 46

[Darkspirit]

(In reply to Sollace from comment #44)

Removing visual indicators that you're on a secure page are TERRIBLE for user security.
Chrome did it, Firefox definitely SHOULD NOT.

That is not correct. It's better for user security to focus on highlighting problematic cases only. Chrome unfortunately hid both protocols which is a bit confusing, yes. Firefox aims to hide https:// (the new majority), but showing http://. Chrome 81 will upgrade all mixed content to https. We should do it, too. (security.mixed_content.upgrade_display_content;true).
Edit: Filed bug 1601408.

Comment 47

[Sollace]

(In reply to Jan Andre Ikenmeyer [:darkspirit] (browser.urlbar.update1.expandTextOnFocus;false) from comment #46)

(In reply to Sollace from comment #44)

Removing visual indicators that you're on a secure page are TERRIBLE for user security.
Chrome did it, Firefox definitely SHOULD NOT.

That is not correct. It's better for user security to focus on highlighting problematic cases only. Chrome unfortunately hid both protocols which is a bit confusing, yes. Firefox aims to hide https:// (the new majority), but showing http://. Chrome 81 will upgrade all mixed content to https. We should do it, too. (security.mixed_content.upgrade_display_content;true).

bugzilla please just let me post a reply

Okay, that's a reasonable change. I was worried you'd be copying what Chrome is doing.

Comment 48

[Sollace]

Back to my original PS before people posted whilst I was typing:

To add to my previous point:

Firefox already has a lot of inputs that do not use the bulging effect. One example being the search bar right next to the address bar (if enabled). Also a lot of search bars/input fields in the options pages and screens.

If this is about accessibility on touch devices (after all, zooming would at least help my fellow fat-fingered surfers), I think Firefox should rather update all of them and be consistent. If it doesn't work everywhere, then maybe it shouldn't be used anywhere. Alternatively use the blue outline on the address and search bar like you do on the rest. I'd personally prefer that over blowing them up like a balloon.

Comment 49

[Marco Bonardo [:mak]]

(In reply to Jan Andre Ikenmeyer [:darkspirit] (browser.urlbar.update1.expandTextOnFocus;false) from comment #46)

May I ask you to please remove pref settings from your nickname? It may confuse other users seeing it, there are better places to discuss settings than a nickname. Thanks.

Comment 50

[Meinert]

The "megabar" thing feels like a very "touch" centric design change. Like if I was on a small form factor device that had a touch screen I wouldn't mind it (think 13" or smaller laptop/tablet type devices), but right now using it on a desktop I just find it annoying (No technical reasons just personal reasons).
Perhaps an alternative would be to just increase the thickness of the border that already appears when the nav bar has focus or at the very least allow users to turn it off/on as an accessibility option or something.

Comment 51

[Sollace]

I'll also add that there are issues with how the mega bar behaves right now that make it especially annoying. It auto-bulges when you open a new tab, and in many situations clicking away from it (like in about:preferences) doesn't actually remove focus from the address bar, giving it this "permanenly swol" look.

Comment 52

[Marco Bonardo [:mak]]

clicking on content should remove focus from the urlbar, please file a bug for about:preferences.

Comment 53

[Sollace]

(In reply to Marco Bonardo [:mak] from comment #52)

clicking on content should remove focus from the urlbar, please file a bug for about:preferences.

Alrighty, bug report filed. https://bugzilla.mozilla.org/show_bug.cgi?id=1601647

Comment 54

[Aravindan]

Hello! I wanted to provide some feedback about how the address bar looks right now. I recently updated my nightly to version 73.0a1, and the address bar seems to have gone through another change. Now, the font is very large when the bar is focused, and the padding in the sides also seems to have reduced. In my opinion, the large font makes it look very displeasing, and the padding seems inconsistent with the top and bottom padding for the section that has the search engine icons. Why was this change made?

Comment 55

[Marco Bonardo [:mak]]

Thank you for your feedback, we are still evaluating the font size increase, this is Nightly after all, it's made to test changes and collect feedback before those changes are released. What you are reporting is likely similar to bug 1601320.
This is preparatory design work for a lot of new interesting features that will come in the future, the final scope is to make the whole searching experience more pleasant and understandable. Obviously design changes are subjective and may not please everyone.

Comment 56

[Aravindan]

Ah, yes, exactly what bug 1601320 is. I understand that design changes are obviously subjective, but this feels like a change that would be considered to not be great among more people than those who do think it's great.

Comment 59

[BelFox]

Long-time user here, did some thorough testing with the new megabar. Not convinced of the expanded location bar at first, but I can get used to it.

However, I think the badges on the favicons (implemented as described in the specification) are too small to be easily noticed and recognized as a star, tab, ... This could pose a problem for visually impaired people. The badges also add visual clutter to the favicon column. For these reasons, I prefer the separate column for bookmarks and tabs from the old implementation.

I'm not sure if I should create a bug for this?

Comment 60

[Jens Mühlenhoff]

I don't like this new feature.

1. The extra attention it brings to the address bar is unnecessary.
2. It convers part of the bookmark toolbar, so I have to click somewhere else first to see my bookmark toolbar, which I find very annoying.

Please either add a user preference to disable it or at least don't cover parts of the bookmark toolbar.

Comment 61

[Marco Bonardo [:mak]]

(In reply to Jens Mühlenhoff from comment #60)

2. It convers part of the bookmark toolbar, so I have to click somewhere else first to see my bookmark toolbar, which I find very annoying.

it should only cover a couple pixels, so the toolbar is usable, you shouldn't need to click elsewhere first. Isn't that the case?

Comment 62

[Jens Mühlenhoff]

(In reply to Marco Bonardo [:mak] from comment #61)

(In reply to Jens Mühlenhoff from comment #60)

2. It convers part of the bookmark toolbar, so I have to click somewhere else first to see my bookmark toolbar, which I find very annoying.

it should only cover a couple pixels, so the toolbar is usable, you shouldn't need to click elsewhere first. Isn't that the case?

That is the case, I don't technically have to click somewhere else first, but I instinctively do that.

Comment 63

[chrisfv]

I don't want to submit a new bug unnecessarily, but I am concerned this buggy implementation has apparently made into 74b6 already. I thought it would be fixed by now, but it wasn't.

I simply cannot get this to work, clicking in URL bar shows urlbar "enlarge" and in focus, but no history list is shown.

Only way to "fix" is to refresh firefox, and even that, it only work once and will have same problem again.

This has to be a big blocker and cannot made to final release as is.

Comment 64

[Drew Willcoxon :adw]

(In reply to chrisfv from comment #63)

I simply cannot get this to work, clicking in URL bar shows urlbar "enlarge" and in focus, but no history list is shown.

Have you hidden the top sites on your new-tab page? Bug 1616793 was just uplifted to beta and should be in the next beta build. With that fix, your top sites/history will be shown when you focus the urlbar.

Comment 65

[Will]

Please take a look at this one (apologies if this isn't the correct place to post it) https://bugzilla.mozilla.org/show_bug.cgi?id=1617333

Comment 66

[Will]

Another (apologies if this is a duplicate or has already been ruled out) https://bugzilla.mozilla.org/show_bug.cgi?id=1617408

Comment 67

[chrisfv]

(In reply to Drew Willcoxon :adw from comment #64)

(In reply to chrisfv from comment #63)

I simply cannot get this to work, clicking in URL bar shows urlbar "enlarge" and in focus, but no history list is shown.

Have you hidden the top sites on your new-tab page? Bug 1616793 was just uplifted to beta and should be in the next beta build. With that fix, your top sites/history will be shown when you focus the urlbar.

That is correct! wow, good to see it fixed.

Comment 68

[Son-Riab]

(In reply to Jens Mühlenhoff from comment #62)

(In reply to Marco Bonardo [:mak] from comment #61)

(In reply to Jens Mühlenhoff from comment #60)

2. It convers part of the bookmark toolbar, so I have to click somewhere else first to see my bookmark toolbar, which I find very annoying.

it should only cover a couple pixels, so the toolbar is usable, you shouldn't need to click elsewhere first. Isn't that the case?

That is the case, I don't technically have to click somewhere else first, but I instinctively do that.

After using the updated urlbar for some days now I experience the same behavior as descriped by Jens - I also instinctively click somewhere else or use the esc key before I perform any other actions.

And another point to consider: When a user (like me) don't have any icons on the left or right side of the urlbar and firefox is running in fullscreen mode some pixel of the urlbar is extended to an area that is not visible.

Comment 69

[Marco Bonardo [:mak]]

(In reply to Son-Riab from comment #68)

And another point to consider: When a user (like me) don't have any icons on the left or right side of the urlbar and firefox is running in fullscreen mode some pixel of the urlbar is extended to an area that is not visible.

I don't think that you can remove the back/forward buttons and the hamburger menu button from Customize? How do you end in such a situation of not having icons on sides of the urlbar?

Comment 70

[Son-Riab]

Attachment: Bildschirmfoto 2020-02-24 um 14.38.15.png

Actually it is possible to move the back/forward buttons.

Comment 71

[Marco Bonardo [:mak]]

Considered the requirements (move back/forward after the urlbar) it sounds like a low priority edge case, feel free to file it, but it won't be a blocker for the feature.

Comment 73

[Will]

Please take a look (sorry if this is not the right place to post this) https://bugzilla.mozilla.org/show_bug.cgi?id=1628051

Comment 74

[Kazumasa Hasegawa (Kazz)]

1627969 - Remove the megabar pref
Please, please revert this change.
It surprises users.

Comment 75

[Will]

Apologies if a duplicate, please take a look https://bugzilla.mozilla.org/show_bug.cgi?id=1629117

Comment 76

[Serhiy]

There were several questions trying to figure out what rationale is behind the expansion and they were ignored as far as I can see. Did I miss an explanation somewhere? I can't say I like or dislike the change yet, I was just trying to figure out what problem it was trying to solve and it seems quite hard if not impossible for now. Without an explanation it looks like an unnecessary "bells and whistles" so can anyone please explain?

Comment 77

[Marcin Raczkowski]

(In reply to Сергій from comment #76)

There were several questions trying to figure out what rationale is behind the expansion and they were ignored as far as I can see. Did I miss an explanation somewhere? I can't say I like or dislike the change yet, I was just trying to figure out what problem it was trying to solve and it seems quite hard if not impossible for now. Without an explanation it looks like an unnecessary "bells and whistles" so can anyone please explain?

The rationale I've found in one reddit post, was to pull attention of users towards the url bar & replace old code with a new one to help with maintanability.

I assume they have succeeded with both, because this monstrosity does pull focus, but I can't comment on a code.

Comment 78

[Elmo]

Thing is, when I click on the URL bar, it auto-dropdown. This is embarassing (in front of clients, as it lists what banks and other client sites I go to) and completely unnecessary. When I click on the URL bar, it should do NOTHING, instead now it completely expands, takes up half the screen. I cannot access my bookmarks toolbar. This is a horrible feature that should be able to switched off.

Comment 79

[stanglow]

I agree, this should be an optional feature. It also breaks usability: pressing escape does not cause it to lose focus which is the expected behavior. Even tabbing away gives inconsistent results in FF75 on LInux. I shouldn't have to use keystrokes and mouse clicks to suspend or return a GUI element to it's default state. This is an "enhancement" and as such should always be optional.

Comment 80

[Meinert]

Is there any way to disable this behavior (enlarge URL bar and expand to show history)? User defined CSS and an about:config options use to work but with the last version bump (79) it doesn't work anymore.

Comment 81

[Meinert]

Nevermind figured out what has changed and got things back to "pre-megabar" (thanks to userchrome.org)

browser.urlbar.suggest.topsites does what browser.urlbar.openViewOnFocus use to do for those that are looking for this information

Comment 82

[Marco Bonardo [:mak]]

(In reply to Meinert from comment #81)

browser.urlbar.suggest.topsites does what browser.urlbar.openViewOnFocus use to do for those that are looking for this information

No need for about:config, the pref is visually exposed in about:preferences#privacy under the Urlbar section.

Comment 83

[ST]

What is the reason or rational for the expanding address bar?

Comment 84

[Marco Bonardo [:mak]]

(In reply to ST from comment #83)

What is the reason or rational for the expanding address bar?

I'm not part of the UX team, so I will explain you what I gathered as a developer.
The team identified various problems through user research and experiments, that pointed out how many users are confused about the focused state of the urlbar, and the fact they can use it to search the Web, retrieve past information or even just solve immediate problems (My firefox is broken, how do I fix it?). The urlbar is one of the main access points of the browser, and as such it can largely improve the user experience. As a consequence more studies and experiments have been run to understand how to improve the situation. Of course it's hard to satisfy everyone when you have millions of users, and that's why the change has been delayed for months while testing it in Nightly and Beta to refine it, and even now we're still iterating over users feedback and trying to find a good compromise for everyone. Of course the feature set is not complete yet, a lot of very interesting new features will come and use the new design for good.

Comment 85

[Sven Grull]

I can understand the reasons for the change. I do not understand that there is no way to turn this behavior off. For my personal feeling expanding the address bar every time I want to enter an url is as much annoying as the ads that started popping up right moment you visited the site.
Probably this comment will also be hidden behind the advocacy label soon. This might be a way to handle such requests but it will not solve the problem that a lot of users will be disappointed how this change inflicts this visual obtrusion to them.

Comment 86

[Keul]

Why not add a checkbox in the personalize area to enable the old skin?
It's 50 lines of CSS (https://github.com/WesleyBranton/Remove-Firefox-Megabar),
there's absolutely 0 technical reason to not add this.

Comment 87

[Sören Hentzschel]

It's 50 lines of CSS […] there's absolutely 0 technical reason to not add this.

That's not true at all. You suggest to add an option for one interface change because only a few lines CSS are needed. But the next one want another UI customization, maybe even five lines less CSS. And suddenly there are requests for 3,000 customizations and this sums up. You should also remember that's not only about an one-time investment of resources. It needs an permanent comittment to consider every possible configuration on every frontend change.

Don't get me wrong. I'm not arguing for or against an option for this change. But your argument that it's only a few lines CSS and there is no reason not to do this does not work.

Comment 88

[Danny Colin [:sdk]]

I don't want to be rude but:

1. If you need help, you should use Mozilla Support or Mozilla Matrix. Bonus, I even created a #firefoxcss room dedicated to help users with their userchrome.css.
2. If you want to give feedback, please use the mailinglists. Bugzilla isn't the place for that and every time your posting in here, you're spamming more than 50 mailboxes.

Comment 89

[timorychert]

Please give us at least the option to keep the old compact design.
As a typographer I don't like the layout and feel of the new one at all, lots of ui elements are getting bigger and bigger and uglier and uglier over time. If you made this an option, then everybody could stay happy.

Comment 90

[Will]

Apologies if this isn't the correct place to post this but there's a favicon issue when Megabar is in dark theme, please take a look https://bugzilla.mozilla.org/show_bug.cgi?id=1647173

Comment 91

[Marco Bonardo [:mak]]

we don't need this project tracking bug anymore, we'll just track remaining bugs as usual.

Comment 92

[Sollace]

(In reply to Keul from comment #86)

Why not add a checkbox in the personalize area to enable the old skin?
It's 50 lines of CSS (https://github.com/WesleyBranton/Remove-Firefox-Megabar),
there's absolutely 0 technical reason to not add this.

Just wanted to thank you, and thanks to userchrome.org. I've gotten used to the megabar as a whole, but the growing is still somewhat annoying so I'm thankful for a way to get rid of it.