Closed Bug 424251 Opened 17 years ago Closed 17 years ago

pageproxystate set to valid when selecting an autocomplete result

Categories

(Firefox :: Address Bar, defect, P2)

defect

Tracking

()

VERIFIED FIXED
Firefox 3

People

(Reporter: zeniko, Assigned: dao)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

Steps to Reproduce: 1. Enable browser.urlbar.autoFill 2. Start entering h t t ... Actual result: As soon as a URL is auto-filled, the current page's favicon is displayed again (opposed to the faded out page indicating non-validated user input). Expected result: Don't display any favicon until you hit Go/Enter or Esc (and if a favicon was to be displayed, it should be the one which is also displayed for the auto-filled suggestion, not the currently visible page's).
This regressed between the 2008031204 and the 2008031303 builds -> bug 419656.
Blocks: 419656
Keywords: regression
Attached patch minimal fix (obsolete) (deleted) — Splinter Review
This minimal change would fix it...
Yup, bug 419656 was the one that added aMustUseURI and uses it.
OS: Windows XP → All
Hardware: PC → All
Comment on attachment 310883 [details] [diff] [review] minimal fix Is this the right fix, then?
Attachment #310883 - Flags: review?(edilee)
Comment on attachment 310883 [details] [diff] [review] minimal fix >+++ browser/base/content/browser.js >@@ -1991,17 +1991,18 @@ function URLBarSetURI(aURI, aMustUseURI) >- state = "valid"; >+ if (!aMustUseURI) >+ state = "valid"; That would fix the issue. Perhaps comment why it shouldn't be valid when forced but is okay when not forced. Potentially someone would want the forced uri to be valid? gavin? Should we check instead.. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/browser.js&rev=1.1008&mark=1953,1957,1999#1953 - if (!value || aMustUseURI) { + if (!value || aMustUseURI != null) treating aMustUseURI as a tri-state null(undefined), true, false?
Attachment #310883 - Flags: review?(gavin.sharp)
Attachment #310883 - Flags: review?(edilee)
Attachment #310883 - Flags: review+
Attached patch v1 (obsolete) (deleted) — Splinter Review
Here's a version if we want to allow the forced uri to cause a valid proxy state.
Attachment #311002 - Flags: review?(gavin.sharp)
Hrm, I'm kind of regretting using URLBarSetURI for bug 419656. I was worried about inconsistencies between the various ways we unescape URIs, but maybe misusing URLBarSetURI for setting the value for non-loads is worse.
(In reply to comment #0) You don't need autofill for this. Just arrow through the list. (In reply to comment #7) > I was worried about inconsistencies between the various ways we unescape URIs That could be solved by letting a helper function do the unescaping.
Flags: blocking-firefox3?
Summary: current page's favicon displayed when letting an address starting with a protocol auto-fill → pageproxystate set to valid when selecting an autocomplete result
Attached patch use a helper function (deleted) — Splinter Review
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #311121 - Flags: review?(gavin.sharp)
Attachment #311002 - Attachment is obsolete: true
Attachment #311002 - Flags: review?(gavin.sharp)
Attachment #310883 - Attachment is obsolete: true
Attachment #310883 - Flags: review?(gavin.sharp)
Comment on attachment 311121 [details] [diff] [review] use a helper function Yeah this is better, thanks!
Attachment #311121 - Flags: review?(gavin.sharp) → review+
Attachment #311121 - Flags: approval1.9?
Not a blocker, autofill is a hidden pref that is unsupported.
Flags: blocking-firefox3? → blocking-firefox3-
(In reply to comment #11) > Not a blocker, autofill is a hidden pref that is unsupported. see comment 8: > You don't need autofill for this. Just arrow through the list.
Flags: blocking-firefox3- → blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
Target Milestone: --- → Firefox 3
Attachment #311121 - Flags: approval1.9?
Keywords: checkin-needed
Checking in browser/base/content/browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.1013; previous revision: 1.1012 done Checking in browser/base/content/urlbarBindings.xml; /cvsroot/mozilla/browser/base/content/urlbarBindings.xml,v <-- urlbarBindings.xml new revision: 1.58; previous revision: 1.57 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
edited test cases https://litmus.mozilla.org/manage_testcases.cgi?testcase_id=8858 to include this expected behavior.
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: