Closed Bug 403854 Opened 14 years ago Closed 14 years ago

Removing searchbar or location bar breaks many things

Categories

(Firefox :: Search, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 3 beta2

People

(Reporter: syskin2, Assigned: Gavin)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111404 Firefox/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111404 Minefield/3.0b2pre

If you use Customize dialog and remove searchbar, a number of things don't work:
a) no Undo Close Tab
b) can't Bookmark All Tabs
c) session restore fails
d) probably more?

Reproducible: Always

Steps to Reproduce:
1. Use Customize dialog to remove searchbar
2. Restart Minefield
3. Open some tabs, attempt to bookemark them (bookmarks -> Bookmark All Tabs). Close some tabs, attempt to unclose them. Try Session Restore
Actual Results:  
Menu items greyed out or missing; session restore silently fails. No errors in Error Console.


Expected Results:  
All this works :)


This started happening on the previews nightly, I think.
This is a regression from bug 400327.
Blocks: 400327
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → Firefox 3 M10
Version: unspecified → Trunk
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #288794 - Flags: review?(mano)
Flags: blocking-firefox3?
Summary: Removing Searchbar breaks many things → Removing searchbar or location bar breaks many things
See also Bug 403743
Duplicate of this bug: 403743
Also fails:

- Starring (When you Star a page, the state of the Star button does not immediately change... the changed state shows only once you switch a tab and come back)
Flags: blocking-firefox3? → blocking-firefox3+
Attachment #288794 - Flags: review?(mano) → review+
I have a question.
If I open 'customize toolbar' windows, then remove search bar, then close 'customize toolbar' window, then reopen 'customize toolber' window and click 'Restore Default Set' , and then close 'customize toolbar',  the dropdown history in location bar is now broken.

There's a error in error console:

Error: uncaught exception: [Exception... "Component does not have requested interface arg 0 [nsIAutoCompleteController.input]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: attachController :: line 267"  data: no]

Is this the same bug or should I file a new one?
(In reply to comment #6)
> Is this the same bug or should I file a new one?

Looks like a different bug, please file and CC me?
Neil Rashbrook pointed out on IRC that with my patch we could compare two nulls accidentally and end up failing to remove the splitter. I'll post a reworked patch.
Keywords: checkin-needed
Attached patch different patchSplinter Review
Attachment #288794 - Attachment is obsolete: true
Attachment #289117 - Flags: review?(mano)
See also Bug 403365 (which as of this comment also has blocking+)
Duplicate of this bug: 404216
Is this ready for a checkin?  Should it be marked as checkin-needed?
(In reply to comment #13)
> Is this ready for a checkin?
Yes, it is.

> Should it be marked as checkin-needed?
No, Gavin will check it in himself. checkin-needed is only for people who don't have CVS access or who do have CVS access but don't have time to check-in the patch.
or people who need to remember they have patches to check in.
Keywords: checkin-needed
(In reply to comment #15)
> or people who need to remember they have patches to check in.

Not really. That's not why the keyword was created, and using it that way just confuses people who deal with checkin-needed. If somebody with commit access adds the keyword to a bug, does he/she mean "adding this so I won't forget to check it in" or "adding this because I don't have time to check it in myself"?
mozilla/browser/base/content/browser.js 	1.893 
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Duplicate of this bug: 404295
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120405 Minefield/3.0b2pre and the steps to reproduce from comment #0

-> Verified fixed 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.