Open Bug 1561531 (megabar) Opened 11 months ago Updated 1 month ago

[meta] Quantumbar design update 1

Categories

(Firefox :: Address Bar, enhancement, P3)

enhancement

Tracking

()

Tracking Status
relnote-firefox --- 75+

People

(Reporter: dao, Unassigned)

References

(Depends on 22 open bugs, Blocks 1 open bug, )

Details

(Keywords: meta)

Attachments

(1 file)

Depends on: 1561533
Depends on: 1561534
No longer depends on: 1551598
Summary: Implement Quantumbar design update behind a pref → [meta] Implement Quantumbar design update behind a pref
Depends on: 1561894
Depends on: 1561901
Depends on: 1561904
Blocks: 1527257
No longer depends on: 1513337
Priority: -- → P3
Depends on: 1567406
Depends on: 1568947
Depends on: 1568956
Depends on: 1568959
Depends on: 1569392
Depends on: 1569478
Depends on: 1569180
Depends on: 1573581
Depends on: 1575010
Depends on: 1575235
Depends on: 1575360
Depends on: 1575563
Depends on: 1575645
No longer blocks: 1527257
Depends on: 1575650
Depends on: 1575651
Depends on: 1575426
Depends on: 1576447
Depends on: 1576657
Depends on: 1577000
Alias: megabar
Depends on: 1577472
Depends on: 1577541
Depends on: 1577742
Depends on: 1577752
Depends on: 1577923
Depends on: 1577924
Depends on: 1577930
Depends on: 1578291
Depends on: 1579002
Depends on: 1579003
Depends on: 1579004
Depends on: 1579063
No longer depends on: 1579063
Depends on: 1579087
Depends on: 1579515
Depends on: 1580248
No longer depends on: 1577924
Depends on: 1580538
Depends on: 1577181
No longer depends on: 1577930
Depends on: 1580822
Depends on: 1580792
Depends on: 1580791
Depends on: 1578715
Depends on: 1581096
Depends on: 1581174
Depends on: 1581627
Depends on: 1581630
Depends on: 1581377
Depends on: 1581763
Depends on: 1581753
Depends on: 1582375
Depends on: 1582396
No longer depends on: 1580791
Depends on: 1583283
Depends on: 1583148
Depends on: 1577740
Depends on: 1583535
Depends on: 1583855
Depends on: 1583993
Depends on: 1584167
Depends on: 1584253
Depends on: 1584270
Depends on: 1584272
Depends on: 1584273
Depends on: 1584278
Depends on: 1584281
Depends on: 1584336
Depends on: 1584350
Depends on: 1584354
Depends on: 1584355
Depends on: 1584507
No longer depends on: 1584281
No longer depends on: 1584354
Depends on: 1584354
No longer depends on: 1584354
Depends on: 1584938
No longer depends on: 1584350
Blocks: 1584161
Depends on: 1584347
No longer depends on: 1584347
Depends on: 1585458
Depends on: 1585755
Depends on: 1584281
Depends on: 1584101
Depends on: 1585847

(In reply to Nathan V from comment #1)

but it looks like trash on the latest nightly

Thank you for your valuable feedback.

(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?

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

(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.

Depends on: 1585919

(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.

Depends on: 1585933

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,

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

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.

The bookmarks problem is covered by bug 1561904.

Depends on: 1585994

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.

(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.

(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.

Depends on: 1585980

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).

Depends on: 1586024
Depends on: 1586026
Depends on: 1586032
Depends on: 1586052

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.

Depends on: 1586054
Duplicate of this bug: 1586064
Depends on: 1586112
Blocks: 1586134
No longer blocks: 1586134
Depends on: 1586134

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.

Depends on: 1586204
No longer depends on: 1586032
Depends on: 1585991
Depends on: 1586209
Depends on: 1586222
No longer depends on: 1586209
Depends on: 1586254

-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)

Depends on: 1586275
No longer depends on: 1586275
Depends on: 1586284

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.

Depends on: 1586287
Depends on: 1586332
Depends on: 1586351
Depends on: 1586386
Depends on: 1586388
Depends on: 1586392
Depends on: 1586395
Depends on: 1586408
Depends on: 1586514
Depends on: 1586523
Depends on: 1586530
Depends on: 1586531
No longer depends on: 1586530
No longer depends on: 1586531
Depends on: 1586520

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.

Depends on: 1586542
Depends on: 1586564
Depends on: 1584350
No longer depends on: 1586388
No longer depends on: 1586395
No longer depends on: 1586564
Depends on: 1583708
Depends on: 1586525
Depends on: 1586595
Depends on: 1585954
Depends on: 1586778
Depends on: 1586799
Depends on: 1587027
Depends on: 1586889
Depends on: 1587119
Depends on: 1587135
Depends on: 1587185

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.

Depends on: 1587478
No longer depends on: 1587478
Summary: [meta] Implement Quantumbar design update behind a pref → [meta] Quantumbar design update behind a
Summary: [meta] Quantumbar design update behind a → [meta] Quantumbar design update
Depends on: 1587680
Depends on: 1587800

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?)

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.

Depends on: 1587915

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.

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.

(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:.

Duplicate of this bug: 1588724
Depends on: 1588724
No longer depends on: 1588724
Depends on: 1588724
No longer depends on: 1588724
Depends on: 1588798
No longer depends on: 1588798
Depends on: 1586457
No longer depends on: 1586457
Depends on: gigabar
Depends on: 1589620
No longer depends on: 1586386
Depends on: 1589826
Depends on: 1589836
Depends on: 1589923
Depends on: 1589998
No longer depends on: 1586222
Depends on: 1590374
No longer depends on: 1586134
Depends on: 1590491
Depends on: 1590024
Depends on: 1590732
Depends on: 1590759
Depends on: 1591012
Depends on: 1591035
No longer depends on: 1591035
Depends on: 1591043
Depends on: 1591242
Depends on: 1590617
Depends on: 1591486

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.

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.

Depends on: 1591548
Depends on: 1591509
Depends on: 1591767
Depends on: 1591768
Depends on: 1591772

(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.

(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).

Depends on: 1591848
Depends on: 1591882

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 ;)

Depends on: 1592126
No longer depends on: 1591772

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 !

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.

Depends on: 1592903
Depends on: 1592268
Blocks: 1593215
Depends on: 1593659
Depends on: 1593661
Depends on: 1593663
Depends on: 1593664
Depends on: 1593665
Depends on: 1592918
Depends on: 1593249
Depends on: 1593825
Depends on: 1593959
Depends on: 1593964
Depends on: 1593965

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

(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 👍

Depends on: 1588780
Depends on: 1594062
Depends on: 1591246
Depends on: 1593701
Depends on: 1596357
Depends on: 1597221
Depends on: 1597222
Depends on: 1597223
Depends on: 1597698
Depends on: 1598345
Blocks: 1597181
Depends on: 1598563
Depends on: 1593886
Depends on: 1599123
Depends on: 1599784
Depends on: 1599785
Depends on: 1599792
Depends on: 1601052
Blocks: 1601052
No longer depends on: 1601052
Summary: [meta] Quantumbar design update → [meta] Quantumbar design update 1
Depends on: 1601315
Depends on: 1601320
Depends on: 1601325
Depends on: 1601330
Depends on: 1601334
Depends on: 1601339
Blocks: 1601362
No longer blocks: 1601362
Depends on: 1601362

(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.

(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.

(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.

(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.

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.

(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.

Flags: needinfo?(jan)
Flags: needinfo?(jan)
Depends on: 1601450

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.

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.

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

Flags: needinfo?(sollacea)

(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

Flags: needinfo?(sollacea)
Depends on: 1601664
Depends on: 1601647
Depends on: 1601750
Depends on: 1601885
Depends on: 1601922

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?

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.

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.

No longer depends on: 1601750
Duplicate of this bug: 1602304
Blocks: 1602303
Depends on: 1602812
No longer depends on: 1590374
No longer depends on: 1591768
No longer depends on: 1591767
No longer depends on: 1593701
No longer depends on: 1591848
No longer depends on: 1591509
No longer depends on: 1591246
No longer depends on: 1589836
No longer depends on: 1590617
Depends on: 1603678
Depends on: 1603778
Depends on: 1603780
Depends on: 1603848
No longer blocks: 1601052
Depends on: 1601052
No longer depends on: 1603848
No longer depends on: 1590732
Depends on: 1604932
No longer depends on: 1604788
Depends on: 1605161
Depends on: 1605889
Depends on: 1605936
Depends on: 1605958
Depends on: 1606069
Depends on: 1606809
Depends on: 1606920
Depends on: 1606928
Depends on: 1606930
Depends on: 1606081
Depends on: 1606904
Depends on: 1606912
Depends on: 1608169
Depends on: 1608170
Depends on: 1608359
Depends on: 1606076
Depends on: 1608418
Depends on: 1608766
No longer depends on: 1606076
Depends on: 1608631
Duplicate of this bug: 1607381
Depends on: 1560348
Blocks: 1609778
No longer depends on: 1608170

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?

No longer blocks: 1609778
Depends on: 1610037
Depends on: 1610685
Depends on: 1611271
Depends on: 1401835
Depends on: 1611929
Depends on: 1611930
Depends on: 1611462
Depends on: 1610932
No longer depends on: 1610932
Depends on: 1612304
Depends on: 1612317
Depends on: 1612509
Depends on: 1612794
Depends on: 1613044
Depends on: 1613264
Blocks: 1287419
Depends on: 1613339
Depends on: 1613699
Depends on: 1613869
Depends on: 1614238
No longer depends on: 1601320
No longer depends on: 1593664
No longer depends on: 1601339
No longer depends on: 1604789
Depends on: 1615222
No longer depends on: 1615222
No longer depends on: 1610037
No longer depends on: 1608418
No longer depends on: 1589998

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.

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

  1. 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?

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

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

  1. 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.

No longer depends on: 1587119
Depends on: 1616793
Depends on: 1616820
No longer depends on: 1611929
Depends on: 1616862
Depends on: 1616872
Depends on: 1616880
Depends on: 1617028
Depends on: 1617029
Depends on: 1617101

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.

(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.

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

Depends on: 1617333
Depends on: 1617345

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

(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.

(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)

  1. 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.

(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?

Flags: needinfo?(son+mozilla)

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

Flags: needinfo?(son+mozilla)

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.

Depends on: 1617603
Depends on: 1617631
Depends on: 1617408
Depends on: 1617696
Depends on: 1615767
Depends on: 1618115
Depends on: 1618250
Depends on: 1618588
Depends on: 1618721
Depends on: 1618878
No longer depends on: 1597223
Depends on: 1619537
Depends on: 1619547
No longer depends on: 1613339
Depends on: 1620231
Depends on: 1620410
Depends on: 1620434
Depends on: 1621608
Depends on: 1621189
Depends on: 1623666
Depends on: 1623944
No longer blocks: 1597181
No longer blocks: 1602303
Depends on: 1625241
Depends on: 1625254
Depends on: 1626741
Depends on: 1627499
Depends on: 1627672
Depends on: 1627861
Depends on: 1627858
Depends on: 1627969
Depends on: 1627988
Depends on: 1627989

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

Depends on: 1628243
Depends on: 1628024
Depends on: 1627923
Depends on: 1628025
Depends on: 1627378
Blocks: 712602
Blocks: 1389594
Blocks: 1376911
Blocks: 1244420
Depends on: 1628557
Depends on: 1628392
Depends on: 1628601
Depends on: 1628731
Depends on: 1628997
Depends on: 1628948

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

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?

Depends on: 1629303
Depends on: 1629379
Depends on: 1629387
No longer depends on: 1627378
Depends on: 1629639
Depends on: 1629122
Depends on: 1628655
Depends on: 1629919
Depends on: 1629924
Depends on: 1629137
No longer depends on: 1629919
Depends on: 1629980
No longer depends on: 1627499
No longer depends on: 1627858
No longer depends on: 1628025
No longer depends on: 1628243
No longer depends on: 1628601
No longer depends on: 1623666
Depends on: 1630275
No longer depends on: 1627989
No longer depends on: 1628557
No longer depends on: 1628948
No longer depends on: 1629303
No longer depends on: 1626741
No longer depends on: 1620231