Not having quicksearch on the toolbar breaks things

RESOLVED FIXED in Thunderbird 3.0a3

Status

defect
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: grizzly, Assigned: lionel)

Tracking

({regression})

Trunk
Thunderbird 3.0a3
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910030846 Shredder/3.0b1pre

Starting with the last two builds, Shredder won't open any Layout "views" if the search window is removed from the toolbar. I tried a new profile, same there as well. I noticed it when I updated Shredder and my view (wide view) showed a blank screen on the right half of the program. The new profile was OK until I removed the search window. When I replaced the search window in my regular profile, everything is fine when opened, as well as with the test profile.

Reproducible: Always

Steps to Reproduce:
1. Open Shredder without Search Window in the toolbar.
2.
3.
Actual Results:  
When opening, no layout views are present (blank screen to the right). Clicking on the Account Name in the folder pane and then clicking on Inbox in the folder pane brings the layout to normal. Closing Shredder and reopening reproduces the anomaly. Adding the Search Window to the toolbar alleviates the problem.

Expected Results:  
Shredder should open with Layout view(s) available.
Reporter

Comment 1

11 years ago
===Edit===

Expected Results:  
Shredder should open with Layout view(s) available ==with search window excluded from toolbar===
onSearchFolderTypeChanged() definitely needs some protection from not finding the quicksearch, probably by starting with |if (!GetSearchInput()) return;|. I think the keypress handlers in search.xml also need some protection from not finding quick-search-menupopup while customizing, though that was a little hard to tell since I wound up crashing while trying to put the quicksearch back on the toolbar and turned my profile to mush.
Blocks: 259914
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-thunderbird3+
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Thunderbird 3.0b1
Version: unspecified → Trunk
Assignee

Comment 3

11 years ago
If nobody beats me at it, I'll take a look at it this week-end.

(I didn't find how to assign a bug to myself; maybe I would need permissions bits enabled for it?)

Comment 4

11 years ago
(In reply to comment #3)
> (I didn't find how to assign a bug to myself; maybe I would need permissions
> bits enabled for it?)

Yes you do. I'll set assign to you
Assignee: nobody → lionel
Summary: Shredder Won't Open Layout Views → Not having quicksearch on the toolbar breaks things
Duplicate of this bug: 454975

Comment 6

11 years ago
I have the same issue. I also get in my error console this two errors:

Error: menuItems[0] is undefined
Source File: chrome://messenger/content/search.xml
Line: 99

Error: gSearchInput is null
Source File: chrome://messenger/content/searchBar.js
Line: 647

Does this have to do with this bug?
Assignee

Comment 7

11 years ago
(In reply to comment #6)
> I have the same issue. I also get in my error console this two errors:
> Error: menuItems[0] is undefined
> Source File: chrome://messenger/content/search.xml

> Error: gSearchInput is null
> Source File: chrome://messenger/content/searchBar.js

> Does this have to do with this bug?

The second error looks like it comes from the same bug, but the first one looks like it is a similar, but different bug.
Assignee

Comment 8

11 years ago
(In reply to comment #2)
> onSearchFolderTypeChanged() definitely needs some protection from not finding
> the quicksearch, probably by starting with |if (!GetSearchInput()) return;|.

Yes, done that and it fixes the bug.

> I think the keypress handlers in search.xml also need some protection from
> not finding quick-search-menupopup while customizing,

It seems to me that not, since if quick-search-menupopup does not exist, then these keypress handlers are never activated.
Assignee

Comment 9

11 years ago
(asking review from mkmelin+mozilla as philringnalda is AWOL)
Attachment #338512 - Flags: review?(mkmelin+mozilla)
Assignee

Updated

11 years ago
Status: NEW → ASSIGNED

Comment 10

11 years ago
(In reply to comment #9)
> Created an attachment (id=338512) [details]
> protect onSearchFolderTypeChanged() from not having a gSearchInput

I've tested your patch in my own build and it fixed the issue I've had in Bug 454975 and it avoid the second error message I brought up in comment 6.
Attachment #338512 - Flags: review?(mkmelin+mozilla) → review+
Comment on attachment 338512 [details] [diff] [review]
protect onSearchFolderTypeChanged() from not having a gSearchInput

Looks good, r=mkmelin

changeset: 328:80aa66c5e7d9
http://hg.mozilla.org/comm-central/rev/80aa66c5e7d9
I think the "menuItems[0] is undefined error" is an older issue, though it would be good to get that fixed too.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 13

11 years ago
(In reply to comment #12)
> I think the "menuItems[0] is undefined error" is an older issue, though it
> would be good to get that fixed too.

Because I couldn't find a bug for this in Bugzilla I opend Bug 455248 (with Steps to Reproduce)
You need to log in before you can comment on or make changes to this bug.