Closed Bug 660882 Opened 9 years ago Closed 9 years ago

search window does not allow to open message from result list [currentHeaderData is not defined]

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
blocker

Tracking

(seamonkey2.2 fixed, seamonkey2.3 fixed)

RESOLVED FIXED
seamonkey2.4
Tracking Status
seamonkey2.2 --- fixed
seamonkey2.3 --- fixed

People

(Reporter: prof, Assigned: InvisibleSmiley)

References

Details

(Keywords: regression)

Attachments

(1 file)

When performing a search via the search window (Tools -> Search Messages) it's impossible to open a message by double-clicking or selcting it and hitting the open button.

The error-message in the error-console differs:

Double click:
Fehler: currentHeaderData is not defined
Quelldatei: chrome://messenger/content/mailWindowOverlay.js
Zeile: 546

Open button:
Fehler: An error occurred executing the cmd_open command: [Exception... "'[JavaScript Error: "currentHeaderData is not defined" {file: "chrome://messenger/content/mailWindowOverlay.js" line: 546}]' when calling method: [nsIController::doCommand]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: chrome://global/content/globalOverlay.js :: goDoCommand :: line 96"  data: yes]
Quelldatei: chrome://global/content/globalOverlay.js
Zeile: 100

Confirmed for SM2.1RC and SM2.2pre
Reproducible with IMAP, POP3 and Local Folders, but not with News & Blogs.

Hmm, currentHeaderData is defined in/filled by msgHdrViewOverlay.js which is included by msgHdrViewOverlay.xul, which is included by mailWindowOverlay.xul.

I smell a "single message window"-only breakage.

I just hope I didn't regress this through fixing bug 637835.
Summary: search window does not allow to open message from result list → search window does not allow to open message from result list [currentHeaderData is not defined]
The fact that it works (only) for feeds is that this breaks in function IsFeedItem (mailWindowOverlay.js) which returns early if the account is an RSS one.
Bah, last known good 2011-05-07, first bad 2011-05-08 -> probably bug 637835. :-(
Blocks: 637835
OK, so it really was bug 637835 that regressed this:

GetFirstSelectedMessage (msgMail3PaneWindow.js), called from IsFeedItem (mailWindowOverlay.js), used to return null (from the catch, because gDBView was null so gDBView.URIForFirstSelectedMessage could not be accessed) so the currentHeaderData check in IsFeedItem was never reached.

Since the renaming of gSearchView to gDBView in bug 637835, gDBView is now defined, so GetFirstSelectedMessage now returns gDBView.URIForFirstSelectedMessage and the rest of IsFeedItem is checked.

In short, the IsFeedItem code contains a non-obvious assumption that if there is gDBView, there is currentHeaderData. This is bad.

The patch I'll attach in a minute gets rid of that code and the assumption.
No longer blocks: 637835
Depends on: 637835
Assignee: nobody → jh
Status: NEW → ASSIGNED
Attachment #536403 - Flags: superreview?(neil)
Attachment #536403 - Flags: review?(mnyromyr)
Adding relnote keyword for now; if this doesn't make 2.1 final, then surely the first minor release (the patch applies against both comm-central and comm-2.0).
Keywords: relnote
Comment on attachment 536403 [details] [diff] [review]
patch [Checkin: comment 11]

>-           'content-base' in currentHeaderData));
Presumably this is a port of the relevant parts of bug 474701 (in particular I notice comments 154-156 cover this issue.)
Attachment #536403 - Flags: superreview?(neil) → superreview+
Comment on attachment 536403 [details] [diff] [review]
patch [Checkin: comment 11]

Karsten: ping for review (has sr=Neil)
Comment on attachment 536403 [details] [diff] [review]
patch [Checkin: comment 11]

>-  if (IsFeedItem() && GetFeedOpenHandler() == 2) {
>+  if (gFolderDisplay.selectedMessageIsFeed && GetFeedOpenHandler() == 2) {

Please fix the { position, while you're at it.
Attachment #536403 - Flags: review?(mnyromyr) → review+
Comment on attachment 536403 [details] [diff] [review]
patch [Checkin: comment 11]

This is a bad regression (included in 2.1 final) which we should fix for any affected branch that has the potential to ship after 2.1 final.

I take it that the uplift to comm-beta has not happened yet. If I'm wrong, please understand this as requesting permission to land on comm-beta, too.
Attachment #536403 - Flags: approval-seamonkey2.1?
Attachment #536403 - Flags: approval-comm-aurora?
Comment on attachment 536403 [details] [diff] [review]
patch [Checkin: comment 11]

http://hg.mozilla.org/comm-central/rev/aeae283c99ef
Attachment #536403 - Attachment description: patch → patch [Checkin: comment 11]
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment on attachment 536403 [details] [diff] [review]
patch [Checkin: comment 11]

We did uplift to comm-beta already.
Attachment #536403 - Flags: approval-seamonkey2.1?
Attachment #536403 - Flags: approval-seamonkey2.1-
Attachment #536403 - Flags: approval-comm-beta+
Attachment #536403 - Flags: approval-comm-aurora?
Attachment #536403 - Flags: approval-comm-aurora+
Duplicate of this bug: 663689
Duplicate of this bug: 665842
Is the "Target Milestone: seamonkey2.2" true? We have to wait all of the way for 2.2 to get this one fixed? Or could it be snuck into the first security fix for the 2.1 series?
(In reply to comment #16)
> Is the "Target Milestone: seamonkey2.2" true? We have to wait all of the way
> for 2.2 to get this one fixed? Or could it be snuck into the first security
> fix for the 2.1 series?

2.2 is the first security fix for 2.1 and is expected out in the next few weeks.
Duplicate of this bug: 669147
Duplicate of this bug: 669215
Duplicate of this bug: 669854
I just received 2.2 via UbuntuZilla this evening. Confirmed fixed with the official Linux build of 2.2. Thanks!
From: http://forums.mozillazine.org/viewtopic.php?p=11021099#p11021099

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++I have recently upgraded to SM 2.2. This bug is only PARTIALLY fixed. While it is now possible to open a particular message in the message search results by double clicking a given message, after ONE message window is opened, if ANOTHER message in the search results is double clicked WHILE the existing opened message window is STILL open, then the subsequent messages double clicked will FAIL to display in the already opened message window - the FIRST message will remain displayed, even though it's obvious that the opened message window refreshes. The only workaround at this moment in SM 2.2 is to always close the e-mail window opened on the message double clicked, then double click another e-mail. This is not the correct display action in a properly working SM mail client mail search window. I can't believe they did not check something as simple as this. If there's anyone that can re-update the status of this bug entry, it would be appreciated. Thank you.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
It's really true, that only one message can be opened/displayed during an extended search action.
(In reply to comment #22)
> From: http://forums.mozillazine.org/viewtopic.php?p=11021099#p11021099
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++I have
> recently upgraded to SM 2.2. This bug is only PARTIALLY fixed. While it is
> now possible to open a particular message in the message search results by
> double clicking a given message, after ONE message window is opened, if
> ANOTHER message in the search results is double clicked WHILE the existing
> opened message window is STILL open, then the subsequent messages double
> clicked will FAIL to display in the already opened message window - the
> FIRST message will remain displayed, even though it's obvious that the
> opened message window refreshes. The only workaround at this moment in SM
> 2.2 is to always close the e-mail window opened on the message double
> clicked, then double click another e-mail. This is not the correct display
> action in a properly working SM mail client mail search window. I can't
> believe they did not check something as simple as this. If there's anyone
> that can re-update the status of this bug entry, it would be appreciated.
> Thank you.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

There was another workaround: click on the button at the bottom "Open Message Folder" the chosen message is highlighted and can be opened.
The actual workaround is to set mailnews.reuse_message_window to false.
Blocks: 671605
Target Milestone: seamonkey2.2 → seamonkey2.4
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.