1312999 - Cache one-off buttons instead of regenerating them at every popupopen

Status: VERIFIED FIXED

(Firefox :: Search, defect, P1)

Description

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Now that the awesomebar uses one-off buttons, it would be better if we'd cache them. The search engines don't change so often and we should not pay the rebuild cost at every opening.

Comment 1

[Florian Quèze [:florian]]

Attachment: Patch

We need to rebuild this list of one-offs either when the search settings change, or when the width of the panel changes.

I haven't found any simple way to get the current panel's width without flushing (that's bug 1357054 anyway), but we can get the textbox size without flushing, and that's good enough to decide if we can skip rebuilding the one-offs.

While I was at it, I also did some small optimizations:
- avoid doing any DOM calls related to open search items when building the one-offs for the location bar panel
- avoid using the Preferences.jsm module (it was used to support unicode characters in engine names, we can now use getStringPref instead).

Comment 2

[Drew Willcoxon :adw]

Comment on attachment 8859166 [details] [diff] [review]
Patch

Review of attachment 8859166 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6187bdf62907
Cache one-off buttons instead of regenerating them at every popupopen, r=adw.

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6187bdf62907

Comment 5

[Florian Quèze [:florian]]

This bug affects the one-off buttons displayed at the bottom of the searchbar and awesomebar panels.

The display should be correctly updated:
- after changing search settings (hidding/showing one-off engines, changing the default, adding an engine...)
- after things that change the panel size (resizing the window, resizing the searchbar, showing/hiding some toolbar buttons).
- other stuff that may affect the textbox's appearance (changing theme?)

It may make sense to verify at the same time as bug 1104325.

Comment 6

[Adrian Florinescu [:aflorinescu]]

Marking as verified on : 57.0a1 20170905220108 && 55.0.3 20170824053622 on Windows 7, Windows 10, Ubuntu 16.04.

Regression & smoke testing covering the display of searchbar / awesomebar pannels:
- default search settings, adding/removing search engines;
- resizing panel size;
- changing resolution + drag and drop + resizing;
- OS high contrast themes + light/dark compact themes;

Didn't cover high DPI, as it was already verified in bug 1104325, but will a test to the pre-beta test suite, so we can make sure nothing has been missed.