First Awesomebar popup population in a session looks bad

NEW
Unassigned

Status

()

Firefox
Address Bar
P3
normal
2 years ago
a year ago

People

(Reporter: Elbart, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Unspecified
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxsearch])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8741778 [details]
abysmalbar first time.mp4

See attachment, slowed down to 0.5 realtime.

It's also showing that the popup shows the results of a previous query for a fraction of a second before showing the results of the new query.
This also happens across tabs.
(Reporter)

Updated

2 years ago
Blocks: 1262507

Updated

2 years ago
Component: Theme → Location Bar
Thanks for filing this bug.
The way we populate the popup is indeed a little bit exotic to avoid size flicker (popup shrinking and growing quickly). This is mostly about the second issue, when you see results of the previous query for a little while. Maybe we could try to hide/unhide the items so we start with a clean state.

The worse thing here seems to be the black square at the beginning though, that sounds more like a graphic glitch than a ui problem.
We could investigate a workaround and eventually ask Graphics team for help.

Both are not affecting the functionality though, and were likely also present in the previous style, so I'd go for a P3 for now. If these are unique to the new style and not happening before, please let us know and we can re-evaluate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [fxsearch]
(Reporter)

Comment 2

2 years ago
(In reply to Marco Bonardo [::mak] from comment #1)
> Thanks for filing this bug.
> The way we populate the popup is indeed a little bit exotic to avoid size
> flicker (popup shrinking and growing quickly). This is mostly about the
> second issue, when you see results of the previous query for a little while.
> Maybe we could try to hide/unhide the items so we start with a clean state.

There's also an issue when you go from a query with only one or two results to one with 10+, there's a scrollbar displayed on the right side of the results-popup for a few frames.

> The worse thing here seems to be the black square at the beginning though,
> that sounds more like a graphic glitch than a ui problem.
> We could investigate a workaround and eventually ask Graphics team for help.

The black area isn't always happening.
What's a bit irritating is that you can see how the popup is being populated one line at a time.
This doesn't happen after the first time, and the animations are smooth.

> Both are not affecting the functionality though, and were likely also
> present in the previous style, so I'd go for a P3 for now. If these are
> unique to the new style and not happening before, please let us know and we
> can re-evaluate.

This wasn't happening before, no. Though, I could only test this in aurora, as there's no toggle in Nightly to go back to the previous awesomebar-design.
(In reply to Elbart from comment #2)
> There's also an issue when you go from a query with only one or two results
> to one with 10+, there's a scrollbar displayed on the right side of the
> results-popup for a few frames.

I think I've seen another report about this in the last days, so it's very likely a dupe.

> > Both are not affecting the functionality though, and were likely also
> > present in the previous style, so I'd go for a P3 for now. If these are
> > unique to the new style and not happening before, please let us know and we
> > can re-evaluate.
> 
> This wasn't happening before, no. Though, I could only test this in aurora,
> as there's no toggle in Nightly to go back to the previous awesomebar-design.

Yes, aurora is a good comparison.
Priority: P3 → P2

Comment 4

2 years ago
(In reply to Marco Bonardo [::mak] from comment #1)
> The worse thing here seems to be the black square at the beginning though,
> that sounds more like a graphic glitch than a ui problem.
> We could investigate a workaround and eventually ask Graphics team for help.
That is normal behavior of menus and similar XUL elements. They just create a black area, and then
it somehow is filled with content. Sometimes the black area stays if this process isn't synchronised.
It's a long-standing bug that was reported several times without reliable STR. You can check it by setting borders and border-radiuses == 10px on urlbar autocomplete. Or just see bug 1251978.

Comment 5

2 years ago
(In reply to Elbart from comment #2)
> There's also an issue when you go from a query with only one or two results to one with 10+,
> there's a scrollbar displayed on the right side of the results-popup for a few frames.
Bug 1264988, as said in comment 3. Was presented forever, but now it's more actual than before.

(In reply to Elbart from comment #0)
> It's also showing that the popup shows the results of a previous query for a
> fraction of a second before showing the results of the new query.
This is still happening for me on DE 45 and on Nightly 47 (according to mozregression gui).
Probably it became more noticeable, but the fact is it's a long-standing bug (with no plan to fix it yet?). It may depend on how many items you have in history & bookmarks & tabs.
Anyway, I hope Marco will reveal the bug number for fixing such "exotic" population, if there's one.

@ Elbart (reporter):
Could you please provide a criteria to check when it was broken? Out of bugs mentioned here the only possible "new" thing may only be "bad popup population". What is that exactly?

By the way, how came that this bug w/o even "actual result vs expected result" gained P2 without even checking, while bug 1240217 is P3? This is "not breaking anything"; 1240217 is. HOW.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.