Flip Unified Autocomplete pref once we merge to 34.

VERIFIED FIXED in mozilla34

Status

()

Toolkit
Places
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: mak, Assigned: mak)

Tracking

Trunk
mozilla34
Points:
1
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
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+
(Assignee)

Updated

3 years ago
Depends on: 995094
(Assignee)

Comment 1

3 years ago
Created attachment 8458270 [details] [diff] [review]
patch v1
Attachment #8458270 - Flags: review+

Updated

3 years ago
Status: NEW → ASSIGNED
Iteration: --- → 33.3
QA Whiteboard: [qa?]
(Assignee)

Comment 2

3 years ago
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+]

Updated

3 years ago
Iteration: 33.3 → 34.1
(Assignee)

Comment 3

3 years ago
https://hg.mozilla.org/integration/fx-team/rev/8bb77d17d0ee

see also http://blog.bonardo.net/2014/07/24/unified-complete-coming-to-firefox-34
Flags: in-testsuite+
Target Milestone: --- → mozilla34
https://hg.mozilla.org/mozilla-central/rev/8bb77d17d0ee
Status: ASSIGNED → RESOLVED
Last Resolved: 3 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

Updated

3 years ago
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)
(Assignee)

Comment 7

3 years ago
(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?
Depends on: 1045985
(Assignee)

Comment 9

3 years ago
(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!]

Updated

3 years ago
Depends on: 1047613

Updated

3 years ago
Depends on: 1047813

Updated

3 years ago
Depends on: 1054699

Updated

3 years ago
No longer depends on: 1054699
(Assignee)

Updated

3 years ago
No longer depends on: 1047613
You need to log in before you can comment on or make changes to this bug.