Closed Bug 1040335 Opened 10 years ago Closed 10 years ago

Flip Unified Autocomplete pref once we merge to 34.

Categories

(Toolkit :: Places, defect)

defect
Not set
normal
Points:
1

Tracking

()

VERIFIED FIXED
mozilla34
Iteration:
34.1

People

(Reporter: mak, Assigned: mak)

References

Details

Attachments

(1 file)

We should do this after the merge, so we have full Nightly coverage. I should also blog post before flipping the pref, to briefly explain what to expect. I'll keep the r=ttaubert from bug 995092 on the patch to flip the pref.
Flags: firefox-backlog+
Depends on: 995094
Attached patch patch v1 (deleted) — Splinter Review
Attachment #8458270 - Flags: review+
Status: NEW → ASSIGNED
Iteration: --- → 33.3
QA Whiteboard: [qa?]
this is QA+ for the same reasons bug 995092 was. Should go into the next iteration, since we can't land this until tuesday.
QA Whiteboard: [qa?] → [qa+]
Iteration: 33.3 → 34.1
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Hi Florin, can a QA contact be assigned for verification of this bug.
Flags: needinfo?(florin.mezei)
Flags: needinfo?(florin.mezei)
QA Contact: andrei.vaida
Depends on: 1043923
Confirmed that the 'browser.urlbar.unifiedcomplete' pref is set to true on Nightly 34.0a1 (2014-07-27). Marco, is there anything else I should be looking at for this specific bug?
Flags: needinfo?(mak77)
(In reply to Andrei Vaida, QA [:avaida] from comment #6) > Marco, is there anything else I should be looking at for this specific bug? I think the idea was to have some basic smoketesting of the urlbar autocompletion to ensure there's nothing really "broken"
Flags: needinfo?(mak77)
(In reply to Marco Bonardo [:mak] from comment #7) > I think the idea was to have some basic smoketesting of the urlbar > autocompletion to ensure there's nothing really "broken" Right, I thought there was a separate bug requiring that. I ran a few tests around the Location Bar's autocomplete feature: general URL autocompletion, switch-to-tab and autocomplete history, targeting the general behavior of both regular and private windows. Tests performed on Nightly 34.0a1 (2014-07-29), using Windows 7 64-bit, Mac OS X 10.9.4 and Ubuntu 13.04 64-bit. There were no issues encountered, but I was wondering about the following behavior: switching from a (blank) new tab page to a different tab where a website is opened, closes that new tab page post-switch. This might be intended as it's the same all the way back to Firefox 4.0, but I thought I should mention it. What do you think?
(In reply to Andrei Vaida, QA [:avaida] from comment #8) > (In reply to Marco Bonardo [:mak] from comment #7) > > I think the idea was to have some basic smoketesting of the urlbar > > autocompletion to ensure there's nothing really "broken" > Right, I thought there was a separate bug requiring that. > > I ran a few tests around the Location Bar's autocomplete feature: general > URL autocompletion, switch-to-tab and autocomplete history, targeting the > general behavior of both regular and private windows. Tests performed on > Nightly 34.0a1 (2014-07-29), using Windows 7 64-bit, Mac OS X 10.9.4 and > Ubuntu 13.04 64-bit. > > There were no issues encountered, but I was wondering about the following > behavior: switching from a (blank) new tab page to a different tab where a > website is opened, closes that new tab page post-switch. This might be > intended as it's the same all the way back to Firefox 4.0, but I thought I > should mention it. Yes, that's an intended feature to not leave empty tabs around. I think this can be considered verified. Thank you.
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+] → [qa!]
Depends on: 1047613
Depends on: 1047813
Depends on: 1054699
No longer depends on: 1054699
No longer depends on: 1047613
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: