Closed Bug 1353831 Opened 7 years ago Closed 7 years ago

OneOff block in search bar doesn't update text if Customize was opened at least once

Categories

(Firefox :: Search, defect, P1)

51 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 55
Tracking Status
firefox-esr45 --- unaffected
firefox52 --- wontfix
firefox-esr52 --- wontfix
firefox53 --- wontfix
firefox54 --- verified
firefox55 --- verified

People

(Reporter: 684sigma, Assigned: adw)

References

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(2 files)

I have a problem with Firefox Beta 53. It also happens in Beta 52, Nightly 55. Doesn't happen in ESR 45
After changing anything in customize, one of text labels in search bar stops updating, and it's distracting.
Here's how to reproduce it:

1. Launch Firefox, type "ab" in search bar, wait until suggestions show up, type "c".
2. Open customize, move some button from the "Additional tools and features" to menu. Close customize
3. Type "xyz" in search bar

Result: OneOff block in suggestions displays "Search for abc with:"
Expected: It should display "Search for xyz with:"
Has STR: --- → yes
Keywords: regression
Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8a98cde343c2eee3ede571646cabf5178816530d&tochange=2e12de6eac1024c2f0520df206295ae89412bd7c

474f38fc48be	Drew Willcoxon — Bug 1180944 - Implement one-off searches from Awesomebar. r=mak,florian
Blocks: 1180944
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Ever confirmed: true
Version: 52 Branch → 51 Branch
Updated regression range (generated by mozregression-gui 0.9.6):
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=4e8b0579b51108c1d7c60bd1d70053136ec4521d&tochange=474f38fc48be9f97b49b084ebf0b59293b81cf16

Mozregression-gui 0.9.7 can't even test repository "fx-team", filed Bug 1354451.
Hi Drew, could you look into this? Seems like this is most likely fallout from your patch.
Flags: needinfo?(adw)
Priority: -- → P1
Whiteboard: [fxsearch]
Assignee: nobody → adw
Status: NEW → ASSIGNED
Flags: needinfo?(adw)
The problem is that the one-off's `textbox` property is reset and not set again after exiting customize mode.  The urlbar sets that property (and `popup`) in its constructor and doesn't have the problem.  That's what this patch does for the searchbar.
Comment on attachment 8856980 [details]
Bug 1353831 - OneOff block in search bar doesn't update text if Customize was opened at least once.

https://reviewboard.mozilla.org/r/128890/#review132484
Attachment #8856980 - Flags: review?(florian) → review+
Too late for 53, nice that we have a fix here though.
Whoops, thought I landed this.
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3742522c4533
OneOff block in search bar doesn't update text if Customize was opened at least once. r=florian
Backout by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/76b21e5cbafe
Backed out changeset 3742522c4533 for failing at least test_focus_autocomplete.xul in a11y suite on OSX 10.10 debug. r=backout
Comment on attachment 8856980 [details]
Bug 1353831 - OneOff block in search bar doesn't update text if Customize was opened at least once.

Clearing the review flag so that hopefully mozreview will let me push a new patch...
Attachment #8856980 - Flags: review+
Comment on attachment 8856980 [details]
Bug 1353831 - OneOff block in search bar doesn't update text if Customize was opened at least once.

Uh... setting the r+ again.
Attachment #8856980 - Flags: review+
Some accessibility tests create their own <searchbar> that doesn't use the normal searchbar popup, so they failed when the searchbar constructor ran and assumed that this.textbox.popup.oneOffButtons was defined.

I'll push this to try and then land again.
Try looks OK.
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/26a0e8b9f278
OneOff block in search bar doesn't update text if Customize was opened at least once. r=florian
https://hg.mozilla.org/mozilla-central/rev/26a0e8b9f278
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
This feels pretty edge-casey to me. Should we consider this for 54 uplift or let it ride the 55 train?
Flags: needinfo?(adw)
We should uplift it.
Flags: needinfo?(adw)
Attached patch Aurora 54 patchSplinter Review
Approval Request Comment
[Feature/Bug causing the regression]: One-off searches in the awesomebar, bug 1180944
[User impact if declined]: This bug
[Is this code covered by automated tests?]: This code is, but not this specific bug
[Has the fix been verified in Nightly?]: Not officially
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Small change, tested manually, feature is well covered by tests
[String changes made/needed]: None
Attachment #8858911 - Flags: approval-mozilla-aurora?
Comment on attachment 8858911 [details] [diff] [review]
Aurora 54 patch

Fix a regression. Aurora54+.
Attachment #8858911 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flags: qe-verify+
Reproduced the initial issue using Nightly 55.0a1 (Build ID: 20170412030252) on Windows 10 x64.

Verified as fixed using the latest Nightly 55.0a1 (Build ID: 20170418030220) on Windows 10 x64, Ubuntu 16.04 x64 and Mac OS X 10.12
Status: RESOLVED → VERIFIED
See Also: → 1357458
Verified as fixed using Firefox 54 beta 1 under Win 10 64-bit, Ubuntu 14.04 64-bit and Mac OS X 10.11.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: