Closed Bug 413836 Opened 17 years ago Closed 17 years ago

Opening and then closing a new window with urlbar focused breaks the urlbar

Categories

(Firefox :: Address Bar, defect, P2)

defect

Tracking

()

VERIFIED FIXED
Firefox 3

People

(Reporter: wesj, Assigned: Mardak)

References

Details

(Keywords: regression, Whiteboard: [fixes bug 426525])

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012304 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012304 Minefield/3.0b3pre After opening and closing a new window when the urlbar is focused, urlbar autocomplete doesn't work. Typing a URL and pressing enter won't load this site either. You have to enter a complete site name and hit the GO button. After that, the urlbar begins working like normal again. Reproducible: Always Steps to Reproduce: 1.Click on the urlbar to focus it 2.Open a new window, either by clicking the toolbar button, or through File->New Window 3.Close the new window 4.Begin typing in the urlbar of the original window Actual Results: No autocomplete is shown. Enter does nothing. Expected Results: Autocomplete results should show. Enter should load the site that you've typed. I don't know that this is a common set of actions, so I'm not sure how to rate the severity of this bug.
Confirmed, with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012407 Minefield/3.0b3pre
Status: UNCONFIRMED → NEW
Component: General → Location Bar and Autocomplete
Ever confirmed: true
Version: unspecified → Trunk
Flags: in-litmus?
Windows only? Can't reproduce on linux.
QA Contact: general → location.bar
Pretty severe, as it happens anytime you close one window and return to the next.
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
Could anyone (on Windows) test backing out those bugs?
(In reply to comment #4) > Pretty severe, as it happens anytime you close one window and return to the > next. > Just to be clear, it only happens if the URL bar is focused in the back window, when you close the new window. I don't know quite how to write that and have it make sense, but if I don't play with the url bar at all while I open and close a new window, everything is fine.
Assignee: nobody → gavin.sharp
Neither of those patches back out cleanly, I guess I could pull by date...
Status: NEW → ASSIGNED
Whiteboard: [swag ?]
Seeing on beta5rc2 on Mac 10.4 (ppc) but not on same build on Linux FC7
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #5) > Could anyone (on Windows) test backing out those bugs? I suggest using --fuzz=somenumber when trying to back out those patches. I don't have windows development machine so can't really test this :(
Attached patch v1 (obsolete) (deleted) — Splinter Review
Workaround for beta4: Click somewhere else and refocus the location bar.
Assignee: gavin.sharp → edilee
Attachment #312114 - Flags: review?(gavin.sharp)
Er.. right we're on beta 5 :p
gavin: So the problem comes from.. 1) opening a new window causes a new input to be attached to the controller 2) closing the window removes the attached input 3) the original window's input isn't attached anymore 4) refocusing the input fixes the problem because it reattaches the input
Whiteboard: [swag ?] → [has patch][need review gavin][fixes bug 424206]
Comment on attachment 312114 [details] [diff] [review] v1 r=me as a workaround, but can you file a bug on the core regression that broke this? I want to figure that out, even if it has to wait until Firefox 3 ships :/
Attachment #312114 - Flags: review?(gavin.sharp) → review+
Whiteboard: [has patch][need review gavin][fixes bug 424206] → [has patch]
Depends on: 426425
(In reply to comment #14) > can you file a bug on the core regression that broke this? Filed bug 426425. Checking in toolkit/content/widgets/autocomplete.xml; /cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v <-- autocomplete.xml new revision: 1.132; previous revision: 1.131 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: --- → Firefox 3
Verified. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre ID:2008040204 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre
Status: RESOLVED → VERIFIED
Potentially causing other problems like bug 426525 which apparently gets fixed when backing out v1.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Attached patch v2 (deleted) — Splinter Review
Back out v1 and fix search binding.
Attachment #312114 - Attachment is obsolete: true
Attachment #313779 - Flags: review?(gavin.sharp)
So this fixes the regression caused by bug 337178 which was in the indicated regression range.
Depends on: 337178
No longer depends on: 426425
Blocks: 337178
Status: REOPENED → ASSIGNED
No longer depends on: 337178
Whiteboard: [has patch][need review gavin]
Attachment #313779 - Flags: review?(gavin.sharp) → review+
Whiteboard: [has patch][need review gavin] → [has patch]
Checking in browser/components/search/content/search.xml; /cvsroot/mozilla/browser/components/search/content/search.xml,v <-- search.xml new revision: 1.124; previous revision: 1.123 done Checking in toolkit/content/widgets/autocomplete.xml; /cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v <-- autocomplete.xml new revision: 1.135; previous revision: 1.134 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Whiteboard: [has patch] → [fixes bug 426525]
Blocks: 426525
Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050104 Minefield/3.0pre ID:2008050104 and with the appropriate Windows build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: