BUILD: 2009-09-17 Shredder build STEPS TO REPRODUCE: 1) Select some mail folder. 2) Click on the little arrow at the left edge of the search bar (the one in the top-right hand corner of the mailnews window). 3) Select "Subject or From filter" 4) Context-click (right-click, or ctrl-click on Mac) on the currently selected folder. 5) Select "Open" 6) In the new window, look at the text in the search bar 7) In the new window, click on the little arrow as in step 2 EXPECTED RESULTS: After step 6, the search bar says "Subject or From filter". After step 7, the selected option in the dropdown is "Subject or From filter". ACTUAL RESULTS: After step 6, the search bar says "Search everywhere". After step 7, the selected option in the dropdown is "Search everywhere".

Confirmed. Note that this also requires step 0: configure in Settings/Advanced/Reading Display -> Open messages in a new window

I don't have that set, in fact. Mine's set to open in a new tab. Note that the "open" I'm selecting in step 5 is for the _folder_ (in the folder pane), not for any message in that folder.

Ah, both good points. The root cause is the same -- the search widget picks up as a default the current view when creating a new tab, but for new windows, it picks up the global default.

This is actually fairly messy, as it deals w/ persistence across 3-pane windows, which is broken for this feature, for sure, but likely for others as well. I've spent a couple of hours on it w/ no successful outcome so far. Things to note whenever someone gets to this: The key decision point is openFirstTab in tabmail.xml, which somehow needs to know for first-tabs-in-new-3pane windows, what searchmode it should be using. I've been poking at the idea that it should look at the current search mode of the topmost 3-pane window, and have a patch that kinda does that, but it fails randomly because the tab persistence code seems to somehow get involved, probably because we don't have session-restore, we just have "restoring N tabs for 1 3-pane window". I suspect we'll have to live w/ this for 3.0.

One aside: I was actually surprised when "Open" on the context menu in the folder pane actually opened in a new window. I'm actually thinking that there's a bug there which is that Open should use the preference of tabs vs. windows, not always open a window. That would diminish the incidence of this bug, although obviously not solve it for people who want the multi-window behavior.

Sid0 mentioned that he'd be up for working on some blockers starting on Thurs Oct 15 or so. I'm hoping this would be a good choice...

Can reproduce STR in comment #0 with the same result of Boris. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091018 Lightning/1.0pre Shredder/3.0pre ID:20091018031417 Changed OS related

This seems to work.

I've tried to tread lightly to avoid the stuff we've had to fix previously with removed search bars. Please r- if this needs more tests.

Comment on attachment 410658 [details] [diff] [review] patch, v1 looks good, sid, and certainly better than what we have now.

http://hg.mozilla.org/comm-central/rev/be02a29bf00d http://hg.mozilla.org/releases/comm-1.9.1/rev/2d005532a15d

Turns out getZOrderDOMWindowEnumerator doesn't work on Linux (bug 156333), so I've switched to getEnumerator instead. I don't think it matters too much, because the case where a new 3pane window is opened and the opener isn't an old one doesn't happen too often. http://hg.mozilla.org/comm-central/rev/266904e7f07f http://hg.mozilla.org/releases/comm-1.9.1/rev/a85e8dd72aa1