Closed Bug 1801297 Opened 2 years ago Closed 2 years ago

Better align urlbar result menu button styling with the UX spec

Categories

(Firefox :: Address Bar, task, P2)

task
Points:
2

Tracking

()

VERIFIED FIXED
111 Branch
Tracking Status
firefox111 --- verified
firefox112 --- verified

People

(Reporter: dao, Assigned: dao)

References

(Blocks 1 open bug)

Details

(Whiteboard: [snt-urlbar-result-menu] )

Attachments

(1 file)

From https://phabricator.services.mozilla.com/D161776:

There's some notable visual differences between the implementation compared to the design.

jteow, would you mind listing what differences you saw? Just want to make sure we don't miss any of that. Doesn't need to be a comprehensive list.

Flags: needinfo?(jteow)

No problem, here are some differences I saw:

  • While highlighted, the meatball button should visually appear within a result rather to the right of. If it's too problematic to implement it like the design, it might be worth mentioning to Ryan since it's a noticeable change.
  • Assuming the meatball menu button visually appears within a highlighted result:
    • When the result row is highlighted, the background of the button should change to match the design.
    • On hover and active, the button background and meatball color should match the design.
    • On focus, the button should have a border and the meatball color should have a different color.
      • Additionally, the urlbar result it is associated with should remain highlighted.
  • The button itself should be a circle rather than a rounded rectangle.
  • While a row that could contain a meatball menu button is not highlighted, the meatball button should not appear.
Flags: needinfo?(jteow)
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Points: --- → 2
Blocks: 1810647
Attachment #9312665 - Attachment description: WIP: Bug 1801297 - Better align urlbar result menu button styling with the UX spec. → Bug 1801297 - Better align urlbar result menu button styling with the UX spec.
Attachment #9312665 - Attachment description: Bug 1801297 - Better align urlbar result menu button styling with the UX spec. → Bug 1801297 - Better align urlbar result menu button styling with the UX spec. r=jteow
Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4b53f5a10a76 Better align urlbar result menu button styling with the UX spec. r=jteow
Flags: needinfo?(dao+bmo)
Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/95efc81f5d0d Better align urlbar result menu button styling with the UX spec. r=jteow
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch
Duplicate of this bug: 1811338
Regressions: 1811497
Regressions: 1811507

Can we back this out and figure out a better approach? It's interfering with our ability to iterate on the weather suggestion. I didn't file a bug for this but it also removed the border radius on all dynamic results on hover and selection: onboarding tab to search, calculator, and unit converter.

I think you'll need to take some ideas from https://phabricator.services.mozilla.com/D163630 to avoid problems like the border radius and hover gap between rows. It's kind of hard to get right for all the different types of rows we now have, when accounting for buttons, rows with row/group labels, dynamic results, etc.

If you do end up making a new patch, could you flag me for review please? I have a lot of experience with this recently.

Flags: needinfo?(dao+bmo)
Regressions: 1811623
Regressions: 1811620

Dao, what are you thoughts about backing out and tweaking this? I should've caught the impact to the dynamic types.

One thought I had was to combine Drew's solution of making the urlbarView-row-inner selectable by also moving the constructions of button step to inside of row-inner so that they are encapsulated when inner is selected. However, I might be missing a key reason why buttons remained separate from inner in the first place.

I'm not sure about the full extent of things being broken... I'm not too worried about the selection gap, and I'm currently unable to see weather results, so I may need some help with that. I believe the calculator and unit converter are disabled by default? Unless there's a desire to enable them in the next week or so, those are probably not a reason to back this out immediately (but certainly fix in a followup). I'm not sure about the status of tab-to-search onboarding either. I suppose that might be something we already ship? So perhaps that's reason enough to back out.

(In reply to James Teow [:jteow] from comment #9)

Dao, what are you thoughts about backing out and tweaking this? I should've caught the impact to the dynamic types.

One thought I had was to combine Drew's solution of making the urlbarView-row-inner selectable by also moving the constructions of button step to inside of row-inner so that they are encapsulated when inner is selected. However, I might be missing a key reason why buttons remained separate from inner in the first place.

I think the reason is mainly the a11y tree hierarchy at this point, although I believe a11y focus would work with nested elements too. I'm not sure to what extent buttons being adjacent to urlbarView-row-inner is baked into various code and tests, but from what I understand putting buttons in urlbarView-row-inner also seems to go against what Drew was suggesting in https://phabricator.services.mozilla.com/D163630#5382438?

Flags: needinfo?(jteow)
Flags: needinfo?(dao+bmo)
Flags: needinfo?(adw)
Blocks: 1811870
No longer blocks: 1810647

Replying to comment 10

I'm currently unable to see weather results, so I may need some help with that.

For the weather suggestion, I have a fix for it already. But I abandoned it because Drew was suggesting we back out your patch instead.
This should fix the weather suggestion on selection and hover:

https://phabricator.services.mozilla.com/D167453

Good call on that Dao, I should've better parsed that comment.

On the topic of potentially backing the patch out, I was under the impression based on Drew’s comment that the direction wasn’t satisfactory, so I was looking to see how to mesh his architectural changes with the existing work.

My POV is if we can spot fix the errors, we should go ahead, but I'm willing to acknowledge my understanding of the long term implications on UrlbarView is not as sophisticated as either you and Drew.

Flags: needinfo?(jteow)
Flags: needinfo?(adw)
Regressions: 1812840

Confirming this issue as verified fixed on 112.0a1(20230223094032) and 111.0b4(20230221190142) using Windows 11, macOS 13 and Ubuntu22.

Status: RESOLVED → VERIFIED
Regressions: 1822320
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: