Closed Bug 1279425 Opened 4 years ago Closed 3 years ago

When browser.urlbar.unifiedcomplete is False, every first time typing something to location bar there is no drop down menu

Categories

(Firefox :: Address Bar, defect, P1, minor)

48 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 48
Tracking Status
firefox47 --- unaffected
firefox48 --- fixed
firefox49 --- unaffected

People

(Reporter: human.peng, Assigned: mak)

References

Details

(Whiteboard: [fxsearch])

Attachments

(2 files)

Attached image bug.png
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.33 Safari/537.36

Steps to reproduce:

1. New profile 
2. Visit https://en.wikipedia.org several times and also bookmark it
3. Set browser.urlbar.unifiedcomplete to False
4. Restart Firefox
5. Type "e" in the location bar


Actual results:

It should have a drop down menu.


Expected results:

It didn't (see attachment).

Note: I KNEW that `browser.urlbar.unifiedcomplete` is abandoned and has been removed in Nightly (or earlier). But this problem is about the existence of this parameter will BREAK something, not just has NO EFFECT, in certain version (current beta, aka 48). So if we didn't fix it and when 48 hit release, average users who still have this parameter set to false before (maybe due to addons, like Classic Theme Restorer) will be confused.

So please make sure you get my point before mark it as WONTFIX.
Blocks: 1223728
Severity: normal → minor
Component: Untriaged → Location Bar
Yes, that pref breaks the awesomebar, but we can't just uplift bug 1223728 since that makes lots of changes and it's not safe enough for a beta uplift. If we'd make the component ignore the pref, tests could break since some of them depend on that pref in FF 48.

I must think about it. Maybe we could still ignore the pref and make the tests set a private property instead. Or maybe I could just remove any test that fails when we ignore the pref, since regardless we don't care about the old implementation.

I'm taking this bug and will see what I can do. Regardless, it will be a beta-only patch.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [fxsearch]
Drew, this is not a real review request since it's just a part of the patch you already reviewed in bug 1223728. It's mostly to check things make sense.

This is intended as a Beta-only patch.
Attachment #8763085 - Flags: review?(adw) → review+
Comment on attachment 8763085 [details]
Bug 1279425 - Remove the unifiedcomplete pref.

Approval Request Comment
[Feature/regressing bug #]: urlbar redesign
[User impact if declined]: If the user disables unifiedcomplete by setting to false the browser.urlbar.unifiedcomplete pref, the awesomebar misbehaves. 
[Describe test coverage new/current, TreeHerder]: nightly, aurora and beta are all using unifiedcomplete by default.
[Risks and why]: This is an extract of the patch that landed in bug 1223728. Most of the changes are minor test changes, the remaning code changes only touch code that was handling the pref and is skipped when unifiedcomplete is enabled (default in 48). The patch itself is pretty simple (modulo the size due to the test changes) and the same removals are in Nightly and Aurora.
[String/UUID change made/needed]: none
Attachment #8763085 - Flags: approval-mozilla-beta?
Comment on attachment 8763085 [details]
Bug 1279425 - Remove the unifiedcomplete pref.

OK, let's do it to fix this issue.
Should be in 48 beta 3.
Attachment #8763085 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
We should verify this won't break anything else.
Flags: qe-verify+
There is nothing left to do here.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
I reproduced this bug using Fx 48.0b1 build (20160606200529) on Windows 10 x64.

I could not reproduce this bug using Fx49.0b4 build(20160627144420) on Windows 10 x64 because the pref "browser.urlbar.unifiedcomplete" is no longer available. 

I also tried by manually creating the pref and set it to false and the bug no longer reproduces.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.